Ubuntu Wiki

• Launchpad Entry: foundations-q-usr-merge

• Created: 2012-04-03

• Contributors: Steve Langasek

• Packages affected: debian-installer, initramfs-tools, all packages shipping files in /bin /sbin /lib /lib32 /lib64

• Status: DRAFT

Summary

Fedora has decided that they are going to merge {/bin,/lib,/sbin} into /usr. https://fedoraproject.org/wiki/Features/UsrMove This means that upstream support for distinguishing between / and /usr for early boot services will atrophy more than it already has, and there will be extra work involved for Ubuntu to maintain this capability. Furthermore, if we can rely on /usr to be mounted when upstart starts, we can simplify a number of system jobs.

For Quantal, merged /usr should be supported. On new systems installer should create {/bin, /lib, /sbin} symlinks into /usr.

Release Note

Ubuntu now supports installations of / merged into /usr. By default on new installation, the installer will create symlinks to point /bin, /sbin, /lib, /lib32, /lib64 to their respective locations under /usr. For further details see: https://wiki.ubuntu.com/FoundationsTeam/Specs/Quantal/UsrMerge

Rationale

Are there examples of real use cases / systems which do not have initramfs AND at the same time have /usr as a separate mount point?

No use cases so far were identified by above question, therefore there is a benefit of supporting merged root and /usr.

This does not affect any of ubuntu default installs.

Direct benefits to Ubuntu:

• Alignment with upstreams and other distributions to not distinguish / and /usr for early boot services
• Simply a number of system upstart jobs, since we can now rely on /usr to be mounted

For other benefits see:

• https://fedoraproject.org/wiki/Features/UsrMove

• http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

User stories

• Julie chooses to have /usr mounted on a separate partition during installation. She can still boot and execute binaries previously shipped in /bin & /sbin.

Assumptions

• It is supported to have /usr mounted on a separate partition
• Mounting /usr becomes required for booting

Design

The following directories will be merged from root to equivalent directories indicated:

• ORIGIN	TARGET
  /bin	/usr/bin
  /sbin	/usr/sbin
  /lib	/usr/lib
  /lib32	/usr/lib32
  /lib64	/usr/lib64

Compatibility legacy symlinks well be created from ORIGIN -> TARGET.

Implementation

Code changes

• scan archive for double binaries (eg stuff in /bin and /usr/bin) and fix these all for Q
• detect and prevent new conflicts, via e.g. lintian check
• implement initramfs-tools support for /usr mounting (by mounting /, reading /etc/fstab, and mounting /usr from there)
• installer should make /bin, /sbin, /lib symlinks into /usr on new systems

Migration

New Installations:

• installer creates compatibility symlinks

Existing Installations:

• not migrated (?!)
• or migration is done via base-files package

Consequences

• slight increase to the size of initramfs in some cases
• some people have to use initramfs that didn't...but doesn't impact our default install cause we don't even boot without initramfs at this point
• some slightly difficult to measure reduction in parallel booting of / and /usr fsck, possible impact on boot time

Test/Demo Plan

• Automatic installation / additional iso-tests testing with single partition for everything & separate / and /usr partitions

• User space functionality (autoconf, user/external scripts, etc) continue to work with both merged & unmerged /usr

Unresolved issues

During BoF it was not confirmed whether XEN is or is not affected. Xen systems may not have control over the kernel/initramfs in use, so could potentially be affected. The question is, does anyone do separate /usr in Xen?

Etherpad original notes from UDS-Q

 * are there examples of real use cases / systems which do not have initramfs AND at the same time have /usr as a separate mount point? (formal logic)
  - there are some examples of either individually, but none were identified to have both simultaneously.
  - for encryption, there is initramfs
Fedora etc... use an either/or solution - do we have a usecase for having both?

Since no use cases were identified by above question, there is a benefit of supporting merged root and /usr. This does not affect any of ubuntu default installs.

Consequences:
 - slight increase to the size of initramfs in some cases
 - some people have to use initramfs that didn't...but doesn't impact our default install cause we don't even boot without initramfs at this point
  - some slightly difficult to measure reduction in parallel booting of / and /usr fsck, possible impact on boot time

 To break your system:
 - change the kernel
 - mount without UUID
 - no initramfs & separate /usr => FAIL
 - this is not the default install...

is XEN affected?  Xen systems may not have control over the kernel/initramfs in use, so could be affected; the question is, does anyone do separate /usr in Xen?

TODO:
 - scan archive for double binaries (eg stuff in /bin and /usr/bin) and fix these all for Q
 - detect new conflicts
 - This makes sense to do in Debian, since their situation is the same, so let's do it there.
 - file a debian bug for an experimental lintian check for files installed into potentially disputed directories
 - implement initramfs-tools support for /usr mounting (by mounting /, reading /etc/fstab, and mounting /usr from there)
- announce the change and make it clear that we don't have to carry a delta from Debian, or special packaging changes in debian/rules, to install to / instead of /usr
- installer should make /bin, /sbin, /lib symlinks into /usr on new systems

CategorySpec