update-initramfs is vulnerable to power loss

[Adrian Moisey]

Power was lost while update-initramfs was running from a security update.

When I turned my PC on after the power loss, it wouldn't boot on any kernel (the default one and the rescue one). I had to boot a rescue CD and manually run update-initramfs.

Unfortunately I didn't take down the errors. If they are needed I can try recreate the bug.

[Jonathan Carter (jonathan)]

Does update-initramfs rebuild the initramfs in place, or does it first generate it and then move it over?

If it's generated in place, it might be a better idea to first create it, and then move it over, to minimise the risk of an unpredicted power outage.

[TerryG (tgalati4)]

Marking as Confirmed. That's a good question. The system should be left bootable for as long as possible. What's the approximate time difference between creating it to /tmp and writing it over, versus creating-and-writing on-the-fly?

For Gutsy, 9.2 MB for initrd with a 35 MB/sec disk would be 0.26 seconds to copy over. Anybody measure update-initramfs with a stopwatch?

Of course, when you lose power, anything is possible. That is why I have an UPS on each of my computers.

To the reporter: Did the backup copies and/or older kernel not boot either? Granted you would have to login with a rescue shell and manually copy over. I'm running Linux Mint 4 XFCE and I've got backups of my original Gutsy kernel and initrd. With updates you would have multiple kernels and initrd images.

[Kees Cook (kees)]

The initramfs is created separately and moved into place in Hardy. If this is reproduced, we can better diagnose problems in the future.

[Adrian Moisey (adrianmoisey)]

TerryG, I didn't try the backup copies of the kernel. I tried the default kernel and the rescue one, both failed.
I only have 1 kernel installed, I remove the old ones.

[TerryG (tgalati4)]

The rescue kernel will fail since initrd is broken. The backup initrd (at least with Linux Mint 4 XFCE, based on gutsy) is called: initrd.img-2.6.22-14-generic.bak You only need to rm the old one and copy the backup to it's place, then you should be OK. Of course you need to do this using the Live CD, mounting the drive then finding the boot directory.

[Jonathan Carter (jonathan)]

Kees, well if hardy creates it separately and then copies to place, I suppose this bug can be closed, since a fix has been committed. I can't really think of anything else that would make initramfs less vulnerable at this stage, I agree that it could do with further investigation.

[Colin Watson (cjwatson)]

Yes, we fixed this bug in hardy.

initramfs-tools (0.85eubuntu24) hardy; urgency=low

  * Implement the initramfs-tools part of the initramfs error handling spec
  * update-initramfs:
    - Make a hard link to the original initramfs image, rather than moving
      it out of the way.
    - Create a new initramfs image to ${initramfs}.new, to ensure we still
      have a functional initramfs in case of failure. The original initramfs
      only gets replaced when a new image is successfully created.
  * scripts/functions:
    - Added add_mountroot_fail_hook function to allow scripts in
      init-premount to register a hook to allow extra information
      to be given to the user, in the event of a non-existant root
      device.
    - The panic function now runs any registered mountroot fail hooks that
      were previously registered, and only does so when passed the -r
      argument from the calling function.
  * scripts/local: Call the panic function with -r to run any registered
    mountroot fail hooks when a root device cannot be found.

 -- Luke Yelavich <email address hidden> Tue, 05 Feb 2008 13:38:51 +1100