[SOLVED] New root structure being employed?

grail · 06-17-2013, 10:32 AM

I have recently moved to an Arch-form of distro and noticed both it and Arch itself have
moved to a new root structure.

The common one I am used to looks like:

Code:

drwxr-xr-x   1 root root  4096 03.06.2013 15:51 bin/
drwxr-xr-x   7 root root  4096 16.06.2013 19:26 boot/
drwxr-xr-x  19 root root  3420 15.06.2013 14:49 dev/
drwxr-xr-x  87 root root  4096 16.06.2013 22:52 etc/
drwxr-xr-x   4 root root  4096 10.06.2013 19:36 home/
drwxr-xr-x   1 root root  4096 03.06.2013 15:51 lib/
drwx------   2 root root 16384 10.06.2013 19:29 lost+found/
drwxr-xr-x   2 root root  4096 17.05.2013 10:32 media/
drwxr-xr-x   2 root root  4096 15.03.2013 10:33 mnt/
drwxr-xr-x   5 root root  4096 12.06.2013 16:27 opt/
dr-xr-xr-x 266 root root     0 15.06.2013 14:48 proc/
drwxr-xr-x   6 root root  4096 13.06.2013 12:37 root/
drwxr-xr-x  21 root root   640 16.06.2013 19:27 run/
drwxr-xr-x   1 root root  4096 03.06.2013 15:51 sbin/
drwxr-xr-x   4 root root  4096 15.03.2013 10:33 srv/
dr-xr-xr-x  13 root root     0 15.06.2013 14:48 sys/
drwxrwxrwt  13 root root   340 17.06.2013 22:55 tmp/
drwxr-xr-x   9 root root  4096 13.06.2013 09:00 usr/
drwxr-xr-x  12 root root  4096 13.06.2013 09:00 var/

Where the new structure appears to have made some symlinks:

Code:

drwxr-xr-x   7 root root  4096 16.06.2013 19:26 boot/
drwxr-xr-x  19 root root  3420 15.06.2013 14:49 dev/
drwxr-xr-x  87 root root  4096 16.06.2013 22:52 etc/
drwxr-xr-x   4 root root  4096 10.06.2013 19:36 home/
drwx------   2 root root 16384 10.06.2013 19:29 lost+found/
drwxr-xr-x   2 root root  4096 17.05.2013 10:32 media/
drwxr-xr-x   2 root root  4096 15.03.2013 10:33 mnt/
drwxr-xr-x   5 root root  4096 12.06.2013 16:27 opt/
dr-xr-xr-x 266 root root     0 15.06.2013 14:48 proc/
drwxr-xr-x   6 root root  4096 13.06.2013 12:37 root/
drwxr-xr-x  21 root root   640 16.06.2013 19:27 run/
drwxr-xr-x   4 root root  4096 15.03.2013 10:33 srv/
dr-xr-xr-x  13 root root     0 15.06.2013 14:48 sys/
drwxrwxrwt  13 root root   340 17.06.2013 22:55 tmp/
drwxr-xr-x   9 root root  4096 13.06.2013 09:00 usr/
drwxr-xr-x  12 root root  4096 13.06.2013 09:00 var/
lrwxrwxrwx   1 root root     7 03.06.2013 15:51 bin -> usr/bin/
lrwxrwxrwx   1 root root     7 03.06.2013 15:51 lib -> usr/lib/
lrwxrwxrwx   1 root root     7 03.06.2013 15:51 sbin -> usr/bin/

So I was wondering if anyone can direct me to documentation on why this sort of change has been implemented?
Specifically I would like to know what issues there are surrounding once /sbin files now being in /usr/bin which is in everyone's PATH?

DavidMcCann · 06-17-2013, 11:08 AM

The starting point would be this
https://wiki.archlinux.org/index.php...stem_hierarchy
It has a few links about possible problems. The discussion on why it was done is probably buried somewhere in the developers' mailing list.

grail · 06-17-2013, 11:56 AM

Thanks for the link David. You are correct that it explains what has been done, but not the why or the impacts

I will leave this open a little longer to see if any other information is forthcoming.

onebuck · 06-17-2013, 05:23 PM

Moved: This thread is more suitable in <Arch> and has been moved accordingly to help your thread/question get the exposure it deserves.

DavidMcCann · 06-18-2013, 11:08 AM

I was interested in this, even though I'm never going to be an Arch user, and I've found some of the discussion:
https://mailman.archlinux.org/piperm...ead.html#22625

John VV · 06-18-2013, 02:26 PM

This has been a hot topic ,some like it some do not .

the remerging of the " /" and "/usr" split

i have no opinion on this
both are good

but a "crystalball " guess ...

with the move to more and more "cloud" services
having /usr might stay around as the local hdd and / as the cloud , or not .
-- like it was with a server and a thin client with /usr/local and /usr .

grail · 06-18-2013, 11:11 PM

Well I am starting to see some light in the forest

Thanks again David for the link.

I guess my concerns would be around now requiring intramfs bringing up the network as well so a nfs mounted /usr can be used prior to init??

I do agree that the endless symlinking that has previously occurred to allow for /bin, /sbin, /lib, /usr/bin, /usr/sbin and /usr/lib to all work has been painful.

What I am struggling with is the lack of separation between bin and sbin from a security point of view in that all users will now have /usr/bin in their path and so can now execute
anything not restricted by chmod.

My other issue, which is a little old fashioned, is the call to 'which' to tell me that a command is in and sbin directory and hence a root-esque command, now all simply return /usr/bin/...

evo2 · 06-18-2013, 11:27 PM

Hi,

this has significant implications for systems with with separate / and /usr partitions. Traditionally, early in the boot process the init system should not assume that /usr is mounted and scripts/tools would restrict themselves to things installed in /bin, /sbin and /lib and forgo things that would be in /usr/bin, /usr/sbin and /usr/lib.

Evo2.

PS. Sorry not an Arch user, but have always set up my servers with separate / and /usr, so have been watching this / to /usr migration with some interest.

grail · 06-19-2013, 01:58 AM

Thanks for the feedback evo2

So are you saying that if /usr is on a separate partition then there would be no option to have it mounted in initramfs to have the major commands available?

If I read correctly this seems to be the solution or at least the objective. I also saw that they have inferred several issue can be overcome by having /usr available early:

Quote:

Most of the failures you will experience with /usr split off and not pre-mounted in the initramfs are graceful failures: they won't become directly visible, however certain features become unavailable due to these failures. Quite a number of programs these days hook themselves into the early boot process at various stages. A popular way to do this is for example via udev rules. The binaries called from these rules are sometimes located on /usr/bin, or link against libraries in /usr/lib, or use data files from /usr/share. If these rules fail udev will proceed with the next one, however later on applications will then not properly detect these udev devices or features of these devices. Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff.

You don't believe us? Well, here's a command line that reveals a few obvious cases of udev rules that will silently fail to work if /usr is split off and not pre-mounted: egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/* -- and you find a lot more if you actually look for it. On my fresh Fedora 15 install that's 23 obvious cases.

I would be interested on your feedback on the above

grail · 06-19-2013, 06:22 AM

Just in case anyone is following this thread, the following are the resources I have found / linked in above, with a small description:

[1]Arch developer's mailing list on the initial discussion to investigate the change with some reasoning

[2]Arch developer wiki on how transformation to new format is to be done

[3]Fedora's coverage on the process and reasoning to be undertaken

[4]Freedesktop's coverage of the systemd error that a separate /usr is broken and suggested alternative

[5]Freedesktop's reasoning behind why the move could / would be beneficial and some coverage on myths / facts around the move

DavidMcCann · 06-19-2013, 10:48 AM

Thanks for the Fedora link. I hadn't noticed that the change was in Fedora: I suppose that means I'll be getting it in CentOS 7 next year.

grail · 06-19-2013, 11:00 AM

From what I can follow, I believe that Fedora may very well be a front runner for this exercise.

grail · 06-27-2013, 07:06 PM

Not sure if any Fedora or Arch people have been looking at this, but if so, I would like to know if there is any documentation or detailed instructions on how to perform this type of move?

I ask as I also have a side development distro and was curious if I did an alternate fork to see what benefits this may have from a packaging point of view.

evo2 · 06-27-2013, 09:26 PM

Hi,

Quote:

Originally Posted by grail

So are you saying that if /usr is on a separate partition then there would be no option to have it mounted in initramfs to have the major commands available?

I'm thinking of cases where /usr can't be mounted for some reason. So perhaps something fancy can be done with initramfs for example have a busybox shell so the the system isn't completely fubared, but surely implementing this would be a serious PITA result in reduced functionality. So the whole thing looks like a lot of work without significant gain. If people really do want to spend their time implementing this then good for them - I'll sit back and watch.

Cheers,

Evo2.

grail · 06-28-2013, 12:43 AM

Thanks for the feedback

Well so far I see Arch (and any forks) plus Fedora (and I assume its forks too) have gone this way. On some the investigation I have done it does seem that initramfs is doing exactly what you have said
and providing a minimal environment should things go wrong (which funnily enough has just happened to a family member's computer after an upgrade which I am stuck now trying to solve ... so I guess i will
see what level of access it has).