Linda Walsh said the following on 01/25/2013 02:50 PM:
Anton Aylward wrote:
The way I look at it the CORRECT way is to have an initrd that does what you want and only what you want.
What does initrd have on it that does the mounting of '/usr'?
Why don't you run 'lsinitrd' and find out?
Isn't it a "script" and a copy of "mount"?
No, its what it takes to boot the system.
Proper configuration or script? Set up the configuration properly (drakut makes this easier) and you get a properly built kernel and initrd every time :-)
drakut determines what modules your kernel needs, and unless you add plugins, it won't add mounting code for /usr. According to it's mission statement, it is designed to only put the *modules* on the initrd necessary for booting your specific HW.
Conversely you could look at it as drakut takes a lot in by default unless you tell it to exclude stuff. The config file can be viewed both ways :-) My point is that you *DO* get to choose. You specify what you want. You have stated you want /usr mounted. So that determines the module you want included. You don't want, say the XFS file system or the Btrfs file system, so you exclude those and you boot faster since you have a smaller initrd. The point is that *YOU* are in control. With the distribution kernel, which you said you were using, you have to take what you are given whether you want it or not, and if it lacks something, like mounting /usr, then tough. The decision as to what modules are part of the initrd have been taken out of your hands. You can either live with it, and have to finagle work-arounds, as you are doing, as you seem unhappy with or we wouldn't be having this thread, or you can do something about it, build a new initrd. That's mkinitrd or drakut. Either way, you are going to have to specify, somehow or other, what to include and what to exclude.
Something else must then take control and execute some copy of 'mount' to make sure /usr is mounted.
Do you want to take a diversion into the innards of how drakut/initrd work and how the initial boot does it stuff and pivots? I'd really rather not. You can google for all that and read it up at your leisure and emerge from that process knowing, in all probability, more about it than I do.
Of course you could always pre-empt the future and run a system that has a single unified root+/usr. That's how its going to be.
Ok, but what about all the directories under /usr?
What about them? I have /usr/share as a separate partition. I suppose that's what you mean, partitions not directories. I have no problem.
How many of them also have to be mounted? /usr/homes could be a place where people put home directories. /usr/share is supposed to be arch independent material that can be 1) quite large, 2) should be shareable, 3) quite likely should be 0n a separate partition from /root and /usr as the size of /usr/share can easily be larger than the combined size of root and /usr. 15G vs. 10.6G on my system.
Oh yes, there's a lot in there, all the docs and manual pages and stuff like that :-) Your point being?
However, reviewing my boot log just now, I see that arbitrary directories seem to be required from /usr/share for boot:
udevd[602]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 512 09': No such file or directory
There is the boot that initrd does and then system 'pivots' and what you probably think of boot takes over. Stop and think why those appear in your log files. To be there the logger has to be running. When does the logger start? Well it may be /etc/init.d/syslog or in my systemd-driven 11.2 its in syslog.target. So to get there the RC stuff or systemd mist be running. That's away along, after the 'pivot'. Then we get to where udevd starts running to start up virtualbox. I won't go down that avenue, but it may have something to do with other aspects of configuration.
---- This means arbitrary shell scripts are needed to *cleanly* "boot" before I could even get a shell prompt. Are those "signed" kernel modules being loaded? I don't get a good feeling about the security of needing to load shell scripts off of /usr/share in order to boot.
I agree with that last line and I think that is an artefact of the way you have configured your system, not a necessary way the system has to be configured. I don't start virtualbox on boot so I'm not able to comment. But I disagree with the idea that your first sentence is a necessity.
In short -- we see shell scripts being called even when booting to mode 'S'... Requiring /usr is bad enough (8.0G v. root at 4.6G).
Linda, all you are talking about is really after boot, after initrd has done its stuff. The issue of whether /usr should be a separate partition has been debated elsewhere. I was - still am to a degree - in favour of partitioning over OneBigFileSystem. Many reasons such as Oh-squared. But there are many things that get changed which old fogies like myself who grew up with V7 on a PDP-11 and 10M TR think the young whipper-snappers have gone wild with, things like *shock* *horror* "virtual memory" -- heck even having more than 1 megabytes of memory! But, like they say "change happens". If I can live with systems with more than I megabyte of memory I'm sure you can live with the huge drives we have today that have one partition for root and /usr/. And Gee-wow! I use LVM, so the conversion was not a big deal for me.
Now it used to be root was larger and /usr was smaller. But the only reason /usr needs to be mounted is the 2-4G of material that was moved off of /root into /usr.
So? If that's all, then move it back.
Where does it stop? Do I need all of /usr/share as well -- the largest parts being font, icons, clipart and docs:
Don't be ridiculous! Those are only needed when you go into graphics mode. Nothing to do with boot.
Will /usr/local also be required for boot? That's historically been for site-local material.
Why should it be?
This is why I am asking for specifics -- when you say /usr, are you including those who have /usr/home? (likely not as that's an uncommon config, BUT, running shell scripts off of /usr/share in order to boot used to be uncommon as well.
You seem to be confusing boot with 'going multi user' or with 'going to graphics mode'. If no user logs in then why does a /home' need to be mounted? In fact we've discussed 'roaming share' where the "home" is on the NFS server and is only mounted when the use logs in at whatever workstation he or she logs in at. As I've pointed out before, SUN were doing this back in the 1980s. If you're running sysvinit and your inittab says to go to mode 1 or 3 and you have the entry in fstab for /usr, then you have a problem with something you've configured earlier on that preventing the system getting past S. Once I had a thing like that; my / needed a good fsck and boot wasn't doing it. Maybe something similar here. Its why I don't use /etc/3 for / any more. My suspicion is that you've done something non-normal that necessitates this odd behaviour. Be it config or fsck. Yes, I'm used to fixing this kind of thing, but that's in 'admin consulting' and 'hands on' mode, where I can scan for 'suspicious changes' and all the things you're not showing us. As I say, what initrd does and init -- process #1 -- does are different. You seem confused over the two. -- Teachers open the door. You enter by yourself. Chinese Proverb -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org