Talk:Features/UsrMove

From FedoraProject

Jump to: navigation, search

Contents

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.

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.

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).

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?

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?

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."

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}?

/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)

/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
  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
  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

no major problems nor great value

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

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")

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?

pushes Fedora away

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

snapshots only /usr

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

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.

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?

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)

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.

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. 

 $ 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

 # 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?

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

Retrieved from "https://fedoraproject.org/wiki/Talk:Features/UsrMove"