Hi, One of the motivations for UsrMerge is to have all read-only parts of the operating system in /usr. The kernel packages install files in /boot though which isn't in line with that idea. Looking at Fedora they install files like vmlinuz that used to be named /boot/$name-$kver as (/usr)/lib/modules/$kver/$name instead. They include /boot/$name-$kver as %ghost. Since all necessary information is passed to /usr/lib/bootloader/bootloader_entry in %post, that script could create links or copies in /boot if needed. Does anyone have a better idea or can we just follow Fedora's approach here? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Am Mon, 12 Apr 2021 10:46:48 +0200
schrieb Ludwig Nussel
Does anyone have a better idea or can we just follow Fedora's approach here?
Since the reasons for "/boot" are obsolete since more than a decade, just go ahead. Just make sure to provide the equivalent of "/boot/vmlinuz" and "/boot/initrd", a pointer to the last installed kernel. This can very well be stored somewhere in "/usr". Olaf
I must disagree about /boot being obsolete: last time I checked grub2 still wasn't able to boot from MD RAID10, so I have to create a small RAID1 /boot to be able to boot.... Should I say that all of my servers use RAID10? Srdačan pozdrav / Best regards / Freundliche Grüße / Cordialement / よろしくお願いします Siniša Bandin On 4/12/21 10:59 AM, Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: Does anyone have a better idea or can we just follow Fedora's approach here? Since the reasons for "/boot" are obsolete since more than a decade, just go ahead.
Just make sure to provide the equivalent of "/boot/vmlinuz" and "/boot/initrd", a pointer to the last installed kernel. This can very well be stored somewhere in "/usr".
Olaf
On 12/04/2021 10.59, Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: Does anyone have a better idea or can we just follow Fedora's approach here?
Since the reasons for "/boot" are obsolete since more than a decade, just go ahead.
I'm not sure this is true. Raid, LVM, encrypted system... all those may need a /boot partition. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Me neither. Having a separate /boot partition makes complex deploys almost fool-proof. I feel safe being able to isolate /boot from the rest of the system. Obviously, not for a desktop, but for servers at least . regards ariel El 12/4/21 a las 8:29, Carlos E. R. escribió:
On 12/04/2021 10.59, Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: Does anyone have a better idea or can we just follow Fedora's approach here?
Since the reasons for "/boot" are obsolete since more than a decade, just go ahead.
I'm not sure this is true.
Raid, LVM, encrypted system... all those may need a /boot partition.
On 2021/04/12 01:59, Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: Does anyone have a better idea or can we just follow Fedora's approach here?
Since the reasons for "/boot" are obsolete since more than a decade, just go ahead.
--- The reasons for boot are obsolete? Since more than a decade ago? What were the reasons for boot being separate? As opposed to being a partition on "/" root along with /sbin/modprobe and /lib/modules? How does Windows boot supporting all the different hardware it does without a ramdisk, and why does linux need one? Window's Rescue Disk, these days, is usually a file (a WIM image) that is booted from the disk as well. Why are all the hw-specific modules and utils read from disk, into ram, then booted as another block device in memory? Why not just read the needed modules off disk and directly boot? Maybe a rescue disk might be a separately bootable image, but these days, in Windows, it is read out of a file.
On 12/04/2021 23.37, L A Walsh wrote:
On 2021/04/12 01:59, Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: Does anyone have a better idea or can we just follow Fedora's approach here?
Since the reasons for "/boot" are obsolete since more than a decade, just go ahead.
The reasons for boot are obsolete? Since more than a decade ago? What were the reasons for boot being separate? As opposed to being a partition on "/" root along with /sbin/modprobe and /lib/modules?
How does Windows boot supporting all the different hardware it does without a ramdisk, and why does linux need one?
One reason is that Windows filesystem can flag a file "system", which means "do not move it". Don't touch it. Don't relocate it. This makes it possible to code a boot loader that knows what sectors to read from disk to boot the system, without knowing anything about the filesystem. It blindly reads the sectors it is told to load. And nobody will move those sectors. This is similar to the strategy used by Lilo. When the kernel was updated, a map of what sectors to load on boot had to be updated. Same thing :-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Am Mon, 12 Apr 2021 14:37:23 -0700
schrieb L A Walsh
What were the reasons for boot being separate?
To make sure that directory can be assigned to a mount point, which points to a disk partition that is fully accessible by incapable BIOS and/or hardware implementations. As you may remember, back in the days the BIOS block interface could access only a small part of a potentially large disk. These days are gone. Otherwise we would not be able to boot from disk today. The kernel will end up anywhere in the range of what can be described by a MBR partition entry. You may have noticed, YaST does not propose a partition for /boot anymore since more than a decade.
How does Windows ...
Yes, I'm sure there are other shocking stories around that or any other unrelated topic. Please, consider the target audience of a potential reply. Olaf
On Tue, Apr 13, 2021 at 02:57:49AM +0200, Carlos E. R. wrote:
On 12/04/2021 23.37, L A Walsh wrote:
On 2021/04/12 01:59, Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: Does anyone have a better idea or can we just follow Fedora's approach here?
Since the reasons for "/boot" are obsolete since more than a decade, just go ahead.
The reasons for boot are obsolete? Since more than a decade ago? What were the reasons for boot being separate? As opposed to being a partition on "/" root along with /sbin/modprobe and /lib/modules?
How does Windows boot supporting all the different hardware it does without a ramdisk, and why does linux need one?
One reason is that Windows filesystem can flag a file "system", which means "do not move it". Don't touch it. Don't relocate it. This makes it possible to code a boot loader that knows what sectors to read from disk to boot the system, without knowing anything about the filesystem. It blindly reads the sectors it is told to load. And nobody will move those sectors.
This is similar to the strategy used by Lilo. When the kernel was updated, a map of what sectors to load on boot had to be updated.
Or like grub that understands the filesystem but not the storage and uses BIOS services to load data from the filesystem - such as the initrd or a select storage driver in the Windows case (which also means you cannot boot anymore when you change your storage hardware). The packing of drivers into initrd is useful when you want to boot from some other medium - like from the network. Try booting Windows over Ethernet. Thanks Michal
Am Mon, 12 Apr 2021 14:37:23 -0700 schrieb L A Walsh
: You may have noticed, YaST does not propose a partition for /boot anymore since more than a decade. Well, Yast does not propose RAID10 (with o3 parity - 3 disks in mirror for very high reliability and more than double read speed), but if you want it you can create it in the Partitioner. Yast proposes BTRFS, but I don't want it, so I can use XFS - also from Yast Partitioner. Yast does not propose /boot, but if you try to put / on RAID10 it will warn you
On 4/13/21 1:23 PM, Olaf Hering wrote: that system won't be bootable. Proposal is just that, you don't have to accept it. If I wanted something without control, I'd use Ubuntu or Centos... Srdačan pozdrav / Best regards / Freundliche Grüße / Cordialement / よろしくお願いします Siniša Bandin
On Tue, 13 Apr 2021 13:36:35 +0200, Sinisa wrote:
On 4/13/21 1:23 PM, Olaf Hering wrote:
Am Mon, 12 Apr 2021 14:37:23 -0700 schrieb L A Walsh
: You may have noticed, YaST does not propose a partition for /boot anymore since more than a decade. Well, Yast does not propose RAID10 (with o3 parity - 3 disks in mirror for very high reliability and more than double read speed), but if you want it you can create it in the Partitioner. Yast proposes BTRFS, but I don't want it, so I can use XFS - also from Yast Partitioner. Yast does not propose /boot, but if you try to put / on RAID10 it will warn you that system won't be bootable. Proposal is just that, you don't have to accept it. If I wanted something without control, I'd use Ubuntu or Centos...
I don't think that the proposal is about breaking such installations. Instead of putting the stuff like vmlinuz and initrd under /boot directly, keep those in the normal place. And for the system that needs the extra /boot partition, we may tweak somehow, e.g. creating symlinks or copying the files in post script or such. This sounds like a feasible option. But we have to be really careful; as usual, devils living in details... Takashi
On 4/13/21 2:16 PM, Takashi Iwai wrote:
On 4/13/21 1:23 PM, Olaf Hering wrote:
Am Mon, 12 Apr 2021 14:37:23 -0700 schrieb L A Walsh
: You may have noticed, YaST does not propose a partition for /boot anymore since more than a decade. Well, Yast does not propose RAID10 (with o3 parity - 3 disks in mirror for very high reliability and more than double read speed), but if you want it you can create it in the Partitioner. Yast proposes BTRFS, but I don't want it, so I can use XFS - also from Yast Partitioner. Yast does not propose /boot, but if you try to put / on RAID10 it will warn you that system won't be bootable. Proposal is just that, you don't have to accept it. If I wanted something without control, I'd use Ubuntu or Centos... I don't think that the proposal is about breaking such installations. Instead of putting the stuff like vmlinuz and initrd under /boot
On Tue, 13 Apr 2021 13:36:35 +0200, Sinisa wrote: directly, keep those in the normal place. /boot IS normal place for those And for the system that needs the extra /boot partition, we may tweak somehow, e.g. creating symlinks Won't work, grub couldn't read symlink target. If it could, we wouldn't need /boot partition. or copying the files in post script or such. This might work, but we would need to remember that when manually tweaking things. This sounds like a feasible option. But we have to be really careful; as usual, devils living in details...
Takashi To me, this seems like a "change just for the sake of change". I can see no improvement in that, just more complications. Sort of remind me of that "other OS", where they change things for no real reason...
/boot was/is working since forever, people know about it and know how to handle it. But hey, this is just my ¢2. I got used to "systemctl restart xxxx" instead od "rcxxxx restart", I'll get used to new /boot if necessary. (btw, that was a lie, I still use rcxxxx commands) Srdačan pozdrav / Best regards / Freundliche Grüße / Cordialement / よろしくお願いします Siniša Bandin
On 2021/04/12 17:57, Carlos E. R. wrote:
On 12/04/2021 23.37, L A Walsh wrote:
How does Windows boot supporting all the different hardware it does without a ramdisk, and why does linux need one?
One reason is that Windows filesystem can flag a file "system", which means "do not move it". Don't touch it. Don't relocate it.
Doesn't the immutable bit on linux accomplish much the same? So linux could do the same thing?
On 2021/04/13 04:32, Michal Such������������������������ wrote:
Or like grub that understands the filesystem but not the storage and uses BIOS services to load data from the filesystem - such as the initrd or a select storage driver in the Windows case (which also means you cannot boot anymore when you change your storage hardware).
---- I've not heard of any windows systems having that problem. Probably the driver for the storage hardware is installed in windows before its use.
The packing of drivers into initrd is useful when you want to boot from some other medium - like from the network. Try booting Windows over Ethernet.
---- Unix used to provide a boot protocol for booting over the network. It predated linux, I'm pretty sure, and AFAIK, it worked with windows as well.
Thanks
You're welcome! :-)
On 2021/04/13 05:16, Takashi Iwai wrote:
I don't think that the proposal is about breaking such installations. Instead of putting the stuff like vmlinuz and initrd under /boot directly, keep those in the normal place. And for the system that needs the extra /boot partition, we may tweak somehow, e.g. creating symlinks or copying the files in post script or such.
--- Um, you realize symlinks don't work in many cases where suse uses them, right? Always wonderful, the symlinks on root that point to an unmounted /usr partition. Not too many things work in that scenario, including symlinks for libraries used by 'mount' to mount /usr (a real consequence of suse's symlinks).
On 2021/04/13 16:30, L A Walsh wrote:
On 2021/04/12 17:57, Carlos E. R. wrote:
On 12/04/2021 23.37, L A Walsh wrote:
How does Windows boot supporting all the different hardware it does without a ramdisk, and why does linux need one?
One reason is that Windows filesystem can flag a file "system", which means "do not move it". Don't touch it. Don't relocate it.
---- Doesn't the immutable bit on linux accomplish much the same?
So linux could do the same thing?
Actually, thinking about this -- Windows also has the benefit of only having to read 1 filesystem type for the OS (NTFS). Still, effectively, one could have a system that boots from the BIOS to read the system disk for a kernel ...er, oh wait, isn't that what the linux bootloader did by default on PC Hardware for ages? Now I think the UEFI bios has similar capabilities to allow it to load the OS from the boot disk. In one scenario, you put the kernel+drivers+a copy of the OS on a boot disk that then boots the main OS. Vs. loading the kernel+drivers directly and booting directly from the hard disk as it reads the system-boot process from disk to continue booting. I still remember the original systemd page recommending booting directly from disk to speed up the boot process.
Am Dienstag, den 13.04.2021, 14:16 +0200 schrieb Takashi Iwai:
I don't think that the proposal is about breaking such installations. Instead of putting the stuff like vmlinuz and initrd under /boot directly, keep those in the normal place. And for the system that needs the extra /boot partition, we may tweak somehow, e.g. creating symlinks or copying the files in post script or such. This sounds like a feasible option. But we have to be really careful; as usual, devils living in details...
That makes things more complicated than they now are and drives up the number of test cases. Putting things into different logical places depending on configuration is somewhat inverted. /boot today exists because the boot loader may be unable to read / It really does not matter for which reason this inability exists unless we are ready to remove them all (or drop support). It seems to me that that is not the case. Hence if we want a unified solution the kernel will have to stay where it is. Regards Oliver
Am Dienstag, den 13.04.2021, 16:30 -0700 schrieb L A Walsh:
On 2021/04/12 17:57, Carlos E. R. wrote:
On 12/04/2021 23.37, L A Walsh wrote:
How does Windows boot supporting all the different hardware it does without a ramdisk, and why does linux need one?
One reason is that Windows filesystem can flag a file "system", which means "do not move it". Don't touch it. Don't relocate it.
Doesn't the immutable bit on linux accomplish much the same?
The i bit is - FS specific - for the logical content - depending on the storage device There are really tough cases. Suppose you have / on a RAID volume in degraded state. Do we really want that case in the boot loader? I am afraid that question has to be answered in the negative for the general case. Regards Oliver
On 2021/04/13 20:58, Oliver Neukum wrote:
The i bit is - FS specific
Only use FS that support it to boot from. extX, xfs, etc...
There are really tough cases. Suppose you have / on a RAID volume in degraded state. Do we really want that case in the boot loader?
1) what is degraded? A bad mirror on a RAID10 that's being rebuilt? That's hardly a cause for concern. 2) If it is your prime choice 3) if it is where your ramdisk loads from, not alot of choice
I am afraid that question has to be answered in the negative for the general case.
General case seems like normal case, especially if you need to recover a system. If it won't boot, resort to a USB key. None of the cases you mention are reasons not to boot from disk.
Am Dienstag, den 13.04.2021, 21:46 -0700 schrieb L A Walsh:
On 2021/04/13 20:58, Oliver Neukum wrote:
The i bit is - FS specific
Only use FS that support it to boot from. extX, xfs, etc...
Very well.
There are really tough cases. Suppose you have / on a RAID volume in degraded state. Do we really want that case in the boot loader?
1) what is degraded? A bad mirror on a RAID10 that's being rebuilt? That's hardly a cause for concern.
I have worse cases for you. / can be on LVM. The assumption that a block cannot move without FS action is just not right. Regards Oliver
On 13.04.2021 14:23, Olaf Hering wrote:
Yes, I'm sure there are other shocking stories around that or any other unrelated topic. Please, consider the target audience of a potential reply.
There is nothing wrong in comparing technologies, but I doubt she is really interested in fair comparison.
On Tue, 13 Apr 2021 15:04:12 +0200, Sinisa wrote:
On 4/13/21 2:16 PM, Takashi Iwai wrote:
On 4/13/21 1:23 PM, Olaf Hering wrote:
Am Mon, 12 Apr 2021 14:37:23 -0700 schrieb L A Walsh
: You may have noticed, YaST does not propose a partition for /boot anymore since more than a decade. Well, Yast does not propose RAID10 (with o3 parity - 3 disks in mirror for very high reliability and more than double read speed), but if you want it you can create it in the Partitioner. Yast proposes BTRFS, but I don't want it, so I can use XFS - also from Yast Partitioner. Yast does not propose /boot, but if you try to put / on RAID10 it will warn you that system won't be bootable. Proposal is just that, you don't have to accept it. If I wanted something without control, I'd use Ubuntu or Centos... I don't think that the proposal is about breaking such installations. Instead of putting the stuff like vmlinuz and initrd under /boot
On Tue, 13 Apr 2021 13:36:35 +0200, Sinisa wrote: directly, keep those in the normal place. /boot IS normal place for those And for the system that needs the extra /boot partition, we may tweak somehow, e.g. creating symlinks Won't work, grub couldn't read symlink target. If it could, we wouldn't need /boot partition.
Oh yeah, right.
or copying the files in post script or such. This might work, but we would need to remember that when manually tweaking things.
Can't it be enough just checking whether /boot is a partition on the installed system? Maybe there's some other missing cases I overlooked, though...
This sounds like a feasible option. But we have to be really careful; as usual, devils living in details...
Takashi To me, this seems like a "change just for the sake of change". I can see no improvement in that, just more complications. Sort of remind me of that "other OS", where they change things for no real reason...
/boot was/is working since forever, people know about it and know how to handle it.
But hey, this is just my ¢2. I got used to "systemctl restart xxxx" instead od "rcxxxx restart", I'll get used to new /boot if necessary. (btw, that was a lie, I still use rcxxxx commands)
Yeah, although it looks "possible", this change is drastic and sensitive. It needs a very compelling reason if we do have to change it. Takashi
On 2021/04/13 22:24, Oliver Neukum wrote:
I have worse cases for you. / can be on LVM. The assumption that a block cannot move without FS action is just not right.
Hey, many tell folks that boot should be a normal disk. Encrypted and raids...tend to be less well supported. That's told to most people and some of them try to read their ramdisk from an LVM partition. But haven't ever heard of them moving things around after copying the ram disk there. They might, I admit, but if they want to boot they probably shouldn't be moving around things needed for boot unless they know it doesn't matter. Like me booting off my RAID -- no prob. The BIOS and the OS see the device as a single disk. So it would work for encryption RAID or LVM. Also, SuSE set that partition up to be excluded from xfs_fsr -- and since nothing is on that partition except the kernel, once it is built+installed, lilo rereads where everything is. If it was on another disk that is regularly read/written, yeah, it might get moved. So you remind us well, why one should keep boot on its own partition.
On 2021/04/13 22:24, Oliver Neukum wrote:
I have worse cases for you. / can be on LVM. The assumption that a block cannot move without FS action is just not right.
Hey, many tell folks that boot should be a normal disk. Encrypted and raids...tend to be less well supported. Yes, things like "full disk encryption" (LVM on LUKS on whole disk, i.e. without separate /boot) is not supported by openSUSE installer :(.
Kind regards, Petr
That's told to most people and some of them try to read their ramdisk from an LVM partition. But haven't ever heard of them moving things around after copying the ram disk there. They might, I admit, but if they want to boot they probably shouldn't be moving around things needed for boot unless they know it doesn't matter. Like me booting off my RAID -- no prob. The BIOS and the OS see the device as a single disk. So it would work for encryption RAID or LVM. Also, SuSE set that partition up to be excluded from xfs_fsr -- and since nothing is on that partition except the kernel, once it is built+installed, lilo rereads where everything is.
If it was on another disk that is regularly read/written, yeah, it might get moved. So you remind us well, why one should keep boot on its own partition.
On 2021/04/13 04:23, Olaf Hering wrote:
Am Mon, 12 Apr 2021 14:37:23 -0700 schrieb L A Walsh
: What were the reasons for boot being separate?
To make sure that directory can be assigned to a mount point, which points to a disk partition that is fully accessible by incapable BIOS and/or hardware implementations. As you may remember, back in the days the BIOS block interface could access only a small part of a potentially large disk.
So /boot can be on an LVM/MDRAID/encrypted partition and its fully supported by SUSE?
You may have noticed, YaST does not propose a partition for /boot anymore since more than a decade.
I haven't noticed, actually, I don't reinstall that often.
How does Windows ... Yes, I'm sure there are other shocking stories around that or any other unrelated topic. Please, consider the target audience of a potential reply.
Unrelated? It's on the same HW, if another OS doesn't need a ramdisk, why should linux? I.e. linux needs a ram disk about as much as it needs a floppy to boot. Believe it or not, people do look at usability issues when comparing Windows and Linux. Linux shouldn't require any more hoops to run than Windows, yet the user-grief level on linux is ignored on every update. Before Win10, you didn't really hear about something breaking every week like you do with TW, for example.
On 14.04.2021 21:05, Petr Vorel wrote:
On 2021/04/13 22:24, Oliver Neukum wrote:
I have worse cases for you. / can be on LVM. The assumption that a block cannot move without FS action is just not right.
Hey, many tell folks that boot should be a normal disk. Encrypted and raids...tend to be less well supported. Yes, things like "full disk encryption" (LVM on LUKS on whole disk, i.e. without separate /boot) is not supported by openSUSE installer :(.
Really? Have you tried?
On Wed, Apr 14, 2021 at 04:24:24PM -0700, L A Walsh wrote:
On 2021/04/13 04:23, Olaf Hering wrote:
Am Mon, 12 Apr 2021 14:37:23 -0700 schrieb L A Walsh
: What were the reasons for boot being separate?
To make sure that directory can be assigned to a mount point, which points to a disk partition that is fully accessible by incapable BIOS and/or hardware implementations. As you may remember, back in the days the BIOS block interface could access only a small part of a potentially large disk.
So /boot can be on an LVM/MDRAID/encrypted partition and its fully supported by SUSE?
You may have noticed, YaST does not propose a partition for /boot anymore since more than a decade.
I haven't noticed, actually, I don't reinstall that often.
How does Windows ... Yes, I'm sure there are other shocking stories around that or any other unrelated topic. Please, consider the target audience of a potential reply.
Unrelated? It's on the same HW, if another OS doesn't need a ramdisk, why should linux? I.e. linux needs a ram disk about as much as it needs a floppy to boot.
It's the same for Windows. Linux has drivers for large number of devices, and you need to preload some to be able to boot the system with a generic distribution kernel. That prealod is done by packing essential drivers into the ramdisk. It works very well both for booting from device/filesystem/RAID not supported by bootloader/BIOS and booting form network. In both cases you store the kernel and the ramdisk on a separate medium that the bootloader/BIOS can access, load over network, whatever. Similarily in the Windows case you can and will have large number of drivers installed, and a few drivers need to be preloaded on boot so that the kernel can access the boot disk once loaded and executed by the bootloader. The exact mechanism is secret MS sauce so I can't tell if there is an actual package of these boot drivers similar to ramdisk or if there is different underlying mechanism. Either way the basic solution is the same. Just having a driver is not enough, you have to tell Windows to preload the driver on boot, otherwise you get the infamous INACESSIBLE_BOOT_DEVICE error.
Believe it or not, people do look at usability issues when comparing Windows and Linux. Linux shouldn't require any more hoops to run than Windows, yet the user-grief level on linux is ignored on every update. Before Win10, you didn't really hear about something breaking every week like you do with TW, for example.
That's because before Win10 MS used the Leap model but now it uses the Tumbleweed model. So if you feel grief from using Tumbleweed there is Leap for you. It has been said quite a few times but you don't seem to be able to hear. Best regards Michal
On Tue, Apr 13, 2021 at 04:36:40PM -0700, L A Walsh wrote:
On 2021/04/13 04:32, Michal Such������������������������ wrote:
Or like grub that understands the filesystem but not the storage and uses BIOS services to load data from the filesystem - such as the initrd or a select storage driver in the Windows case (which also means you cannot boot anymore when you change your storage hardware).
---- I've not heard of any windows systems having that problem. Probably the driver for the storage hardware is installed in windows before its use. Then you need to be listening more carefully. Ever heard of INACESSIBLE_BOOT_DEVICE error?
The packing of drivers into initrd is useful when you want to boot from some other medium - like from the network. Try booting Windows over Ethernet.
Unix used to provide a boot protocol for booting over the network. It predated linux, I'm pretty sure, and AFAIK, it worked with windows as well. You don't know very far here. Or can you share what protocol it is, specifically, and how do you create a netbooted installtion of Windows?
Best regards Michal
On Thu, Apr 15, 2021 at 12:33 PM Michal Suchánek
It's the same for Windows.
Linux has drivers for large number of devices, and you need to preload some to be able to boot the system with a generic distribution kernel.
That prealod is done by packing essential drivers into the ramdisk. It works very well both for booting from device/filesystem/RAID not supported by bootloader/BIOS and booting form network. In both cases you store the kernel and the ramdisk on a separate medium that the bootloader/BIOS can access, load over network, whatever.
Similarily in the Windows case you can and will have large number of drivers installed, and a few drivers need to be preloaded on boot so that the kernel can access the boot disk once loaded and executed by the bootloader. The exact mechanism is secret MS sauce so I can't tell if there is an actual package of these boot drivers similar to ramdisk or if there is different underlying mechanism. Either way the basic solution is the same. Just having a driver is not enough, you have to tell Windows to preload the driver on boot, otherwise you get the infamous INACESSIBLE_BOOT_DEVICE error.
Windows loader is using firmware services to access system disk, it reads the registry where boot drivers are listed and loads them together with the kernel. This method won't work in Linux as you cannot load kernel and modules side by side; loading modules requires user space which is one reason for initrd.
On 15.04.21 12:06, Andrei Borzenkov wrote:
Windows loader is using firmware services to access system disk, it reads the registry where boot drivers are listed and loads them together with the kernel. This method won't work in Linux as you cannot load kernel and modules side by side; loading modules requires user space which is one reason for initrd.
But in the end it is not *that* different: Windows reads additional files via firmware services (registry and drivers) and Linux reads an additional file via firmware services (initrd). What's exactly in that files does not really matter, both cannot reliably boot if the loading of that "addon" fails. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Thu, Apr 15, 2021 at 01:06:30PM +0300, Andrei Borzenkov wrote:
On Thu, Apr 15, 2021 at 12:33 PM Michal Suchánek
wrote: It's the same for Windows.
Linux has drivers for large number of devices, and you need to preload some to be able to boot the system with a generic distribution kernel.
That prealod is done by packing essential drivers into the ramdisk. It works very well both for booting from device/filesystem/RAID not supported by bootloader/BIOS and booting form network. In both cases you store the kernel and the ramdisk on a separate medium that the bootloader/BIOS can access, load over network, whatever.
Similarily in the Windows case you can and will have large number of drivers installed, and a few drivers need to be preloaded on boot so that the kernel can access the boot disk once loaded and executed by the bootloader. The exact mechanism is secret MS sauce so I can't tell if there is an actual package of these boot drivers similar to ramdisk or if there is different underlying mechanism. Either way the basic solution is the same. Just having a driver is not enough, you have to tell Windows to preload the driver on boot, otherwise you get the infamous INACESSIBLE_BOOT_DEVICE error.
Windows loader is using firmware services to access system disk, it reads the registry where boot drivers are listed and loads them together with the kernel.
Thanks for the clarification.
This method won't work in Linux as you cannot load kernel and modules side by side; loading modules requires user space which is one reason for initrd.
Obviously it could. The userspace does very little, kernel does the heavy lifting of linking the module to the kernel, patching its code for the current CPU architecture, etc. What the userspace does is lookup of module binary depending on some request from the kernel, some situation in the userspace filesystem, applyyng some parameters according to user configuration (which can be specified as kernel commandline argument most of the time) etc. You could implement a slightly different loading mechanism which links to a module binary provided in memory by the bootlaoder but there is little practical value so nobody bothered. There is the additional hassle of resolving dependencies on additional modules and firmware files beforehand. Especially the firmware files loaded can depend on the hardware revsion detected and cannot be always determined beforehand, and there is no mechanism of firmware lookup other than asking userspace for specific filename which means a preloaded firmware blob is not particularly useful. Thanks Michal
On 14.04.2021 21:05, Petr Vorel wrote:
On 2021/04/13 22:24, Oliver Neukum wrote:
I have worse cases for you. / can be on LVM. The assumption that a block cannot move without FS action is just not right.
Hey, many tell folks that boot should be a normal disk. Encrypted and raids...tend to be less well supported. Yes, things like "full disk encryption" (LVM on LUKS on whole disk, i.e. without separate /boot) is not supported by openSUSE installer :(.
Really? Have you tried? Hm, I cannot find the bug I filled in 2017, which ended as wontfix. But right, things might have changed, I'll retest it.
Kind regards, Petr
Am Wed, 14 Apr 2021 16:24:24 -0700
schrieb L A Walsh
So /boot can be on an LVM/MDRAID/encrypted partition and its fully supported by SUSE?
No. Did you read what you quoted? Ask for external assistance if the quoted sentence is too complicated.
Unrelated? It's on the same HW, if another OS ...
How is that relevant to the topic (moving files from A to B, to achieve what the OP asked about)? In case the OP wanted to change how SUSE Linux is loaded into memory, he would have used another Subject line, he would have written another email body, he would have written to a different email distribution list, and most likely I would have nothing to contribute to such email thread. Olaf
On Thu, Apr 15, 2021 at 4:31 PM Olaf Hering
Am Wed, 14 Apr 2021 16:24:24 -0700 schrieb L A Walsh
: So /boot can be on an LVM/MDRAID/encrypted partition and its fully supported by SUSE?
No.
/boot most certainly can be on an LVM/MDRAID/encrypted partition, if under /boot we silently understand "filesystem kernel is loaded from". Whether it is supported by SUSE I have no idea and I do not see how it is relevant to openSUSE.
On 4/15/21 4:36 AM, Michal Suchánek wrote:
On Tue, Apr 13, 2021 at 04:36:40PM -0700, L A Walsh wrote:
On 2021/04/13 04:32, Michal Such������������������������ wrote:
Or like grub that understands the filesystem but not the storage and uses BIOS services to load data from the filesystem - such as the initrd or a select storage driver in the Windows case (which also means you cannot boot anymore when you change your storage hardware).
---- I've not heard of any windows systems having that problem. Probably the driver for the storage hardware is installed in windows before its use. Then you need to be listening more carefully. Ever heard of INACESSIBLE_BOOT_DEVICE error?
The packing of drivers into initrd is useful when you want to boot from some other medium - like from the network. Try booting Windows over Ethernet.
Unix used to provide a boot protocol for booting over the network. It predated linux, I'm pretty sure, and AFAIK, it worked with windows as well. You don't know very far here. Or can you share what protocol it is, specifically, and how do you create a netbooted installtion of Windows?
I have seen a TFTP boot of a Windows installer. It was slow, but it worked. I was not involved in setting it up, and I have no idea of the internals. Larry
On 15.04.2021 21:20, Larry Finger wrote:
On 4/15/21 4:36 AM, Michal Suchánek wrote:
On Tue, Apr 13, 2021 at 04:36:40PM -0700, L A Walsh wrote:
Unix used to provide a boot protocol for booting over the network. It predated linux, I'm pretty sure, and AFAIK, it worked with windows as well. You don't know very far here. Or can you share what protocol it is, specifically, and how do you create a netbooted installtion of Windows?
I have seen a TFTP boot of a Windows installer.
That's not surprising given that PXE is based on TFTP and it does not matter *what* you are booting over LAN via PXE, you end up loading it with TFTP. And PXE is the industry standard network boot protocol today.
It was slow, but it worked. I was not involved in setting it up, and I have no idea of the internals.
Larry
On Fri, Apr 16, 2021 at 07:28:26AM +0300, Andrei Borzenkov wrote:
On 15.04.2021 21:20, Larry Finger wrote:
On 4/15/21 4:36 AM, Michal Suchánek wrote:
On Tue, Apr 13, 2021 at 04:36:40PM -0700, L A Walsh wrote:
Unix used to provide a boot protocol for booting over the network. It predated linux, I'm pretty sure, and AFAIK, it worked with windows as well. You don't know very far here. Or can you share what protocol it is, specifically, and how do you create a netbooted installtion of Windows?
I have seen a TFTP boot of a Windows installer.
That's not surprising given that PXE is based on TFTP and it does not matter *what* you are booting over LAN via PXE, you end up loading it with TFTP. And PXE is the industry standard network boot protocol today.
It was slow, but it worked. I was not involved in setting it up, and I have no idea of the internals.
Yes, but loading Windows installer from TFTP does not mean Windows can boot from network. The installer is a Windows PE image that boots from ramdisk no matter where that ramdisk image is loaded from. So while Microsoft provides a bootloader that can fetch the installer ramdisk from TFTP it still does not make it possible to boot Windows from network. The only way I know if is using hardware iSCSI which obviously works because Windows does not know about the networking. Thanks Michal
On 2021/04/15 06:24, Olaf Hering wrote:
Am Wed, 14 Apr 2021 16:24:24 -0700 schrieb L A Walsh
: So /boot can be on an LVM/MDRAID/encrypted partition and its fully supported by SUSE?
No.
Did you read what you quoted? Ask for external assistance if the quoted sentence is too complicated.
Unrelated? It's on the same HW, if another OS ...
How is that relevant to the topic (moving files from A to B, to achieve what the OP asked about)? Olaf
Oh...You didn't get my transition...thought we were talking both kernel+ramdisk usage at boot... My comment related to the practice of having a ramdisk image + kernel in a file on disk that is usually located in /boot. So you would want to remove the linux kernel from /boot but leave ramdisk-boot image in /boot? Isn't that more confusing? I forget are the 1 or 2 files? Either way, you would want to move only the kernel off boot, and leave the rest there?
On 2021/04/15 02:33, Michal Suchánek wrote:
I.e. linux needs a ram disk about as much as it needs a floppy to boot.
It's the same for Windows.
Linux has drivers for large number of devices, and you need to preload some to be able to boot the system with a generic distribution kernel.
Just like windows has support for a large number of drivers built in. It is able to access the entire driver data base shipped with windows. The key ingredient here is that Windows doesn't support all the file systems that linux does for boot. Their hidden system partition that is before the OS partition needs to be in NTFS. That partition is installed when you first install Windows onto the machine. It is generally 'fixed' to the HW on that machine as configured by the computer-provider (or OEM).
That prealod is done by packing essential drivers into the ramdisk. It works very well both for booting ...
Here's the 1st part you are missing. The ramdisk and the kernel that boots from that ramdisk have to be loaded from "somewhere". Guess what. That "somewhere" is near the same in both cases. Linux has a boot partition it loads kernel+drivers from (drivers being in the form of a ramdisk). Windows has a system-partition it loads the NT-bootloader and drivers from. They are both loading a single-format disk image they they continue to boot from.
Similarily in the Windows case you can and will have large number of drivers installed, and a few drivers need to be preloaded on boot so that the kernel can access the boot disk once loaded and executed by the bootloader. The exact mechanism is secret MS sauce...
---- See "Windows Internals, 6th Edition". (Parts I+II). It covers up through Win7+Server2008. The exact mechanism is detailed in Chapter 13 (in part 2) under Startup & Shutdown. It details parts you missed w/linux -- like the BIOS detecting the boot method (basic BIOS or EFI), reading in the initial boot loader for the given method. That may provide a menu of bootable images -- on linux and on Windows. That can then load those bootable "blobs" into memory and continue.
you have to tell Windows to preload the driver on boot, otherwise you get the infamous INACESSIBLE_BOOT_DEVICE error.
Not very famous or infamous unless you construct your own PC's. The BIOS provided by the vendor usually has complete ability to read the initial HW that it will boot from.
Believe it or not, people do look at usability issues when comparing Windows and Linux. Linux shouldn't require any more hoops to run than Windows, yet the user-grief level on linux is ignored on every update. Before Win10, you didn't really hear about something breaking every week like you do with TW, for example.
That's because before Win10 MS used the Leap model but now it uses the Tumbleweed model.
With TW it's every day, w/Windows it used to be once every few years (never the Leap model), and now is every few-several months w/monthly security updates. That's still not close to the daily TW update, but like TW, they don't do extensive testing before release so Win10 customers are basically beta testing for MS for free if you look at the SW quality level.
So if you feel grief from using Tumbleweed there is Leap for you. It has been said quite a few times but you don't seem to be able to hear.
I _read_ quite well, thank-you, but I've been using OpenSuse since before there was a Leap or a TW, so thanks for the suggestion. As it is, both have benefits & problems (like Windows, and like most-or-many other linux-distro's).
Best regards Michal
Ditto - Linda
On Sat, Apr 17, 2021 at 03:25:44PM -0700, L A Walsh wrote:
On 2021/04/15 02:33, Michal Suchánek wrote:
I.e. linux needs a ram disk about as much as it needs a floppy to boot.
It's the same for Windows.
Linux has drivers for large number of devices, and you need to preload some to be able to boot the system with a generic distribution kernel.
Just like windows has support for a large number of drivers built in. It
But the key is that the correct storage driver is preloaded on boot.
is able to access the entire driver data base shipped
Once booted.
with windows. The key ingredient here is that Windows doesn't support all the file systems that linux does for boot. Their hidden system partition that is before the OS partition needs to be in NTFS. That partition is installed when you first install Windows onto the machine.
Are you talking about the recovery partition? That's not used at all during normal boot. Also Windows does support FAT, and somebody wrote a btrfs driver for it, too. All of these work perfectly fine so long as Widows knows to preload the correct driver.
It is generally 'fixed' to the HW on that machine as configured by the computer-provider (or OEM).
Only until you change the machine. And even a single vendor like Dell ships large number of different machine models. It's completely beside the point, anyway.
That prealod is done by packing essential drivers into the ramdisk. It works very well both for booting ...
Here's the 1st part you are missing. The ramdisk and the kernel that boots from that ramdisk have to be loaded from "somewhere".
Guess what. That "somewhere" is near the same in both cases. Linux has a boot partition it loads kernel+drivers from (drivers being in the form of a ramdisk). Windows has a system-partition it loads the NT-bootloader and drivers from. They are both loading a single-format disk image they they continue to boot from.
So you finally came to the conclusion that it's about the same after trying to grief about how Linux is clumsy with it's boot process compared to Windows, great ...
Similarily in the Windows case you can and will have large number of drivers installed, and a few drivers need to be preloaded on boot so that the kernel can access the boot disk once loaded and executed by the bootloader. The exact mechanism is secret MS sauce...
---- See "Windows Internals, 6th Edition". (Parts I+II). It covers up through Win7+Server2008. The exact mechanism is detailed in Chapter 13 (in part 2) under Startup & Shutdown.
That's not freely avalable book. Anyway, it has been pointed out how this works exactly in this thread already.
It details parts you missed w/linux -- like the BIOS detecting the boot method (basic BIOS or EFI), reading in the initial boot loader
BIOS does not detect the boot method, BIOS implements the boot method.
for the given method. That may provide a menu of bootable images -- on linux and on Windows. That can then load those bootable "blobs" into memory and continue.
you have to tell Windows to preload the driver on boot, otherwise you get the infamous INACESSIBLE_BOOT_DEVICE error.
Not very famous or infamous unless you construct your own PC's. The BIOS provided by the vendor usually has complete ability to read the initial HW that it will boot from.
It's not about the BIOS being able to access the boot disk but about windows preloading the correct driver to be able to read from the disk once the NT kernel starts. And it can easily happen when you change your storage configuration - such as when you replace your storage controller - either discreate or the one built into your mainboard. And here the usability of Linux is much better than Windows, actually. On Linux similar drivers are unified while on Widows every hardware vendor ships their own driver so it is more likely that the same storage driver will continue to work after you replace your storage controller or mainboard, and by default most storage drivers are included in the ramdisk so that you can boot from any kind of storage supported by Linux. Best regards Michal
On 19.04.21 10:31, Michal Suchánek wrote:
It's not about the BIOS being able to access the boot disk but about windows preloading the correct driver to be able to read from the disk once the NT kernel starts. And it can easily happen when you change your storage configuration - such as when you replace your storage controller - either discreate or the one built into your mainboard.
Just switch your SATA controller from "Legacy" to "AHCI" in BIOS and try to get by without reinstallation of Windows ;-) (yes, it's possible, but it is not easy for the uninitiated).
And here the usability of Linux is much better than Windows, actually.
Well, the same stunt on Linux back then also included the "use a rescue CD to boot..." ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Olaf Hering wrote: >Am Mon, 12 Apr 2021 10:46:48 +0200 >schrieb Ludwig Nussel: > >> Does anyone have a better idea or can we just follow Fedora's approach here? > >Since the reasons for "/boot" are obsolete since more than a decade, just go ahead. > >Just make sure to provide the equivalent of "/boot/vmlinuz" and >"/boot/initrd", a pointer to the last installed kernel. This can >very well be stored somewhere in "/usr". Here's my suggestion to move the kernel related read-only files from /boot to /lib/modules/%kernelrelease-%build_flavor 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 as a start. 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. Longer term I'd expect that logic to move out of the kernel's %post. A possibility would be to go for systemd's kernel-install for example. From 85d641c3099cc7f9e2189cb84601cbbf805c75ed Mon Sep 17 00:00:00 2001 From: Ludwig Nussel Date: Mon, 12 Apr 2021 13:26:04 +0200 Subject: [PATCH] Move files in /boot to modules dir --- rpm/kernel-binary.spec.in | 47 ++++++++++++++++++++++++++++----------- rpm/post.sh | 17 ++++++++++++++ rpm/postun.sh | 2 +- 3 files changed, 52 insertions(+), 14 deletions(-) diff --git a/rpm/kernel-binary.spec.in b/rpm/kernel-binary.spec.in index 40433d95cea4..068ce7dc54da 100644 --- a/rpm/kernel-binary.spec.in +++ b/rpm/kernel-binary.spec.in @@ -530,10 +530,10 @@ add_vmlinux() # sign the modules, firmware and possibly the kernel in the buildservice BRP_PESIGN_FILES="" %if "%CONFIG_EFI_STUB" == "y" -BRP_PESIGN_FILES="/boot/$image-%kernelrelease-%build_flavor" +BRP_PESIGN_FILES="/lib/modules/%kernelrelease-%build_flavor/$image" %endif %ifarch s390x ppc64 ppc64le -BRP_PESIGN_FILES="/boot/$image-%kernelrelease-%build_flavor" +BRP_PESIGN_FILES="/lib/modules/%kernelrelease-%build_flavor/$image" %endif %if "%CONFIG_MODULE_SIG" == "y" BRP_PESIGN_FILES="$BRP_PESIGN_FILES *.ko" @@ -803,7 +803,7 @@ add_dirs_to_filelist() { # print all parents :a # skip directories owned by other packages - s:^%%dir (/boot|/etc|/lib/(modules|firmware)|/usr/src)/[^/]+$:: + s:^%%dir (/boot|/etc|(/usr)?/lib/(modules|firmware)|/usr/src)/[^/]+$:: s:/[^/]+$::p ta ' "$@" | sort -u @@ -816,10 +816,19 @@ fi shopt -s nullglob dotglob > %my_builddir/kernel-devel.files -for file in %buildroot/boot/symtypes* %buildroot/lib/modules/*/{build,source}; do - f=${file##%buildroot} - echo "$f" -done | add_dirs_to_filelist >%my_builddir/kernel-devel.files +{ + echo "/lib/modules/%kernelrelease-%build_flavor/build" + echo "/lib/modules/%kernelrelease-%build_flavor/source" + cd %buildroot + for file in boot/symtypes*; do + l="${file##*/}" + l="lib/modules/%kernelrelease-%build_flavor/${l//-%kernelrelease-%build_flavor}" + mv "$file" "%{buildroot}/$l" + ln -s "../$l" $file + echo "/$l" + echo "%%ghost /$file" + done +} | add_dirs_to_filelist >%my_builddir/kernel-devel.files ( cd %buildroot ; find .%obj_install_dir/%cpu_arch_flavor -type f ; ) | \ sed -e 's/^[.]//' | grep -v -e '[.]ipa-clones$' -e '/Symbols[.]list$' -e '/ipa-clones[.]list$'| \ add_dirs_to_filelist >> %my_builddir/kernel-devel.files @@ -828,6 +837,8 @@ add_dirs_to_filelist >> %my_builddir/kernel-devel.files echo %ghost /boot/initrd$suffix cd %buildroot for f in boot/*; do + l="${f##*/}" + l="lib/modules/%kernelrelease-%build_flavor/${l//-%kernelrelease-%build_flavor}" if test -L "$f"; then echo "%%ghost /$f" continue @@ -842,16 +853,22 @@ add_dirs_to_filelist >> %my_builddir/kernel-devel.files boot/vmlinux-*.%{compress_vmlinux}) ;; boot/vmlinux-*) - if $ghost_vmlinux; then - echo "%%ghost /$f" - continue - fi + [ "$ghost_vmlinux" != 'true' ] || echo -n "%%ghost " + ;; + boot/vmlinuz-*) + echo -n "%%attr(0644, root, root) " ;; boot/symtypes*) + echo "%exclude /$l" continue ;; esac - echo "%%attr(0644, root, root) /$f" + mv "$f" "$l" + ln -s "../$l" $f + # the find in the CONFIG_MODULES condition below also finds the files + # but there's sort -u later, so this is ok + echo "/$l" + echo "%%ghost /$f" done if [ %CONFIG_MODULES = y ]; then @@ -860,7 +877,11 @@ add_dirs_to_filelist >> %my_builddir/kernel-devel.files \( -path '*/modules.*' ! -path '*/modules.order' \ ! -path '*/modules.builtin' \ ! -path '*/modules.builtin.modinfo' \) -printf '%%%%ghost /%%p\n' \ - -o -name '*.ko' -prune -o -type f -printf '/%%p\n' + -o -name '*.ko' -prune \ + -o \( -type f \ + ! -path '*/symtypes*' \ + ! -path '*/vmlinu*' \ + \) -printf '/%%p\n' cat %my_builddir/base-modules fi if test %CONFIG_MODULE_SIG = "y" -a -d etc/uefi/certs; then diff --git a/rpm/post.sh b/rpm/post.sh index 052ae5a6fdd2..b5167ed99443 100644 --- a/rpm/post.sh +++ b/rpm/post.sh @@ -10,6 +10,23 @@ for x in /boot/@IMAGE@ /boot/initrd; do rm -f $x$suffix ln -s ${x##*/}-@KERNELRELEASE@-@FLAVOR@ $x$suffix done +# compat stuff for /boot. +# if /boot is not a speparate partition we can just link the kernel +# there to save space. Otherwise copy. +if mountpoint -q /boot; then + copy_or_link="cp -a" +else + copy_or_link="ln -sf" +fi +# XXX: need to fix suse-module-tools for sysctl.conf and System.map +for x in @IMAGE@ sysctl.conf System.map; do + if [ ! -e /boot/$x-@KERNELRELEASE@-@FLAVOR@ ]; then + $copy_or_link ../lib/modules/@KERNELRELEASE@-@FLAVOR@/$x /boot/$x-@KERNELRELEASE@-@FLAVOR@ + if [ -e /lib/modules/@KERNELRELEASE@-@FLAVOR@/.$x.hmac ]; then + $copy_or_link ../lib/modules/@KERNELRELEASE@-@FLAVOR@/.$x.hmac /boot/.$x-@KERNELRELEASE@-@FLAVOR@.hmac + fi + fi +done # Add symlinks of compatible modules to /lib/modules/$krel/weak-updates/, # run depmod and mkinitrd diff --git a/rpm/postun.sh b/rpm/postun.sh index d5165044abc4..4da20759f3ff 100644 --- a/rpm/postun.sh +++ b/rpm/postun.sh @@ -6,7 +6,7 @@ rm -f /boot/do_purge_kernels wm2=/usr/lib/module-init-tools/weak-modules2 nvr=@SUBPACKAGE@-@RPM_VERSION_RELEASE@ -if [ -e /boot/System.map-@KERNELRELEASE@-@FLAVOR@ ]; then +if [ -e /lib/modules/@KERNELRELEASE@-@FLAVOR@/System.map ]; then # the same package was reinstalled or just rebuilt, otherwise the files # would have been deleted by now # do not remove anything in this case (bnc#533766) -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Mon, Apr 19, 2021 at 06:06:47PM +0200, Ludwig Nussel wrote: > Olaf Hering wrote: > > Am Mon, 12 Apr 2021 10:46:48 +0200 > > schrieb Ludwig Nussel: > > > > > Does anyone have a better idea or can we just follow Fedora's approach here? > > > > Since the reasons for "/boot" are obsolete since more than a decade, just go ahead. > > > > Just make sure to provide the equivalent of "/boot/vmlinuz" and > > "/boot/initrd", a pointer to the last installed kernel. This can > > very well be stored somewhere in "/usr". > > Here's my suggestion to move the kernel related read-only files from > /boot to /lib/modules/%kernelrelease-%build_flavor What do we get exactly by moving from /boot to /lib? Isn't /lib as much obsolete as /boot? Thanks Michal > > 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 as a start. 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. > > Longer term I'd expect that logic to move out of the kernel's %post. > A possibility would be to go for systemd's kernel-install for > example. > > From 85d641c3099cc7f9e2189cb84601cbbf805c75ed Mon Sep 17 00:00:00 2001 > From: Ludwig Nussel > Date: Mon, 12 Apr 2021 13:26:04 +0200 > Subject: [PATCH] Move files in /boot to modules dir > > --- > rpm/kernel-binary.spec.in | 47 ++++++++++++++++++++++++++++----------- > rpm/post.sh | 17 ++++++++++++++ > rpm/postun.sh | 2 +- > 3 files changed, 52 insertions(+), 14 deletions(-) > > diff --git a/rpm/kernel-binary.spec.in b/rpm/kernel-binary.spec.in > index 40433d95cea4..068ce7dc54da 100644 > --- a/rpm/kernel-binary.spec.in > +++ b/rpm/kernel-binary.spec.in > @@ -530,10 +530,10 @@ add_vmlinux() > # sign the modules, firmware and possibly the kernel in the buildservice > BRP_PESIGN_FILES="" > %if "%CONFIG_EFI_STUB" == "y" > -BRP_PESIGN_FILES="/boot/$image-%kernelrelease-%build_flavor" > +BRP_PESIGN_FILES="/lib/modules/%kernelrelease-%build_flavor/$image" > %endif > %ifarch s390x ppc64 ppc64le > -BRP_PESIGN_FILES="/boot/$image-%kernelrelease-%build_flavor" > +BRP_PESIGN_FILES="/lib/modules/%kernelrelease-%build_flavor/$image" > %endif > %if "%CONFIG_MODULE_SIG" == "y" > BRP_PESIGN_FILES="$BRP_PESIGN_FILES *.ko" > @@ -803,7 +803,7 @@ add_dirs_to_filelist() { > # print all parents > :a > # skip directories owned by other packages > - s:^%%dir (/boot|/etc|/lib/(modules|firmware)|/usr/src)/[^/]+$:: > + s:^%%dir (/boot|/etc|(/usr)?/lib/(modules|firmware)|/usr/src)/[^/]+$:: > s:/[^/]+$::p > ta > ' "$@" | sort -u > @@ -816,10 +816,19 @@ fi > > shopt -s nullglob dotglob > > %my_builddir/kernel-devel.files > -for file in %buildroot/boot/symtypes* %buildroot/lib/modules/*/{build,source}; do > - f=${file##%buildroot} > - echo "$f" > -done | add_dirs_to_filelist >%my_builddir/kernel-devel.files > +{ > + echo "/lib/modules/%kernelrelease-%build_flavor/build" > + echo "/lib/modules/%kernelrelease-%build_flavor/source" > + cd %buildroot > + for file in boot/symtypes*; do > + l="${file##*/}" > + l="lib/modules/%kernelrelease-%build_flavor/${l//-%kernelrelease-%build_flavor}" > + mv "$file" "%{buildroot}/$l" > + ln -s "../$l" $file > + echo "/$l" > + echo "%%ghost /$file" > + done > +} | add_dirs_to_filelist >%my_builddir/kernel-devel.files > ( cd %buildroot ; find .%obj_install_dir/%cpu_arch_flavor -type f ; ) | \ > sed -e 's/^[.]//' | grep -v -e '[.]ipa-clones$' -e '/Symbols[.]list$' -e '/ipa-clones[.]list$'| \ > add_dirs_to_filelist >> %my_builddir/kernel-devel.files > @@ -828,6 +837,8 @@ add_dirs_to_filelist >> %my_builddir/kernel-devel.files > echo %ghost /boot/initrd$suffix > cd %buildroot > for f in boot/*; do > + l="${f##*/}" > + l="lib/modules/%kernelrelease-%build_flavor/${l//-%kernelrelease-%build_flavor}" > if test -L "$f"; then > echo "%%ghost /$f" > continue > @@ -842,16 +853,22 @@ add_dirs_to_filelist >> %my_builddir/kernel-devel.files > boot/vmlinux-*.%{compress_vmlinux}) > ;; > boot/vmlinux-*) > - if $ghost_vmlinux; then > - echo "%%ghost /$f" > - continue > - fi > + [ "$ghost_vmlinux" != 'true' ] || echo -n "%%ghost " > + ;; > + boot/vmlinuz-*) > + echo -n "%%attr(0644, root, root) " > ;; > boot/symtypes*) > + echo "%exclude /$l" > continue > ;; > esac > - echo "%%attr(0644, root, root) /$f" > + mv "$f" "$l" > + ln -s "../$l" $f > + # the find in the CONFIG_MODULES condition below also finds the files > + # but there's sort -u later, so this is ok > + echo "/$l" > + echo "%%ghost /$f" > done > > if [ %CONFIG_MODULES = y ]; then > @@ -860,7 +877,11 @@ add_dirs_to_filelist >> %my_builddir/kernel-devel.files > \( -path '*/modules.*' ! -path '*/modules.order' \ > ! -path '*/modules.builtin' \ > ! -path '*/modules.builtin.modinfo' \) -printf '%%%%ghost /%%p\n' \ > - -o -name '*.ko' -prune -o -type f -printf '/%%p\n' > + -o -name '*.ko' -prune \ > + -o \( -type f \ > + ! -path '*/symtypes*' \ > + ! -path '*/vmlinu*' \ > + \) -printf '/%%p\n' > cat %my_builddir/base-modules > fi > if test %CONFIG_MODULE_SIG = "y" -a -d etc/uefi/certs; then > diff --git a/rpm/post.sh b/rpm/post.sh > index 052ae5a6fdd2..b5167ed99443 100644 > --- a/rpm/post.sh > +++ b/rpm/post.sh > @@ -10,6 +10,23 @@ for x in /boot/@IMAGE@ /boot/initrd; do > rm -f $x$suffix > ln -s ${x##*/}-@KERNELRELEASE@-@FLAVOR@ $x$suffix > done > +# compat stuff for /boot. > +# if /boot is not a speparate partition we can just link the kernel > +# there to save space. Otherwise copy. > +if mountpoint -q /boot; then > + copy_or_link="cp -a" > +else > + copy_or_link="ln -sf" > +fi > +# XXX: need to fix suse-module-tools for sysctl.conf and System.map > +for x in @IMAGE@ sysctl.conf System.map; do > + if [ ! -e /boot/$x-@KERNELRELEASE@-@FLAVOR@ ]; then > + $copy_or_link ../lib/modules/@KERNELRELEASE@-@FLAVOR@/$x /boot/$x-@KERNELRELEASE@-@FLAVOR@ > + if [ -e /lib/modules/@KERNELRELEASE@-@FLAVOR@/.$x.hmac ]; then > + $copy_or_link ../lib/modules/@KERNELRELEASE@-@FLAVOR@/.$x.hmac /boot/.$x-@KERNELRELEASE@-@FLAVOR@.hmac > + fi > + fi > +done > > # Add symlinks of compatible modules to /lib/modules/$krel/weak-updates/, > # run depmod and mkinitrd > diff --git a/rpm/postun.sh b/rpm/postun.sh > index d5165044abc4..4da20759f3ff 100644 > --- a/rpm/postun.sh > +++ b/rpm/postun.sh > @@ -6,7 +6,7 @@ rm -f /boot/do_purge_kernels > wm2=/usr/lib/module-init-tools/weak-modules2 > nvr=@SUBPACKAGE@-@RPM_VERSION_RELEASE@ > > -if [ -e /boot/System.map-@KERNELRELEASE@-@FLAVOR@ ]; then > +if [ -e /lib/modules/@KERNELRELEASE@-@FLAVOR@/System.map ]; then > # the same package was reinstalled or just rebuilt, otherwise the files > # would have been deleted by now > # do not remove anything in this case (bnc#533766) > > -- > (o_ Ludwig Nussel > //\ > V_/_ http://www.suse.com/ > SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer > HRB 36809 (AG Nürnberg)
Michal Suchánek wrote:
On Mon, Apr 19, 2021 at 06:06:47PM +0200, Ludwig Nussel wrote:
Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: Does anyone have a better idea or can we just follow Fedora's approach here?
Since the reasons for "/boot" are obsolete since more than a decade, just go ahead.
Just make sure to provide the equivalent of "/boot/vmlinuz" and "/boot/initrd", a pointer to the last installed kernel. This can very well be stored somewhere in "/usr".
Here's my suggestion to move the kernel related read-only files from /boot to /lib/modules/%kernelrelease-%build_flavor
What do we get exactly by moving from /boot to /lib?
Isn't /lib as much obsolete as /boot?
Yes and no. In the usrmerge case /lib is a symlink to /usr/lib. RPM happily follows that. So there is no urgent need for packages to actually install to /usr. That's why I so far did not touch any packages that do not produce a usrmerge conflict. Longer term I suppose we do want to adjust all packages to install into /usr for consistency. So we do not need to serialize the efforts and wait for usrmerge to actually happen. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Mon, Apr 19, 2021 at 06:58:25PM +0200, Ludwig Nussel wrote:
Michal Suchánek wrote:
On Mon, Apr 19, 2021 at 06:06:47PM +0200, Ludwig Nussel wrote:
Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: Does anyone have a better idea or can we just follow Fedora's approach here?
Since the reasons for "/boot" are obsolete since more than a decade, just go ahead.
Just make sure to provide the equivalent of "/boot/vmlinuz" and "/boot/initrd", a pointer to the last installed kernel. This can very well be stored somewhere in "/usr".
Here's my suggestion to move the kernel related read-only files from /boot to /lib/modules/%kernelrelease-%build_flavor
What do we get exactly by moving from /boot to /lib?
Isn't /lib as much obsolete as /boot?
Yes and no. In the usrmerge case /lib is a symlink to /usr/lib. RPM happily follows that. So there is no urgent need for packages to actually install to /usr. That's why I so far did not touch any packages that do not produce a usrmerge conflict. Longer term I suppose we do want to adjust all packages to install into /usr for consistency.
So we do not need to serialize the efforts and wait for usrmerge to actually happen.
On the other hand, if we expect that the kernel needs to be adjusted again to install into usr maybe it makes sense to do in one go rather than having 3 different variants of where kernel installs. Thanks Michal
Michal Suchánek wrote:
On Mon, Apr 19, 2021 at 06:58:25PM +0200, Ludwig Nussel wrote:
Michal Suchánek wrote:
On Mon, Apr 19, 2021 at 06:06:47PM +0200, Ludwig Nussel wrote:
Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: Does anyone have a better idea or can we just follow Fedora's approach here?
Since the reasons for "/boot" are obsolete since more than a decade, just go ahead.
Just make sure to provide the equivalent of "/boot/vmlinuz" and "/boot/initrd", a pointer to the last installed kernel. This can very well be stored somewhere in "/usr".
Here's my suggestion to move the kernel related read-only files from /boot to /lib/modules/%kernelrelease-%build_flavor
What do we get exactly by moving from /boot to /lib?
Isn't /lib as much obsolete as /boot?
Yes and no. In the usrmerge case /lib is a symlink to /usr/lib. RPM happily follows that. So there is no urgent need for packages to actually install to /usr. That's why I so far did not touch any packages that do not produce a usrmerge conflict. Longer term I suppose we do want to adjust all packages to install into /usr for consistency.
So we do not need to serialize the efforts and wait for usrmerge to actually happen.
On the other hand, if we expect that the kernel needs to be adjusted again to install into usr maybe it makes sense to do in one go rather than having 3 different variants of where kernel installs.
Sure, fair point. If timing is the only concern I'd count that as +1 on the general approach at least :-) Btw talking about different variants where the kernel installs... Would it make sense to have a consistent kernel file name across architectures? Right now it might be vmlinuz, vmlinux, Image, image or zImage¹. cu Ludwig [1] https://github.com/openSUSE/installation-images/blob/master/etc/config#L16 -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On 19.04.2021 19:06, Ludwig Nussel wrote:
Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: Does anyone have a better idea or can we just follow Fedora's approach here?
Since the reasons for "/boot" are obsolete since more than a decade, just go ahead.
Just make sure to provide the equivalent of "/boot/vmlinuz" and "/boot/initrd", a pointer to the last installed kernel. This can very well be stored somewhere in "/usr".
Here's my suggestion to move the kernel related read-only files from /boot to /lib/modules/%kernelrelease-%build_flavor
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 as a start. Some tools require adjustments before we can drop those links. If boot is a separate partition, a copy is used instead of a link.
Cross-filesystem links do not work in grub so you need to modify grub to look for kernels and load them from /lib. Not sure if dracut needs fixing too. And I still do not understand the problem that you are trying to solve or what you gain by having kernel in /lib.
Am Mon, 12 Apr 2021 10:46:48 +0200
schrieb Ludwig Nussel
One of the motivations for UsrMerge is to have all read-only parts of the operating system in /usr. The kernel packages install files in /boot though which isn't in line with that idea.
Meanwhile I think all the files below /boot are part of the same state that is supposed to be within the single to-be-snapshotted subvolume. As such the entire directory should be moved to /usr. What would be the benefit to duplicate files like vmlinuz-version, xen.gz or grub2/* out of /usr back to /boot? Those who currently must use a dedicated /boot, because they have to use an incapable bootloader, could adjust their fstab and mount the thing on /usr/boot instead, and everything will likely continue to work for them. Such setups can not benefit from the single atomic snapshot anyway. Olaf
On 20.04.2021 00:51, Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: One of the motivations for UsrMerge is to have all read-only parts of the operating system in /usr. The kernel packages install files in /boot though which isn't in line with that idea.
Meanwhile I think all the files below /boot are part of the same state that is supposed to be within the single to-be-snapshotted subvolume. As such the entire directory should be moved to /usr. What would be the benefit to duplicate files like vmlinuz-version, xen.gz or grub2/* out of /usr back to /boot?
/usr is supposed to contain pristine distribution content and be common to and identical for any system using this OS version. Initrd is specific to each system and generated at run time, so it obviously does not fit there. Unless intention is to switch to common giant initrd.
Andrei Borzenkov wrote:
On 19.04.2021 19:06, Ludwig Nussel wrote:
Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: Does anyone have a better idea or can we just follow Fedora's approach here?
Since the reasons for "/boot" are obsolete since more than a decade, just go ahead.
Just make sure to provide the equivalent of "/boot/vmlinuz" and "/boot/initrd", a pointer to the last installed kernel. This can very well be stored somewhere in "/usr".
Here's my suggestion to move the kernel related read-only files from /boot to /lib/modules/%kernelrelease-%build_flavor
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 as a start. Some tools require adjustments before we can drop those links. If boot is a separate partition, a copy is used instead of a link.
Cross-filesystem links do not work in grub so you need to modify grub to look for kernels and load them from /lib. Not sure if dracut needs fixing too.
There is no cross filesystem link. Symlinks are used if /boot is on the same FS (could also use hardlinks if desired) and a copy if not. I'd be surprised if dracut would be problematic though as Fedora already moved the kernel out of /boot six years ago.
And I still do not understand the problem that you are trying to solve or what you gain by having kernel in /lib.
Well in the end erasing technical debt. /lib is not the goal though, /usr/lib is. Since /lib will turn into a symlink with usrmerge and rpm follows that, we do not strictly need to explicitly install into /usr. Interestingly Fedora still does not use /usr in kernel.spec, even after almost a decade of usrmerge. Anyway, I've tried to explain the general direction in this article: https://lnussel.github.io/2020/12/16/fslayout/ cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Tue, Apr 20, 2021 at 07:30:52AM +0300, Andrei Borzenkov wrote:
On 20.04.2021 00:51, Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: One of the motivations for UsrMerge is to have all read-only parts of the operating system in /usr. The kernel packages install files in /boot though which isn't in line with that idea.
Meanwhile I think all the files below /boot are part of the same state that is supposed to be within the single to-be-snapshotted subvolume. As such the entire directory should be moved to /usr. What would be the benefit to duplicate files like vmlinuz-version, xen.gz or grub2/* out of /usr back to /boot?
/usr is supposed to contain pristine distribution content and be common to and identical for any system using this OS version. Initrd is specific to each system and generated at run time, so it obviously does not fit there. Unless intention is to switch to common giant initrd.
AFAIK we are using common giant initrd by default. You can change the content by making changes to settings in /etc, though. Which is the reason it is probably not fit for /usr. Having the ramdisk and the tekrnel in separate location will make the bootloader configuration needlessly convoluted so the only reasonable way to get sane bootloader configuration is to symlink or copy the kernel alongside the initrd. Thanks Michal
Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: One of the motivations for UsrMerge is to have all read-only parts of the operating system in /usr. The kernel packages install files in /boot though which isn't in line with that idea.
Meanwhile I think all the files below /boot are part of the same state that is supposed to be within the single to-be-snapshotted subvolume. As such the entire directory should be moved to /usr. What would be the benefit to duplicate files like vmlinuz-version, xen.gz or grub2/* out of /usr back to /boot?
For the kernel there is no duplication if /boot is on the same volume. Those grub files on the other hand already are copies today.
Those who currently must use a dedicated /boot, because they have to use an incapable bootloader, could adjust their fstab and mount the thing on /usr/boot instead, and everything will likely continue to work for them. Such setups can not benefit from the single atomic snapshot anyway.
I believe we cannot avoid improving the tooling to manage the boot files better. The tool has to be aware of the available snapshots/OS revisions and configure the bootloader, generate the initrd, copy/link the kernel etc accordingly. Having rpm drop the kernel unconditionally into /boot and then some %post script that generates the initrd and updates grub has been fragile always. "incapable" bootloader might be considered a feature rather than a bug btw :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Dne 15. 04. 21 v 14:16 Petr Vorel napsal(a):
On 14.04.2021 21:05, Petr Vorel wrote:
On 2021/04/13 22:24, Oliver Neukum wrote:
I have worse cases for you. / can be on LVM. The assumption that a block cannot move without FS action is just not right.
Hey, many tell folks that boot should be a normal disk. Encrypted and raids...tend to be less well supported. Yes, things like "full disk encryption" (LVM on LUKS on whole disk, i.e. without separate /boot) is not supported by openSUSE installer :(.
Really? Have you tried? Hm, I cannot find the bug I filled in 2017, which ended as wontfix. But right, things might have changed, I'll retest it.
Even if this works, how would GRUB read its configuration file from an encrypted disk? Are you suggesting that GRUB asks for the password first? And then the Linux OS asks for this password again before it can mount the root filesystem? How is this an improvement over a separate /boot partition? Petr T
On Wed, Apr 28, 2021 at 05:27:00PM +0200, Petr Tesařík wrote:
Dne 15. 04. 21 v 14:16 Petr Vorel napsal(a):
On 14.04.2021 21:05, Petr Vorel wrote:
On 2021/04/13 22:24, Oliver Neukum wrote:
I have worse cases for you. / can be on LVM. The assumption that a block cannot move without FS action is just not right.
Hey, many tell folks that boot should be a normal disk. Encrypted and raids...tend to be less well supported. Yes, things like "full disk encryption" (LVM on LUKS on whole disk, i.e. without separate /boot) is not supported by openSUSE installer :(.
Really? Have you tried? Hm, I cannot find the bug I filled in 2017, which ended as wontfix. But right, things might have changed, I'll retest it.
Even if this works, how would GRUB read its configuration file from an encrypted disk? Are you suggesting that GRUB asks for the password first? And then the Linux OS asks for this password again before it can mount the root filesystem? How is this an improvement over a separate /boot partition?
I can confirm that since 15.1 the /boot partition is not necessary anymore even if the main disk is encrypted. But as you suggested the downside is that you have to type two times the encryption password: the first time for grub and the second time when systemd mounts the disk. I personelly still use the separate unencrypted /boot partition. It is however a weak point. An attacker that can have physycal access to the computer can replace the content of /boot and then compromise the system. Giacomo
On Wed, Apr 28, 2021 at 05:27:00PM +0200, Petr Tesařík wrote:
Dne 15. 04. 21 v 14:16 Petr Vorel napsal(a):
On 14.04.2021 21:05, Petr Vorel wrote:
On 2021/04/13 22:24, Oliver Neukum wrote:
I have worse cases for you. / can be on LVM. The assumption that a block cannot move without FS action is just not right.
Hey, many tell folks that boot should be a normal disk. Encrypted and raids...tend to be less well supported. Yes, things like "full disk encryption" (LVM on LUKS on whole disk, i.e. without separate /boot) is not supported by openSUSE installer :(.
Really? Have you tried? Hm, I cannot find the bug I filled in 2017, which ended as wontfix. But right, things might have changed, I'll retest it.
Even if this works, how would GRUB read its configuration file from an encrypted disk? Are you suggesting that GRUB asks for the password first? And then the Linux OS asks for this password again before it can mount the root filesystem? How is this an improvement over a separate /boot partition?
Yes, two password prompts is the standard thse days. Clearly there is also the problem that whenever Linux gains support for a new RAID or similar scheme grub does not support it immediately and for some time separate /boot is needed. Thanks Michal
On 28.04.2021 18:27, Petr Tesařík wrote:
Dne 15. 04. 21 v 14:16 Petr Vorel napsal(a):
On 14.04.2021 21:05, Petr Vorel wrote:
On 2021/04/13 22:24, Oliver Neukum wrote:
I have worse cases for you. / can be on LVM. The assumption that a block cannot move without FS action is just not right.
Hey, many tell folks that boot should be a normal disk. Encrypted and raids...tend to be less well supported. Yes, things like "full disk encryption" (LVM on LUKS on whole disk, i.e. without separate /boot) is not supported by openSUSE installer :(.
Really? Have you tried? Hm, I cannot find the bug I filled in 2017, which ended as wontfix. But right, things might have changed, I'll retest it.
Even if this works, how would GRUB read its configuration file from an encrypted disk? Are you suggesting that GRUB asks for the password first?
Yes.
And then the Linux OS asks for this password again before it can mount the root filesystem?
It is possible to avoid it (arguably with lowered security) by storing keys in initrd.
How is this an improvement over a separate /boot partition?
You are welcome to implement protocol to pass secrets between bootloader and kernel. Some of *BSD flavors support it and it is also implemented in grub.
Dne 28. 04. 21 v 19:20 Andrei Borzenkov napsal(a):
On 28.04.2021 18:27, Petr Tesařík wrote:
Dne 15. 04. 21 v 14:16 Petr Vorel napsal(a):
On 14.04.2021 21:05, Petr Vorel wrote:
On 2021/04/13 22:24, Oliver Neukum wrote: > I have worse cases for you. / can be on LVM. > The assumption that a block cannot move without FS action is just > not right. ---- Hey, many tell folks that boot should be a normal disk. Encrypted and raids...tend to be less well supported. Yes, things like "full disk encryption" (LVM on LUKS on whole disk, i.e. without separate /boot) is not supported by openSUSE installer :(. Really? Have you tried? Hm, I cannot find the bug I filled in 2017, which ended as wontfix. But right, things might have changed, I'll retest it. Even if this works, how would GRUB read its configuration file from an encrypted disk? Are you suggesting that GRUB asks for the password first? Yes.
And then the Linux OS asks for this password again before it can mount the root filesystem? It is possible to avoid it (arguably with lowered security) by storing keys in initrd.
How is this an improvement over a separate /boot partition?
You are welcome to implement protocol to pass secrets between bootloader and kernel. Some of *BSD flavors support it and it is also implemented in grub.
That's not my point. My point is that there is nothing secret stored under /boot. If it is a separate partition, it may be left unencrypted, avoiding the need to give a password to the boot loader. That's how my system boots today. If the kernel is moved to /usr (encrypted in my setup), I'll end up typing my disk password twice on each boot, and I perceive it as a regression. Just my two cents Petr T
Dne 28. 04. 21 v 19:20 Andrei Borzenkov napsal(a):
On 28.04.2021 18:27, Petr Tesařík wrote:
Dne 15. 04. 21 v 14:16 Petr Vorel napsal(a):
On 14.04.2021 21:05, Petr Vorel wrote:
> On 2021/04/13 22:24, Oliver Neukum wrote: > > I have worse cases for you. / can be on LVM. > > The assumption that a block cannot move without FS action is just > > not right. > ---- > Hey, many tell folks that boot should be a normal disk. > Encrypted and raids...tend to be less well supported. Yes, things like "full disk encryption" (LVM on LUKS on whole disk, i.e. without separate /boot) is not supported by openSUSE installer :(. Really? Have you tried? Hm, I cannot find the bug I filled in 2017, which ended as wontfix. But right, things might have changed, I'll retest it. Even if this works, how would GRUB read its configuration file from an encrypted disk? Are you suggesting that GRUB asks for the password first? Yes.
And then the Linux OS asks for this password again before it can mount the root filesystem? It is possible to avoid it (arguably with lowered security) by storing keys in initrd.
How is this an improvement over a separate /boot partition?
You are welcome to implement protocol to pass secrets between bootloader and kernel. Some of *BSD flavors support it and it is also implemented in grub.
That's not my point. My point is that there is nothing secret stored under /boot. If it is a separate partition, it may be left unencrypted, avoiding the need to give a password to the boot loader. That's how my system boots today. If the kernel is moved to /usr (encrypted in my setup), I'll end up typing my disk password twice on each boot, and I perceive it as a regression.
Do we support /etc/crypttab [1]? That allows passing the password from grub to initrd. But I have experience only with the Debian implementation [2]. Kind regards, Petr [1] https://man7.org/linux/man-pages/man5/crypttab.5.html [2] https://linux.die.net/man/5/crypttab
Just my two cents
Petr T
On 28.04.2021 23:11, Petr Vorel wrote:
Dne 28. 04. 21 v 19:20 Andrei Borzenkov napsal(a):
On 28.04.2021 18:27, Petr Tesařík wrote:
Dne 15. 04. 21 v 14:16 Petr Vorel napsal(a):
On 14.04.2021 21:05, Petr Vorel wrote: >> On 2021/04/13 22:24, Oliver Neukum wrote: >>> I have worse cases for you. / can be on LVM. >>> The assumption that a block cannot move without FS action is just >>> not right. >> ---- >> Hey, many tell folks that boot should be a normal disk. >> Encrypted and raids...tend to be less well supported. > Yes, things like "full disk encryption" (LVM on LUKS on whole disk, > i.e. without separate /boot) is not supported by openSUSE installer :(. Really? Have you tried? Hm, I cannot find the bug I filled in 2017, which ended as wontfix. But right, things might have changed, I'll retest it. Even if this works, how would GRUB read its configuration file from an encrypted disk? Are you suggesting that GRUB asks for the password first? Yes.
And then the Linux OS asks for this password again before it can mount the root filesystem? It is possible to avoid it (arguably with lowered security) by storing keys in initrd.
How is this an improvement over a separate /boot partition?
You are welcome to implement protocol to pass secrets between bootloader and kernel. Some of *BSD flavors support it and it is also implemented in grub.
That's not my point. My point is that there is nothing secret stored under /boot. If it is a separate partition, it may be left unencrypted, avoiding the need to give a password to the boot loader. That's how my system boots today. If the kernel is moved to /usr (encrypted in my setup), I'll end up typing my disk password twice on each boot, and I perceive it as a regression.
Do we support /etc/crypttab [1]?
Is it a joke?
That allows passing the password from grub to initrd.
Not that I am aware of. Care to elaborate?
But I have experience only with the Debian implementation [2].
Kind regards, Petr
[1] https://man7.org/linux/man-pages/man5/crypttab.5.html [2] https://linux.die.net/man/5/crypttab
Just my two cents
Petr T
On 28.04.2021 23:11, Petr Vorel wrote:
Dne 28. 04. 21 v 19:20 Andrei Borzenkov napsal(a):
On 28.04.2021 18:27, Petr Tesařík wrote:
Dne 15. 04. 21 v 14:16 Petr Vorel napsal(a):
> On 14.04.2021 21:05, Petr Vorel wrote: >>> On 2021/04/13 22:24, Oliver Neukum wrote: >>>> I have worse cases for you. / can be on LVM. >>>> The assumption that a block cannot move without FS action is just >>>> not right. >>> ---- >>> Hey, many tell folks that boot should be a normal disk. >>> Encrypted and raids...tend to be less well supported. >> Yes, things like "full disk encryption" (LVM on LUKS on whole disk, >> i.e. without separate /boot) is not supported by openSUSE installer :(. > Really? Have you tried? Hm, I cannot find the bug I filled in 2017, which ended as wontfix. But right, things might have changed, I'll retest it. Even if this works, how would GRUB read its configuration file from an encrypted disk? Are you suggesting that GRUB asks for the password first? Yes.
And then the Linux OS asks for this password again before it can mount the root filesystem? It is possible to avoid it (arguably with lowered security) by storing keys in initrd.
How is this an improvement over a separate /boot partition?
You are welcome to implement protocol to pass secrets between bootloader and kernel. Some of *BSD flavors support it and it is also implemented in grub.
That's not my point. My point is that there is nothing secret stored under /boot. If it is a separate partition, it may be left unencrypted, avoiding the need to give a password to the boot loader. That's how my system boots today. If the kernel is moved to /usr (encrypted in my setup), I'll end up typing my disk password twice on each boot, and I perceive it as a regression.
Do we support /etc/crypttab [1]?
Is it a joke? Not sure what particularly you mean :). But yes, I see we use it in openSUSE as well for adding cryptdevice config.
Well, it's not all. And I forgot the other pieces [3]: hook for initramfs (to copy "password" file crypto_keyfile.bin) and grub config (adding cryptdevice to GRUB_CMDLINE_LINUX and GRUB_ENABLE_CRYPTODISK=yes)
That allows passing the password from grub to initrd.
Not that I am aware of. Care to elaborate? [3]. Obviously we'd need to transform /etc/initramfs-tools/hooks/crypto_keyfile into Dracut hook (IMHO trivial).
BTW with further tweaking and some limitations it works with LUKS2 :). Kind regards, Petr [3] https://unixsheikh.com/tutorials/real-full-disk-encryption-using-grub-on-deb...
But I have experience only with the Debian implementation [2].
Kind regards, Petr
[1] https://man7.org/linux/man-pages/man5/crypttab.5.html [2] https://linux.die.net/man/5/crypttab
Just my two cents
Petr T
On Thu, Apr 29, 2021 at 12:30 PM Petr Vorel
On 28.04.2021 23:11, Petr Vorel wrote:
Dne 28. 04. 21 v 19:20 Andrei Borzenkov napsal(a):
On 28.04.2021 18:27, Petr Tesařík wrote:
Dne 15. 04. 21 v 14:16 Petr Vorel napsal(a): >> On 14.04.2021 21:05, Petr Vorel wrote: >>>> On 2021/04/13 22:24, Oliver Neukum wrote: >>>>> I have worse cases for you. / can be on LVM. >>>>> The assumption that a block cannot move without FS action is just >>>>> not right. >>>> ---- >>>> Hey, many tell folks that boot should be a normal disk. >>>> Encrypted and raids...tend to be less well supported. >>> Yes, things like "full disk encryption" (LVM on LUKS on whole disk, >>> i.e. without separate /boot) is not supported by openSUSE installer :(. >> Really? Have you tried? > Hm, I cannot find the bug I filled in 2017, which ended as wontfix. > But right, things might have changed, I'll retest it. Even if this works, how would GRUB read its configuration file from an encrypted disk? Are you suggesting that GRUB asks for the password first? Yes.
And then the Linux OS asks for this password again before it can mount the root filesystem? It is possible to avoid it (arguably with lowered security) by storing keys in initrd.
How is this an improvement over a separate /boot partition?
You are welcome to implement protocol to pass secrets between bootloader and kernel. Some of *BSD flavors support it and it is also implemented in grub.
That's not my point. My point is that there is nothing secret stored under /boot. If it is a separate partition, it may be left unencrypted, avoiding the need to give a password to the boot loader. That's how my system boots today. If the kernel is moved to /usr (encrypted in my setup), I'll end up typing my disk password twice on each boot, and I perceive it as a regression.
Do we support /etc/crypttab [1]?
Is it a joke? Not sure what particularly you mean :). But yes, I see we use it in openSUSE as well for adding cryptdevice config.
Well, it's not all. And I forgot the other pieces [3]: hook for initramfs (to copy "password" file crypto_keyfile.bin) and grub config (adding cryptdevice to GRUB_CMDLINE_LINUX and GRUB_ENABLE_CRYPTODISK=yes)
That allows passing the password from grub to initrd.
That's not "passing secret from bootloader to kernel". That is "storing key in initrd" which I already mentioned.
Dne 29. 04. 21 v 11:30 Petr Vorel napsal(a):
On 28.04.2021 23:11, Petr Vorel wrote:
That allows passing the password from grub to initrd.
Not that I am aware of. Care to elaborate? [3]. Obviously we'd need to transform /etc/initramfs-tools/hooks/crypto_keyfile into Dracut hook (IMHO trivial).
BTW with further tweaking and some limitations it works with LUKS2 :).
Can you be more specific about the limitations? IIRC the openSUSE default PBKDF for LUKS2-encrypted disks is Argon2i, but GRUB does not implement this key-derivation function, so my system would become unbootable, unless I make sure to configure one keyslot explicitly to PBKDF2. Is that what you mean? Well, I would once again perceive it as a regression. Just my two cents, Petr T
On Wed, Apr 28, 2021 at 8:47 PM Petr Tesařík
That's not my point. My point is that there is nothing secret stored under /boot. If it is a separate partition, it may be left unencrypted, avoiding the need to give a password to the boot loader.
Currently neither grub.cfg nor initrd are verified. Which means it is possible to install modified initrd which takes over after you unlocked root.
Dne 29. 04. 21 v 11:30 Petr Vorel napsal(a):
On 28.04.2021 23:11, Petr Vorel wrote:
That allows passing the password from grub to initrd.
Not that I am aware of. Care to elaborate? [3]. Obviously we'd need to transform /etc/initramfs-tools/hooks/crypto_keyfile into Dracut hook (IMHO trivial).
BTW with further tweaking and some limitations it works with LUKS2 :).
Can you be more specific about the limitations?
IIRC the openSUSE default PBKDF for LUKS2-encrypted disks is Argon2i, but GRUB does not implement this key-derivation function, so my system would become unbootable, unless I make sure to configure one keyslot explicitly to PBKDF2. Yes, missing Argon2i is the main limitation. Converting to PBKDF2 is trivial, but it has to be handled once yast gets support for LUKS2. I suppose Patrick Steinhardt is planning to add it, but after grub-2.06 (decided few months ago - before grub-2.06-rc1).
Other limitation is missing LUKS2 detection in grub-probe. https://savannah.gnu.org/bugs/?55093 IMHO it shouldn't be that difficult to implement it. Kind regards, Petr
Is that what you mean? Well, I would once again perceive it as a regression.
Just my two cents, Petr T
On Thu, Apr 29, 2021 at 12:30 PM Petr Vorel
wrote:
On 28.04.2021 23:11, Petr Vorel wrote:
Dne 28. 04. 21 v 19:20 Andrei Borzenkov napsal(a):
On 28.04.2021 18:27, Petr Tesařík wrote: > Dne 15. 04. 21 v 14:16 Petr Vorel napsal(a): >>> On 14.04.2021 21:05, Petr Vorel wrote: >>>>> On 2021/04/13 22:24, Oliver Neukum wrote: >>>>>> I have worse cases for you. / can be on LVM. >>>>>> The assumption that a block cannot move without FS action is just >>>>>> not right. >>>>> ---- >>>>> Hey, many tell folks that boot should be a normal disk. >>>>> Encrypted and raids...tend to be less well supported. >>>> Yes, things like "full disk encryption" (LVM on LUKS on whole disk, >>>> i.e. without separate /boot) is not supported by openSUSE installer :(. >>> Really? Have you tried? >> Hm, I cannot find the bug I filled in 2017, which ended as wontfix. >> But right, things might have changed, I'll retest it. > Even if this works, how would GRUB read its configuration file from an > encrypted disk? Are you suggesting that GRUB asks for the password > first? Yes.
> And then the Linux OS asks for this password again before it can > mount the root filesystem? It is possible to avoid it (arguably with lowered security) by storing keys in initrd.
> How is this an improvement over a separate > /boot partition?
You are welcome to implement protocol to pass secrets between bootloader and kernel. Some of *BSD flavors support it and it is also implemented in grub.
That's not my point. My point is that there is nothing secret stored under /boot. If it is a separate partition, it may be left unencrypted, avoiding the need to give a password to the boot loader. That's how my system boots today. If the kernel is moved to /usr (encrypted in my setup), I'll end up typing my disk password twice on each boot, and I perceive it as a regression.
Do we support /etc/crypttab [1]?
Is it a joke? Not sure what particularly you mean :). But yes, I see we use it in openSUSE as well for adding cryptdevice config.
Well, it's not all. And I forgot the other pieces [3]: hook for initramfs (to copy "password" file crypto_keyfile.bin) and grub config (adding cryptdevice to GRUB_CMDLINE_LINUX and GRUB_ENABLE_CRYPTODISK=yes)
That allows passing the password from grub to initrd.
That's not "passing secret from bootloader to kernel". That is "storing key in initrd" which I already mentioned. OK, sorry. It's just it has the same effect for me (not having to type password twice).
Kind regards, Petr
On Wed, Apr 28, 2021 at 8:47 PM Petr Tesařík
wrote:
That's not my point. My point is that there is nothing secret stored under /boot. If it is a separate partition, it may be left unencrypted, avoiding the need to give a password to the boot loader.
Currently neither grub.cfg nor initrd are verified. Which means it is possible to install modified initrd which takes over after you unlocked root. Yes. That's why I'd prefer full disc encryption (LUKS on whole disc).
Kind regards, Petr
Dne 29. 04. 21 v 11:55 Andrei Borzenkov napsal(a):
That's not my point. My point is that there is nothing secret stored under /boot. If it is a separate partition, it may be left unencrypted, avoiding the need to give a password to the boot loader. Currently neither grub.cfg nor initrd are verified. Which means it is
On Wed, Apr 28, 2021 at 8:47 PM Petr Tesařík
wrote: possible to install modified initrd which takes over after you unlocked root.
If anyone can write to your disk, I think it's game over one way or another. But you can make it slightly harder for them, sure. Petr T
Ludwig Nussel wrote: >Olaf Hering wrote: >>Am Mon, 12 Apr 2021 10:46:48 +0200 >>schrieb Ludwig Nussel: >> >>>Does anyone have a better idea or can we just follow Fedora's approach here? >> >>Since the reasons for "/boot" are obsolete since more than a decade, just go ahead. >> >>Just make sure to provide the equivalent of "/boot/vmlinuz" and >>"/boot/initrd", a pointer to the last installed kernel. This can >>very well be stored somewhere in "/usr". > >Here's my suggestion to move the kernel related read-only files from >/boot to /lib/modules/%kernelrelease-%build_flavor As the UsrMerge is completed now this additional patch also changes the location to /usr/lib/modules. Needs https://github.com/openSUSE/rpm-config-SUSE/pull/42 and https://build.opensuse.org/request/show/887990 From 4b108e6ff505c1b1bbb7b1fc2356aeb32a21ff4f Mon Sep 17 00:00:00 2001 From: Ludwig Nussel Date: Thu, 10 Jun 2021 14:03:30 +0200 Subject: [PATCH] Install into /usr/lib/modules --- rpm/check-module-license | 2 +- rpm/kernel-binary.spec.in | 34 +++++++++++++++++++--------------- rpm/kernel-obs-qa.spec.in | 2 +- rpm/kernel-source.rpmlintrc | 6 +++--- rpm/kernel-subpackage-build | 16 ++++++++-------- rpm/mergedep | 4 ++-- rpm/post.sh | 10 +++++----- rpm/postun.sh | 4 ++-- rpm/split-modules | 8 ++++---- 9 files changed, 45 insertions(+), 41 deletions(-) diff --git a/rpm/check-module-license b/rpm/check-module-license index b5f67fce99a4..31ed08cb9cab 100755 --- a/rpm/check-module-license +++ b/rpm/check-module-license @@ -4,7 +4,7 @@ rc=0 for file in $(find "$@" -name '*.ko' -o -name '*.ko.xz'); do l=$(/sbin/modinfo -F license "$file") if [ -z "$l" ]; then - echo "ERROR: No license is included for module ${file##*/lib/modules/}" + echo "ERROR: No license is included for module ${file##*/usr/lib/modules/}" rc=1 fi done diff --git a/rpm/kernel-binary.spec.in b/rpm/kernel-binary.spec.in index a5e30504384a..df05e844f65a 100644 --- a/rpm/kernel-binary.spec.in +++ b/rpm/kernel-binary.spec.in @@ -440,12 +440,15 @@ done %install +mkdir -p %{buildroot}/usr/lib +ln -s usr/lib %{buildroot}/lib + # get rid of /usr/lib/rpm/brp-strip-debug # strip removes too much from the vmlinux ELF binary export NO_BRP_STRIP_DEBUG=true export STRIP_KEEP_SYMTAB='*/vmlinux-*' -# /lib/modules/%kernelrelease-%build_flavor/source points to the source +# /usr/lib/modules/%kernelrelease-%build_flavor/source points to the source # directory installed by kernel-devel. The kernel-%build_flavor-devel package # has a correct dependency on kernel-devel, but the brp check does not see # kernel-devel during build. @@ -532,10 +535,10 @@ add_vmlinux() # sign the modules, firmware and possibly the kernel in the buildservice BRP_PESIGN_FILES="" %if "%CONFIG_EFI_STUB" == "y" -BRP_PESIGN_FILES="/lib/modules/%kernelrelease-%build_flavor/$image" +BRP_PESIGN_FILES="/usr/lib/modules/%kernelrelease-%build_flavor/$image" %endif %ifarch s390x ppc64 ppc64le -BRP_PESIGN_FILES="/lib/modules/%kernelrelease-%build_flavor/$image" +BRP_PESIGN_FILES="/usr/lib/modules/%kernelrelease-%build_flavor/$image" %endif %if "%CONFIG_MODULE_SIG" == "y" BRP_PESIGN_FILES="$BRP_PESIGN_FILES *.ko" @@ -800,6 +803,7 @@ if [ %CONFIG_MODULES = y ]; then fi rm -rf %{buildroot}/lib/firmware +rm %{buildroot}/lib add_dirs_to_filelist() { sed -rn ' @@ -826,14 +830,14 @@ fi shopt -s nullglob dotglob > %my_builddir/kernel-devel.files { - echo "/lib/modules/%kernelrelease-%build_flavor/build" - echo "/lib/modules/%kernelrelease-%build_flavor/source" + echo "/usr/lib/modules/%kernelrelease-%build_flavor/build" + echo "/usr/lib/modules/%kernelrelease-%build_flavor/source" cd %buildroot for file in boot/symtypes*; do l="${file##*/}" - l="lib/modules/%kernelrelease-%build_flavor/${l//-%kernelrelease-%build_flavor}" + l="usr/lib/modules/%kernelrelease-%build_flavor/${l//-%kernelrelease-%build_flavor}" mv "$file" "%{buildroot}/$l" - ln -s "../$l" $file + ln -s "../../$l" $file echo "/$l" echo "%%ghost /$file" done @@ -847,7 +851,7 @@ add_dirs_to_filelist >> %my_builddir/kernel-devel.files cd %buildroot for f in boot/*; do l="${f##*/}" - l="lib/modules/%kernelrelease-%build_flavor/${l//-%kernelrelease-%build_flavor}" + l="usr/lib/modules/%kernelrelease-%build_flavor/${l//-%kernelrelease-%build_flavor}" if test -L "$f"; then echo "%%ghost /$f" continue @@ -873,7 +877,7 @@ add_dirs_to_filelist >> %my_builddir/kernel-devel.files ;; esac mv "$f" "$l" - ln -s "../$l" $f + ln -s "../../$l" $f # the find in the CONFIG_MODULES condition below also finds the files # but there's sort -u later, so this is ok echo "/$l" @@ -881,7 +885,7 @@ add_dirs_to_filelist >> %my_builddir/kernel-devel.files done if [ %CONFIG_MODULES = y ]; then - find lib/modules/%kernelrelease-%build_flavor \ + find usr/lib/modules/%kernelrelease-%build_flavor \ -type d -o \ \( -path '*/modules.*' ! -path '*/modules.order' \ ! -path '*/modules.builtin' \ @@ -944,15 +948,15 @@ for f in %my_builddir/*-kmp-modules; do done if [ %CONFIG_MODULES = y ]; then - install -m 644 %_sourcedir/modules.fips %{buildroot}/lib/modules/%kernelrelease-%build_flavor/modules.fips - echo /lib/modules/%kernelrelease-%build_flavor/modules.fips >> %my_builddir/kernel-base.files - echo /lib/modules/%kernelrelease-%build_flavor/modules.fips >> %my_builddir/kernel-main.files + install -m 644 %_sourcedir/modules.fips %{buildroot}/usr/lib/modules/%kernelrelease-%build_flavor/modules.fips + echo /usr/lib/modules/%kernelrelease-%build_flavor/modules.fips >> %my_builddir/kernel-base.files + echo /usr/lib/modules/%kernelrelease-%build_flavor/modules.fips >> %my_builddir/kernel-main.files fi # Hardlink duplicate files automatically (from package fdupes): It doesn't save # much, but it keeps rpmlint from breaking the package build. Note that we skip # /usr/src/linux-obj intentionally, to not accidentally break timestamps there -%fdupes $RPM_BUILD_ROOT/lib +%fdupes $RPM_BUILD_ROOT/usr/lib %preun -f preun.sh @@ -1094,7 +1098,7 @@ static, unlike the %{patch_package}- -flavor package names. %files %{livepatch} # rpmlint complains about empty packages, so lets own something %defattr(-, root, root) -%dir /lib/modules/%kernelrelease-%build_flavor +%dir /usr/lib/modules/%kernelrelease-%build_flavor %endif %if 0%{?klp_symbols} && "%livepatch" != "" diff --git a/rpm/kernel-obs-qa.spec.in b/rpm/kernel-obs-qa.spec.in index 251885dbef33..b193562a1f77 100644 --- a/rpm/kernel-obs-qa.spec.in +++ b/rpm/kernel-obs-qa.spec.in @@ -60,7 +60,7 @@ projects and runs basic tests. # and called here. krel=$(uname -r) -if test ! -d "/lib/modules/$krel/kernel"; then +if test ! -d "/usr/lib/modules/$krel/kernel"; then echo "Kernel package for $krel not installed; exiting" exit 0 fi diff --git a/rpm/kernel-source.rpmlintrc b/rpm/kernel-source.rpmlintrc index 5d4abc78cb23..402f718f1332 100644 --- a/rpm/kernel-source.rpmlintrc +++ b/rpm/kernel-source.rpmlintrc @@ -1,10 +1,10 @@ # These zero-length files are correct: addFilter("zero-length /usr/src/linux-.*-obj/.*/include/config.*h") # vdsos are special -addFilter("shared-lib-without-dependency-information /lib/modules/[1-9].*/vdso/.*") -addFilter("missing-PT_GNU_STACK-section /lib/modules/[1-9].*/vdso/.*") +addFilter("shared-lib-without-dependency-information /usr/lib/modules/[1-9].*/vdso/.*") +addFilter("missing-PT_GNU_STACK-section /usr/lib/modules/[1-9].*/vdso/.*") # This is a stale symlink until the kernel-source package is installed: -addFilter("dangling-symlink /lib/modules/[1-9].*/source") +addFilter("dangling-symlink /usr/lib/modules/[1-9].*/source") # These hidden files are fine: addFilter("hidden-file-or-dir /usr/src/linux-.*-obj/.*/.config") addFilter("hidden-file-or-dir /usr/src/linux-.*-obj/.*/.kernel-binary.spec.buildenv") diff --git a/rpm/kernel-subpackage-build b/rpm/kernel-subpackage-build index 71df40c00906..5ff9bd818ff0 100644 --- a/rpm/kernel-subpackage-build +++ b/rpm/kernel-subpackage-build @@ -21,17 +21,17 @@ rpm -q --qf '%{POSTUN}' $kernel_package_name | sed -e "s/$kernel_nvrq/$package_n [ -z "$(rpm -q --triggers $kernel_package_name)" ] # not handled -KREL=$(cat kernel.flist | grep ^/lib/modules | { sort -r ||: ;} | head -n 1 | sed -e s,^/lib/modules/,, -e 's,/.*,,') +KREL=$(cat kernel.flist | grep ^/usr/lib/modules | { sort -r ||: ;} | head -n 1 | sed -e s,^/usr/lib/modules/,, -e 's,/.*,,') $scriptdir/mergedep $KREL > modules.dep $scriptdir/moddep modules.dep request-modules modules -$scriptdir/modflist kernel.flist modules modules.flist /lib/modules/$KREL/modules.builtin -cat kernel.flist | grep -v ^/lib/modules >> modules.flist -[ -d /lib/modules/$KREL/vdso ] && echo /lib/modules/$KREL/vdso >> modules.flist ||: -echo /lib/modules/$KREL/modules.* | tr ' ' '\n' >> modules.flist +$scriptdir/modflist kernel.flist modules modules.flist /usr/lib/modules/$KREL/modules.builtin +cat kernel.flist | grep -v ^/usr/lib/modules >> modules.flist +[ -d /usr/lib/modules/$KREL/vdso ] && echo /usr/lib/modules/$KREL/vdso >> modules.flist ||: +echo /usr/lib/modules/$KREL/modules.* | tr ' ' '\n' >> modules.flist tar -C / -cf- -T modules.flist | tar -C $RPM_BUILD_ROOT -xvf- @@ -44,8 +44,8 @@ exit 1 fi echo "%defattr(-,root,root)" > subpackage.flist -cat kernel.flist | grep -v ^/lib/modules >> subpackage.flist -echo /lib/modules/$KREL >> subpackage.flist +cat kernel.flist | grep -v ^/usr/lib/modules >> subpackage.flist +echo /usr/lib/modules/$KREL >> subpackage.flist cat kernel-ghost.flist | sed -e 's/^/%ghost /' >> subpackage.flist cat kernel-ghost.flist | while read ghost ; do @@ -66,7 +66,7 @@ cat kernel-ghost.flist | while read ghost ; do bs=1024 seek=2047 count=1 chmod 0600 $RPM_BUILD_ROOT$ghost ;; - /lib/modules/$KREL/modules.*) + /usr/lib/modules/$KREL/modules.*) [ -f $RPM_BUILD_ROOT$ghost ] ;; *) diff --git a/rpm/mergedep b/rpm/mergedep index c0ca85a8292e..28ef9fdb8c8b 100755 --- a/rpm/mergedep +++ b/rpm/mergedep @@ -2,8 +2,8 @@ KREL=$1 -{ cat /lib/modules/$KREL/modules.dep ; -cat /lib/modules/$KREL/modules.softdep | grep : | sed -e 's/^softdep //' -e 's/ \(pre\|post\):/:/' ; } \ +{ cat /usr/lib/modules/$KREL/modules.dep ; +cat /usr/lib/modules/$KREL/modules.softdep | grep : | sed -e 's/^softdep //' -e 's/ \(pre\|post\):/:/' ; } \ | \ while read l ; do MOD=$(echo "$l" | sed -e 's/:.*//') diff --git a/rpm/post.sh b/rpm/post.sh index b5167ed99443..1ce458c2ff78 100644 --- a/rpm/post.sh +++ b/rpm/post.sh @@ -21,14 +21,14 @@ fi # XXX: need to fix suse-module-tools for sysctl.conf and System.map for x in @IMAGE@ sysctl.conf System.map; do if [ ! -e /boot/$x-@KERNELRELEASE@-@FLAVOR@ ]; then - $copy_or_link ../lib/modules/@KERNELRELEASE@-@FLAVOR@/$x /boot/$x-@KERNELRELEASE@-@FLAVOR@ - if [ -e /lib/modules/@KERNELRELEASE@-@FLAVOR@/.$x.hmac ]; then - $copy_or_link ../lib/modules/@KERNELRELEASE@-@FLAVOR@/.$x.hmac /boot/.$x-@KERNELRELEASE@-@FLAVOR@.hmac + $copy_or_link ../usr/lib/modules/@KERNELRELEASE@-@FLAVOR@/$x /boot/$x-@KERNELRELEASE@-@FLAVOR@ + if [ -e /usr/lib/modules/@KERNELRELEASE@-@FLAVOR@/.$x.hmac ]; then + $copy_or_link ../usr/lib/modules/@KERNELRELEASE@-@FLAVOR@/.$x.hmac /boot/.$x-@KERNELRELEASE@-@FLAVOR@.hmac fi fi done -# Add symlinks of compatible modules to /lib/modules/$krel/weak-updates/, +# Add symlinks of compatible modules to /usr/lib/modules/$krel/weak-updates/, # run depmod and mkinitrd wm2_rc=0 wm2=/usr/lib/module-init-tools/weak-modules2 @@ -73,7 +73,7 @@ if [ -f /etc/fstab -a ! -e /.buildenv ] ; then if [ @FLAVOR@ = rt ]; then default=force-default fi - if [ -e /boot/$initrd -o ! -e /lib/modules/@KERNELRELEASE@-@FLAVOR@ ] && \ + if [ -e /boot/$initrd -o ! -e /usr/lib/modules/@KERNELRELEASE@-@FLAVOR@ ] && \ run_bootloader ; then [ -e /boot/$initrd ] || initrd= if [ -x /usr/lib/bootloader/bootloader_entry ]; then diff --git a/rpm/postun.sh b/rpm/postun.sh index 4da20759f3ff..8612c4ba3780 100644 --- a/rpm/postun.sh +++ b/rpm/postun.sh @@ -6,7 +6,7 @@ rm -f /boot/do_purge_kernels wm2=/usr/lib/module-init-tools/weak-modules2 nvr=@SUBPACKAGE@-@RPM_VERSION_RELEASE@ -if [ -e /lib/modules/@KERNELRELEASE@-@FLAVOR@/System.map ]; then +if [ -e /usr/lib/modules/@KERNELRELEASE@-@FLAVOR@/System.map ]; then # the same package was reinstalled or just rebuilt, otherwise the files # would have been deleted by now # do not remove anything in this case (bnc#533766) @@ -21,7 +21,7 @@ if [ @BASE_PACKAGE@ = 0 ]; then rm -f /var/run/rpm-$nvr-modules exit 0 fi -# Remove symlinks from /lib/modules/$krel/weak-updates/. +# Remove symlinks from /usr/lib/modules/$krel/weak-updates/. if [ -x $wm2 ]; then /bin/bash -${-/e/} $wm2 --remove-kernel @KERNELRELEASE@-@FLAVOR@ fi diff --git a/rpm/split-modules b/rpm/split-modules index 329b11034287..ca07f09c144e 100755 --- a/rpm/split-modules +++ b/rpm/split-modules @@ -77,7 +77,7 @@ while read mod path; do no) ;; "") - echo "warning: ${path#/lib/modules/*/kernel/} not listed in supported.conf" >&2 + echo "warning: ${path#/usr/lib/modules/*/kernel/} not listed in supported.conf" >&2 ;; *) echo "error: invalid support flag for $mod: $support" >&2 @@ -115,11 +115,11 @@ join -j 1 -o 2.2 "$tmp/base" "$tmp/all" >"$opt_out/base-modules" # base firmware kver=$(make $MAKE_ARGS -s -C "$opt_builddir" kernelrelease) -if test -d "$opt_dir/lib/firmware/$kver"; then +if test -d "$opt_dir/usr/lib/firmware/$kver"; then join <(/sbin/modinfo -F firmware \ $(sed "s:^:$opt_dir:" "$opt_out/base-modules") | sort) \ - <(find "$opt_dir/lib/firmware/$kver" -type f -printf '%P\n' | sort) -fi | sed "s:^:/lib/firmware/$kver/:" >"$opt_out/base-firmware" + <(find "$opt_dir/usr/lib/firmware/$kver" -type f -printf '%P\n' | sort) +fi | sed "s:^:/usr/lib/firmware/$kver/:" >"$opt_out/base-firmware" # kmps for f in "$opt_builddir"/Module.*-kmp; do -- 2.26.2 cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Fri, 11 Jun 2021 15:07:14 +0200, Ludwig Nussel wrote:
Ludwig Nussel wrote:
Olaf Hering wrote:
Am Mon, 12 Apr 2021 10:46:48 +0200 schrieb Ludwig Nussel
: Does anyone have a better idea or can we just follow Fedora's approach here?
Since the reasons for "/boot" are obsolete since more than a decade, just go ahead.
Just make sure to provide the equivalent of "/boot/vmlinuz" and "/boot/initrd", a pointer to the last installed kernel. This can very well be stored somewhere in "/usr".
Here's my suggestion to move the kernel related read-only files from /boot to /lib/modules/%kernelrelease-%build_flavor
As the UsrMerge is completed now this additional patch also changes the location to /usr/lib/modules. Needs https://github.com/openSUSE/rpm-config-SUSE/pull/42 and https://build.opensuse.org/request/show/887990
Note that the rpm/* stuff is common among many releases including SLE12 and SLE15 (managed in packaging git branch), hence unconditionally replacing to /usr/lib is no-go. It has to be handled with some macro so that it's conditionally replaced only for TW. thanks, Takashi
On 14/04/2021 01.30, L A Walsh wrote:
On 2021/04/12 17:57, Carlos E. R. wrote:
On 12/04/2021 23.37, L A Walsh wrote:
How does Windows boot supporting all the different hardware it does without a ramdisk, and why does linux need one? One reason is that Windows filesystem can flag a file "system", which means "do not move it". Don't touch it. Don't relocate it.
Doesn't the immutable bit on linux accomplish much the same?
So linux could do the same thing?
Huh, I forgot about this post, sorry. No, I don't think so. An immutable file could still be moved around on the disk surface. Just not changed. A file with an immutable attribute can not be: Modified Deleted Renamed No soft or hard link created by anyone including root user. (https://www.cyberciti.biz/tips/linux-password-trick.html) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 16/04/2021 13.21, Michal Suchánek wrote:
On Fri, Apr 16, 2021 at 07:28:26AM +0300, Andrei Borzenkov wrote:
On 15.04.2021 21:20, Larry Finger wrote:
On 4/15/21 4:36 AM, Michal Suchánek wrote:
On Tue, Apr 13, 2021 at 04:36:40PM -0700, L A Walsh wrote:
Unix used to provide a boot protocol for booting over the network. It predated linux, I'm pretty sure, and AFAIK, it worked with windows as well. You don't know very far here. Or can you share what protocol it is, specifically, and how do you create a netbooted installtion of Windows?
I have seen a TFTP boot of a Windows installer.
That's not surprising given that PXE is based on TFTP and it does not matter *what* you are booting over LAN via PXE, you end up loading it with TFTP. And PXE is the industry standard network boot protocol today.
It was slow, but it worked. I was not involved in setting it up, and I have no idea of the internals.
Yes, but loading Windows installer from TFTP does not mean Windows can boot from network. The installer is a Windows PE image that boots from ramdisk no matter where that ramdisk image is loaded from.
So while Microsoft provides a bootloader that can fetch the installer ramdisk from TFTP it still does not make it possible to boot Windows from network. The only way I know if is using hardware iSCSI which obviously works because Windows does not know about the networking.
I worked at a place where some ancient enterprise Windows was booted from the Network. Some high security system for the military. I was a user, not privileged to know how it was done. I think it was some sort of hybrid. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Takashi Iwai wrote:
On Fri, 11 Jun 2021 15:07:14 +0200, Ludwig Nussel wrote:
[...] As the UsrMerge is completed now this additional patch also changes the location to /usr/lib/modules. Needs https://github.com/openSUSE/rpm-config-SUSE/pull/42 and https://build.opensuse.org/request/show/887990
Note that the rpm/* stuff is common among many releases including SLE12 and SLE15 (managed in packaging git branch), hence unconditionally replacing to /usr/lib is no-go. It has to be handled with some macro so that it's conditionally replaced only for TW.
OK so here is a patch that keeps /lib/modules on older releases. I managed to successfully build and boot it based on 5.13-rc5 with Leap 15.3 in kvm. Meanwhile 5.13-rc6 is in kerncvs. Rebased on that one, builds are running. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Thu, 17 Jun 2021 13:55:56 +0200, Ludwig Nussel wrote: > > Takashi Iwai wrote: > >On Fri, 11 Jun 2021 15:07:14 +0200, > >Ludwig Nussel wrote: > >> [...] > >> As the UsrMerge is completed now this additional patch also changes > >> the location to /usr/lib/modules. > >> Needs https://github.com/openSUSE/rpm-config-SUSE/pull/42 and > >> https://build.opensuse.org/request/show/887990 > > > >Note that the rpm/* stuff is common among many releases including > >SLE12 and SLE15 (managed in packaging git branch), hence > >unconditionally replacing to /usr/lib is no-go. It has to be handled > >with some macro so that it's conditionally replaced only for TW. > > OK so here is a patch that keeps /lib/modules on older releases. I > managed to successfully build and boot it based on 5.13-rc5 with > Leap 15.3 in kvm. > Meanwhile 5.13-rc6 is in kerncvs. Rebased on that one, builds are > running. Thanks, this one looks much better. But, could you open a Bugzilla entry and give some information there? We need the proper information source that can be tracked in future for such a fundamental change. Since it's for TW, I don't think Jira is always required, but at least a Bugzilla entry would help in that manner. thanks, Takashi > > cu > Ludwig > > -- > (o_ Ludwig Nussel > //\ > V_/_ http://www.suse.com/ > SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer > HRB 36809 (AG Nürnberg) > >From d6eb800c34353b03eb24ddaf302d74dab1c3aec9 Mon Sep 17 00:00:00 2001 > From: Ludwig Nussel> Date: Thu, 17 Jun 2021 13:31:32 +0200 > Subject: [PATCH] UsrMerge the kernel > > - 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. > --- > rpm/kernel-binary.spec.in | 75 +++++++++++++++++++++++++++---------- > rpm/kernel-obs-qa.spec.in | 2 +- > rpm/kernel-source.rpmlintrc | 6 +-- > rpm/kernel-subpackage-build | 30 +++++++++------ > rpm/kernel-subpackage-spec | 11 ++++++ > rpm/post.sh | 19 +++++++++- > rpm/postun.sh | 4 +- > rpm/split-modules | 10 +++-- > 8 files changed, 116 insertions(+), 41 deletions(-) > > diff --git a/rpm/kernel-binary.spec.in b/rpm/kernel-binary.spec.in > index 9d7434a179fe..65a5c64ebe41 100644 > --- a/rpm/kernel-binary.spec.in > +++ b/rpm/kernel-binary.spec.in > @@ -68,6 +68,13 @@ > %define install_vdso 0 > %endif > > +%if %{undefined usrmerged} && 0%{?suse_version} >= 1550 > +%define usrmerged 1 > +%endif > + > +%define modules_dir %{?usrmerged:/usr}/lib/modules/%kernelrelease-%build_flavor > + > + > Name: kernel-@FLAVOR@ > Summary: @SUMMARY@ > License: GPL-2.0 > @@ -465,6 +472,11 @@ done > > %install > > +%if 0%{?usrmerged} > +mkdir -p %{buildroot}/usr/lib > +ln -s usr/lib %{buildroot}/lib > +%endif > + > # get rid of /usr/lib/rpm/brp-strip-debug > # strip removes too much from the vmlinux ELF binary > export NO_BRP_STRIP_DEBUG=true > @@ -557,10 +569,10 @@ add_vmlinux() > # sign the modules, firmware and possibly the kernel in the buildservice > BRP_PESIGN_FILES="" > %if "%CONFIG_EFI_STUB" == "y" > -BRP_PESIGN_FILES="/boot/$image-%kernelrelease-%build_flavor" > +BRP_PESIGN_FILES="%modules_dir/$image" > %endif > %ifarch s390x ppc64 ppc64le > -BRP_PESIGN_FILES="/boot/$image-%kernelrelease-%build_flavor" > +BRP_PESIGN_FILES="%modules_dir/$image" > %endif > %if "%CONFIG_MODULE_SIG" == "y" > BRP_PESIGN_FILES="$BRP_PESIGN_FILES *.ko" > @@ -623,6 +635,7 @@ for sub in '' '-extra' \ > -e "s:@RPM_TARGET_CPU@:%_target_cpu:g" \ > -e "s:@CPU_ARCH_FLAVOR@:%cpu_arch_flavor:g" \ > -e "s:@SRCVARIANT@:%variant:g" \ > + -e "s:@MODULESDIR@:%modules_dir:g" \ > %_sourcedir/$script.sh > %my_builddir/$script$sub.sh > if test "$base_package" -eq 1 -a "${#certs[@]}" -gt 0; then > case "$script" in > @@ -829,6 +842,9 @@ if [ %CONFIG_MODULES = y ]; then > fi > > rm -rf %{buildroot}/lib/firmware > +%if 0%{?usrmerged} > +rm %{buildroot}/lib > +%endif > > add_dirs_to_filelist() { > sed -rn ' > @@ -841,7 +857,7 @@ add_dirs_to_filelist() { > # print all parents > :a > # skip directories owned by other packages > - s:^%%dir (/boot|/etc|/lib/(modules|firmware)|/usr/src)/[^/]+$:: > + s:^%%dir (/boot|/etc|(/usr)?/lib/(modules|firmware)|/usr/src)/[^/]+$:: > s:/[^/]+$::p > ta > ' "$@" | sort -u > @@ -854,10 +870,19 @@ fi > > shopt -s nullglob dotglob > > %my_builddir/kernel-devel.files > -for file in %buildroot/boot/symtypes* %buildroot/lib/modules/*/{build,source}; do > - f=${file##%buildroot} > - echo "$f" > -done | add_dirs_to_filelist >%my_builddir/kernel-devel.files > +{ > + echo "%modules_dir/build" > + echo "%modules_dir/source" > + cd %buildroot > + for file in boot/symtypes*; do > + l="${file##*/}" > + l="%modules_dir/${l//-%kernelrelease-%build_flavor}" > + mv "$file" "%{buildroot}$l" > + ln -s "..$l" $file > + echo "$l" > + echo "%%ghost /$file" > + done > +} | add_dirs_to_filelist >%my_builddir/kernel-devel.files > ( cd %buildroot ; find .%obj_install_dir/%cpu_arch_flavor -type f ; ) | \ > sed -e 's/^[.]//' | grep -v -e '[.]ipa-clones$' -e '/Symbols[.]list$' -e '/ipa-clones[.]list$'| \ > add_dirs_to_filelist >> %my_builddir/kernel-devel.files > @@ -866,6 +891,8 @@ add_dirs_to_filelist >> %my_builddir/kernel-devel.files > echo %ghost /boot/initrd$suffix > cd %buildroot > for f in boot/*; do > + l="${f##*/}" > + l="%modules_dir/${l//-%kernelrelease-%build_flavor}" > if test -L "$f"; then > echo "%%ghost /$f" > continue > @@ -880,25 +907,35 @@ add_dirs_to_filelist >> %my_builddir/kernel-devel.files > boot/vmlinux-*.%{compress_vmlinux}) > ;; > boot/vmlinux-*) > - if $ghost_vmlinux; then > - echo "%%ghost /$f" > - continue > - fi > + [ "$ghost_vmlinux" != 'true' ] || echo -n "%%ghost " > + ;; > + boot/vmlinuz-*) > + echo -n "%%attr(0644, root, root) " > ;; > boot/symtypes*) > + echo "%exclude $l" > continue > ;; > esac > - echo "%%attr(0644, root, root) /$f" > + mv "$f" "./$l" > + ln -s "..$l" $f > + # the find in the CONFIG_MODULES condition below also finds the files > + # but there's sort -u later, so this is ok > + echo "$l" > + echo "%%ghost /$f" > done > > if [ %CONFIG_MODULES = y ]; then > - find lib/modules/%kernelrelease-%build_flavor \ > + find %{?usrmerged:usr/}lib/modules/%kernelrelease-%build_flavor \ > -type d -o \ > \( -path '*/modules.*' ! -path '*/modules.order' \ > ! -path '*/modules.builtin' \ > ! -path '*/modules.builtin.modinfo' \) -printf '%%%%ghost /%%p\n' \ > - -o -name '*.ko' -prune -o -type f -printf '/%%p\n' > + -o -name '*.ko' -prune \ > + -o \( -type f \ > + ! -path '*/symtypes*' \ > + ! -path '*/vmlinu*' \ > + \) -printf '/%%p\n' > cat %my_builddir/base-modules > fi > if test %CONFIG_MODULE_SIG = "y" -a -d etc/uefi/certs; then > @@ -956,15 +993,15 @@ for f in %my_builddir/*-kmp-modules; do > done > > if [ %CONFIG_MODULES = y ]; then > - install -m 644 %_sourcedir/modules.fips %{buildroot}/lib/modules/%kernelrelease-%build_flavor/modules.fips > - echo /lib/modules/%kernelrelease-%build_flavor/modules.fips >> %my_builddir/kernel-base.files > - echo /lib/modules/%kernelrelease-%build_flavor/modules.fips >> %my_builddir/kernel-main.files > + install -m 644 %_sourcedir/modules.fips %{buildroot}%modules_dir/modules.fips > + echo %modules_dir/modules.fips >> %my_builddir/kernel-base.files > + echo %modules_dir/modules.fips >> %my_builddir/kernel-main.files > fi > > # Hardlink duplicate files automatically (from package fdupes): It doesn't save > # much, but it keeps rpmlint from breaking the package build. Note that we skip > # /usr/src/linux-obj intentionally, to not accidentally break timestamps there > -%fdupes $RPM_BUILD_ROOT/lib > +%fdupes %buildroot%modules_dir > > %preun -f preun.sh > > @@ -1144,7 +1181,7 @@ static, unlike the %{patch_package}- -flavor package names. > %files %{livepatch} > # rpmlint complains about empty packages, so lets own something > %defattr(-, root, root) > -%dir /lib/modules/%kernelrelease-%build_flavor > +%dir %modules_dir > %endif > > %if 0%{?klp_symbols} && "%livepatch" != "" > diff --git a/rpm/kernel-obs-qa.spec.in b/rpm/kernel-obs-qa.spec.in > index 251885dbef33..fa8234e8af62 100644 > --- a/rpm/kernel-obs-qa.spec.in > +++ b/rpm/kernel-obs-qa.spec.in > @@ -60,7 +60,7 @@ projects and runs basic tests. > # and called here. > > krel=$(uname -r) > -if test ! -d "/lib/modules/$krel/kernel"; then > +if test ! -d "/lib/modules/$krel/kernel" && test ! -d "/usr/lib/modules/$krel/kernel"; then > echo "Kernel package for $krel not installed; exiting" > exit 0 > fi > diff --git a/rpm/kernel-source.rpmlintrc b/rpm/kernel-source.rpmlintrc > index 5d4abc78cb23..748d9097df9e 100644 > --- a/rpm/kernel-source.rpmlintrc > +++ b/rpm/kernel-source.rpmlintrc > @@ -1,10 +1,10 @@ > # These zero-length files are correct: > addFilter("zero-length /usr/src/linux-.*-obj/.*/include/config.*h") > # vdsos are special > -addFilter("shared-lib-without-dependency-information /lib/modules/[1-9].*/vdso/.*") > -addFilter("missing-PT_GNU_STACK-section /lib/modules/[1-9].*/vdso/.*") > +addFilter("shared-lib-without-dependency-information .*/lib/modules/[1-9].*/vdso/.*") > +addFilter("missing-PT_GNU_STACK-section .*/lib/modules/[1-9].*/vdso/.*") > # This is a stale symlink until the kernel-source package is installed: > -addFilter("dangling-symlink /lib/modules/[1-9].*/source") > +addFilter("dangling-symlink .*/lib/modules/[1-9].*/source") > # These hidden files are fine: > addFilter("hidden-file-or-dir /usr/src/linux-.*-obj/.*/.config") > addFilter("hidden-file-or-dir /usr/src/linux-.*-obj/.*/.kernel-binary.spec.buildenv") > diff --git a/rpm/kernel-subpackage-build b/rpm/kernel-subpackage-build > index 71df40c00906..6bc9b16a1ace 100644 > --- a/rpm/kernel-subpackage-build > +++ b/rpm/kernel-subpackage-build > @@ -21,7 +21,8 @@ rpm -q --qf '%{POSTUN}' $kernel_package_name | sed -e "s/$kernel_nvrq/$package_n > > [ -z "$(rpm -q --triggers $kernel_package_name)" ] # not handled > > -KREL=$(cat kernel.flist | grep ^/lib/modules | { sort -r ||: ;} | head -n 1 | sed -e s,^/lib/modules/,, -e 's,/.*,,') > +KREL=$(sed -rne '/^(\/usr)?\/lib\/modules\/([^/]+)$/{s,.*/,,;p;q}' < kernel.flist) > +grep -q /usr/lib/modules/ kernel.flist && USR=/usr > > $scriptdir/mergedep $KREL > modules.dep > > @@ -29,9 +30,9 @@ $scriptdir/mergedep $KREL > modules.dep > $scriptdir/moddep modules.dep request-modules modules > > $scriptdir/modflist kernel.flist modules modules.flist /lib/modules/$KREL/modules.builtin > -cat kernel.flist | grep -v ^/lib/modules >> modules.flist > -[ -d /lib/modules/$KREL/vdso ] && echo /lib/modules/$KREL/vdso >> modules.flist ||: > -echo /lib/modules/$KREL/modules.* | tr ' ' '\n' >> modules.flist > +grep -v ^$USR/lib/modules < kernel.flist >> modules.flist > +[ -d $USR/lib/modules/$KREL/vdso ] && echo $USR/lib/modules/$KREL/vdso >> modules.flist ||: > +echo $USR/lib/modules/$KREL/modules.* | tr ' ' '\n' >> modules.flist > > tar -C / -cf- -T modules.flist | tar -C $RPM_BUILD_ROOT -xvf- > > @@ -44,18 +45,24 @@ exit 1 > fi > > echo "%defattr(-,root,root)" > subpackage.flist > -cat kernel.flist | grep -v ^/lib/modules >> subpackage.flist > -echo /lib/modules/$KREL >> subpackage.flist > +grep -v $USR/lib/modules < kernel.flist >> subpackage.flist > +echo $USR/lib/modules/$KREL >> subpackage.flist > cat kernel-ghost.flist | sed -e 's/^/%ghost /' >> subpackage.flist > > cat kernel-ghost.flist | while read ghost ; do > case $ghost in > - /boot/image-%build_flavor | /boot/vmlinux-%build_flavor | /boot/vmlinuz-%build_flavor | \ > - /boot/Image-%build_flavor | /boot/initrd-%build_flavor) > + /boot/image-$KREL | /boot/vmlinux-$KREL | /boot/vmlinuz-$KREL | \ > + /boot/Image-$KREL | /boot/initrd-$KREL) > + ;; > + /boot/System.map-$KREL | /boot/symtypes-$KREL* | /boot/symvers-$KREL*) > ;; > /boot/vmlinux | /boot/vmlinuz | /boot/zImage | /boot/Image | /boot/image | /boot/initrd) > ;; > - /boot/vmlinux-$KREL) > + /boot/.*$KREL.hmac ) > + ;; > + /boot/config-$KREL | /boot/sysctl.conf-$KREL) > + ;; > + /boot/vmlinux-$KREL*) > [ -f /boot/vmlinux-$KREL.gz ] && touch vmlinux-$KREL > ;; > /boot/initrd-$KREL | /boot/initrd-$KREL-kdump) > @@ -66,13 +73,14 @@ cat kernel-ghost.flist | while read ghost ; do > bs=1024 seek=2047 count=1 > chmod 0600 $RPM_BUILD_ROOT$ghost > ;; > - /lib/modules/$KREL/modules.*) > + $USR/lib/modules/$KREL/modules.*) > [ -f $RPM_BUILD_ROOT$ghost ] > ;; > + $USR/lib/modules/$KREL/vmlinux) > + ;; > *) > echo Missing file "$ghost" not handled. > exit 1; > ;; > esac > done > - > diff --git a/rpm/kernel-subpackage-spec b/rpm/kernel-subpackage-spec > index 3f2bea62aa43..cbf649fc38c5 100644 > --- a/rpm/kernel-subpackage-spec > +++ b/rpm/kernel-subpackage-spec > @@ -1,6 +1,10 @@ > %define rpm_kver %(rpm -q --qf '%%{VERSION}' %kernel_package_name) > %define rpm_krel %(rpm -q --qf '%%{RELEASE}' %kernel_package_name) > > +%if %{undefined usrmerged} && 0%{?suse_version} >= 1550 > +%define usrmerged 1 > +%endif > + > # Force bzip2 instead of lzma compression to > # 1) allow install on older dist versions, and > # 2) decrease build times (bsc#962356) > @@ -79,10 +83,17 @@ There is no reason to install this package. > %build > > %install > +%if 0%{?usrmerged} > +ln -s usr/lib %{buildroot}/lib > +%endif > > echo "%{?modules}" | tr ', ' '\n\n' > request-modules > %scriptdir/kernel-subpackage-build %kernel_package_name %rpm_kver-%rpm_krel %package_name-%version-%release > > +%if 0%{?usrmerged} > +rm %{buildroot}/lib > +%endif > + > %preun -f preun.sh > > %postun -f postun.sh > diff --git a/rpm/post.sh b/rpm/post.sh > index 052ae5a6fdd2..3443305860e4 100644 > --- a/rpm/post.sh > +++ b/rpm/post.sh > @@ -10,6 +10,23 @@ for x in /boot/@IMAGE@ /boot/initrd; do > rm -f $x$suffix > ln -s ${x##*/}-@KERNELRELEASE@-@FLAVOR@ $x$suffix > done > +# compat stuff for /boot. > +# if /boot is not a speparate partition we can just link the kernel > +# there to save space. Otherwise copy. > +if mountpoint -q /boot; then > + copy_or_link="cp -a" > +else > + copy_or_link="ln -sf" > +fi > +# XXX: need to fix suse-module-tools for sysctl.conf and System.map > +for x in @IMAGE@ sysctl.conf System.map; do > + if [ ! -e /boot/$x-@KERNELRELEASE@-@FLAVOR@ ]; then > + $copy_or_link ..@MODULESDIR@/$x /boot/$x-@KERNELRELEASE@-@FLAVOR@ > + if [ -e @MODULESDIR@/.$x.hmac ]; then > + $copy_or_link ..@MODULESDIR@/.$x.hmac /boot/.$x-@KERNELRELEASE@-@FLAVOR@.hmac > + fi > + fi > +done > > # Add symlinks of compatible modules to /lib/modules/$krel/weak-updates/, > # run depmod and mkinitrd > @@ -56,7 +73,7 @@ if [ -f /etc/fstab -a ! -e /.buildenv ] ; then > if [ @FLAVOR@ = rt ]; then > default=force-default > fi > - if [ -e /boot/$initrd -o ! -e /lib/modules/@KERNELRELEASE@-@FLAVOR@ ] && \ > + if [ -e /boot/$initrd -o ! -e @MODULESDIR@ ] && \ > run_bootloader ; then > [ -e /boot/$initrd ] || initrd= > if [ -x /usr/lib/bootloader/bootloader_entry ]; then > diff --git a/rpm/postun.sh b/rpm/postun.sh > index d5165044abc4..25cc463135e5 100644 > --- a/rpm/postun.sh > +++ b/rpm/postun.sh > @@ -6,7 +6,7 @@ rm -f /boot/do_purge_kernels > wm2=/usr/lib/module-init-tools/weak-modules2 > nvr=@SUBPACKAGE@-@RPM_VERSION_RELEASE@ > > -if [ -e /boot/System.map-@KERNELRELEASE@-@FLAVOR@ ]; then > +if [ -e @MODULESDIR@/System.map ]; then > # the same package was reinstalled or just rebuilt, otherwise the files > # would have been deleted by now > # do not remove anything in this case (bnc#533766) > @@ -21,7 +21,7 @@ if [ @BASE_PACKAGE@ = 0 ]; then > rm -f /var/run/rpm-$nvr-modules > exit 0 > fi > -# Remove symlinks from /lib/modules/$krel/weak-updates/. > +# Remove symlinks from /usr/lib/modules/$krel/weak-updates/. > if [ -x $wm2 ]; then > /bin/bash -${-/e/} $wm2 --remove-kernel @KERNELRELEASE@-@FLAVOR@ > fi > diff --git a/rpm/split-modules b/rpm/split-modules > index 4f27fecff94a..58505fe1bb52 100755 > --- a/rpm/split-modules > +++ b/rpm/split-modules > @@ -77,7 +77,7 @@ while read mod path; do > no) > ;; > "") > - echo "warning: ${path#/lib/modules/*/kernel/} not listed in supported.conf" >&2 > + echo "warning: $mod not listed in supported.conf" >&2 > ;; > *) > echo "error: invalid support flag for $mod: $support" >&2 > @@ -119,11 +119,13 @@ join -j 1 -o 2.2 "$tmp/base" "$tmp/all" >"$opt_out/base-modules" > > # base firmware > kver=$(make $MAKE_ARGS -s -C "$opt_builddir" kernelrelease) > -if test -d "$opt_dir/lib/firmware/$kver"; then > +fw_dir=/lib/firmware/$kver > +test -d $opt_dir/usr$fw_dir && fw_dir=/usr$fw_dir > +if test -d "$opt_dir$fw_dir"; then > join <(/sbin/modinfo -F firmware \ > $(sed "s:^:$opt_dir:" "$opt_out/base-modules") | sort) \ > - <(find "$opt_dir/lib/firmware/$kver" -type f -printf '%P\n' | sort) > -fi | sed "s:^:/lib/firmware/$kver/:" >"$opt_out/base-firmware" > + <(find "$opt_dir$fw_dir" -type f -printf '%P\n' | sort) > +fi | sed "s:^:$fw_dir:" >"$opt_out/base-firmware" > > # kmps > for f in "$opt_builddir"/Module.*-kmp; do > -- > 2.26.2 >
Takashi Iwai wrote:
On Thu, 17 Jun 2021 13:55:56 +0200, Ludwig Nussel wrote:
Takashi Iwai wrote:
On Fri, 11 Jun 2021 15:07:14 +0200, Ludwig Nussel wrote:
[...] As the UsrMerge is completed now this additional patch also changes the location to /usr/lib/modules. Needs https://github.com/openSUSE/rpm-config-SUSE/pull/42 and https://build.opensuse.org/request/show/887990
Note that the rpm/* stuff is common among many releases including SLE12 and SLE15 (managed in packaging git branch), hence unconditionally replacing to /usr/lib is no-go. It has to be handled with some macro so that it's conditionally replaced only for TW.
OK so here is a patch that keeps /lib/modules on older releases. I managed to successfully build and boot it based on 5.13-rc5 with Leap 15.3 in kvm. Meanwhile 5.13-rc6 is in kerncvs. Rebased on that one, builds are running.
Thanks, this one looks much better. But, could you open a Bugzilla entry and give some information there? We need the proper information source that can be tracked in future for such a fundamental change. Since it's for TW, I don't think Jira is always required, but at least a Bugzilla entry would help in that manner.
Ah, sure. Sorry I fogot to add the reference to bug 1184804. Will do so for next revision of the patch. Any other remarks? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Thu, 17 Jun 2021 17:08:34 +0200, Ludwig Nussel wrote:
Takashi Iwai wrote:
On Thu, 17 Jun 2021 13:55:56 +0200, Ludwig Nussel wrote:
Takashi Iwai wrote:
On Fri, 11 Jun 2021 15:07:14 +0200, Ludwig Nussel wrote:
[...] As the UsrMerge is completed now this additional patch also changes the location to /usr/lib/modules. Needs https://github.com/openSUSE/rpm-config-SUSE/pull/42 and https://build.opensuse.org/request/show/887990
Note that the rpm/* stuff is common among many releases including SLE12 and SLE15 (managed in packaging git branch), hence unconditionally replacing to /usr/lib is no-go. It has to be handled with some macro so that it's conditionally replaced only for TW.
OK so here is a patch that keeps /lib/modules on older releases. I managed to successfully build and boot it based on 5.13-rc5 with Leap 15.3 in kvm. Meanwhile 5.13-rc6 is in kerncvs. Rebased on that one, builds are running.
Thanks, this one looks much better. But, could you open a Bugzilla entry and give some information there? We need the proper information source that can be tracked in future for such a fundamental change. Since it's for TW, I don't think Jira is always required, but at least a Bugzilla entry would help in that manner.
Ah, sure. Sorry I fogot to add the reference to bug 1184804.
Yep, let's use that, as now we seem to have agreed on moving forward.
Will do so for next revision of the patch. Any other remarks?
As mentioned in another (internal) thread, the changes should be applied to packaging git branch, and it should be compatible with the old SLE -- so unconditionally moving out of /boot sounds a bit too adventurous for SLE, even if it would work somehow. I'm inclined for keeping the stuff in /boot at least for SLE12 and SLE15. thanks, Takashi
Takashi Iwai wrote: > [...] >As mentioned in another (internal) thread, the changes should be >applied to packaging git branch, and it should be compatible with the >old SLE -- so unconditionally moving out of /boot sounds a bit too >adventurous for SLE, even if it would work somehow. I'm inclined for >keeping the stuff in /boot at least for SLE12 and SLE15. Ok, next try: From d2a7145a755beebc4b78288f1094851be3ef6a64 Mon Sep 17 00:00:00 2001 From: Ludwig NusselDate: Thu, 17 Jun 2021 13:31:32 +0200 Subject: [PATCH] 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. --- rpm/kernel-binary.spec.in | 106 +++++++++++++++++++++++++++++++----- rpm/kernel-obs-qa.spec.in | 2 +- rpm/kernel-source.rpmlintrc | 6 +- rpm/kernel-subpackage-build | 30 ++++++---- rpm/kernel-subpackage-spec | 11 ++++ rpm/post.sh | 19 ++++++- rpm/postun.sh | 4 +- rpm/split-modules | 10 ++-- 8 files changed, 152 insertions(+), 36 deletions(-) diff --git a/rpm/kernel-binary.spec.in b/rpm/kernel-binary.spec.in index 9d7434a179fe..120e2419afa8 100644 --- a/rpm/kernel-binary.spec.in +++ b/rpm/kernel-binary.spec.in @@ -68,6 +68,20 @@ %define install_vdso 0 %endif +# TW is usrmerged +%if %{undefined usrmerged} && 0%{?suse_version} >= 1550 +%define usrmerged 1 +%endif + +%if 0%{?usrmerged} +%define modules_dir /usr/lib/modules/%kernelrelease-%build_flavor +%define systemmap %{modules_dir}/System.map +%else +%define modules_dir /lib/modules/%kernelrelease-%build_flavor +%define systemmap /boot/System.map-%kernelrelease-%build_flavor +%endif + + Name: kernel-@FLAVOR@ Summary: @SUMMARY@ License: GPL-2.0 @@ -465,6 +479,14 @@ done %install +%if 0%{?usrmerged} +# add symlink for usrmerge so install scripts will just follow the +# link and end up placing files in /usr/lib. The link will be +# removed later and is not packaged here. +mkdir -p %{buildroot}/usr/lib +ln -s usr/lib %{buildroot}/lib +%endif + # get rid of /usr/lib/rpm/brp-strip-debug # strip removes too much from the vmlinux ELF binary export NO_BRP_STRIP_DEBUG=true @@ -557,11 +579,19 @@ add_vmlinux() # sign the modules, firmware and possibly the kernel in the buildservice BRP_PESIGN_FILES="" %if "%CONFIG_EFI_STUB" == "y" +%if 0%{?usrmerged} +BRP_PESIGN_FILES="%modules_dir/$image" +%else BRP_PESIGN_FILES="/boot/$image-%kernelrelease-%build_flavor" %endif +%endif %ifarch s390x ppc64 ppc64le +%if 0%{?usrmerged} +BRP_PESIGN_FILES="%modules_dir/$image" +%else BRP_PESIGN_FILES="/boot/$image-%kernelrelease-%build_flavor" %endif +%endif %if "%CONFIG_MODULE_SIG" == "y" BRP_PESIGN_FILES="$BRP_PESIGN_FILES *.ko" %endif @@ -623,6 +653,13 @@ for sub in '' '-extra' \ -e "s:@RPM_TARGET_CPU@:%_target_cpu:g" \ -e "s:@CPU_ARCH_FLAVOR@:%cpu_arch_flavor:g" \ -e "s:@SRCVARIANT@:%variant:g" \ + -e "s:@MODULESDIR@:%modules_dir:g" \ + -e "s:@SYSTEMMAP@:%systemmap:g" \ +%if 0%{?usrmerged} + -e "s:^@USRMERGE@::" \ +%else + -e "/^@USRMERGE@/d" \ +%endif %_sourcedir/$script.sh > %my_builddir/$script$sub.sh if test "$base_package" -eq 1 -a "${#certs[@]}" -gt 0; then case "$script" in @@ -829,6 +866,10 @@ if [ %CONFIG_MODULES = y ]; then fi rm -rf %{buildroot}/lib/firmware +%if 0%{?usrmerged} +# remove usrmerge aid +rm %{buildroot}/lib +%endif add_dirs_to_filelist() { sed -rn ' @@ -841,7 +882,7 @@ add_dirs_to_filelist() { # print all parents :a # skip directories owned by other packages - s:^%%dir (/boot|/etc|/lib/(modules|firmware)|/usr/src)/[^/]+$:: + s:^%%dir (/boot|/etc|(/usr)?/lib/(modules|firmware)|/usr/src)/[^/]+$:: s:/[^/]+$::p ta ' "$@" | sort -u @@ -854,10 +895,23 @@ fi shopt -s nullglob dotglob > %my_builddir/kernel-devel.files -for file in %buildroot/boot/symtypes* %buildroot/lib/modules/*/{build,source}; do - f=${file##%buildroot} - echo "$f" -done | add_dirs_to_filelist >%my_builddir/kernel-devel.files +{ + echo "%modules_dir/build" + echo "%modules_dir/source" + cd %buildroot + for file in boot/symtypes*; do +%if 0%{?usrmerged} + l="${file##*/}" + l="%modules_dir/${l//-%kernelrelease-%build_flavor}" + mv "$file" "%{buildroot}$l" + ln -s "..$l" $file + echo "$l" + echo "%%ghost /$file" +%else + echo "/$file" +%endif + done +} | add_dirs_to_filelist >%my_builddir/kernel-devel.files ( cd %buildroot ; find .%obj_install_dir/%cpu_arch_flavor -type f ; ) | \ sed -e 's/^[.]//' | grep -v -e '[.]ipa-clones$' -e '/Symbols[.]list$' -e '/ipa-clones[.]list$'| \ add_dirs_to_filelist >> %my_builddir/kernel-devel.files @@ -866,6 +920,8 @@ add_dirs_to_filelist >> %my_builddir/kernel-devel.files echo %ghost /boot/initrd$suffix cd %buildroot for f in boot/*; do + l="${f##*/}" + l="%modules_dir/${l//-%kernelrelease-%build_flavor}" if test -L "$f"; then echo "%%ghost /$f" continue @@ -881,24 +937,46 @@ add_dirs_to_filelist >> %my_builddir/kernel-devel.files ;; boot/vmlinux-*) if $ghost_vmlinux; then - echo "%%ghost /$f" - continue + # fall through to mark next echo as %ghost + echo -n "%%ghost " fi ;; +%if 0%{?usrmerged} + boot/vmlinuz-*) + echo -n "%%attr(0644, root, root) " + ;; +%endif boot/symtypes*) +%if 0%{?usrmerged} + echo "%exclude $l" +%endif continue ;; esac +%if 0%{?usrmerged} + mv "$f" "./$l" + ln -s "..$l" $f + # the find in the CONFIG_MODULES condition below also finds the files + # but there's sort -u later, so this is ok + echo "$l" # note: must be first after case statement above + echo "%%ghost /$f" +%else echo "%%attr(0644, root, root) /$f" +%endif done if [ %CONFIG_MODULES = y ]; then - find lib/modules/%kernelrelease-%build_flavor \ + find %{?usrmerged:usr/}lib/modules/%kernelrelease-%build_flavor \ -type d -o \ \( -path '*/modules.*' ! -path '*/modules.order' \ ! -path '*/modules.builtin' \ ! -path '*/modules.builtin.modinfo' \) -printf '%%%%ghost /%%p\n' \ - -o -name '*.ko' -prune -o -type f -printf '/%%p\n' + -o -name '*.ko' -prune \ +%if 0%{?usrmerged} + -o \( -type f ! -path '*/symtypes*' ! -path '*/vmlinu*' \) -printf '/%%p\n' +%else + -o -type f -printf '/%%p\n' +%endif cat %my_builddir/base-modules fi if test %CONFIG_MODULE_SIG = "y" -a -d etc/uefi/certs; then @@ -956,15 +1034,15 @@ for f in %my_builddir/*-kmp-modules; do done if [ %CONFIG_MODULES = y ]; then - install -m 644 %_sourcedir/modules.fips %{buildroot}/lib/modules/%kernelrelease-%build_flavor/modules.fips - echo /lib/modules/%kernelrelease-%build_flavor/modules.fips >> %my_builddir/kernel-base.files - echo /lib/modules/%kernelrelease-%build_flavor/modules.fips >> %my_builddir/kernel-main.files + install -m 644 %_sourcedir/modules.fips %{buildroot}%modules_dir/modules.fips + echo %modules_dir/modules.fips >> %my_builddir/kernel-base.files + echo %modules_dir/modules.fips >> %my_builddir/kernel-main.files fi # Hardlink duplicate files automatically (from package fdupes): It doesn't save # much, but it keeps rpmlint from breaking the package build. Note that we skip # /usr/src/linux-obj intentionally, to not accidentally break timestamps there -%fdupes $RPM_BUILD_ROOT/lib +%fdupes %buildroot%modules_dir %preun -f preun.sh @@ -1144,7 +1222,7 @@ static, unlike the %{patch_package}- -flavor package names. %files %{livepatch} # rpmlint complains about empty packages, so lets own something %defattr(-, root, root) -%dir /lib/modules/%kernelrelease-%build_flavor +%dir %modules_dir %endif %if 0%{?klp_symbols} && "%livepatch" != "" diff --git a/rpm/kernel-obs-qa.spec.in b/rpm/kernel-obs-qa.spec.in index 251885dbef33..fa8234e8af62 100644 --- a/rpm/kernel-obs-qa.spec.in +++ b/rpm/kernel-obs-qa.spec.in @@ -60,7 +60,7 @@ projects and runs basic tests. # and called here. krel=$(uname -r) -if test ! -d "/lib/modules/$krel/kernel"; then +if test ! -d "/lib/modules/$krel/kernel" && test ! -d "/usr/lib/modules/$krel/kernel"; then echo "Kernel package for $krel not installed; exiting" exit 0 fi diff --git a/rpm/kernel-source.rpmlintrc b/rpm/kernel-source.rpmlintrc index 5d4abc78cb23..748d9097df9e 100644 --- a/rpm/kernel-source.rpmlintrc +++ b/rpm/kernel-source.rpmlintrc @@ -1,10 +1,10 @@ # These zero-length files are correct: addFilter("zero-length /usr/src/linux-.*-obj/.*/include/config.*h") # vdsos are special -addFilter("shared-lib-without-dependency-information /lib/modules/[1-9].*/vdso/.*") -addFilter("missing-PT_GNU_STACK-section /lib/modules/[1-9].*/vdso/.*") +addFilter("shared-lib-without-dependency-information .*/lib/modules/[1-9].*/vdso/.*") +addFilter("missing-PT_GNU_STACK-section .*/lib/modules/[1-9].*/vdso/.*") # This is a stale symlink until the kernel-source package is installed: -addFilter("dangling-symlink /lib/modules/[1-9].*/source") +addFilter("dangling-symlink .*/lib/modules/[1-9].*/source") # These hidden files are fine: addFilter("hidden-file-or-dir /usr/src/linux-.*-obj/.*/.config") addFilter("hidden-file-or-dir /usr/src/linux-.*-obj/.*/.kernel-binary.spec.buildenv") diff --git a/rpm/kernel-subpackage-build b/rpm/kernel-subpackage-build index 71df40c00906..6bc9b16a1ace 100644 --- a/rpm/kernel-subpackage-build +++ b/rpm/kernel-subpackage-build @@ -21,7 +21,8 @@ rpm -q --qf '%{POSTUN}' $kernel_package_name | sed -e "s/$kernel_nvrq/$package_n [ -z "$(rpm -q --triggers $kernel_package_name)" ] # not handled -KREL=$(cat kernel.flist | grep ^/lib/modules | { sort -r ||: ;} | head -n 1 | sed -e s,^/lib/modules/,, -e 's,/.*,,') +KREL=$(sed -rne '/^(\/usr)?\/lib\/modules\/([^/]+)$/{s,.*/,,;p;q}' < kernel.flist) +grep -q /usr/lib/modules/ kernel.flist && USR=/usr $scriptdir/mergedep $KREL > modules.dep @@ -29,9 +30,9 @@ $scriptdir/mergedep $KREL > modules.dep $scriptdir/moddep modules.dep request-modules modules $scriptdir/modflist kernel.flist modules modules.flist /lib/modules/$KREL/modules.builtin -cat kernel.flist | grep -v ^/lib/modules >> modules.flist -[ -d /lib/modules/$KREL/vdso ] && echo /lib/modules/$KREL/vdso >> modules.flist ||: -echo /lib/modules/$KREL/modules.* | tr ' ' '\n' >> modules.flist +grep -v ^$USR/lib/modules < kernel.flist >> modules.flist +[ -d $USR/lib/modules/$KREL/vdso ] && echo $USR/lib/modules/$KREL/vdso >> modules.flist ||: +echo $USR/lib/modules/$KREL/modules.* | tr ' ' '\n' >> modules.flist tar -C / -cf- -T modules.flist | tar -C $RPM_BUILD_ROOT -xvf- @@ -44,18 +45,24 @@ exit 1 fi echo "%defattr(-,root,root)" > subpackage.flist -cat kernel.flist | grep -v ^/lib/modules >> subpackage.flist -echo /lib/modules/$KREL >> subpackage.flist +grep -v $USR/lib/modules < kernel.flist >> subpackage.flist +echo $USR/lib/modules/$KREL >> subpackage.flist cat kernel-ghost.flist | sed -e 's/^/%ghost /' >> subpackage.flist cat kernel-ghost.flist | while read ghost ; do case $ghost in - /boot/image-%build_flavor | /boot/vmlinux-%build_flavor | /boot/vmlinuz-%build_flavor | \ - /boot/Image-%build_flavor | /boot/initrd-%build_flavor) + /boot/image-$KREL | /boot/vmlinux-$KREL | /boot/vmlinuz-$KREL | \ + /boot/Image-$KREL | /boot/initrd-$KREL) + ;; + /boot/System.map-$KREL | /boot/symtypes-$KREL* | /boot/symvers-$KREL*) ;; /boot/vmlinux | /boot/vmlinuz | /boot/zImage | /boot/Image | /boot/image | /boot/initrd) ;; - /boot/vmlinux-$KREL) + /boot/.*$KREL.hmac ) + ;; + /boot/config-$KREL | /boot/sysctl.conf-$KREL) + ;; + /boot/vmlinux-$KREL*) [ -f /boot/vmlinux-$KREL.gz ] && touch vmlinux-$KREL ;; /boot/initrd-$KREL | /boot/initrd-$KREL-kdump) @@ -66,13 +73,14 @@ cat kernel-ghost.flist | while read ghost ; do bs=1024 seek=2047 count=1 chmod 0600 $RPM_BUILD_ROOT$ghost ;; - /lib/modules/$KREL/modules.*) + $USR/lib/modules/$KREL/modules.*) [ -f $RPM_BUILD_ROOT$ghost ] ;; + $USR/lib/modules/$KREL/vmlinux) + ;; *) echo Missing file "$ghost" not handled. exit 1; ;; esac done - diff --git a/rpm/kernel-subpackage-spec b/rpm/kernel-subpackage-spec index 3f2bea62aa43..cbf649fc38c5 100644 --- a/rpm/kernel-subpackage-spec +++ b/rpm/kernel-subpackage-spec @@ -1,6 +1,10 @@ %define rpm_kver %(rpm -q --qf '%%{VERSION}' %kernel_package_name) %define rpm_krel %(rpm -q --qf '%%{RELEASE}' %kernel_package_name) +%if %{undefined usrmerged} && 0%{?suse_version} >= 1550 +%define usrmerged 1 +%endif + # Force bzip2 instead of lzma compression to # 1) allow install on older dist versions, and # 2) decrease build times (bsc#962356) @@ -79,10 +83,17 @@ There is no reason to install this package. %build %install +%if 0%{?usrmerged} +ln -s usr/lib %{buildroot}/lib +%endif echo "%{?modules}" | tr ', ' '\n\n' > request-modules %scriptdir/kernel-subpackage-build %kernel_package_name %rpm_kver-%rpm_krel %package_name-%version-%release +%if 0%{?usrmerged} +rm %{buildroot}/lib +%endif + %preun -f preun.sh %postun -f postun.sh diff --git a/rpm/post.sh b/rpm/post.sh index 052ae5a6fdd2..8c389802ed39 100644 --- a/rpm/post.sh +++ b/rpm/post.sh @@ -10,6 +10,23 @@ for x in /boot/@IMAGE@ /boot/initrd; do rm -f $x$suffix ln -s ${x##*/}-@KERNELRELEASE@-@FLAVOR@ $x$suffix done +@USRMERGE@# compat stuff for /boot. +@USRMERGE@# if /boot is not a speparate partition we can just link the kernel +@USRMERGE@# there to save space. Otherwise copy. +@USRMERGE@if mountpoint -q /boot; then +@USRMERGE@ copy_or_link="cp -a" +@USRMERGE@else +@USRMERGE@ copy_or_link="ln -sf" +@USRMERGE@fi +@USRMERGE@# XXX: need to fix suse-module-tools for sysctl.conf and System.map +@USRMERGE@for x in @IMAGE@ sysctl.conf System.map; do +@USRMERGE@ if [ ! -e /boot/$x-@KERNELRELEASE@-@FLAVOR@ ]; then +@USRMERGE@ $copy_or_link ..@MODULESDIR@/$x /boot/$x-@KERNELRELEASE@-@FLAVOR@ +@USRMERGE@ if [ -e @MODULESDIR@/.$x.hmac ]; then +@USRMERGE@ $copy_or_link ..@MODULESDIR@/.$x.hmac /boot/.$x-@KERNELRELEASE@-@FLAVOR@.hmac +@USRMERGE@ fi +@USRMERGE@ fi +@USRMERGE@done # Add symlinks of compatible modules to /lib/modules/$krel/weak-updates/, # run depmod and mkinitrd @@ -56,7 +73,7 @@ if [ -f /etc/fstab -a ! -e /.buildenv ] ; then if [ @FLAVOR@ = rt ]; then default=force-default fi - if [ -e /boot/$initrd -o ! -e /lib/modules/@KERNELRELEASE@-@FLAVOR@ ] && \ + if [ -e /boot/$initrd -o ! -e @MODULESDIR@ ] && \ run_bootloader ; then [ -e /boot/$initrd ] || initrd= if [ -x /usr/lib/bootloader/bootloader_entry ]; then diff --git a/rpm/postun.sh b/rpm/postun.sh index d5165044abc4..d5c3a6664922 100644 --- a/rpm/postun.sh +++ b/rpm/postun.sh @@ -6,7 +6,7 @@ rm -f /boot/do_purge_kernels wm2=/usr/lib/module-init-tools/weak-modules2 nvr=@SUBPACKAGE@-@RPM_VERSION_RELEASE@ -if [ -e /boot/System.map-@KERNELRELEASE@-@FLAVOR@ ]; then +if [ -e @SYSTEMMAP@ ]; then # the same package was reinstalled or just rebuilt, otherwise the files # would have been deleted by now # do not remove anything in this case (bnc#533766) @@ -21,7 +21,7 @@ if [ @BASE_PACKAGE@ = 0 ]; then rm -f /var/run/rpm-$nvr-modules exit 0 fi -# Remove symlinks from /lib/modules/$krel/weak-updates/. +# Remove symlinks from @MODULESDIR@/weak-updates/. if [ -x $wm2 ]; then /bin/bash -${-/e/} $wm2 --remove-kernel @KERNELRELEASE@-@FLAVOR@ fi diff --git a/rpm/split-modules b/rpm/split-modules index 4f27fecff94a..58505fe1bb52 100755 --- a/rpm/split-modules +++ b/rpm/split-modules @@ -77,7 +77,7 @@ while read mod path; do no) ;; "") - echo "warning: ${path#/lib/modules/*/kernel/} not listed in supported.conf" >&2 + echo "warning: $mod not listed in supported.conf" >&2 ;; *) echo "error: invalid support flag for $mod: $support" >&2 @@ -119,11 +119,13 @@ join -j 1 -o 2.2 "$tmp/base" "$tmp/all" >"$opt_out/base-modules" # base firmware kver=$(make $MAKE_ARGS -s -C "$opt_builddir" kernelrelease) -if test -d "$opt_dir/lib/firmware/$kver"; then +fw_dir=/lib/firmware/$kver +test -d $opt_dir/usr$fw_dir && fw_dir=/usr$fw_dir +if test -d "$opt_dir$fw_dir"; then join <(/sbin/modinfo -F firmware \ $(sed "s:^:$opt_dir:" "$opt_out/base-modules") | sort) \ - <(find "$opt_dir/lib/firmware/$kver" -type f -printf '%P\n' | sort) -fi | sed "s:^:/lib/firmware/$kver/:" >"$opt_out/base-firmware" + <(find "$opt_dir$fw_dir" -type f -printf '%P\n' | sort) +fi | sed "s:^:$fw_dir:" >"$opt_out/base-firmware" # kmps for f in "$opt_builddir"/Module.*-kmp; do -- 2.26.2 cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
participants (16)
-
Andrei Borzenkov
-
ariel sabiguero yawelak
-
Carlos E. R.
-
Giacomo Comes
-
L A Walsh
-
Larry Finger
-
Ludwig Nussel
-
Michal Suchánek
-
Olaf Hering
-
Oliver Neukum
-
Oliver Neukum
-
Petr Tesařík
-
Petr Vorel
-
Sinisa
-
Stefan Seyfried
-
Takashi Iwai