initramfs-tools-ubuntu-core: hook assumes system-image is installed, without dependency

Bug #1376111 reported by Steve Langasek
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
initramfs-tools-ubuntu-core (Ubuntu)
Fix Released
Undecided
James Hunt

Bug Description

The initramfs hook in the initramfs-tools-ubuntu-core package includes the following:

# Extra stuff we need
mkdir -p "$DESTDIR/etc/system-image/"
cp /etc/system-image/archive-master.tar.xz "$DESTDIR/etc/system-image/"
cp /etc/system-image/archive-master.tar.xz.asc "$DESTDIR/etc/system-image/"
copy_exec /bin/chown
copy_exec /bin/tar
copy_exec /usr/bin/gpg
copy_exec /usr/bin/system-image-upgrader
copy_exec /usr/bin/unxz

The i-t-u-c package does not depend on any of the packages providing these files; which means that installing i-t-u-c without installing, e.g., the package that provides /etc/system-image/archive-master.tar.xz , can break initramfs upgrades for the system.

It's also not clear to me why the upgrade is being done from the initramfs. My understanding was that Stéphane had proposed that the update should be done from the running system using a namespace-specific rw remount of the rootfs (preventing processes other than the upgrader from writing to the disk). This would enable the update to be applied with only a single reboot. With the proposed script, another reboot is still required in order to fully apply the update because the update may change the running kernel. (Which means that the current script is buggy, because it doesn't reboot at the end - it just leaves the system mounted rw and boots into it.)

Steve Langasek (vorlon)
Changed in initramfs-tools-ubuntu-core (Ubuntu):
assignee: nobody → James Hunt (jamesodhunt)
Revision history for this message
James Hunt (jamesodhunt) wrote :

Hi Steve,

Immediate problem fixed, pending upload by someone with appropriate powers :-)

> My understanding was that Stéphane had proposed that the update should be done from the running system using a
> namespace-specific rw remount of the rootfs...
The blueprint does mention this as an idea (using the words 'may' and 'might'), so it sounds like we need to discuss if that is the approach we want to take, and then flesh out work items as appropriate.

Revision history for this message
James Hunt (jamesodhunt) wrote :

(I guess if we want to do this from the live system we should also put the functionality in a different package as the name would be misleading otherwise).

Revision history for this message
Michael Vogt (mvo) wrote :

I think it would be good to discuss the pro/cons of the different approaches. While the downside of doing it in the initramfs is that it takes longer the upside is that we avoid the "firefox-upgrade" (i.e. if files are updated on the same location as the previous file but are no longer compatible with the old running version, we might have something similar with daemons, apache modules or similar) problem that we have with the live upgrades with apt/dpkg.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package initramfs-tools-ubuntu-core - 0.2

---------------
initramfs-tools-ubuntu-core (0.2) utopic; urgency=low

  * scripts/read-only-rootfs: Add required directories.
  * debian/control: Add missing Depends: on system-image-common (LP: #1376111).
 -- James Hunt <email address hidden> Wed, 01 Oct 2014 13:27:51 +0100

Changed in initramfs-tools-ubuntu-core (Ubuntu):
status: New → Fix Released
Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1376111] Re: initramfs-tools-ubuntu-core: hook assumes system-image is installed, without dependency

On Wed, Oct 01, 2014 at 01:09:53PM -0000, Michael Vogt wrote:
> I think it would be good to discuss the pro/cons of the different
> approaches. While the downside of doing it in the initramfs is that it
> takes longer the upside is that we avoid the "firefox-upgrade" (i.e. if
> files are updated on the same location as the previous file but are no
> longer compatible with the old running version, we might have something
> similar with daemons, apache modules or similar) problem that we have
> with the live upgrades with apt/dpkg.

Ok; I understood this had already been decided and it was only a matter of
implementing it. I certainly don't think that the firefox upgrade problem
justifies forcing users to do two reboots in order to apply an update to
their system, certainly not on servers (Ubuntu Core) but also not on
desktops. Firefox's idiosyncratic architecture causes problems on upgrades,
but it's idiosyncratic - services running on a server don't tend to have
this issue, and if we want to be safe we can just shut down all
click-provided services as part of the upgrade process while still saving
ourselves a reboot until the end.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.