Michael Cronenworth:
>> Nope. It has everything to do with booting. Some packages in /bin
>> depended on libs in /usr/lib{64} so calling the init script
>> before /usr is mounted would fail. There's a discussion about this
>> in the devel list if you search the history for it.
>
Kam Leo:
> Thanks for setting me straight. Does that mean we're heading back
> toward separate partitions for everything?
Well, the sound of this condition says the opposite: That we're running
away from being able to use separate partitions.
I'd always been able to put /usr on a separate partition, and it was a
long standing recommendation (to use separate partitions for home, opt
var, usr, tmp), since you could mount them with different parameters, or
different file systems, or even on individual disc drives, for optimum
performance. Not to mention additional protection against accidents.
Whether that be someone, or something, filling up all the space on a
single partition system. Or mounting a partition read-only to make it
harder to accidentally, or deliberately, change system files. Or not
having to chug through a very long fsck on a single partition system, on
a very huge drive, simply because of an accident that might have only
concerned the home partition.
And, as I recall, the boot process is not supposed to depend on
something that might be on an unmounted partition. And usr being one of
the partitions that doesn't have to be present. You end up making it
impossible, or problematic to boot up in single mode, to do maintenance
on a system. It looks like someone's done something dumb in 64-bit
land.
If you look at /usr/bin in the FSH*, it's presence is not supposed to be
required to boot (in single mode), and /usr/lib holds files
that /usr/bin might want. So, requiring /usr/lib* anything, just to
boot, ought to be an error.
* http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
