[Bug 1190567] New: vmlinuz is no longer present on /boot/ breaking separate boot partitions
http://bugzilla.opensuse.org/show_bug.cgi?id=1190567 Bug ID: 1190567 Summary: vmlinuz is no longer present on /boot/ breaking separate boot partitions Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: dcermak@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- The kernel packaging in Tumbleweed changed "recently" (at some point in the last months): vmlinuz is no longer on /boot/ but is now in /usr/lib/modules. I guess that this has been introduced as part of the usrmerge effort. However, this breaks images build by kiwi that use a separate boot partition, as now all these symlinks are dead when booting from that separate partition. This leads to booting issues like: Loading Linux 5.14.1-1-default ... error: ../../grub-core/fs/fshelp.c:257:file `/vmlinuz-5.14.1-1-default' not found. Loading initial ramdisk ... error: ../../grub-core/loader/i386/linux.c:1053:you need to load the kernel first. Example disk image: - https://build.opensuse.org/package/show/Virtualization:Appliances:Images:Tes... - https://build.opensuse.org/package/show/Virtualization:Appliances:Images:Tes... -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1190567 http://bugzilla.opensuse.org/show_bug.cgi?id=1190567#c1 --- Comment #1 from Ludwig Nussel <lnussel@suse.com> --- The kernel package specifically does a copy when /boot is on a separate partition. I guess kiwi copies the result of installing into a single volume over a tree that has mountpoints. In that case it has to replace the symlinks with copies itself. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1190567 http://bugzilla.opensuse.org/show_bug.cgi?id=1190567#c2 --- Comment #2 from Ludwig Nussel <lnussel@suse.com> --- Alternatively is it possible for kiwi to pass down eg some env var so the %post script can trigger on it to do cp instead of ln -s? -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1190567 http://bugzilla.opensuse.org/show_bug.cgi?id=1190567#c3 --- Comment #3 from Marcus Schaefer <ms@suse.com> --- so you are saying the kernel package includes post processing code that checks if boot is on a different location and depending on that condition at install time it does something. First question why ? And second this breaks if the installation of the kernel package is not done on the running system In an image builder you create the root filesystem first, that's where the kernel gets installed and at that point you don't know anything about the later target. This is were the kernel package post processing design fails From the created root tree an image is build and one configuration can be, create me the image with an extra boot partition. With the new kernel layout the image builder would need to check this condition and moves kernel files such that it works again. kiwi can do this but it actually should not be one of its responsibilities and it feels wrong.
I guess kiwi copies the result of installing...
nope kiwi does nothing with the kernel. With this change we get somehow forced to fixup the broken systems which is really a step back So this is not only about kiwi, this causes issues to anybody who installs the kernel outside of the target and deploy to target later. Is there an opportunity to recall the kernel post such that we can at least recall on target such that the code you have becomes effective ? Thanks -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1190567 http://bugzilla.opensuse.org/show_bug.cgi?id=1190567#c4 --- Comment #4 from Ludwig Nussel <lnussel@suse.com> --- (In reply to Marcus Schaefer from comment #3)
First question why ?
The OS moves to /usr and /usr only. Those symlinks are only created for compatibility until the tooling around bootloaders is adopted.
So this is not only about kiwi, this causes issues to anybody who installs the kernel outside of the target and deploy to target later.
Only if a separate /boot is used which is not the default setup as it doesn't work well with snapshots. Anyway any image builder needs to take special precautions for getting an image to boot. Means calling scripts to copy eg grub to the right location and creating a suitable initrd. The kernel is part of the boot process so now becomes another aspect to consider.
Is there an opportunity to recall the kernel post such that we can at least recall on target such that the code you have becomes effective ?
So far not but could be done easily if there's need for it (ie looping over /usr/lib/modules/*/vmlinuz). How does kiwi install the bootloader? Calling into perl-Bootloader? Might be possible to add code there too. -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1190567 http://bugzilla.opensuse.org/show_bug.cgi?id=1190567#c5 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.wilck@suse.com --- Comment #5 from Michal Suchanek <msuchanek@suse.com> --- This is not exactly new. You can have an EFI boot partition on the target system, and if you do an image on a system without one then you don't have any content to copy there. By making an image on some system and copying it to a different system you *can* break things. You could also call it backwards that you make an image on a system that has one partition layout and expect it to work with different partition layout. Like you could make an image on btrfs that has snapper configured and then you deploy it on xfs and suddenly the snapper services fail. We actually do have a kernel post script that you can call now but I am not sure we want to make it a stable enough public API that anyone can use https://github.com/openSUSE/suse-module-tools/blob/master/kernel-scriptlets/... -- You are receiving this mail because: You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1190567 http://bugzilla.opensuse.org/show_bug.cgi?id=1190567#c6 --- Comment #6 from Michal Suchanek <msuchanek@suse.com> --- but you don't really need to know. this code extracts the kernel scriptlets: https://github.com/openSUSE/kernel-source/blob/packaging/rpm/kernel-subpacka... There is some query format to get the interpreter for the script (hopefully, it's not like documentation for rpm exists). Then you can run the script (preinst, postinst, posttrans) with the interpreter, and pass it the rpm argument which should be 1 if you have 1 kernel in the image. The scripts are very clever and skip some processing when they detect the kernel is being just reinstalled but I think the part you are interested in is not optimized this way. -- You are receiving this mail because: You are the assignee for the bug.
participants (1)
-
bugzilla_noreply＠suse.com