public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: "Peter Müller" <peter.mueller@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] Core Update 168: Hard-code kernel version to 5.15.35
Date: Thu, 12 May 2022 19:33:59 +0000	[thread overview]
Message-ID: <3154bd2f-76b2-16dc-90cb-823e18495a3e@ipfire.org> (raw)
In-Reply-To: <3FDE9848-6782-4CBF-934A-B158C4C3EBF1@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3342 bytes --]

Hello Jon,

thanks for your reply.

Usually, I do push fixes to Core Updates straight into "next". However, I do not have
permission to push into "master" (Michael or Arne need to do this for me), and as soon
as a patch lands there _and_ the nightly builds ran successfully, it is available to
the "testing" channel of upcoming Core Updates.

However, I do not feel sufficiently confident with this patch, which is why I sent it
to the mailing list, and wait for feedback on it before amending.

On a general notice: Any IPFire installation that ran Core Update 167 from the "stable"
channel before (and has been rebooted at least once ever since) can, to my knowledge,
update to Core Update 168 without all the hiccups Adolf and Rob observed. (Please do
let me know if this is wrong.)

Therefore, you do not necessarily have to wait for this patch to land in "master",
presumed your systems ran on Core Update 167 from the "stable" channel before.

Thanks, and best regards,
Peter Müller


> Peter,
> 
> How do I tell when this makes it into the CU 168 testing build?  (The one that Pakfire will pickup & install)
> 
> I will can test this on the Raspberry Pi RPi4B and on the FriendlyArm R2S
> 
> 
> Jon
> 
> 
>> On May 12, 2022, at 12:41 PM, Peter Müller <peter.mueller(a)ipfire.org> wrote:
>>
>> On systems that have previously running on testing, kernel 5.15.32 might
>> still be installed. dracut being called with ${KVER} will then build an
>> inital ramdisk for the wrong kernel, as 5.15.32 might still be running,
>> albeit 5.15.35 has been installed due to the Pakfire procedure when
>> upgrading on testing.
>>
>> Due to lack of hardware, this patch is untested on ARM.
>>
>> https://lists.ipfire.org/pipermail/development/2022-May/013433.html
>>
>> Reported-by: Stefan Schantl <stefan.schantl(a)ipfire.org>
>> Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org>
>> ---
>> config/rootfiles/core/168/update.sh | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/config/rootfiles/core/168/update.sh b/config/rootfiles/core/168/update.sh
>> index d21f648dd..7cc8800b2 100644
>> --- a/config/rootfiles/core/168/update.sh
>> +++ b/config/rootfiles/core/168/update.sh
>> @@ -107,14 +107,14 @@ chmod -v 750 /etc/sudoers.d
>> chmod -v 640 /etc/sudoers.d/*
>>
>> # Rebuild initial ramdisk to apply microcode updates
>> -dracut --regenerate-all --force
>> +dracut --kver="5.15.35-ipfire" --regenerate-all --force
>> case "$(uname -m)" in
>>          armv*)
>> -                mkimage -A arm -T ramdisk -C lzma -d /boot/initramfs-${KVER}-ipfire.img /boot/uInit-${KVER}-ipfire
>> -                rm /boot/initramfs-${KVER}-ipfire.img
>> +                mkimage -A arm -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire
>> +                rm /boot/initramfs-5.15.35-ipfire.img
>>                  ;;
>>          aarch64)
>> -                mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-${KVER}-ipfire.img /boot/uInit-${KVER}-ipfire
>> +                mkimage -A arm64 -T ramdisk -C lzma -d /boot/initramfs-5.15.35-ipfire.img /boot/uInit-5.15.35-ipfire
>>                  # dont remove initramfs because grub need this to boot.
>>                  ;;
>> esac
>> -- 
>> 2.35.3
> 

  reply	other threads:[~2022-05-12 19:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-12 17:41 Peter Müller
2022-05-12 18:10 ` Jon Murphy
2022-05-12 19:33   ` Peter Müller [this message]
2022-05-12 19:53     ` Adolf Belka
2022-05-12 20:00       ` Peter Müller
2022-05-12 20:11         ` Adolf Belka
2022-05-13 10:11 ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3154bd2f-76b2-16dc-90cb-823e18495a3e@ipfire.org \
    --to=peter.mueller@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox