When using "Recover a broken system" from the Server CD boot menu, /boot is not mounted

Bug #320183 reported by Etienne Goyer
6
Affects Status Importance Assigned to Milestone
rescue (Ubuntu)
Fix Released
Low
Colin Watson

Bug Description

Binary package hint: debian-installer

Booting from the intrepid Server CD, and choosing the "Recover a broken system", the /boot partition is not mounted automatically.

When installing using LVM, the default is to create a separate /boot partition that is not on an LV. Hence, when using the server CD to recover a system that have been installed using LVM, the /boot partition will not be automatically available when recovering the system using the CD.

This is very annoying in some circumstance, such as when doing anything that invoke update-initramfs. update-initramfs would not fail, it would just create a new initramfs under /boot in the root filesystem LV, not in the /boot partition. As such, the system will still boot using the old initramfs.

Tags: iso-testing
Revision history for this message
Colin Watson (cjwatson) wrote :

Isn't this covered in the message displayed when you choose the rescue shell option?

_Description: Executing a shell
 After this message, you will be given a shell with ${DEVICE} mounted on
 "/". If you need any other file systems (such as a separate "/usr"), you
 will have to mount those yourself.

That said, I agree that we could probably handle this more smoothly. My worry, though, is cases where the /boot filesystem is broken in some way and needs recovery.

Changed in debian-installer:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Colin Watson (cjwatson) wrote :

Perhaps a viable approach here would be to display a menu of the subsidiary filesystems that you might want to mount, and allow the user to select from them. This would cope with the subsidiary-filesystem-needs-recovery case, while making it clearer how to cope with the case you describe.

Changed in rescue:
status: Confirmed → Triaged
Revision history for this message
Etienne Goyer (etienne-goyer-outlands) wrote :

I like the idea of prompting to mount other filesystem, but this would still not address the use-case where an admin do not know he needs the /boot filesystem mounted for recovering his system. This would be the case if recovering said system would indirectly call initramfs somehow (ie, installing/removing a package that calls it, such as multipath-tools for example). This is especially bad as update-initramfs would just go ahead and create a new initramfs in the empty /boot mount point, which would not get loaded by GRUB at next reboot.

Perhaps the real solution is to make initramfs aware of the filesystem on which it should write the initramfs, and make it warn somehow if it not mounted? Just saying.

tags: added: iso-testing
Colin Watson (cjwatson)
Changed in rescue (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package rescue - 1.33ubuntu1

---------------
rescue (1.33ubuntu1) quantal; urgency=low

  * If the target system has a separate /boot, offer to try to mount it, to
    make it easier to do things like reinstalling boot loaders (LP: #320183,
    #1045409).
 -- Colin Watson <email address hidden> Thu, 20 Sep 2012 15:00:21 +0100

Changed in rescue (Ubuntu):
status: Triaged → Fix Released
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.