[factory] no vmlinuz-<version> on /boot filesystem
Something seems very wrong with the following: /boot # ls -agG *13.13* lrwxrwxrwx 1 47 Sep 1 18:35 System.map-5.13.13-1-default -> ../usr/lib/modules/5.13.13-1-default/System.map -rw------- 1 13231620 Sep 1 18:36 initrd-5.13.13-1-default lrwxrwxrwx 1 48 Sep 1 18:35 sysctl.conf-5.13.13-1-default -> ../usr/lib/modules/5.13.13-1-default/sysctl.conf lrwxrwxrwx 1 44 Sep 1 18:35 vmlinuz-5.13.13-1-default -> ../usr/lib/modules/5.13.13-1-default/vmlinuz /usr/lib/modules/ seems like a bizarre place for the kernel to live. Is this absence of a kernel on /boot supposed to work when /boot is a separate partition with EXTx filesystem from /? I have multiple installations on RAID where /boot is a separate filesystem from /. None are UEFI or GPT. Before I put this kernel on them, I'd like to know. Is there a config option somewhere that can be configured to put a real vmlinuz-<version> physically back into the /boot filesystem automatically at kernel installation time? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 02.09.2021 05:53, Felix Miata wrote:
Something seems very wrong with the following:
No, it is not. ------------------------------------------------------------------- Thu Jun 17 13:31:32 CEST 2021 - ludwig.nussel@suse.de - UsrMerge the kernel (boo#1184804) - Move files in /boot to modules dir The file names in /boot are included as %ghost links. The %post script creates symlinks for the kernel, sysctl.conf and System.map in /boot for compatibility. Some tools require adjustments before we can drop those links. If boot is a separate partition, a copy is used instead of a link. The logic for /boot/vmlinuz and /boot/initrd doesn't change with this patch. - Use /usr/lib/modules as module dir when usermerge is active in the target distro. - commit 6f5ed04 ------------------------------------------------------------------- And this was discussed extensively on this list which you are supposed to be following if you are using factory.
/boot # ls -agG *13.13* lrwxrwxrwx 1 47 Sep 1 18:35 System.map-5.13.13-1-default -> ../usr/lib/modules/5.13.13-1-default/System.map -rw------- 1 13231620 Sep 1 18:36 initrd-5.13.13-1-default lrwxrwxrwx 1 48 Sep 1 18:35 sysctl.conf-5.13.13-1-default -> ../usr/lib/modules/5.13.13-1-default/sysctl.conf lrwxrwxrwx 1 44 Sep 1 18:35 vmlinuz-5.13.13-1-default -> ../usr/lib/modules/5.13.13-1-default/vmlinuz
/usr/lib/modules/ seems like a bizarre place for the kernel to live.
Why is it more bizarre than any other random directory in root filesystem like /boot?
Is this absence of a kernel on /boot supposed to work when /boot is a
separate partition with EXTx filesystem
What about testing it and creating bug report if it does not work?
from /? I have multiple installations on RAID where /boot is a separate filesystem from /. None are UEFI or GPT. Before I put this kernel on them, I'd like to know.
Is there a config option somewhere that can be configured to put a real vmlinuz-<version> physically back into the /boot filesystem automatically at kernel installation time?
Andrei Borzenkov composed on 2021-09-02 08:29 (UTC+0300):
Felix Miata wrote:
And this was discussed extensively on this list which you are supposed to be following if you are using factory.
Everyone doesn't have the memory you have. I read some of it at the time, maybe even a lot. All I remember about it now is it happened. I was very surprised when the kernel became a live part of UsrMerge 3 months later, right /before/ a move from 5.13 to 5.14.
/usr/lib/modules/ seems like a bizarre place for the kernel to live.
Why is it more bizarre than any other random directory in root filesystem like /boot?
Because it's the heart of the system, not a mere module buried deep in the /usr numbers jungle.
Is this absence of a kernel on /boot supposed to work when /boot is a
separate partition with EXTx filesystem
What about testing it and creating bug report if it does not work?
In due time.
from /? I have multiple installations on RAID where /boot is a separate filesystem from /. None are UEFI or GPT. Before I put this kernel on them, I'd like to know.
Is there a config option somewhere that can be configured to put a real vmlinuz-<version> physically back into the /boot filesystem automatically at kernel installation time?
And the most important question is ignored. Not having kernel living in /boot, whether /boot is separate filesystem or not, will royally screw the most used part of my backup systems. Not having it there all but guarantees I'll want to be upgrading TW kernels little more often than as the kernel branches, which isn't actually all that much less often than I do now. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Thu, 2021-09-02 at 08:29 +0300, Andrei Borzenkov wrote:
And this was discussed extensively on this list which you are supposed to be following if you are using factory.
The /usr merge in general was discussed extensively, but the move of the kernel much less so. The kernel part of usrmerge has been reverted and un-reverted multiple times before the change actually hit tumbleweed on Aug. 24. This change went in very quietly actually, it wasn't even mentioned in Dominique's "New Tumbleweed snapshot" email, probably because the version number didn't change, only the release (5.13.12-1.2 -> 5.13.12-2.1). Arguably, this would have been a topic for the review of the week. After all, we have been looking for the kernel under /boot for 3 decades :-) And while following this list is certainly recommended for factory users, it's not a strict requirement. If reading every "snapshot" email from top to bottom was a requirement, I'd have to stop using TW, and many others as well I suppose. Recalling an almost 3-months-old changelog entry for the kernel is not something you'd expect from a user. Regards Martin
participants (3)
-
Andrei Borzenkov -
Felix Miata -
Martin Wilck