I just noticed that ever since Fedora 11 the Installation Guide recommends against having a /usr partition separate from the root file system (though as recently as Fedora 12 the Example Usage still showed a separate /usr). I've always used a separate /usr kept mounted read-only except when necessary for updates. I was wondering just what sort of "boot process becomes more complex" issues I've been fortunate enough to avoid, and whether the reasons for that recommendation have become stronger in more recent releases.
On Wed, Mar 9, 2011 at 8:32 PM, Robert Nichols rnicholsNOSPAM@comcast.netwrote:
I just noticed that ever since Fedora 11 the Installation Guide recommends against having a /usr partition separate from the root file system (though as recently as Fedora 12 the Example Usage still showed a separate /usr). I've always used a separate /usr kept mounted read-only except when necessary for updates. I was wondering just what sort of "boot process becomes more complex" issues I've been fortunate enough to avoid, and whether the reasons for that recommendation have become stronger in more recent releases.
It probably has less to do with the boot process and more with disto upgrading; i.e. less likely that user files get clobbered if /usr is separate.
Kam Leo wrote:
It probably has less to do with the boot process and more with disto upgrading; i.e. less likely that user files get clobbered if /usr is separate.
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.
On Thu, Mar 10, 2011 at 9:08 AM, Michael Cronenworth mike@cchtml.comwrote:
Kam Leo wrote:
It probably has less to do with the boot process and more with disto upgrading; i.e. less likely that user files get clobbered if /usr is separate.
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.
Thanks for setting me straight. Does that mean we're heading back toward separate partitions for everything?
Kam Leo wrote:
Thanks for setting me straight. Does that mean we're heading back toward separate partitions for everything?
AFAIK /usr will not be defaulted as a separate partition any time soon. Some packagers see benefits to it and some do not. It is not an officially supported option.
The only partitioning change coming up in Fedora 15 that I can think of is with /var/run and /var/lock, which has a feature page[1].
On Thu, Mar 10, 2011 at 12:04:13PM -0600, Michael Cronenworth wrote:
Kam Leo wrote:
Thanks for setting me straight. Does that mean we're heading back toward separate partitions for everything?
AFAIK /usr will not be defaulted as a separate partition any time soon. Some packagers see benefits to it and some do not. It is not an officially supported option.
The only partitioning change coming up in Fedora 15 that I can think of is with /var/run and /var/lock, which has a feature page[1].
[1] http://fedoraproject.org/wiki/Features/var-run-tmpfs
I was unaware until the recent discussion that having /usr mounted separately was a potential problem.
I've configured my eeepc (901) that way because the 4 gig ssd just isn't big enough if /usr is put on it, along with / and /boot. Moving /boot off doesn't save much space, either.
so, for F14 I manually moved /usr after installation, and F15 I had the installer put it on the second (larger) SSD. So far I've not seen any obvious blowups from doing that.
Does anyone know of examples of what might explode or otherwise go bad because of separating /usr?
thanks!
On Thu, Mar 10, 2011 at 12:45 PM, fred smith fredex@fcshome.stoneham.ma.us wrote:
I've configured my eeepc (901) that way because the 4 gig ssd just isn't big enough if /usr is put on it, along with / and /boot. Moving /boot off doesn't save much space, either.
so, for F14 I manually moved /usr after installation, and F15 I had the installer put it on the second (larger) SSD. So far I've not seen any obvious blowups from doing that.
Going OT here but just to offer a different solution.
I have an eeePC 701 w/ 4GB internal SSD and 8GB SD card. Since I don't keep anything important on my eeePC I tried LVM striping but using all the 4GB SSD and the same size LV on the 8GB card. I put "/" on it and then created /boot and swap on the rest of the 8GB SD card. It seems a little faster and was fun to experiment on a non-critical system.
Richard
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 wrote:
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
They should not. IMO, boot should depend only upon these directories being present:
/ /boot /bin /sbin /lib /etc /root
The /usr file system should not be necessary for boot. Any libraries which executables in /bin and /sbin depend upon should be in /lib.
The libraries in /usr/lib should serve the executables in /usr/bin and /usr/sbin, which are not needed by executables in /bin and /sbin.
[...]
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.
[...]
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.
I heartily agree.
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.
Yep.
Mike
On 03/10/2011 05:08 PM, Michael Cronenworth wrote:
Kam Leo wrote:
It probably has less to do with the boot process and more with disto upgrading; i.e. less likely that user files get clobbered if /usr is separate.
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.
I thought that programs in /bin and /sbin are not dynamically linked ....
Vaclav M.
On 04/14/2011 02:01 PM, Vaclav Mocek wrote:
On 03/10/2011 05:08 PM, Michael Cronenworth wrote:
Kam Leo wrote:
It probably has less to do with the boot process and more with disto upgrading; i.e. less likely that user files get clobbered if /usr is separate.
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.
I thought that programs in /bin and /sbin are not dynamically linked ....
Nope - That's an urban legend.
Programs below /bin and /sbin are supposed not to access anything below /usr (e.g. be dynamically linked to anything below /usr/lib), c.f.: http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES and http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES
Ralf
On 04/14/2011 01:58 PM, Ralf Corsepius wrote:
On 04/14/2011 02:01 PM, Vaclav Mocek wrote:
On 03/10/2011 05:08 PM, Michael Cronenworth wrote:
Kam Leo wrote:
It probably has less to do with the boot process and more with disto upgrading; i.e. less likely that user files get clobbered if /usr is separate.
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.
I thought that programs in /bin and /sbin are not dynamically linked ....
Nope - That's an urban legend.
Actually that's not strictly true. Many* of the binaries in these paths on UNIX System V R4 systems were statically linked - certainly su was and I think also others.
I'm not sure whether the BSDs ever had this although I am sure someone does - at some point around 5.2 FreeBSD grew the /rescue tree (man 8 rescue on a FreeBSD box) which is intended to contain statically-linked binaries for system recovery in the event that the dynamically linked executables in /bin and /sbin are unusable. I think they still have this in current releases although I've not installed a BSD box in a few years.
Programs below /bin and /sbin are supposed not to access anything below /usr (e.g. be dynamically linked to anything below /usr/lib), c.f.: http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES and http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES
Post-dates many of these conventions by decades.
Regards, Bryn.
* if not all; I wasn't there back then and don't have spare time right now to trawl through the references for evidence.
On 04/14/2011 03:10 PM, Bryn M. Reeves wrote:
On 04/14/2011 01:58 PM, Ralf Corsepius wrote:
On 04/14/2011 02:01 PM, Vaclav Mocek wrote:
On 03/10/2011 05:08 PM, Michael Cronenworth wrote:
Kam Leo wrote:
It probably has less to do with the boot process and more with disto upgrading; i.e. less likely that user files get clobbered if /usr is separate.
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.
I thought that programs in /bin and /sbin are not dynamically linked ....
Nope - That's an urban legend.
Actually that's not strictly true. Many* of the binaries in these paths on UNIX System V R4 systems were statically linked - certainly su was and I think also others.
Correct. Historically many of them were statically linked.
Most of these statically linked binaries existed for historical reasons, due to technical limitations of the OS or because maintainers wanted to avoid moving libs to /lib.
Programs below /bin and /sbin are supposed not to access anything below /usr (e.g. be dynamically linked to anything below /usr/lib), c.f.: http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES and http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES
Post-dates many of these conventions by decades.
On linux, static linkage of /bin and /sbin binaries had never been required. It's just that there had been times when dynamically linking them wasn't possible.
Ralf
On 04/14/2011 01:58 PM, Ralf Corsepius wrote:
On 04/14/2011 02:01 PM, Vaclav Mocek wrote:
On 03/10/2011 05:08 PM, Michael Cronenworth wrote:
Kam Leo wrote:
It probably has less to do with the boot process and more with disto upgrading; i.e. less likely that user files get clobbered if /usr is separate.
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.
I thought that programs in /bin and /sbin are not dynamically linked ....
Nope - That's an urban legend.
Programs below /bin and /sbin are supposed not to access anything below /usr (e.g. be dynamically linked to anything below /usr/lib), c.f.: http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES and http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES
Ralf
Well, ldd confirms that it is an urban legend.
It reminds me, that few months back I observed that Fedora's binaries in /bin are much bigger that Slackware's binaries (tens of %), both +- the same version. Now, I am wondering why, if it is dynamically linked.
Vaclav M.
Vaclav Mocek wrote:
Well, ldd confirms that it is an urban legend.
On my system ldd is in /usr/bin, not /bin
It reminds me, that few months back I observed that Fedora's binaries in /bin are much bigger that Slackware's binaries (tens of %), both +- the same version. Now, I am wondering why, if it is dynamically linked.
Vaclav M.
Vaclav Mocek wrote:
It reminds me, that few months back I observed that Fedora's binaries in /bin are much bigger that Slackware's binaries (tens of %), both +- the same version. Now, I am wondering why, if it is dynamically linked.
Vaclav M.
Could the difference be in the compiler version and in the compilations flags used to build the binaries?
On 04/14/2011 07:31 PM, JD wrote:
Vaclav Mocek wrote:
It reminds me, that few months back I observed that Fedora's binaries in /bin are much bigger that Slackware's binaries (tens of %), both +- the same version. Now, I am wondering why, if it is dynamically linked.
Vaclav M.
Could the difference be in the compiler version and in the compilations flags used to build the binaries?
Probably flags, the compiler was the same. The differences were for an example 22k versus 27k and when I check it again (F14/Slackware13.1), the differences are minimal.
Vaclav M.
On Thu, Apr 14, 2011 at 20:45:05 +0100, Vaclav Mocek little.owl@email.cz wrote:
On 04/14/2011 07:31 PM, JD wrote:
Vaclav Mocek wrote:
It reminds me, that few months back I observed that Fedora's binaries in /bin are much bigger that Slackware's binaries (tens of %), both +- the same version. Now, I am wondering why, if it is dynamically linked.
Vaclav M.
Could the difference be in the compiler version and in the compilations flags used to build the binaries?
Probably flags, the compiler was the same. The differences were for an example 22k versus 27k and when I check it again (F14/Slackware13.1), the differences are minimal.
prelink will also make a difference.
On 04/14/2011 08:12 PM, Mike McCarty wrote:
Vaclav Mocek wrote:
Well, ldd confirms that it is an urban legend.
On my system ldd is in /usr/bin, not /bin
ldd an analysis tool (Print shared library dependencies). It isn't needed for booting.
The actual dynamic linker is ld.so (located in /lib rsp /lib64).
Ralf
On 04/14/2011 07:40 PM, Ralf Corsepius wrote:
On 04/14/2011 08:12 PM, Mike McCarty wrote:
Vaclav Mocek wrote:
Well, ldd confirms that it is an urban legend.
On my system ldd is in /usr/bin, not /bin
ldd an analysis tool (Print shared library dependencies). It isn't needed for booting.
The actual dynamic linker is ld.so (located in /lib rsp /lib64).
Ralf
Yes, I know, it was clumsily written. I wanted to say, that the *usage* of ldd confirmed, that files in /bin are not statically linked and thus it is really an urban legend.
Vaclav M.
On 03/10/2011 10:02 AM, Robert Nichols wrote:
I just noticed that ever since Fedora 11 the Installation Guide recommends against having a /usr partition separate from the root file system (though as recently as Fedora 12 the Example Usage still showed a separate /usr). I've always used a separate /usr kept mounted read-only except when necessary for updates. I was wondering just what sort of "boot process becomes more complex" issues I've been fortunate enough to avoid, and whether the reasons for that recommendation have become stronger in more recent releases.
Some of the reasons are outlined in
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
Of course, the typical response is argue that, this shouldn't be the case but that is at this point just wishful thinking.
Rahul
Rahul Sundaram wrote:
Some of the reasons are outlined in
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
Thanks very much for that link. It's very informative, and reasonably well written, though with a few forgivable grammatical errors.
Of course, the typical response is argue that, this shouldn't be the case but that is at this point just wishful thinking.
Not on my machine.
$ egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/* egrep: /*/udev/rules.d/*: No such file or directory
I think this particular quote
What to do about this? Well, in theory all these programs could be fixed, and major parts of /usr be moved into /. However, the question is for what benefit?
is misdirected. The question should be posed the other way. What is the benefit of making non-necessary programs be necessary to boot? Obviously, there is none, it's just something which happened b/c people didn't think about what they were doing.
Also, it's not necessary to move "major parts of /usr into /".
So, what you are saying is that things are broken, and nobody at Red Hat wants to do anything about it, simply because nobody did the necessary thought and effort before making changes, and now it's "too late".
Well, different people have different priorities, I suppose. I don't have those problems on my machine, and I have, at times in the past, had /usr be a separately mounted file system, though at present it's not the way my machine is configured.
It's one of the more unattractive parts of the current direction being taken by the UNIX world, and Linux in particular, that changes get made w/o careful consideration and planning. People see a way in which they would prefer the system would behave differently, and so they figure out a way to change that, and everyone jumps on the bandwagon because there is a sort of automatic glee at "newness", and then later people start slapping their foreheads and wishing that things hadn't turned out quite the way they did.
This might be a good opportunity for some of the more cool headed people at Red Hat and other distro providers to argue for a little more deliberate approach to choosing the future direction of their products.
Just something possibly worth considering.
Mike
On 04/12/2011 03:05 AM, Mike McCarty wrote:
Rahul Sundaram wrote:
Some of the reasons are outlined in
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
Thanks very much for that link. It's very informative, and reasonably well written, though with a few forgivable grammatical errors.
Of course, the typical response is argue that, this shouldn't be the case but that is at this point just wishful thinking.
Hi,
So the inconvenients of separate /usr will be apply to separate /var /var/log and /var/tmp ???
and my reasons by that partitions are minimize file fragmentation and aallocate only the space necessary with lVM meanwhile separate the files by use case
/usr programs and supports files /var/log appending log files /var/tmp big temporary files
or in the future the only partitions will be /boot / and /home only?
speedy boot times are welcome but in my use case I value more the separate partittions, I only reboot my F14 machines each 7 days or more,
and I don't need 3G, I have good Audio after some fight and filing a bug d-bus, print and plug & play works fine
these things works now in my F14 systems, so really new versions (incompatible with separate partitions) were developed for F15 ??
Gabriel
Gabriel Ramirez wrote:
On 04/12/2011 03:05 AM, Mike McCarty wrote:
Rahul Sundaram wrote:
Some of the reasons are outlined in
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
Thanks very much for that link. It's very informative, and reasonably well written, though with a few forgivable grammatical errors.
Of course, the typical response is argue that, this shouldn't be the case but that is at this point just wishful thinking.
Hi,
So the inconvenients of separate /usr will be apply to separate /var /var/log and /var/tmp ???
I suppose it depends upon what kinds of rules get written by the distros and end users for udev. It seems unlikely that actual binaries in /bin and /sbin would be made to depend upon anything in /var.
and my reasons by that partitions are minimize file fragmentation and aallocate only the space necessary with lVM meanwhile separate the files by use case
There are numerous reasons for putting things not necessary for boot into separate partitions, and especially on separate discs. Only some of them are mentioned in the article cited, performance being one of them.
[...]
and I don't need 3G, I have good Audio after some fight and filing a bug d-bus, print and plug & play works fine
these things works now in my F14 systems, so really new versions (incompatible with separate partitions) were developed for F15 ??
The article is written in somewhat an overdone tone. There is no necessity, as I mentioned, that "major parts of /usr be moved into /" as it states. They want to make a point, and not all of the argument they present is actually realistic.
It certainly would take some serious thought and some real work to fix things now, I believe. One could argue that the thought and work should have been beforehand, but the attitude I thought I detected was one of extreme reluctance even to consider revisiting the decisions which have beem made, let alone to take any action on them.
Furthermore, there is nothing to prevent the end user from "breaking" things on his own later, given the way udev "works". It would not be much work, however, to find executable binaries in /bin and /sbin which depend upon anything in /usr/... and this work could, in fact, be automated.
$ for x in /sbin/* ; do readelf -l $x 2>/dev/null | grep '/usr' ; done
or something similar might do it. I'm sure there are some here more knowledgeable than am I about these matters.
Mike
On 04/12/2011 04:50 AM, Mike McCarty wrote:
Gabriel Ramirez wrote:
So the inconvenients of separate /usr will be apply to separate /var /var/log and /var/tmp ???
I suppose it depends upon what kinds of rules get written by the distros and end users for udev. It seems unlikely that actual binaries in /bin and /sbin would be made to depend upon anything in /var.
well the existing rules works just fine in my F14 systems, but sometimes the unlikely get developed and the likely well is forgotten, so that's my reason to ask about the situation with /var
and I don't need 3G, I have good Audio after some fight and filing a bug d-bus, print and plug& play works fine
these things works now in my F14 systems, so really new versions (incompatible with separate partitions) were developed for F15 ??
The article is written in somewhat an overdone tone. There is no necessity, as I mentioned, that "major parts of /usr be moved into /" as it states. They want to make a point, and not all of the argument they present is actually realistic.
It certainly would take some serious thought and some real work to fix things now, I believe. One could argue that the thought and work should have been beforehand, but the attitude I thought I detected was one of extreme reluctance even to consider revisiting the decisions which have beem made, let alone to take any action on them.
Well, the article points the problems are daemon's fault, but maybe the clean design of systemd is too clean
Gabriel
Gabriel Ramirez wrote:
[...]
Well, the article points the problems are daemon's fault, but maybe the clean design of systemd is too clean
That's not my understanding. The systemd is reporting a fact, that's all. The cause of any boot problems is the way udev works, I think. I'm no udev expert by any means. I tried it briefly (for a few weeks) and decided that it wasn't for me a few years ago, and I don't run it. That being said, I don't see how to make udev handle automatic creation and mount of devices which aren't required for boot, and also handle the devices required for boot, given the way it works. Boot is a multistage process, and being able to stop at an intermediate stage is not something the designer of udev considered very deeply.
Mike
On 04/13/2011 12:53 PM, Mike McCarty wrote:
Gabriel Ramirez wrote:
Well, the article points the problems are daemon's fault, but maybe the clean design of systemd is too clean
That's not my understanding. The systemd is reporting a fact, that's all. The cause of any boot problems is the way udev works, I think. I'm no udev expert by any means. I tried it briefly (for a few weeks) and decided that it wasn't for me a few years ago, and I don't run it. That being said, I don't see how to make udev handle automatic creation and mount of devices which aren't required for boot, and also handle the devices required for boot, given the way it works. Boot is a multistage process, and being able to stop at an intermediate stage is not something the designer of udev considered very deeply.
Mike
ok, so I was wrong about the webpage and the situation, well thanks, for your explanation the only thing to do is install the F15, live with it or try to do a workaround myself (I don't care if it's ugly) meanwhile works in my use case.
Gabriel
On 04/15/2011 12:22 AM, Gabriel Ramirez wrote:
ok, so I was wrong about the webpage and the situation, well thanks, for your explanation the only thing to do is install the F15, live with it or try to do a workaround myself (I don't care if it's ugly) meanwhile works in my use case.
You want an ugly workaround? How about keeping your separate /usr, but keep a very stripped-down copy (just the stuff needed during boot) under the /usr directory on your root file system. That will, of course, all be hidden when the separate /usr file system gets mounted.
OK, so how do you maintain the contents of that buried /usr while the system is running? Time to get tricky with bind mounts:
1. Create a directory /usr0.
2. Arrange /etc/fstab so that the /usr directory gets bind mounted onto /usr0 _before_ the real /usr gets mounted. (Note: I haven't done any testing to see if you can actually ensure that the mounts get done in this sequence during the auto mounting of local file systems.)
Now /usr0 is your window into that overlaid /usr directory. You can use rsync with the "--existing" option to update just the files that you placed in that root fs /usr.
If you ever umount /usr0, though, there's no way to regain access without rebooting.
As an extra-credit exercise, figure out how to set this up on a running system without booting from a rescue disk.
Once upon a time, Robert Nichols rnicholsNOSPAM@comcast.net said:
If you ever umount /usr0, though, there's no way to regain access without rebooting.
That's not true; if you bind mount / somewhere, so can see the /usr on the root filesystem (bind mounts don't follow filesystem mounts recursively; if you want that, you use rbind).
On 04/15/2011 08:49 AM, Robert Nichols wrote:
On 04/15/2011 12:22 AM, Gabriel Ramirez wrote:
ok, so I was wrong about the webpage and the situation, well thanks, for your explanation the only thing to do is install the F15, live with it or try to do a workaround myself (I don't care if it's ugly) meanwhile works in my use case.
You want an ugly workaround? How about keeping your separate /usr, but keep a very stripped-down copy (just the stuff needed during boot) under the /usr directory on your root file system. That will, of course, all be hidden when the separate /usr file system gets mounted.
well I don't mind a ugly workaround, meanwhile my system works.
my current system F14 works, at least I don't see anything broken with it.
if when I install F15:
all works fine, well thats it. ( maybe will be lucky) if it's broken well time to look a workaround not necessarily this one
I have workarounds in other parts of my Fedora systems, so a workaround more to keep the system working will be fine
copying /usr/bin /bin to / will not work under my actual partition / is too small for them.
but well maybe I can a create it a little bigger, and I'm familiar with bind mounts and rsync , so thanks by sharing this workaround
OK, so how do you maintain the contents of that buried /usr while the system is running? Time to get tricky with bind mounts:
Create a directory /usr0.
Arrange /etc/fstab so that the /usr directory gets bind mounted onto /usr0 _before_ the real /usr gets mounted. (Note: I haven't done any testing to see if you can actually ensure that the mounts get done in this sequence during the auto mounting of local file systems.)
well mounting filesystems seems will be controlled by systemd too (maybe I'm wrong here too I read a 2010 long webpage), so mounting fs will be the same or change
Now /usr0 is your window into that overlaid /usr directory. You can use rsync with the "--existing" option to update just the files that you placed in that root fs /usr.
better leave out that flag, because if install new daemon will be not included.
Gabriel
If you ever umount /usr0, though, there's no way to regain access without rebooting.
As an extra-credit exercise, figure out how to set this up on a running system without booting from a rescue disk.
On 04/15/2011 12:21 PM, Gabriel Ramirez wrote:
On 04/15/2011 08:49 AM, Robert Nichols wrote:
You want an ugly workaround? How about keeping your separate /usr, but keep a very stripped-down copy (just the stuff needed during boot) under the /usr directory on your root file system. That will, of course, all be hidden when the separate /usr file system gets mounted.
well I don't mind a ugly workaround, meanwhile my system works.
my current system F14 works, at least I don't see anything broken with it.
if when I install F15:
all works fine, well thats it. ( maybe will be lucky) if it's broken well time to look a workaround not necessarily this one
I have workarounds in other parts of my Fedora systems, so a workaround more to keep the system working will be fine
copying /usr/bin /bin to / will not work under my actual partition / is too small for them.
but well maybe I can a create it a little bigger, and I'm familiar with bind mounts and rsync , so thanks by sharing this workaround
Not even 1% of the programs in /usr/bin are relevant to the boot process. You need those, such libraries from /usr/lib (or /usr/lib64) that they need, some bits from /usr/share (/usr/share/hwdata in particular), probably a few more bits and pieces that I haven't taken the time to track down.
[SNIP]
Now /usr0 is your window into that overlaid /usr directory. You can use rsync with the "--existing" option to update just the files that you placed in that root fs /usr.
better leave out that flag, because if install new daemon will be not included.
There aren't many daemons that run before the local file systems have been mounted. Should you happen to install one of those, _and_ it misguidedly installs in /usr, then you'll have something to add to your minimal root filesystem version of /usr. Using the "--existing" flag ensures that only the files you've deemed necessary get copied, not the whole directory.
Hardest part, really, is coming up with a meaningful test. My systems, like yours, currently boot just fine with a separate /usr file system, so there's not much way to know if you've missed something that should, at least in theory, have been included.
On 04/15/2011 02:59 PM, Robert Nichols wrote:
Not even 1% of the programs in /usr/bin are relevant to the boot process. You need those, such libraries from /usr/lib (or /usr/lib64) that they need, some bits from /usr/share (/usr/share/hwdata in particular), probably a few more bits and pieces that I haven't taken the time to track down.
oh I forgot to add quick, I don't mind a quick and ugly workaround, so that's I think about the nonselective rsync. but if is a slow (complex) one meanwhile works
[SNIP] There aren't many daemons that run before the local file systems have been mounted. Should you happen to install one of those, _and_ it misguidedly installs in /usr, then you'll have something to add to your minimal root filesystem version of /usr. Using the "--existing" flag ensures that only the files you've deemed necessary get copied, not the whole directory.
thanks for clarifying that
Hardest part, really, is coming up with a meaningful test. My systems, like yours, currently boot just fine with a separate /usr file system, so there's not much way to know if you've missed something that should, at least in theory, have been included.
Well I install F15 and if in my use case is broken will take a look at to make a specific workaround for it.
Gabriel
On 04/12/2011 01:35 PM, Mike McCarty wrote:
Of course, the typical response is argue that, this shouldn't be the case but that is at this point just wishful thinking.
Not on my machine.
$ egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/* egrep: /*/udev/rules.d/*: No such file or directory
Your system is not relevant to the broader discussion. This isn't about individual systems and guidelines are not written for that.
So, what you are saying is that things are broken, and nobody at Red Hat wants to do anything about it, simply because nobody did the necessary thought and effort before making changes, and now it's "too late".
Nope. I didn't say that and majority of changes in the open source world happen because of individuals. Not vendors. If people care enough about something, step up and fix the software or pay a vendor to do it for you.
Rahul
Rahul Sundaram wrote:
On 04/12/2011 01:35 PM, Mike McCarty wrote:
Of course, the typical response is argue that, this shouldn't be the case but that is at this point just wishful thinking.
Not on my machine.
$ egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/* egrep: /*/udev/rules.d/*: No such file or directory
Your system is not relevant to the broader discussion. This isn't about individual systems and guidelines are not written for that.
It's true that my /machine/ is not relevant here. However, my /attitude/ is. I don't accept changes uncritically.
So, what you are saying is that things are broken, and nobody at Red Hat wants to do anything about it, simply because nobody did the necessary thought and effort before making changes, and now it's "too late".
Nope. I didn't say that and majority of changes in the open source world
Ok, that's my perception. If that isn't what you meant, then what did you mean?
Is there anyone at Red Hat who intends to take any action about this?
Why or why not?
Is the cause for this situation being addressed for future growth planning?
I think these are questions which some of those who use Red Hat products would like to know.
happen because of individuals.
This I agree with.
Not vendors. If people care enough about
This I don't agree with. Red Hat does not have to accept upstream changes meekly. The changes which happen to Red Hat products occur because Red Hat incorporates them, not because of upstream providers. It's Red Hat's decision what goes into everything it produces.
I'm not saying that Red Hat (or any other vendor) is responsible for the changes from upstream. However, all vendors are responsible for making the decisions about what to incorporate.
something, step up and fix the software or pay a vendor to do it for you.
Err, Red Hat _is_ being paid to fix software, or at least refuse to accept upstream changes w/o insisiting upon modifications, by those who purchase RHEL. Does RHEL have this (at least perceived) problem?
Mike
On 04/13/2011 11:36 PM, Mike McCarty wrote:
It's true that my /machine/ is not relevant here. However, my /attitude/ is. I don't accept changes uncritically.
Your attitude is irrelevant as well. This discussion is not about you. It is about whether /usr as a separate partition has problems in the general case.
Ok, that's my perception. If that isn't what you meant, then what did you mean?
If you want to talk about Red Hat, find the press contact or a customer representative if you are one. I have no interest to speak on behalf of Red Hat and from a personal viewpoint, I have no interest in a separate /usr partition. Fedora is a project that Red Hat participates in and where majority of packages are maintained by volunteers. It is not a commercial product. Fedora explicitly has a goal to stay close to upstream as much as possible. If there are changes being made to this, it would have to be made upstream regardless of who is driving it.
Err, Red Hat _is_ being paid to fix software, or at least refuse to accept upstream changes w/o insisiting upon modifications, by those who purchase RHEL. Does RHEL have this (at least perceived) problem?
I have no idea what you are talking about here with regards to modifications nor do I know of any customer paying Red Hat to fix this perceived problem.
Rahul
On 04/14/2011 01:02 AM, charles zeitler wrote:
"please define 'general case'"
Already defined in the wiki page I refererred to. Do read the thread completely before asking questions.
Rahul
On 04/14/2011 12:02 PM, charles zeitler wrote:
"i'm not trying to argue, i'm trying to understand. i _had_ read the whole thread, _and_ the wiki article. i re-read the wiki article, and couldn't find the definition there."
It is not a formal definition but the wiki page does describe the details just fine.
Rahul
On Tue, Apr 12, 2011 at 2:59 AM, Rahul Sundaram metherid@gmail.com wrote:
On 03/10/2011 10:02 AM, Robert Nichols wrote:
I just noticed that ever since Fedora 11 the Installation Guide recommends against having a /usr partition separate from the root file system (though as recently as Fedora 12 the Example Usage still showed a separate /usr). I've always used a separate /usr kept mounted read-only except when necessary for updates. I was wondering just what sort of "boot process becomes more complex" issues I've been fortunate enough to avoid, and whether the reasons for that recommendation have become stronger in more recent releases.
Some of the reasons are outlined in
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
Of course, the typical response is argue that, this shouldn't be the case but that is at this point just wishful thinking.
Only wishful if people are unwilling to reconsider past actions and are unwilling to consider the necessary changes. The cause appears lost in Fedora/RedHat only because 1 or 2 "large voices" seem to consider this a "religious" fight and will not consider doing anything to fix it. The attitude that the Filesystem Hierarchy Standard is outmoded and unnecessary and that modern hardware doesn't need to keep things on separate spindles or take space considerations into account anymore belongs to these "large voices" in this realm and therefore it cannot be fixed.
In actuality, only a few pieces need to be moved, but instead major surgery was applied to move the whole of /usr into / instead of applying a band aid and move a few small pieces around.
On Tue, Apr 12, 2011 at 4:08 PM, Gregory Woodbury redwolfe@gmail.comwrote:
Only wishful if people are unwilling to reconsider past actions and are unwilling to consider the necessary changes. The cause appears lost in Fedora/RedHat only because 1 or 2 "large voices" seem to consider this a "religious" fight and will not consider doing anything to fix it.
None of the issues mentioned in the wiki page I referred to is specific to one distro or the other. This is all just upstream configuration. I am pretty sure upstream will take patches if anyone is actually willing to do the leg work instead of just talking about it but I don't have any expectations. For anyone wanting to work on it, the wiki page references some of the issues but it is not exhaustive list and there are quite a few more of them. It is a starting point. All the best
Rahul
Rahul Sundaram wrote:
None of the issues mentioned in the wiki page I referred to is specific to one distro or the other. This is all just upstream configuration. I am
Yes.
pretty sure upstream will take patches if anyone is actually willing to do the leg work instead of just talking about it but I don't have any
Isn't there anyone at Red Hat who is "anyone" ?
expectations. For anyone wanting to work on it, the wiki page references some of the issues but it is not exhaustive list and there are quite a few more of them. It is a starting point. All the best
I'm certain it isn't a comprehensive list. However, my question remains: Isn't anyone at Red Hat "anyone"? Especially since RHEL is a "for pay" product?
Mike
On 04/13/2011 11:14 AM, Mike McCarty wrote:
I'm certain it isn't a comprehensive list. However, my question remains: Isn't anyone at Red Hat "anyone"? Especially since RHEL is a "for pay" product?
I haven't looked into this, but I'd be willing to bet that the only way to get RedHat interested in this is to have one or more of their *customers* complain.
On 04/12/2011 03:38 AM, Gregory Woodbury wrote:
On Tue, Apr 12, 2011 at 2:59 AM, Rahul Sundaram <metherid@gmail.com mailto:metherid@gmail.com> wrote:
On 03/10/2011 <tel:03%2F10%2F2011> 10:02 AM, Robert Nichols wrote: > I just noticed that ever since Fedora 11 the Installation Guide > recommends against having a /usr partition separate from the root file > system (though as recently as Fedora 12 the Example Usage still showed a > separate /usr). I've always used a separate /usr kept mounted read-only > except when necessary for updates. I was wondering just what sort of > "boot process becomes more complex" issues I've been fortunate enough to > avoid, and whether the reasons for that recommendation have become > stronger in more recent releases. Some of the reasons are outlined in http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Of course, the typical response is argue that, this shouldn't be the case but that is at this point just wishful thinking.Only wishful if people are unwilling to reconsider past actions and are unwilling to consider the necessary changes. The cause appears lost in Fedora/RedHat only because 1 or 2 "large voices" seem to consider this a "religious" fight and will not consider doing anything to fix it. The attitude that the Filesystem Hierarchy Standard is outmoded and unnecessary and that modern hardware doesn't need to keep things on separate spindles or take space considerations into account anymore belongs to these "large voices" in this realm and therefore it cannot be fixed.
In actuality, only a few pieces need to be moved, but instead major surgery was applied to move the whole of /usr into / instead of applying a band aid and move a few small pieces around.
I generally agree. My reasons for keeping separate /, /var, and /usr has been / is to provide some degree of protection from corruption to the file system. If all of these were under /, then a corruption in / would make the other two also inaccessible. So They indeed ought to be kept separate for that reason, to minimize loss.
Cheersm
JD
On Tue, 2011-04-12 at 07:07 -0700, JD wrote:
On 04/12/2011 03:38 AM, Gregory Woodbury wrote:
On Tue, Apr 12, 2011 at 2:59 AM, Rahul Sundaram <metherid@gmail.com mailto:metherid@gmail.com> wrote:
On 03/10/2011 <tel:03%2F10%2F2011> 10:02 AM, Robert Nichols wrote: > I just noticed that ever since Fedora 11 the Installation Guide > recommends against having a /usr partition separate from the root file > system (though as recently as Fedora 12 the Example Usage still showed a > separate /usr). I've always used a separate /usr kept mounted read-only > except when necessary for updates. I was wondering just what sort of > "boot process becomes more complex" issues I've been fortunate enough to > avoid, and whether the reasons for that recommendation have become > stronger in more recent releases. Some of the reasons are outlined in http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Of course, the typical response is argue that, this shouldn't be the case but that is at this point just wishful thinking.Only wishful if people are unwilling to reconsider past actions and are unwilling to consider the necessary changes. The cause appears lost in Fedora/RedHat only because 1 or 2 "large voices" seem to consider this a "religious" fight and will not consider doing anything to fix it. The attitude that the Filesystem Hierarchy Standard is outmoded and unnecessary and that modern hardware doesn't need to keep things on separate spindles or take space considerations into account anymore belongs to these "large voices" in this realm and therefore it cannot be fixed.
In actuality, only a few pieces need to be moved, but instead major surgery was applied to move the whole of /usr into / instead of applying a band aid and move a few small pieces around.
I generally agree. My reasons for keeping separate /, /var, and /usr has been / is to provide some degree of protection from corruption to the file system. If all of these were under /, then a corruption in / would make the other two also inaccessible. So They indeed ought to be kept separate for that reason, to minimize loss.
Cheersm
JD
Separating these file system trees is not more efficient unless the partitions are on separate hard drives.
On 04/12/2011 03:04 PM, Aaron Konstam wrote:
On Tue, 2011-04-12 at 07:07 -0700, JD wrote:
On 04/12/2011 03:38 AM, Gregory Woodbury wrote:
On Tue, Apr 12, 2011 at 2:59 AM, Rahul Sundaram<metherid@gmail.com mailto:metherid@gmail.com> wrote:
On 03/10/2011<tel:03%2F10%2F2011> 10:02 AM, Robert Nichols wrote: > I just noticed that ever since Fedora 11 the Installation Guide > recommends against having a /usr partition separate from the root file > system (though as recently as Fedora 12 the Example Usage still showed a > separate /usr). I've always used a separate /usr kept mounted read-only > except when necessary for updates. I was wondering just what sort of > "boot process becomes more complex" issues I've been fortunate enough to > avoid, and whether the reasons for that recommendation have become > stronger in more recent releases. Some of the reasons are outlined in http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Of course, the typical response is argue that, this shouldn't be the case but that is at this point just wishful thinking.Only wishful if people are unwilling to reconsider past actions and are unwilling to consider the necessary changes. The cause appears lost in Fedora/RedHat only because 1 or 2 "large voices" seem to consider this a "religious" fight and will not consider doing anything to fix it. The attitude that the Filesystem Hierarchy Standard is outmoded and unnecessary and that modern hardware doesn't need to keep things on separate spindles or take space considerations into account anymore belongs to these "large voices" in this realm and therefore it cannot be fixed.
In actuality, only a few pieces need to be moved, but instead major surgery was applied to move the whole of /usr into / instead of applying a band aid and move a few small pieces around.
I generally agree. My reasons for keeping separate /, /var, and /usr has been / is to provide some degree of protection from corruption to the file system. If all of these were under /, then a corruption in / would make the other two also inaccessible. So They indeed ought to be kept separate for that reason, to minimize loss.
Cheersm
JD
Separating these file system trees is not more efficient unless the partitions are on separate hard drives.
Sorry, I said nothing about efficiency. I merely separate these dirs onto separate partitions to prevent the corruption of one of them to affect the accessibility to the others.
On Tue, 2011-04-12 at 17:04 -0500, Aaron Konstam wrote:
Separating these file system trees is not more efficient unless the partitions are on separate hard drives.
Well, that rather depends... For some people, *efficiency* can mean not sitting through an entire huge drive do a fsck thanks to only one partition needing checking. Or using different file systems and/or mount options on the different partitions. Or putting certain partitions into faster parts of the drive. Or putting certain mount points on partitions that aren't going to get fragmented by other things.
Some snippage when you reply, PLEASE!
On Wed, 2011-04-13 at 16:15 +0930, Tim wrote:
On Tue, 2011-04-12 at 17:04 -0500, Aaron Konstam wrote:
Separating these file system trees is not more efficient unless the partitions are on separate hard drives.
Well, that rather depends... For some people, *efficiency* can mean not sitting through an entire huge drive do a fsck thanks to only one partition needing checking. Or using different file systems and/or mount options on the different partitions. Or putting certain partitions into faster parts of the drive. Or putting certain mount points on partitions that aren't going to get fragmented by other things.
Some snippage when you reply, PLEASE!
I don't know what snippage means but efficiency to me means faster access to information on the drives. Only one of the things on your list of "efficiencies" speaks to that kind of efficiency.
On 04/13/2011 06:35 AM, Aaron Konstam wrote:
I don't know what snippage means
"Snippage" refers to trimming out (or snipping) those parts of the message that aren't relevant to your reply. As an example, instead of quoting your entire post, including all of the quoted text, I only quoted the one line I was replying to. This makes it much easier for people to find your reply and know what you're talking about.
Aaron Konstam wrote:
Some snippage when you reply, PLEASE!
I don't know what snippage means but efficiency to me means faster
It means "please trim your quotes".
access to information on the drives. Only one of the things on your list of "efficiencies" speaks to that kind of efficiency.
Different file systems are optimized for different things. Some of them, for example, do better at holding large sparse files. So, "efficiency" has several possible interpretations.
Mike
On Wed, 2011-04-13 at 13:18 -0500, Mike McCarty wrote:
Different file systems are optimized for different things. Some of them, for example, do better at holding large sparse files. So, "efficiency" has several possible interpretations.
That may be true but that has nothing to do with having the sub-file trees of / in different partitions. If you want that kind of efficiency just have you whole / partition optimized for sparse files.
Aaron Konstam wrote:
On Wed, 2011-04-13 at 13:18 -0500, Mike McCarty wrote:
Different file systems are optimized for different things. Some of them, for example, do better at holding large sparse files. So, "efficiency" has several possible interpretations.
That may be true but that has nothing to do with having the sub-file trees of / in different partitions. If you want that kind of efficiency just have you whole / partition optimized for sparse files.
Yes, it does, b/c optimizing for one kind of efficiency normally reduces other kinds. So, a FS optimized for sparse files may not be optimized in another way desirable for other sub-trees.
That was the point of what I wrote. What is the best file system for /usr/bin may not be the same as that for /bin, b/c /usr/bin might be expected to contain large(ish) data files, while /bin should only contain relatively small binaries.
In any case, the fact that one person doesn't feel a need for a certain kind of flexibility shouldn't be an argument for eliminating it altogether, w/o consulting with those who might feel a need for it.
At present, it isn't an issue for me anyway, since I use the same sorts of FS for all my partitions. That doesn't mean that I'm insensitive to the needs of others.
Mike
-
Aaron Konstam -
Bruno Wolff III -
Bryn M. Reeves -
Charles Zeitler -
Chris Adams -
Fred Smith -
Gabriel Ramirez -
Gregory Woodbury -
JD -
Joe Zeff -
Kam Leo -
little.owl -
Michael Cronenworth -
Mike McCarty -
Rahul Sundaram -
Ralf Corsepius -
Richard Shaw -
Robert Nichols -
Tim