| Summary: | RFE: kernel-install: support targets other than /boot/ | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Andrew <abrouwers> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED WONTFIX | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
(In reply to comment #0) > 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. > 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. Right, I like this much more. I think it's quite broken that anaconda forced /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 thouht about this, but unfortunately, /boot/efi is a VFAT partition, so symlinks are out. > At this point in time, we better do not add config options that we would > later remove again. > Understood, thanks! I'll work around it for now on this laptop. I have another running Arch, with just /boot as the ESP, and things are much simpler. (In reply to comment #2) > > 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 thouht about this, but unfortunately, /boot/efi is a VFAT partition, so > symlinks are out. /boot is still in the rootfs? Then it should be possible to create symlinks there that point on (not live on) the FAT partition? Yeah, that's right - kernel-install was writing it to /boot/${machine-id}/, but the gummiboot install went to /boot/efi/ (vfat, ESP). So, I needed to copy the stuff from /boot/${machine-id} to /boot/efi/ . I cannot create the symlink on /boot/efi/, because it is a vfat partition, I guess.
|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Last night, I converted an F20 install to boot using gummiboot. The kernel.rpm package integrates very nicely here, and uses kernel-install to provide snippets for gummiboot. Unfortunately, anaconda forces the ESP to be /boot/efi/ (which I find itself really strange). 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} . The result of course is that gummiboot couldn't boot without manually moving the contents to /boot/efi/ . 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. Thanks for the consideration, and sorry if I'm misunderstanding the situation.