UsrMerge
|
⇤ ← Revision 1 as of 2012-05-18 10:18:52
Size: 2359
Comment:
|
Size: 3958
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 7: | Line 7: |
| * '''Status''': DRAFT | |
| Line 10: | Line 11: |
| 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. |
|
| Line 12: | Line 17: |
| This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.) It is mandatory. |
Ubuntu now supports root merged into /usr. On newly installed systems, {/bin,/lib,/sbin} directories are symlinks to directories under {/usr}. |
| Line 18: | Line 21: |
| 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]] |
|
| Line 19: | Line 36: |
* Julie chooses to have /usr mounted on a separate partition during installation. She can still boot and execute binaries previously shipped in /bin & /sbin. |
|
| Line 22: | Line 41: |
| * It is supported to have /usr mounted on a separate partition * Mounting /usr becomes required for booting |
|
| Line 24: | Line 46: |
| You can have subsections that better describe specific parts of the issue. | 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. |
| Line 28: | Line 59: |
| This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: | === Code changes === |
| Line 30: | Line 61: |
| === UI Changes === Should cover changes required to the UI, or specific UI that is required to implement this === Code Changes === Code changes should include an overview of what needs to change, and in some cases even the specific details. |
* 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 |
| Line 40: | Line 68: |
| Include: * data migration, if any * redirects from old URLs to new ones, if any * how users will be pointed to the new way of doing things, if necessary. |
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 |
| Line 47: | Line 83: |
| It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. This need not be added or completed until the specification is nearing beta. |
* 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 |
| Line 53: | Line 88: |
| This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. == BoF agenda and discussion == Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. |
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? |
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 root merged into /usr. On newly installed systems, {/bin,/lib,/sbin} directories are symlinks to directories under {/usr}.
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:
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?
FoundationsTeam/Specs/Quantal/UsrMerge (last edited 2012-06-08 13:28:54 by xnox)