From Fedora Project Wiki

The contingency plan is flawed

The contingency plan is flawed. Disregarding the compat symlinks is not an option as those will be needed for third party scripts, FHS compliance, user comfort, etc.

  • This is not true. The symlinks in the package from %post are still there. --harald 12:34, 1 November 2011 (UTC)
    • It was unclear to me that you're proposing that all package maintainers with programs or libraries in / will need to update their packages to carry the compat symlinks in addition to replacing the / directories. Perhaps if you add your middle two bullets from http://lists.fedoraproject.org/pipermail/devel/2011-October/158810.html to the Roadmap section it will be more clear.
  • Actually there is no contingency plan at all. Basically when we decide to start changing the packages, there is no way back apart from reverting all the changes in the huge number of packages investing almost the same amount of time that was needed to put the changes in.
    • We use git, and a git revert should be possible in a smaller amount of time. --harald 10:02, 11 November 2011 (UTC)

A lot of work

Seems like a lot of work if you want all packages placing things in /bin, /sbin, /lib, and /lib64 to not only change their installation directory but also add code to emplace compat symlinks. I liked the plan better when I misunderstood it to only be needing to replace the "/" directories with symlinks into "/usr". Also, your list of 257 packages is incomplete. For instance, you're missing bash. Linking the script that you use to generate the list so people can fix it and find the real number of affected packages would be great.

sbin -> bin separate

I would strongly suggest considering the /sbin/ => /bin/ and /{s,}}bin => /usr/{s,}bin separately. There's different considerations for each (for instance, the consolehelper porting is only necessary for the /sbin/ => /bin/ move, not for the / to /usr/ move.)

FHS

The statement "Historically /bin, /sbin, /lib had the purpose to contain the utilities to mount /usr" is only one reason for the split. The FHS specifies other reasons: http://pathname.com/fhs/pub/fhs-2.3.html#PURPOSE2. The one that sticks out as unaddressed is "Disk errors that corrupt data on the root filesystem are a greater problem than errors on any other partition. A small root filesystem is less prone to corruption as the result of a system crash." This is both helped (the root filesystem will indeed be smaller) and hindered (but the root filesystem is essential in part because it contains the tools necessary to recover from disk errors... which would no longer be the case) by this change.

Additionally, the FHS is not only specifying these directories for purely technical reasons but also for organizational reasons. For instance, /bin contains "Essential" user command binaries. The section of FHS pointed at above would seem to indicate a definition of "Essential" that includes not only what's necessary to boot (what this feature is saying is no longer necessary) but also the commands necessary to recover, repair, or restore a system. The /bin and /sbin split is even more a separation due to organization of binaries rather than a need to do that to prevent breaking the system.

  • Many of the proposed benefits of this feature, such as "/usr can be read-only and shareable. " are already present in the current /usr. For all such benefits, the benefit is actually that more files are going to be included on /usr (or the inverse, that less will be included on /).
  • For dependencies, the Feature also needs to make sure that it works for the non-programming/library files that are stored in those directories on /. For instance, /lib/udev, /lib/systemd, /lib/terminfo.... These may all be fine but they need to be considered as dependencies that may need changing.
    • We have the compat symlinks. --harald 10:02, 11 November 2011 (UTC)

FPC

FPC should probably be involved as obeying the FHS is a packaging mandate (they'd want to evaluate whether any of this violates the FHS or not and whether it seems justified to make an exception if so) and also, if individual packages (like coreutils) were to implement symlinks, then how to deal with that (making symlinks for the major directories in filesystem may sidestep, that, though).

  • FPC took an informal look at this today. There's a consensus that we'd be against the /usr/bin, /usr/sbin merge. Merging /bin, /sbin, /lib, /lib64 into their /usr/ counterparts and keeping the compat symlinks will probably take some Guidelines updates but out initial view is that whether or not to go forward with that portion is up to FESCo.

anaconda and docs

anaconda and the docs team are additional dependencies as documentation and code that recommends relative partition sizes would need to be updated.

single user

One thing I'm not clear on is when the switch between the initramfs and the actual / filesystem is performed. For instance, what does the user get if they boot single user? What do they get if they boot single user and /usr is on an nfs filesystem?

  • This is a good point. The initramfs would have to mount itsself to /usr in this case. --harald 10:02, 11 November 2011 (UTC)

Special cases with non-packages

Special cases dealt with outside of packages should always be held as a last resort if a change is deemed beneficial enough and there is no other option but to do it outside of packaging (this is for two reasons -- the anaconda team doesn't like maintaining the special cases and people who attempt to upgrade without anaconda have to be made aware of that they need to perform the special case manually). Can you think of a way not to do the / => /usr directory symlinks outside of packaging?

  • For new installations, the filesystem package will provide the symlinks with lua (like for /var/run in the /run case). The upgrade path can be done with a dracut module and a boot parameter. --harald 10:02, 11 November 2011 (UTC)

Test Case

The test case is more of a "how to test that we changed things" rather than "how to test we didn't break things". Probably be good to supplement it with something along the lines of "login and see that bash starts up as your shell despite having moved the binary to /usr/bin" and "run /sbin/ifconfig |/bin/grep -i ip to verify that commands used in user shell scripts continue to work despite having moved."

  • yes --harald 10:02, 11 November 2011 (UTC)

Consolehelper

The feature page is ambiguous - what is the proposed plan regarding usermode ("consolehelper")? If the plan is to remove it, what replaces it, and who does the work for the ~73 packages that currently depend on userhelper{,-gtk}?

  • first suggestion, move the "real" binary to /usr/libexec instead of /usr/sbin --harald 10:02, 11 November 2011 (UTC)
  • second suggestion, drop userhelper/consolehelper entirely and create shell wrappers with "#!/usr/bin/pkexec /usr/libexec/<tool>" --harald 10:02, 11 November 2011 (UTC)
    • Unless I am mistaken, this would use /etc/pam.d/polkit-1 for all applications instead of an application-specific PAM configuration; this would need a more detailed analysis/migration path (e.g. what replaces the centralized /etc/pam.d/config-util file? Can we require policykit in all situations? SELinux policy changes). Mitr 15:54, 14 November 2011 (UTC)

/boot

What about /boot? It is not mentioned as a well defined directory. Depending on the way the initramfs is generated it may be shareable or not. --Till 19:14, 25 October 2011 (UTC)

  • IMHO, /boot should be hostonly. And we need to copy /lib/modules/$(uname -r) there in the future, together with the vmlinuz and initramfs to have a consistent boot environment --harald 10:02, 11 November 2011 (UTC)
    • That would make /boot directory essential. You may need /lib/modules/ at runtime, i.e. when you plug in some USB device, but you don't need /boot after you booted the system. So you may not mount /boot with a custom kernel on a server to increase security a little bit. Or you may not have /boot directory at all for chroot/PXE/embedded system.

/sbin is root/privileged users only

I strongly don't want sbin removed anywhere. It's for root/privileged users only to execute. Even if its original intent was static bin. Do not stuff that into any bin directory. This is a pure waste of time. We should be moving root/privileged user tools out of /bin and into /sbin /usr/sbin (superuser bin) where some really should belong.

Unacceptable

I think that this is totally unacceptable. Reasons are:

  1. partitioning of disk is important for a lot of use-cases and should not be ignored. / and /usr are different partitions very often. --Alukin
    • please name some --harald 10:26, 11 November 2011 (UTC)
  1. /sbin, /usr/sbin should contain binaries for super-user. E.g. fdisk is not for unprivileged user because if can easily damage system. --Alukin
  1. / partition should contain minimal base system that could be read-only after boot, /usr is for user packages. Ignoring those definitions could lead to total Windows-like mess instead of elegant UNIX-like system. I wonder that someone thinks that "very known system" is more modern and elegant? --Alukin
    • the initramfs can take that role easily --harald 10:26, 11 November 2011 (UTC)
  1. Messing up all things in one directory does not make system simpler, it creates more chaos... This proposal calls strong emotions against breaking important traditions and rules. --Alukin
    • that's your opinion and not based on facts, IMHO --harald 10:26, 11 November 2011 (UTC)

no major problems nor great value

I see no major problems nor great value in this change. Several points require clarification. --User:stevea

  • Is the plan is to symlink the directories, not the individual files ? --User:stevea
    • The individual files only for the transition stage. As soon as a directory only contains symlinks, it can be replaced by a symlink entirely. --harald 10:26, 11 November 2011 (UTC)
  • The concept of a superuser-bin:/sbin /usr/sbin isn't meaningful anymore as users may have capabilities or SELINUX context to perform specific admin functions and various security profiles requires multiple distinct admin roles. --User:stevea
    • correct --harald 10:26, 11 November 2011 (UTC)
  • This project will encourage developers, ignorant of FHS, to code atrocities such as "/usr/bin/ls", creating a new form of non-portability. I suggest that /usr/bin NOT be used as the real directory, but instead an new directory created such as /usr/biNG be used with others dirs linking to this. Similar changes for /usr/libNG* may be justified. This will at least obviate the majority non-portability it encourages. --User:stevea
    • hmm, I don't know, if I like idea. It might have some advantages, yes. --harald 10:26, 11 November 2011 (UTC)

without initramfs

Will this still work for systems that boot just kernel without initrd/initramfs? (NOTE: there's a major difference between "we do not support booting without initrd, it may still work however" and "we make booting without initrd impossible")

  • It works for systems with /usr in the root filesystem. With /usr as a separate partition you would need an initramfs, as you do for LVM, raid, encryption, etc... --harald 10:02, 11 November 2011 (UTC)

new meaning of /

I fail to understand new meaning of / filesystem. Currently / is a part of boot chain (simplified):

  1. BIOS reads first 512 bytes (MBR) of boot media and runs it. Nothing else. It does not knows what loader it boots. It even don't have to know about partitions.
  2. MBR contains the code, that reads the rest of boot loader and runs it. Nothing else. It does not know about OS, mountpoints, etc.
  3. Boot loader reads kernel (and optionally initrd) and runs it. Nothing else. The only thing that bootloader does is running the kernel.
  4. Kernel (apart from initializing hardware) mounts / filesystem and runs /sbin/init. Nothing else. It does not have to know about other mountpoints, encryptions, installed software and daemons.
  5. Init @ root fs mounts remaining filesystems, makes necessary preparations and runs daemons.

Every link in this chain has a specific purpose. And / fs is the base system, that is enough to check and mount all other parts of the system together and run it. It's stable, never changing, may be even read-only. It's however still a minimal working system, that you can log in, even if all other partitions are dead. But what's the "new meaning" of root filesystem?

    • IMHO, the meaning of / is "/etc" (the host configuration) and the layout of the toplevel directories. --harald 10:22, 11 November 2011 (UTC)

pushes Fedora away

What problem are you trying to solve? -- less clutter across the filesystem

  • true. But to fix it one must finally force people to read FHS standard and think before writing software. :) Moving directories around actually increases this mess, pushes Fedora away from other linux/unix distros and pushes developers away from Fedora.

snapshots only /usr

What problem are you trying to solve? -- if you snapshot /usr before updating, you have snapshotted the OS at once.

  • No, you don't. Because you don't have /etc and /var snapshots, which are actually more important then /usr. Talking about fedora, you can recover all the lib/bin/usr files from a simple rpm -qa output. But you cannot recover /var and /etc this way.
    • You are right, therefore I suggest to rethink the population of /var and /etc by rpm. IMHO rpm packages should not provide files in the %filelist in /var and /etc. The UsrMove feature is just the first step in this direction. --harald 10:02, 11 November 2011 (UTC)
      • If this is the first step, then what's the final goal? If next you put files from /var and /etc to /usr/var and /usr/etc and symlink them, then you end up reinventing the same root filesystem under /usr. Looks pointless, unless the point is to increase the number of symlinks. :)

rpm and /usr @network

Ok, so imagine you have a /usr mounted from a network location and you want to update a package. So maybe you mount the master copy of /usr on your master machine and update /usr with your package manager. [...] But what about /sbin /bin /lib and /lib64? They still have the old binaries.

  • this problem is not fixed by bin->usr move either. If you're talking about /usr @network AND about package manager controlling all the files around, then you must also move /var and /etc to /usr as well, otherwise installed software may just not start (missing init.d script) or won't work (missing configuration, missing /var/lib/ subdirectories, etc). Same with /boot + /lib/modules. So in this case to have a consistent system you'll have to export entire root fs anyway. And then moving /bin to /usr/bin is just an unnecessary attempt to break something.

separate /usr broken because of systemd?

BTW, is separate-usr-is-broken the only "broken" thing currently? And it was not "broken" before systemd? I mean, systemd is the first and only init system revealing this brokeness? Then, maybe, don't change the world, just fix systemd?

  • systemd is not broken! Read the document again. --harald 12:57, 7 November 2011 (UTC)
    • Well... Is separate-usr-is-broken the only "broken" thing currently? And it was not "broken" before systemd?
      • The link describes the known issues. And yes, it was already broken before systemd existed. --harald 10:02, 11 November 2011 (UTC)

Updating the initramfs

In this question you argue that if someone had a separate /usr with all the binaries, the general purpose rescue binaries like fdisk and alike in /bin and /sbin would not be updated by the package management and thus wont get a glibc security update. But the same applies to the initramfs: If you propose to have the rescue binaries in the initramfs, then you need to outline a way to update the initramfs through the package management. This question is completely unclear ATM. --Cwickert 17:04, 7 November 2011 (UTC)

  • Same applies to the current initramfs as it is now... This would be a separate feature, not specifically tight to this one --harald 17:16, 7 November 2011 (UTC)
    • It may be a different problem, but is becomes more pressuring with this feature and thus should be addressed. --Cwickert 17:42, 7 November 2011 (UTC)
      • Why is it more than before? --harald 17:56, 7 November 2011 (UTC)

Only one real use case

I do not like to force changes on almost 900 packages (which if even only 1 hour took in average would mean 900 man hours of work) with only one real fully working use case and that is a virtualization system with LXC, where the /usr is then easily shared among hundreds or thousands of containers. The snapshotting on updates will not fully work due to needed snapshotting of the rest of the system (/etc/, /var/, /boot/). The networked shared /usr will not work fully either on its own at least due to the needed updates of kernels, initramfs and configuration files as well. Other already working solutions for networked clients with shared mounts exist. So the LXC virtualization remains and that can be, although not as elegantly and simply, solved with the current placement of package files as well.

  • It's the first step in the right direction. Of course we will have to rework our strategy for /etc, /var/, /boot/, kernel and initramfs also, but not with this feature, but with future features. --harald 10:02, 11 November 2011 (UTC)

reduces ability to fix the system

It does not depend on being /usr local or remote fs. Currently you have a lot of options to recover the system after a major disaster like this. But after this change you won't be able to do that. And initramfs won't help in such case. You're left with the only option of LiveCD for the same version and arch of OS.

  • So, what's your strategy? --harald 14:38, 14 November 2011 (UTC)
 $ ldd /bin/rpm|fgrep usr
 librpm.so.2 => /usr/lib64/librpm.so.2 (0x00000039da800000)
 librpmio.so.2 => /usr/lib64/librpmio.so.2 (0x00000039d9c00000)
 libelf.so.1 => /usr/lib64/libelf.so.1 (0x00000039d9000000)
 liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00000039edc00000)
 liblua-5.1.so => /usr/lib64/liblua-5.1.so (0x00000039ee000000)
 libnss3.so => /usr/lib64/libnss3.so (0x00000039e6000000)
 libnssutil3.so => /usr/lib64/libnssutil3.so (0x00000039e5000000)

 $ which yum
 /usr/bin/yum

 $ which rpm2cpio
 /usr/bin/rpm2cpio

 $ which gzip
 /usr/bin/gzip

 $ which bzip2
 /usr/bin/bzip2
    • Easy, root partition is enough to manually bring up network and recover the rest:
 # ifconfig eth0 192.168.107.91 netmask 255.255.255.0 up
 # # (optionally use /sbin/vconfig and /sbin/ip, if network structure needs them)
 # vi /etc/resolv.conf # put DNS servers there
 # cat < /dev/tcp/192.168.107.24/12345 > /bin/busybox
 # chmod +x /bin/busybox
 # busybox wget --help
 # busybox rpm --help
 # # (wget and put rpm with deps in place, then rpm -qa, wget all rpms and unpack only /usr/ part)

I don't mind about rpm deps being moved to /bin to make this a few steps easier, but it's not necessary. You may even recover mplayer first and watch some DVD on tty2 in framebuffer while other parts of /usr/ are being downloaded/unpacked.

And this is just one of possible options. If you have backups on another disk, you can mount and unpack them (BTW, ldd /bin/gzip, you have gzip). If you have another machine with same list of packages nearby you can just tar|wget|untar it. On dual-boot PC you can boot to another OS (who said windows?), download files, then boot back and mount the (FAT) partition where you saved them. If you have troubles with network on that PC you can bring those files on DVD/USB disk. Lots of options, that you lose when throw away files from root partition.

Compat-symlinks compatibility

Won't compat-symlinks cause problems because of ".." directory not pointing to the parent directory?

  • Maybe, but I can't think of a usecase of /lib/../ or /bin/../ --harald 14:48, 14 November 2011 (UTC)
    • There're symlinks like "/usr/bin/awk -> ../../bin/gawk", but I'm mainly afraid of links "/bin/sometool -> ../etc/alternatives/sometool". Don't know, there may be other cases, something similar to "/etc/resolv.conf -> ../var/run/ppp/resolv.conf".

Let's fix multilib at the same time

Since we're already doing some major filesystem restructuring, should we go one step further and put files in /usr/bin/$ARCH and libraries in /usr/lib/$ARCH ? Noarch files can be put in /usr/bin or /usr/bin/noarch, and either /usr/lib | /usr/lib/noarch (for bytecodes) or under /usr/share/

If the argument is that /usr can now be mounted shared and read-only, this will now extend things further and allow a /usr mount to be shared across different architectures (e.g. x86, x86_64, ppc and ARM) MichelSalim

[I agree - should fix all three non-extant problems instead of just one. (executable, libraries, and architectural dependence). - stevea]

Wording improvement

  • In the sentence "This will split all non-host specific data to /usr.", was the intention perhaps to tell that this type of files is to be /gathered/ rather than split between top-level directories?
  • Missing entry under "FAQ --> What problem are you trying to solve?":
    • Simplify package maintainers work of deciding which files to place/install outside /usr in order the app to work on every system.
Retrieved from "https://fedoraproject.org/w/index.php?title=Talk:Features/UsrMove&oldid=271215"