From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 96F8F619F5 for ; Thu, 10 Feb 2022 11:58:37 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 86B4F1BD96 for ; Thu, 10 Feb 2022 11:58:07 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 714D81BD8D for ; Thu, 10 Feb 2022 11:58:06 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 49B4446B08 for ; Thu, 10 Feb 2022 11:58:06 +0100 (CET) Date: Thu, 10 Feb 2022 11:57:58 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox VE development discussion References: <20220204184538.3139247-1-s.ivanov@proxmox.com> In-Reply-To: <<20220204184538.3139247-1-s.ivanov@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.15.0 (https://github.com/astroidmail/astroid) Message-Id: <1644490514.p27tcbmg79.astroid@nora.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.196 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pve-devel] [PATCH pve-kernel-meta/proxmox-ve v2] proxmox-boot: add kernel pinning functionality (#3761) X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2022 10:58:37 -0000 On February 4, 2022 7:45 pm, Stoiko Ivanov wrote: > changes v1->v2: > * incorporated the feedback on the v1 (by Aaron and Fabian - huge thx!): > ** a next-boot pin is now handled independently from a pin - i.e. if you > both pin a kernel and set one for the next-boot - the system afterward= s > keeps the pinned version (instead of the latest) > ** change from modifying /etc/default/grub to creating a snippet in > /etc/default/grub.d/proxmox-boot-pin.cfg - I did not see a need for ha= ving > two pinning files there (since they get written both at each relevant > invocation anyways - thus also no need for prefixing with y_ and z_ > ** the semantics of unpin changed (it now takes an optional argument to > remove the next-boot-pin only (made the cleanup-service cleaner) > ** added a check to the apthook in proxmox-ve as Fabian suggested > * changed the semantics of get_first_line - to check for file existence > itself, since it makes using it shorter at almost all call-sites > * fixed two perlcritic warnings in the pve apthook (which is quite > independent of the series) >=20 > again tested on 3 VMs (ext4, zfs+uefi, zfs+legacy) - but would be gratefu= l > if you find some use-case apart from - pin permanent, pin next-boot, rebo= ot, > reboot. some small things noted as replies to patches (might warrant a v3 - so=20 I'll wait for your replies ;)), and the following proxmox-ve followups=20 as discussed off-list: diff --git a/debian/apthook/pve-apt-hook b/debian/apthook/pve-apt-hook index 6de56c4..ff9877e 100755 --- a/debian/apthook/pve-apt-hook +++ b/debian/apthook/pve-apt-hook @@ -15,12 +15,12 @@ my $log =3D sub { print "W: ($hook_name) $line"; }; =20 -if (!defined $fd || $fd =3D=3D 0) { +if (!defined $fd || $fd =3D=3D 0 || $fd !~ /^\d+$/) { $log->("APT_HOOK_INFO_FD not correctly defined, skipping apt-pve-hook ch= ecks\n"); exit 0; } =20 -open(my $fh, q{<&=3D}, "${fd}") or die "E: could not open APT_HOOK_INFO_FD= (${fd}) - $!\n"; +open(my $fh, "<&=3D", $fd) or die "E: could not open APT_HOOK_INFO_FD (${f= d}) - $!\n"; =20 my $cleanup =3D sub { my ($rc, $confirm) =3D @_; @@ -99,8 +99,8 @@ while (my $line =3D <$fh>) { if ($action eq '**REMOVE**') { my $next_boot_ver =3D $file_read_firstline->("/etc/kernel/next-boot-= pin"); my $pinned_ver =3D $file_read_firstline->("/etc/kernel/proxmox-boot-= pin"); - my $remove_pinned_ver =3D ($next_boot_ver && $pkg =3D~ /$next_boot_v= er/); - $remove_pinned_ver ||=3D ($pinned_ver && $pkg =3D~ /$pinned_ver/); + my $remove_pinned_ver =3D ($next_boot_ver && $pkg =3D~ /${next_boot_= ver}$/); + $remove_pinned_ver ||=3D ($pinned_ver && $pkg =3D~ /${pinned_ver}$/)= ; if ($remove_pinned_ver) { $log->("!! WARNING !!\n"); $log->("You are attempting to remove the currently pinned kernel '= ${pkg}'!\n"); >=20 >=20 > original cover letter of v1: > The following series adds: > * proxmox-boot-tool kernel pin (to permanently set the > default entry of the respective bootloader) > * proxmox-boot-tool kernel unpin (to undo a previous pin) > * proxmox-boot-tool kernel next-boot (to do a pin+touch a file, which cau= ses > an unpin on next boot) >=20 > This is the first functionality which is available for 'regular grub-setu= ps' > (i.e. systems setup with lvm-thin with our ISO or systems installed on to= p > of plain debian) as well. >=20 > The first two patches are cleanup+refactoring (and should not change any > functionality) >=20 > The choices (those I think might benefit from a bit of feedback) for this > implementation were: > * for grub - automaticially rewrite '/etc/default/grub' (as this is where > I'd look to check whether some default is set) > * for systemd - set the entry in the loader.conf and not in the efivars > (`bootctl set-default/set-once`) - mostly from my bias towards config > files instead of UEFI vars (depending on implementation quality of the > UEFI) - another reason was to keep the implementation close for both > boot-loaders > * for p-b-t booted systems the need to run `p-b-t refresh` manually > afterwards (following the behavior of `p-b-t kernel add/remove`) could > be changed to invoking the refresh directly (as with non-p-b-t booted > systems). Especially since it might make sense to 'add' multiple kernel= s > and then do the mount+copy+configupdate only once, whereas you can only > pin on version anyways >=20 > Tested on three VMs installed from the 7.1 ISO (UEFI+ZFS, legacy+ZFS, > UEFI+lvm-thin). >=20 >=20 > proxmox-kernel-meta: > Stoiko Ivanov (4): > proxmox-boot: return empty if file does not exist in get_first_line > proxmox-boot: fix #3671 add pin/unpin for kernel-version > proxmox-boot: add kernel next-boot command > proxmox-boot: add pin/unpin functionality for non-p-b-t systems >=20 > bin/proxmox-boot-tool | 76 ++++++++++++++++++++++- > debian/pve-kernel-helper.install | 1 + > debian/rules | 3 + > proxmox-boot/Makefile | 4 ++ > proxmox-boot/functions | 45 ++++++++++++++ > proxmox-boot/proxmox-boot-cleanup.service | 13 ++++ > proxmox-boot/zz-proxmox-boot | 8 +++ > 7 files changed, 147 insertions(+), 3 deletions(-) > create mode 100644 proxmox-boot/proxmox-boot-cleanup.service >=20 > proxmox-ve: > Stoiko Ivanov (2): > apt-hook: fix perlcritic warnings > apt-hook: add check preventing the removal of pinned kernels >=20 > debian/apthook/pve-apt-hook | 34 ++++++++++++++++++++++++++++++++-- > 1 file changed, 32 insertions(+), 2 deletions(-) >=20 > --=20 > 2.30.2 >=20 >=20 >=20 > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel >=20 >=20 >=20