![](https://seccdn.libravatar.org/avatar/aea1d8248292e6482742234c5cb514de.jpg?s=120&d=mm&r=g)
Anton Aylward wrote:
Linda Walsh said the following on 04/11/2013 09:59 PM:
Also, it's not just about / and /usr, but also /usr/share --- at least a few current booting progs make use of it,
Would you care to be more specific - tell us exactly what those are and where they occur in the boot sequence, please.
They are in areas that were used as reasons to move files from '/' to '/usr/... what I would mostly call 'services'...
and the same arguments used for /usr can be used for /usr/share (where do you load your fonts from?)
I happily have my /usr/share as a NFS supplied by a 'headless server'. Of course your mileage may vary; you may have your fonts supplied by the font server - xfs.
That's disabled in some recent X due to some security bug or another. It is assumed all fonts are local. I've been struggling to keep xfs-font server available. I've been told by suse that it's outdated and should be dropped. This is especially true since the xfs-font server used by suse doesn't support scalable fonts (apparently there is a version that does, but not the one we use).
The point being that this is not needed until the X server starts up.
But having "X" available @ boot, was used to support the argument that /usr files needed to be on "/", so that booting to a full desktop could be parallelized.
You may term that part of the boot sequence, but its not part of what the initrd does for the rest of us.
---- That's the flip side of my point. The stuff in initrd is stuff that isn't able to be done in systemd and needs to be done before systemd launches. My question was why does the stuff that is done in initrd have to live in /usr? It was on root, why not leave it on root? It was systemd that needed things on /usr, But now initrd needs things on /usr -- or rather the things that initrd does needs things on /usr -- but that isn't "systemd", right? So if no one moved files from /{bin,sbin,lib,lib64} --> their /usr equivs, what was the issue besides libblkid was on /usr? Wouldn't it be simpler and more compatible to move libblkid to /lib64? There was 1 lib that mount needed that was on /usr. Because of that all files on root had to be moved to /usr? It, like the DNS server; like
Postfix; like the cron, ssh, and cups daemons, are all user space and all come later.
Agreed... This was the traditional model. What I want to know is why has 'S' and '1' equivalent functional run levels been crippled to need booting from a ram disk when in other distros (RH/Fedora, at least), this is not the case? The point was NEVER that all of the system startup had to be on 'root'... that's never been the case. The only things that had to be were the things on initrd. BUT one of the main arguments for moving everything from '/' to /usr was to be able to startup all of the services at *boot time*. If you accept that services are separate from boot, that there is no compelling reason why the boot-related files cannot remain (be moved back) to /root and create a compatible boot case...(like booting from HD). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org