Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

pkglayering: support packages installing into /boot #853

Closed
cgwalters opened this issue Jun 28, 2017 · 3 comments
Closed

pkglayering: support packages installing into /boot #853

cgwalters opened this issue Jun 28, 2017 · 3 comments
Labels
kind/enhancement

Comments

@cgwalters
Copy link
Member

This is a bit similar to #233
but specific to /boot.

Known affected packages:

  • extlinux
  • fwupdate-efi

I was trying to rebase to rawhide, but something in the virt stack drags in extlinux, which installs files into /boot.

The general problem with /boot is that we don't have a mechanism to make updates there transactional. Right now the ostree position on this is to copy content in the installer, and don't update it by default. We probably should have a mechanism to update it...maybe an explicitly non-transactional thing?

The "extlinux for libguestfs" case is highly special because it's not for the host; libguestfs makes mini VM images using the host content.

But fwupdate-efi is intended to add a new host boot target (AIUI).
@cgwalters cgwalters mentioned this issue Jun 28, 2017
Closed
@cgwalters
Copy link
Member Author

Perhaps one thing we could do is have an "update /boot on shutdown" model. We'd check whether or not the files in /usr/lib/ostree-boot (except the kernel) need to be updated (hash? have a stamp file with deployment checksum?), and if so, mount /boot writable then.

A tricky thing we should figure out then is rollback. Do we want to revert /boot too? I'm not sure.

(Actually another thing this breaks in general is having multiple OSes installed via ostree...but that's not a new problem and it's fringe)

@cgwalters
Copy link
Member Author

If anyone is hitting this:

Resolving dependencies... done
error: Unpacking syslinux-extlinux-nonlinux-6.04-0.2.fc26.noarch:
Unsupported path: /boot/extlinux; See
https://github.com/projectatomic/rpm-ostree/issues/233

You can use this COPR as a workaround: https://copr.fedorainfracloud.org/coprs/walters/syslinux-stub/ (It moves extlinux data to /usr/lib).

@cgwalters
Copy link
Member Author

My offhand take is that for extlinux, the right thing is to move the data into /usr/lib, and have extlinux -i explicitly copy it; then it would be at parity with what we're doing with grub2.

fwupdate-efi is a harder case. But we could also take the "installer" approach, and have e.g. a systemd unit for it that runs at bootup and copies the data if applicable.

cgwalters added a commit to cgwalters/rpm-ostree that referenced this issue Sep 1, 2017
@cgwalters
unpacker: Translate /boot → /usr/lib/ostree-boot
dc0e8db 
At one point `rpm-ostree install libvirt` dragged in libguestfs which in turn
brought in `syslinux-extlinux-nonlinux` which has files in `/boot/extlinux`,
which we rejected.  (That dependency chain appears to have been fixed currently)

For the general case, this is just a partial fix in that we haven't nailed down
the semantics of how updates for `/boot` work.  But in this particular case,
we'll just break libguestfs' `extlinux` verb, which I'm OK with.

Another case is `fwupdate-efi` - we require manual intervention to copy the
data into `/boot` after installing the package.

This is also preparation for [unified core](coreos#729)
in that we now ensure imported kernels don't end up in `/boot` unless
explicitly configured.

Closes: coreos#853
@cgwalters cgwalters mentioned this issue Sep 1, 2017
Closed
rh-atomic-bot pushed a commit that referenced this issue Sep 5, 2017
@cgwalters @rh-atomic-bot
unpacker: Translate /boot → /usr/lib/ostree-boot
5278940 
At one point `rpm-ostree install libvirt` dragged in libguestfs which in turn
brought in `syslinux-extlinux-nonlinux` which has files in `/boot/extlinux`,
which we rejected.  (That dependency chain appears to have been fixed currently)

For the general case, this is just a partial fix in that we haven't nailed down
the semantics of how updates for `/boot` work.  But in this particular case,
we'll just break libguestfs' `extlinux` verb, which I'm OK with.

Another case is `fwupdate-efi` - we require manual intervention to copy the
data into `/boot` after installing the package.

This is also preparation for [unified core](#729)
in that we now ensure imported kernels don't end up in `/boot` unless
explicitly configured.

Closes: #853

Closes: #969
Approved by: jlebon
This was referenced Sep 25, 2017
Merged
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

unpacker: Translate /boot → /usr/lib/ostree-boot cgwalters/rpm-ostree
1 participant
@cgwalters