friendly-recovery violates the Linux Filesystem Hierarchy Standard

Bug #234409 reported by Steven Black
This bug affects 2 people
Affects Status Importance Assigned to Milestone
friendly-recovery (Ubuntu)
Stéphane Graber
newt (Ubuntu)

Bug Description

Binary package hint: friendly-recovery

friendly-recovery uses files in /usr, but runs in single-user mode.

This is a violation of the Linux Filesystem Hierarchy Standard, which states that "The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system." (See )

friendly-recovery, due to the current install locations:

(1) prevents the system from booting in recovery mode if the /usr partition is corrupted.
(2) prevents /usr from being resized, as it can never be unmounted

I'm a fan of LVM, and found #2 a huge problem for me. A huge benefit of LVM is that it allows you to dynamically increase the size of partitions. This benefit is negated if you can't unmount some of your partitions due to software using it.

Revision history for this message
Steven Black (blacks-indiana) wrote :

My preference:

Instead of /usr/share, the recovery menu logic moves to /lib. Either whiptail needs to also move to /bin, or you need to fall-back to a shell-based solution if whiptail is unavailable (such as the partition not available).

Michael Vogt (mvo)
Changed in friendly-recovery:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Gianmarco De Francisci Morales (gianmarco-dfm) wrote :

I am new to launchpad and I am seeking a start point to get involved.
I saw you offer mentoring for this bug, and I would like to tackle it.

Revision history for this message
Stéphane Graber (stgraber) wrote :

friendly-recovery depends on whiptail which is currently in /usr (and libnewt in /usr/lib). These two will need to be moved to / before friendly-recovery can work properly without /usr.

For the time being friendly-recovery will be moved to /lib and will drop to a root shell should /usr be unavailable.

Changed in friendly-recovery (Ubuntu):
assignee: nobody → Stéphane Graber (stgraber)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package friendly-recovery - 0.2.13

friendly-recovery (0.2.13) oneiric; urgency=low

  * Move everything to /lib/recovery-mode/ (LP: #234409)
  * Don't use the fullpath to whiptail
  * Add new init script starting on recovery-mode (LP: #459376)
  * If whiptail can't be found, just start sulogin
  * Add a script to start mountall (remount everything read/write)
    (LP: #575469, LP: #651782)
  * Export READONLY to all scripts so they can test on the read/write state
  * Disable most scripts when the system is read only
  * Change file system check to happen when remount is called
  * Wait after all scripts returning output so the user can read it
  * Add postinst script to move any existing script to /lib/recovery-mode
    and make /usr/share/recovery-mode a symlink
  * Mark as breaking on older grub2, upstart and initramfs-tools
  * Small packaging refresh:
    - Bump standard to 3.9.2, no change needed
    - Drop simple patchsys (no patches)
    - No need to depend on bash (essential package)
    - Add ${misc:Depends} to dependencies
 -- Stephane Graber <email address hidden> Wed, 07 Sep 2011 20:18:53 -0400

Changed in friendly-recovery (Ubuntu):
status: Triaged → Fix Released
Changed in newt (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers