![]() |
Error information when booting: cann't find /usr/
Hi, everyone, I put my /usr in another partition different with that for the root. In that case, when system is booting, it is reported that some scripts or applications cannot be found because they are in the /usr/bin or /usr/sbin rather than in /bin or /sbin, for example, the virtualbox. How can I deal with them?
Thank you very much! |
All Virtualbox drivers should be in /lib/modules/<kernel-version>/misc for Sid and should be in the same general area for Squeeze and Wheezy. It may depend on your kernel version. Make sure your /usr partition is set correctly in fstab with UUID=. You can find the correct numbers to use in /dev/disk/by-uuid. Usually running update-grub2 will solve the problem.
If that does not work post more info. |
I'm not sure how much of this applies on Debian, but here are a couple of ways I've worked around issues with this on Red Hat related systems, which also do not officially support a separate /usr file system:
Method 1: Keep a stub /usr tree under /usr on the root file system. To find what need to go there, you have to dig through the startup scripts and identify all needed programs, data files, and shared libraries. Takes a while, but it's doable. The ongoing problems are keeping those files up to date and the tricks you have to play to back up that part of the root file system. (Temporarily bind-mounting the root file system to a temporary directory is your friend here.)Method 2: Arrange to mount /usr along with the root file system early in the boot process. It's easy enough to do. You just need to edit /etc/dracut.conf to uncomment the "add_dracutmodules" line to readI've used both methods successfully, and found method 2 best for me. My /usr is normally mounted read-only, and can easily be checked by "fsck -n" while the system is running. |
Quote:
can not find /usr/sbin/alsactl : no such a file or directory. However, /usr/sbin/alsactl exists. It is just because that /usr partition is not mounted at that time. |
Thank you so much! It seems very complex, but I will try it. I am just wondering the structure of packages. If they are needed before mounting, they shouldn't be put in other partitions except root because debian installation support seperate /usr /var and so on.
Quote:
|
Checking the Debian installation guide, I see that a separate /usr file system is indeed supported and recommended (except for single user systems with a small disk), which implies that packages really should use the root file system for any files needed before other partitions are mounted. I suspect, though, that this is a case of the installation guide not reflecting the actual needs of the current system. I know it took a while for the Red Hat / Fedora documentation to get rid of all recommendations for a separate /usr. If I were a Debian user, I'd report it as a bug in the documentation and perhaps in the installer too.
That of course still leaves you needing a workaround for your immediate problem. Because of my unfamiliarity with Debian, I really can't offer anything more specific or detailed than what I have already said. For me, method 2 actually turned out to be way easier than I thought it would be. |
Quote:
The problem is Debian does not have /etc/dracut.conf. You would have to change the order in /etc/rcS.d but I'm not sure what the risk of doing this would be if any. |
Code:
:/home/chevy# ls -l /etc/rcS.d |
It is weird that udev reports that error message to me. It is supposed not to start alsa so early.
|
Quote:
Not at all you have one of two problems. Your startup scrips are in the wrong order or /etc/fstab is miss configured. Post your /etc/fstab so someone can help you sort this out Code:
chevy@sid:~$ cat /etc/fstabCode:
chevy@sid:~$ ls -l /dev/disk/by-uuidEdit: on the off chance that something got added to /etc/modules post that too. Code:
chevy@sid:~$ cat /etc/modules |
here is my /etc/fstab:
Quote:
Quote:
Here is my /etc/modules: Quote:
|
The only other thing you can do is look at /etc/rcS.d to see where alsa-utils is loaded, if it's before mountall.sh then that is your problem.
Do you have a default Debian install or have you modified it. (sysvinit vs systemd) |
You might also see if there any udev rules that would call alsactl way back up in the S02udev script.
|
| All times are GMT -5. The time now is 05:19 PM. |