Bug 76737 - RFE: kernel-install: support targets other than /boot/
Summary: RFE: kernel-install: support targets other than /boot/
Status: RESOLVED WONTFIX
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-28 13:59 UTC by Andrew
Modified: 2014-04-02 17:21 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Andrew 2014-03-28 13:59:25 UTC
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.
Comment 1 Kay Sievers 2014-03-29 19:29:43 UTC
(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.
Comment 2 Andrew 2014-04-02 11:21:20 UTC
> 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.
Comment 3 Kay Sievers 2014-04-02 12:08:55 UTC
(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?
Comment 4 Andrew 2014-04-02 17:21:38 UTC
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.