search

ibm-s390-linux / s390-tools

Tools for use with the s390 Linux kernel and device drivers
MIT License
63 stars 59 forks source link

set BOOT_IMAGE in bootmap #78

Open sharkcz opened 4 years ago

sharkcz commented 4 years ago

There are some use cases that rely on having BOOT_IMAGE= set. There is a inconsistency on the s390x platform, because booting from DASD sets it, but booting from virtio disk in KVM does not. When looking at other platforms, then grub2 sets it on x86, aarch64, pseries (ppc).

Please read https://bugzilla.redhat.com/show_bug.cgi?id=1782026 (the original request) https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg02999.html (follow up discussion with virt people) for more information.

borntraeger commented 4 years ago

Looking at https://bugzilla.redhat.com/show_bug.cgi?id=1415032 what you actually want it that the zipl program appends "BOOT_IMAGE=<kernel file name after last "/"> for all variants (DASD, SCSI, virtio). Is that correct? That would mean that adding "BOOT_IMAGE=<kernel file name after last "/"> when writing the boot records (and not during boot) would actually solve your problem?

Prashanth684 commented 4 years ago

As of today on a zVM system, BOOT_IMAGE is a number indicating the selected boot record. For the purpose specified in https://bugzilla.redhat.com/show_bug.cgi?id=1782026, it needs to be the path to the kernel file name. It would be nice to be consistent across all variants to have just one or the other. I would prefer the kernel file name since that is how it is specified for other arches and used in dracut too.

jlebon commented 3 years ago

If changing the semantics of BOOT_IMAGE is too late at this point, could we introduce a new e.g. BOOT_IMAGE_PATH kernel argument which is simply the /boot-relative path to the kernel image? For BLS configs at least, this would just mean taking the value of the linux key and converting that to a BOOT_IMAGE_PATH=$value karg.

Prashanth684 commented 3 years ago

@jlebon that sounds like a reasonable idea. @sharkcz @borntraeger thoughts? @borntraeger like you mentioned, this new argument would be added when writing the boot records.

xnox commented 3 years ago

In UEFI world, we can tell which drive something has booted from and how. Which menu entry. And which files. Upon network boot we normally pass the interface mac address as the command line arg.

So yes, having all that information passed to the kernel would be nice. Aka ccw id of the thing we booted from, which menu number if any, and file path. To know if i booted off 0.0.300 and what menu entry I did there.

Are there any other ways that this information is already exposed by the HMC / z/VM ? anything in /proc or /sys?

stefan-haberland commented 3 years ago

Hi, some information can be obtained from /sys/firmware/ipl/ this is what lsreipl uses as well. Device, ipl_type, loadparm and parm for ccw type IPL for example.

For the zipl BOOT_IMAGE entry there is currently not that much choice to provide different information than the number. The zipl loader does simply not know about the filename for example. It only has the title and the entry number available. And it is not that easy to provide/extent this information because we have only a limited amount of space available for the loader entries where the title is stored.

This could for example be omitted/extended by storing additional information in the bootmap for the entry. There is an upcoming item to support environment blocks for zipl which I can imagine to be helpful here.

But in addition there is also a limitation in the kernel that only 896 byte of data can be stored for the kernel commandline. All currently used data plus whatever should be added in the future would need to fit in this amount of data. I am aware of customer scenarios where with a large amount of devices this was already a problem.

This could be omitted/extended by storing the commandline to a different location in the kernel.

There might be chances to improve all this in the future but this will take time. I can currently only offer to open items for this and they will be prioritized accordingly.

jlebon commented 3 years ago

OSTree-specific dracut workaround for this in https://github.com/dracutdevs/dracut/pull/1539.

nikita-dubrovskii commented 3 years ago

Hi, @stefan-haberland , could you please say, is it a defined behavior:

Am i right, that BOOT_IMAGE= is only used with DASD disks ?

stefan-haberland commented 3 years ago

Hi,

what I can say is that the "BOOT_IMAGE=N" entry is created by the zipl stage2 loader in the menu code (menu.c: menu() ). This loader is NOT used for zFCP IPL. So the zipl code can not create this entry.

I can not say if the firmware loader, that is used for zFCP, ever created this entry.

nikita-dubrovskii commented 3 years ago

Hi,

what I can say is that the "BOOT_IMAGE=N" entry is created by the zipl stage2 loader in the menu code (menu.c: menu() ). This loader is NOT used for zFCP IPL. So the zipl code can not create this entry.

I can not say if the firmware loader, that is used for zFCP, ever created this entry.

Yep, i saw that code. But how do you think - should zipl also add BOOT_IMAGE on zfcp?

stefan-haberland commented 3 years ago

AFAIK this was never intended.

But there are plans to change the BOOT_IMAGE= number to the actual file name and I think it makes sense that this should look identical across all IPL methods afterwards.

jlebon commented 3 years ago

But there are plans to change the BOOT_IMAGE= number to the actual file name and I think it makes sense that this should look identical across all IPL methods afterwards.

This sounds great! We just need to make sure we revert https://github.com/dracutdevs/dracut/pull/1539 once that happens.