<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - RFE: kernel-install: support targets other than /boot/" href="https://bugs.freedesktop.org/show_bug.cgi?id=76737#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - RFE: kernel-install: support targets other than /boot/" href="https://bugs.freedesktop.org/show_bug.cgi?id=76737">bug 76737</a> from <a class="email" href="mailto:kay@vrfy.org" title="Kay Sievers <kay@vrfy.org>"> Kay Sievers</a> <pre>(In reply to <a href="show_bug.cgi?id=76737#c0">comment #0</a>) > Unfortunately, anaconda forces the ESP to be /boot/efi/ (which I find itself > really strange). It is strange, and stacking different types an functions of boot and firmware mountpoints is just a broken idea. It is rather common though, most distros do that by default. > Since kernel-install hard-codes /boot/ as the target, the > result was that my loader snippets, kernel, etc. were not actually copied to > the ESP, but simply in /boot/${machine-id} . Right, with gummiboot we decided that, for simplicity reasons, all of /boot ends up in the ESP, and systemd auto-discovers that and sets up an automountpoint without any need for an fstab entry. gummiboot has no plans to support a separate /boot partition, so it needs to read the kernels from the ESP. > The result of course is that > gummiboot couldn't boot without manually moving the contents to /boot/efi/ . If you do not want to change the entire /boot mountpoint, you might be able to just create /boot/loader and /boot/$machine-id as symlinks into the /boot/efi/ partition. We know from people running setups like that just fine. > I think I could manually copy the 90-xx snippet in > /usr/lib/kernel/install.d/ , but it seems like this should perhaps be more > configurable ? Perhaps a kernel_install_target option in system.conf or so > ? I'd hate to override the relatively large script just to change the > location, and miss out on future updates. We do not really want that kind of configurability for known broken and limited setups. In our view /boot/efi is unfixable. As mentioned, we decided for now to just use /boot as the ESP and let the firmware read the kernels from there. Until we possibly come up with a better solution, the "symlink trick" should hide that for setups where /boot should not be changed. At this point in time, we better do not add config options that we would later remove again. We specifically do not want to support any nested mountpoints, because they cannot be configured as automounts, which is the most appropriate option for the rather fragile ESP mounting. > Thanks for the consideration, and sorry if I'm misunderstanding the > situation. Not at all a misunderstanding on your side, it is just that, with gummiboot, we explicitly did not want to follow the mess the distros are creating with /boot/efi/ layout. We need to sort that out some day, if we can't agree on /boot being the ESP, we probably need another /firmware top-level mountpoint, instead of the misguided /boot/efi/ nesting.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>