Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Dale wrote: Canek Peláez Valdés wrote: Dale, could yo please add again rd.debug to your kernel command line, boot with the initramfs, and post the output from dmesg (without you manually mounting your LVM volume)? Regards. It's attached. I see what it is doing but no idea how to fix it. It didn't use to do this. This is a recent thing. It doesn't appear to be init thingy related and I think Walt is having the same issue. Kernel maybe? I'm on 3.2.11. Thanks. Dale :-) :-) It's a bug. Roach report here: https://bugs.gentoo.org/show_bug.cgi?id=409921 Going back a version and then reboot. Then I'm off to bed. It's 4:00AM here. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Wed, 04 Apr 2012 04:05:27 -0500, Dale wrote: It's a bug. Roach report here: https://bugs.gentoo.org/show_bug.cgi?id=409921 Going back a version and then reboot. No need for that, just change locking_dir in lvm.conf to somewhere writeable, as mentioned in the bug report - comment 6. -- Neil Bothwick If ignorance is bliss, you must be orgasmic. signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Neil Bothwick wrote: On Wed, 04 Apr 2012 04:05:27 -0500, Dale wrote: It's a bug. Roach report here: https://bugs.gentoo.org/show_bug.cgi?id=409921 Going back a version and then reboot. No need for that, just change locking_dir in lvm.conf to somewhere writeable, as mentioned in the bug report - comment 6. Well, I didn't want to mess with the config much since I may make it worse. So, I built a new kernel 3.3.0 and built a new init do hicky. Now, it seems to work. It boots with no errors and everything mounts. I also downgraded to lvm2-2.02.88 which works. A newer version may work but that is what I went back to. It was the last one that I knew worked. So, I took my med and I'm off to bed. Hmmm. I'm a poet and didn't know it. :-p I'll test some more tomorrow. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Wed, 04 Apr 2012 04:54:05 -0500, Dale wrote: No need for that, just change locking_dir in lvm.conf to somewhere writeable, as mentioned in the bug report - comment 6. Well, I didn't want to mess with the config much since I may make it worse. So, I built a new kernel 3.3.0 and built a new init do hicky. Now, it seems to work. It boots with no errors and everything mounts. I also downgraded to lvm2-2.02.88 which works. A newer version may work but that is what I went back to. It was the last one that I knew worked. You didn't want to change one line in a file, which you could have easily changed back if it didn't work, so you rebuilt the whole kernel and initramfs (which are irrelevant to the bug) and downgraded? :-O -- Neil Bothwick Give a man a fish and you have fed him for a day, but give him a case of dynamite and soon the village will be showered with mud and seaweed and unidentifiable chunks of fish. signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Wed, Apr 4, 2012 at 4:54 AM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: On Wed, 04 Apr 2012 04:05:27 -0500, Dale wrote: It's a bug. Roach report here: https://bugs.gentoo.org/show_bug.cgi?id=409921 Going back a version and then reboot. No need for that, just change locking_dir in lvm.conf to somewhere writeable, as mentioned in the bug report - comment 6. Well, I didn't want to mess with the config much since I may make it worse. So, I built a new kernel 3.3.0 and built a new init do hicky. Now, it seems to work. It boots with no errors and everything mounts. I also downgraded to lvm2-2.02.88 which works. A newer version may work but that is what I went back to. It was the last one that I knew worked. So, I took my med and I'm off to bed. Hmmm. I'm a poet and didn't know it. :-p I'll test some more tomorrow. It seems the problem it's in LVM, or (more appropriately) in the failure to create the /run tmpfs: # mount | grep /run tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755) It seems other problems (like 张春江's one with plymouth) have the same reason. With systemd the /run tmpfsgets created, so maybe now that systemd and udev are being merged this problem will go away. For now, I think we can (finally) call this case closed; Dale, I would strongly recommend the workaround (editing the config file) instead of downgrading. Eventually you will need the new version anyhow. Glad to hear it works, albeit with some issues (unrelated to the initramfs). Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Wed, 4 Apr 2012 12:23:01 -0500, Canek Peláez Valdés wrote: It seems the problem it's in LVM, or (more appropriately) in the failure to create the /run tmpfs: # mount | grep /run tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755) /run is not the problem. The default setting is to write to /var/lock. Changing that to /run/lock removes the problem. -- Neil Bothwick Profanity, The Language of Computer Professionals. signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Neil Bothwick wrote: On Wed, 04 Apr 2012 04:54:05 -0500, Dale wrote: No need for that, just change locking_dir in lvm.conf to somewhere writeable, as mentioned in the bug report - comment 6. Well, I didn't want to mess with the config much since I may make it worse. So, I built a new kernel 3.3.0 and built a new init do hicky. Now, it seems to work. It boots with no errors and everything mounts. I also downgraded to lvm2-2.02.88 which works. A newer version may work but that is what I went back to. It was the last one that I knew worked. You didn't want to change one line in a file, which you could have easily changed back if it didn't work, so you rebuilt the whole kernel and initramfs (which are irrelevant to the bug) and downgraded? :-O Well, yea. I figure they will fix it pretty quick since the bug is active and folks are working on it. I wouldn't want my change to break something in the future when just using a known good version, one that I was using until just the other day, will work just fine. Also, I'll forget I changed that and let the config update when it gets updated again. They could lead to breakage too. Also, I was wanting to update the kernel anyway. I had trouble with my network on a older kernel and had to update to fix that. So far, the new 3.3 kernel has helped my network even more. I was actually fixing more than one issue with the kernel upgrade and downgrading was all of a one line command. I'm more likely to remember downgrading than editing a config file these days. I'm just glad to get some of this mess sorted. sighs Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Canek Peláez Valdés wrote: On Wed, Apr 4, 2012 at 4:54 AM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: On Wed, 04 Apr 2012 04:05:27 -0500, Dale wrote: It's a bug. Roach report here: https://bugs.gentoo.org/show_bug.cgi?id=409921 Going back a version and then reboot. No need for that, just change locking_dir in lvm.conf to somewhere writeable, as mentioned in the bug report - comment 6. Well, I didn't want to mess with the config much since I may make it worse. So, I built a new kernel 3.3.0 and built a new init do hicky. Now, it seems to work. It boots with no errors and everything mounts. I also downgraded to lvm2-2.02.88 which works. A newer version may work but that is what I went back to. It was the last one that I knew worked. So, I took my med and I'm off to bed. Hmmm. I'm a poet and didn't know it. :-p I'll test some more tomorrow. It seems the problem it's in LVM, or (more appropriately) in the failure to create the /run tmpfs: # mount | grep /run tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755) It seems other problems (like 张春江's one with plymouth) have the same reason. With systemd the /run tmpfsgets created, so maybe now that systemd and udev are being merged this problem will go away. For now, I think we can (finally) call this case closed; Dale, I would strongly recommend the workaround (editing the config file) instead of downgrading. Eventually you will need the new version anyhow. Glad to hear it works, albeit with some issues (unrelated to the initramfs). Regards. I'm glad too. Now to keep this mess working. That's my new concern. lol Thanks much for all the help. I needed it. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On 4/2/2012 11:12 PM, Dale wrote: Canek Peláez Valdés wrote: Actually, the initramfs finished without a single error: between [1.962007] dracut: + source_conf /etc/conf.d and [2.395576] dracut: Switching root there is not a single error. The initramfs did what it needed to do; the user space failed *after* initramfs switched root. Did you recreated the initramfs after the kernel recompilation? 1st rule of non-trivial initramfs: you need to recreate it everytime you change kernels. Which partition is the LVM one? /home or /data? Either way, either partition should not matter to boot the system correctly. We need to see the errors *after* the initramfs switched root; maybe you can delete /var/log/messages, reboot, and post it? Regards. So the init thingy is going to print all that stuff each time? Or is that the debug stuff you had me add to the grub line? Please say it is so. It's one reason I checked my email. I was counting and realized the debug stuff that was added may haver done all that. Taking a deep breath helped tho. ;-) I still want my hands on that neck tho. lol It was the debug stuff; every line that look like dracut: + stuff here was debugging information; AFAICT dracut mounted /dev/sda3 as root then it mounted the two other partitions it found. But this could be a problem (from your other email): root@fireball / # dracut -H -f /boot/init-thingy E: Dracut module lvm cannot be found. E: Dracut module lvm cannot be found. dracut couldn't find it's lvm module, even though your USE flags are set correctly. Can you try re-emerging dracut with its current USE flags? You should have a folder in /usr/lib/dracut/modules named 'lvm' that has a 'module-setup.sh' script in it, plus probably some other support files, if everything got installed correctly. --Mike
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Mike Edenfield wrote: It was the debug stuff; every line that look like dracut: + stuff here was debugging information; AFAICT dracut mounted /dev/sda3 as root then it mounted the two other partitions it found. But this could be a problem (from your other email): root@fireball / # dracut -H -f /boot/init-thingy E: Dracut module lvm cannot be found. E: Dracut module lvm cannot be found. dracut couldn't find it's lvm module, even though your USE flags are set correctly. Can you try re-emerging dracut with its current USE flags? You should have a folder in /usr/lib/dracut/modules named 'lvm' that has a 'module-setup.sh' script in it, plus probably some other support files, if everything got installed correctly. --Mike I have re-emerged dracut several times and it still gives the same error. I even tried changing versions once to see if it was a bug or something. I found others with errors for other modules but no one posted a fix. It's a head scratcher for sure. Since lvm is not needed for booting YET, I think my main problem is the kernel and lvm. Now, even if I boot with the old kernel and no init thingy, I have to restart lvm before it will let me mount my /data partition. I think when I added the needed stuff for dracut and the init thingy, it messed up something for lvm. I can't put my finger on what yet tho. The directory you mentions is there and there is all sorts of goodies in there. I'm not sure why dracut is not finding it. I'm gonna be gone for a while but will be back as soon as I can. I got to take a friend to court. :-( Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, Apr 3, 2012 at 8:21 AM, Dale rdalek1...@gmail.com wrote: Mike Edenfield wrote: It was the debug stuff; every line that look like dracut: + stuff here was debugging information; AFAICT dracut mounted /dev/sda3 as root then it mounted the two other partitions it found. But this could be a problem (from your other email): root@fireball / # dracut -H -f /boot/init-thingy E: Dracut module lvm cannot be found. E: Dracut module lvm cannot be found. dracut couldn't find it's lvm module, even though your USE flags are set correctly. Can you try re-emerging dracut with its current USE flags? You should have a folder in /usr/lib/dracut/modules named 'lvm' that has a 'module-setup.sh' script in it, plus probably some other support files, if everything got installed correctly. --Mike I have re-emerged dracut several times and it still gives the same error. I even tried changing versions once to see if it was a bug or something. I found others with errors for other modules but no one posted a fix. It's a head scratcher for sure. Since lvm is not needed for booting YET, I think my main problem is the kernel and lvm. Now, even if I boot with the old kernel and no init thingy, I have to restart lvm before it will let me mount my /data partition. I think when I added the needed stuff for dracut and the init thingy, it messed up something for lvm. I can't put my finger on what yet tho. The directory you mentions is there and there is all sorts of goodies in there. I'm not sure why dracut is not finding it. I do. I don't use LVM, so i didn't had neither USE=device-mapper, nor DRACUT_MODULES=lvm, so I add them. Then I tried to create my initramfs with LVM, and like in your case, it failed. Using the --debug option for dracut, it *seems* (it's really verbose and I didn't read everything), it seems that it doesn't find the lvm module not because it's not there, but because I actually don't have any LVM volumes. So I removed the -H option for dracut to stop looking at my host status, and lo and behold, it included the LVM module. So please, try that. If it works, then there is two options: 1. Dracut has a bug that stops it from detecting your host LVM status; maybe it only checks the important or standard partitions, or maybe the checking process itself has a bug. 2. Your LVM configuration (while it works) it's not canonically detectable. Either case, please try re-creating your dracut initramfs without the -H option. I think that's the last problem (the other problem was that you got scared with the humongous debug output that dracut generates with dr.debug), and so we can then finally put this case to rest. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Canek Peláez Valdés wrote: I do. I don't use LVM, so i didn't had neither USE=device-mapper, nor DRACUT_MODULES=lvm, so I add them. Then I tried to create my initramfs with LVM, and like in your case, it failed. Using the --debug option for dracut, it *seems* (it's really verbose and I didn't read everything), it seems that it doesn't find the lvm module not because it's not there, but because I actually don't have any LVM volumes. So I removed the -H option for dracut to stop looking at my host status, and lo and behold, it included the LVM module. So please, try that. If it works, then there is two options: 1. Dracut has a bug that stops it from detecting your host LVM status; maybe it only checks the important or standard partitions, or maybe the checking process itself has a bug. 2. Your LVM configuration (while it works) it's not canonically detectable. Either case, please try re-creating your dracut initramfs without the -H option. I think that's the last problem (the other problem was that you got scared with the humongous debug output that dracut generates with dr.debug), and so we can then finally put this case to rest. Regards. Not so fast there Tex. This ain't over but the fat lady may be clearing her throat. Riddle me this Batman. I tried it without the -H. That was much better. No boo boos. But wait. This is me you know. ;-) When I boot, lvm fails to start. After it boots to a console and I login, I can restart lvm and it works fine. So, when I boot, the drive that is set up for lvm isn't working. It's not a big deal right now but it is about to be when /usr gets put on lvm. If I put /usr on lvm, Houston, we have a problem. May not boot right at all. At this point, this fails regardless of the kernel. I may try some older kernels in a bit tho. Also, it no longer matters if I use the init thingy either. It fails either way. Looks like the init thingy is working, until I break it anyway. Give me time. lol Canek, I know you don't use lvm so, anybody have any ideas? Maybe a new thread since this may not be init thingy related. Well, I rebooted and wrote down the errors then searched a bit. I found this: http://speeves.erikin.com/2012/01/root-your-box-and-mount-lvm-partitions.html So, it seems that / needs to be mounted rw so that lvm can start. How do I fix this you reckon? Doesn't the init thingy do that or is that done after the init thingy is done? sighs Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, 2012-04-03 at 19:02 -0500, Dale wrote: Canek Peláez Valdés wrote: I do. I don't use LVM, so i didn't had neither USE=device-mapper, nor DRACUT_MODULES=lvm, so I add them. Then I tried to create my initramfs with LVM, and like in your case, it failed. Using the --debug option Dale, with genkernel you have to tell it to start LVM on the kernel commandline (dolvm) which triggers a script within the initramfs - do you have to do the same thing with dracut? BillK
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
William Kenworthy wrote: On Tue, 2012-04-03 at 19:02 -0500, Dale wrote: Canek Peláez Valdés wrote: I do. I don't use LVM, so i didn't had neither USE=device-mapper, nor DRACUT_MODULES=lvm, so I add them. Then I tried to create my initramfs with LVM, and like in your case, it failed. Using the --debug option Dale, with genkernel you have to tell it to start LVM on the kernel commandline (dolvm) which triggers a script within the initramfs - do you have to do the same thing with dracut? BillK Well, I dunno. I know how to find out tho. dale adds dolvm to his kernel line and is about to reboot If I ain't back in a few minutes, send help. . . quick. lol Also, see the other new thread. I think Walt has the same thing. BRB Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Dale wrote: William Kenworthy wrote: On Tue, 2012-04-03 at 19:02 -0500, Dale wrote: Canek Peláez Valdés wrote: I do. I don't use LVM, so i didn't had neither USE=device-mapper, nor DRACUT_MODULES=lvm, so I add them. Then I tried to create my initramfs with LVM, and like in your case, it failed. Using the --debug option Dale, with genkernel you have to tell it to start LVM on the kernel commandline (dolvm) which triggers a script within the initramfs - do you have to do the same thing with dracut? BillK Well, I dunno. I know how to find out tho. dale adds dolvm to his kernel line and is about to reboot If I ain't back in a few minutes, send help. . . quick. lol Also, see the other new thread. I think Walt has the same thing. BRB Dale :-) :-) I'm back. I tried and it did the same. Worth a shot tho. I noticed this. It mounts / ro then tries to start lvm. Then just a few lines later, it mounts / rw. So, it appears that it needs to mount / rw then start lvm. I dunno. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, Apr 3, 2012 at 10:12 PM, Dale rdalek1...@gmail.com wrote: Dale wrote: William Kenworthy wrote: On Tue, 2012-04-03 at 19:02 -0500, Dale wrote: Canek Peláez Valdés wrote: I do. I don't use LVM, so i didn't had neither USE=device-mapper, nor DRACUT_MODULES=lvm, so I add them. Then I tried to create my initramfs with LVM, and like in your case, it failed. Using the --debug option Dale, with genkernel you have to tell it to start LVM on the kernel commandline (dolvm) which triggers a script within the initramfs - do you have to do the same thing with dracut? BillK Well, I dunno. I know how to find out tho. dale adds dolvm to his kernel line and is about to reboot If I ain't back in a few minutes, send help. . . quick. lol Also, see the other new thread. I think Walt has the same thing. BRB Dale :-) :-) I'm back. I tried and it did the same. Worth a shot tho. I noticed this. It mounts / ro then tries to start lvm. Then just a few lines later, it mounts / rw. So, it appears that it needs to mount / rw then start lvm. I dunno. Dale, could yo please add again rd.debug to your kernel command line, boot with the initramfs, and post the output from dmesg (without you manually mounting your LVM volume)? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Canek Peláez Valdés wrote: SNIP I'm a little confused: you log in KDE as a regular user, open a Konsole, type su -, and what happens? What do you mean with Konsole won't even try to come up? In the shell that Krusader provides (which I assume you run as a regular user), what it's the result of which su? And also, what happens when (inside the shell from Krusader) you run /bin/su? If not for the fact that you say that in a virtual console su works, I would be willing to suggest that your initramfs never does the switch_root, and so you end up with the minimal / from the initramfs, and your normal /usr. That would be beyond bizarre, but if you *can* use su in a virtual console, then it should be there. I usally log in in GNOME, open a gnome-terminal, and set a fixed number of tabs in gnome-terminal where I su -, and work as root in there. I also can run an X11 program as root with su -lc /usr/bin/gedit, but I almost never do that (although it works; I just checked). I don't think I understand how do you use su. Could you explain it to me, please? One last thing: create a directory /tmp/whatever, and inside it unpack your initramfs: zcat /boot/init-thingie | cpio -i Could you do a ls -R /tmp/whatever so we can see what actually ends up in yout initramfs? Regards. Actually, I log into KDE as a user and when Konsole opens, it asks for the root password. I have the KDE session saved so it opens all this on its own. Anyway, since I have it set that way, Konsole never opens, I assume because it can't find the su command. I have been doing it this way since back in the KDE3 days. It has never done this before. I finally got around to rebooting to check on this, hence the delay in replying, and found this in the boot up process, the stuff that scrolls up the screen. I'm having to type this in since it is NOT in dmesg or the logs but just printed on the screen. dracut: switching root switch_root: failed to mount moving /dev to /sysroot/dev: Invaild argument switch_root: forcing unmount of /dev switch_root: failed to unlink dev: Directory not empty INIT: version 2.88 booting Keep in mind, the three middle lines with the problems are NOT shown in dmesg, messages or anywhere else but the screen. I had to boot with nox to even see this. This is what ticks me on this mess. With the way it logs things, you better hope you got video buffer to scroll up with or you don't get to see the failure. Also, while booted with the init thingy, I made sure the real / partition was mounted. It shows sda3 was mounted and based on the space used, I believe it. I got to clean out some old kernels pretty soon. ;-) I'm attaching the results from the ls command. It's a bit lengthy. o_O Thanks. Sorry for the delay. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n root@fireball /tmp/whatever # ls -R /tmp/whatever /tmp/whatever: total 22 drwxr-xr-x 15 root root 432 Apr 2 02:33 . drwxrwxrwt 10 root root 376 Apr 2 02:32 .. drwxr-xr-x 2 root root 576 Apr 2 02:33 bin drwxr-xr-x 2 root root48 Apr 2 02:33 dev drwxr-xr-x 7 root root 432 Apr 2 02:33 etc -rwxr-xr-x 1 root root 12622 Apr 2 02:33 init lrwxrwxrwx 1 root root 5 Apr 2 02:33 lib - lib64 drwxr-xr-x 5 root root 1072 Apr 2 02:33 lib64 drwxr-xr-x 2 root root48 Apr 2 02:33 proc drwxr-xr-x 2 root root48 Apr 2 02:33 root drwxr-xr-x 5 root root 128 Apr 2 02:33 run drwxr-xr-x 2 root root 440 Apr 2 02:33 sbin -rwxr-xr-x 1 root root 2547 Apr 2 02:33 shutdown drwxr-xr-x 2 root root48 Apr 2 02:33 sys drwxr-xr-x 2 root root48 Apr 2 02:33 sysroot drwxr-xr-x 2 root root48 Apr 2 02:33 tmp drwxr-xr-x 6 root root 144 Apr 2 02:33 usr drwxr-xr-x 3 root root 120 Apr 2 02:33 var /tmp/whatever/bin: total 1313 drwxr-xr-x 2 root root576 Apr 2 02:33 . drwxr-xr-x 15 root root432 Apr 2 02:33 .. -rwxr-xr-x 1 root root 31024 Apr 2 02:33 basename -rwxr-xr-x 1 root root 55840 Apr 2 02:33 cat -rwxr-xr-x 1 root root 35216 Apr 2 02:33 chroot -rwxr-xr-x 1 root root 113440 Apr 2 02:33 cp -rwxr-xr-x 1 root root 109688 Apr 2 02:33 dash -rwxr-xr-x 1 root root 22736 Apr 2 02:33 dmesg -rwxr-xr-x 1 root root 55776 Apr 2 02:33 ln -rwxr-xr-x 1 root root 113872 Apr 2 02:33 ls -rwxr-xr-x 1 root root 55760 Apr 2 02:33 mkdir -rwxr-xr-x 1 root root 35120 Apr 2 02:33 mkfifo -rwxr-xr-x 1 root root 39248 Apr 2 02:33 mknod -rws--x--x 1 root root 102984 Apr 2 02:33 mount -rwxr-xr-x 1 root root 101120 Apr 2 02:33 mv lrwxrwxrwx 1 root root 16 Apr 2 02:33 pidof - ../sbin/killall5 -rwxr-xr-x 1 root root 47520 Apr 2 02:33 readlink -rwxr-xr-x 1 root root 63984 Apr 2 02:33 rm -rwxr-xr-x 1 root root 134504 Apr 2 02:33 sed lrwxrwxrwx 1 root root 4 Apr 2 02:33 sh - dash -rwxr-xr-x 1 root root 35120
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Mon, Apr 2, 2012 at 2:41 AM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: SNIP I'm a little confused: you log in KDE as a regular user, open a Konsole, type su -, and what happens? What do you mean with Konsole won't even try to come up? In the shell that Krusader provides (which I assume you run as a regular user), what it's the result of which su? And also, what happens when (inside the shell from Krusader) you run /bin/su? If not for the fact that you say that in a virtual console su works, I would be willing to suggest that your initramfs never does the switch_root, and so you end up with the minimal / from the initramfs, and your normal /usr. That would be beyond bizarre, but if you *can* use su in a virtual console, then it should be there. I usally log in in GNOME, open a gnome-terminal, and set a fixed number of tabs in gnome-terminal where I su -, and work as root in there. I also can run an X11 program as root with su -lc /usr/bin/gedit, but I almost never do that (although it works; I just checked). I don't think I understand how do you use su. Could you explain it to me, please? One last thing: create a directory /tmp/whatever, and inside it unpack your initramfs: zcat /boot/init-thingie | cpio -i Could you do a ls -R /tmp/whatever so we can see what actually ends up in yout initramfs? Regards. Actually, I log into KDE as a user and when Konsole opens, it asks for the root password. I have the KDE session saved so it opens all this on its own. Anyway, since I have it set that way, Konsole never opens, I assume because it can't find the su command. I have been doing it this way since back in the KDE3 days. It has never done this before. Oh, I see; so you always use an X terminal as a root session. You never use a terminal as a regular user? I have never been able to do that. I finally got around to rebooting to check on this, hence the delay in replying, and found this in the boot up process, the stuff that scrolls up the screen. I'm having to type this in since it is NOT in dmesg or the logs but just printed on the screen. dracut: switching root switch_root: failed to mount moving /dev to /sysroot/dev: Invaild argument switch_root: forcing unmount of /dev switch_root: failed to unlink dev: Directory not empty INIT: version 2.88 booting Do you have /dev listed in your fstab? Actually, can you show us your /etc/fstab file? Keep in mind, the three middle lines with the problems are NOT shown in dmesg, messages or anywhere else but the screen. I had to boot with nox to even see this. This is what ticks me on this mess. With the way it logs things, you better hope you got video buffer to scroll up with or you don't get to see the failure. Add this to your kernel command line: rd.debug rd.udev.debug Also, remove quiet and splash (if any) from the kernel command line. All this info is in the dracut man pages: man dracut man dracut.cmdline Also, while booted with the init thingy, I made sure the real / partition was mounted. It shows sda3 was mounted and based on the space used, I believe it. I got to clean out some old kernels pretty soon. ;-) Yeah, but it is mounted as it should? As I said last mail, could you check if in the shell that Krusader provides, what it's the result of which su? And also, what happens when (inside the shell from Krusader) you run /bin/su? Also, an ls -l /bin/su would be helpful (even from the virtual console: Ctrl+Alt+F1); it may be a permissions related thing. I think you can make that ls /bin/su; it seems that you have ls aliased to ls -l. The listing of your initramfs seems fine; therefore, probably the problem is elsewhere. Again, please show us your fstab, and lets also see your kernel command line (in either GRUB, GRUB2 or LILO, whichever you use). And, I repeat, if you want to see the dracut output in dmesg, add the following to your kernel command line: rd.debug rd.udev.debug and remove splash and quiet from it, if they are set. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Canek Peláez Valdés wrote: On Mon, Apr 2, 2012 at 2:41 AM, Dale rdalek1...@gmail.com wrote: SNIP Actually, I log into KDE as a user and when Konsole opens, it asks for the root password. I have the KDE session saved so it opens all this on its own. Anyway, since I have it set that way, Konsole never opens, I assume because it can't find the su command. I have been doing it this way since back in the KDE3 days. It has never done this before. Oh, I see; so you always use an X terminal as a root session. You never use a terminal as a regular user? I have never been able to do that. It is rare that I login as a user then su to root in Console. I do that all the time tho when in KDE. KDE no longer allows a person to login as root and I think it is a good idea as well. So, when I need to emerge something, edit a config file or do other things as root, then su or kdesu comes in handy. ;-) I am able to open about anything as root if needed. Konsole and some sort of file manager, Konqueror or Krusaderm is my biggest tools. I finally got around to rebooting to check on this, hence the delay in replying, and found this in the boot up process, the stuff that scrolls up the screen. I'm having to type this in since it is NOT in dmesg or the logs but just printed on the screen. dracut: switching root switch_root: failed to mount moving /dev to /sysroot/dev: Invaild argument switch_root: forcing unmount of /dev switch_root: failed to unlink dev: Directory not empty INIT: version 2.88 booting Do you have /dev listed in your fstab? Actually, can you show us your /etc/fstab file? LABEL=boot /boot ext2defaults1 2 LABEL=root / reiserfsdefaults0 1 LABEL=swap noneswapsw 0 0 LABEL=var /varext3defaults0 2 LABEL=portage /usr/portageext3defaults0 2 LABEL=home /home reiserfsdefaults0 2 LABEL=data /data ext4defaults0 2 tmpfs /var/tmp/portage tmpfs noatime 0 0 shm /dev/shmtmpfs nodev,nosuid,noexec 0 0 I have never had /dev in fstab that I recall. I also removed all the things that were commented out since they should be ignored anyway. I have a lot of old lines that are no longer needed, CD drive, old partitions and such. Keep in mind, the three middle lines with the problems are NOT shown in dmesg, messages or anywhere else but the screen. I had to boot with nox to even see this. This is what ticks me on this mess. With the way it logs things, you better hope you got video buffer to scroll up with or you don't get to see the failure. Add this to your kernel command line: rd.debug rd.udev.debug Got that added. Let me know what to look for. Right now I plan to use nox so that I can look for myself, since boo boos are not logged to dmesg or messages. Also, remove quiet and splash (if any) from the kernel command line. All this info is in the dracut man pages: man dracut man dracut.cmdline I don't use the quiet or the splash stuff. I like it simple remember? I watch the stuff scroll up and that is how I saw the errors posted. If I wasn't watching real close, I would have never noticed them since I was using dmesg, messages and grep. Also, while booted with the init thingy, I made sure the real / partition was mounted. It shows sda3 was mounted and based on the space used, I believe it. I got to clean out some old kernels pretty soon. ;-) Yeah, but it is mounted as it should? As I said last mail, could you check if in the shell that Krusader provides, what it's the result of which su? And also, what happens when (inside the shell from Krusader) you run /bin/su? Also, an ls -l /bin/su would be helpful (even from the virtual console: Ctrl+Alt+F1); it may be a permissions related thing. I think you can make that ls /bin/su; it seems that you have ls aliased to ls -l. I have ls aliased to ls -al. You noticed huh? lol I can't show that because it won't let me get that far. When I tell Krusader to open as root, a pop up window comes up and asks for the root password. When I type in the password, it complains about su not being in the path or missing then goes away. So, I can't post that one. That said, I did a mount some file and then did the same while booted without the init thingy. Here it is then I'll explain. Take note of the / partition which is sda3 here: rootfs / rootfs rw 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Mon, Apr 2, 2012 at 2:54 PM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Mon, Apr 2, 2012 at 2:41 AM, Dale rdalek1...@gmail.com wrote: SNIP Actually, I log into KDE as a user and when Konsole opens, it asks for the root password. I have the KDE session saved so it opens all this on its own. Anyway, since I have it set that way, Konsole never opens, I assume because it can't find the su command. I have been doing it this way since back in the KDE3 days. It has never done this before. Oh, I see; so you always use an X terminal as a root session. You never use a terminal as a regular user? I have never been able to do that. It is rare that I login as a user then su to root in Console. I do that all the time tho when in KDE. KDE no longer allows a person to login as root and I think it is a good idea as well. So, when I need to emerge something, edit a config file or do other things as root, then su or kdesu comes in handy. ;-) I am able to open about anything as root if needed. Konsole and some sort of file manager, Konqueror or Krusaderm is my biggest tools. I finally got around to rebooting to check on this, hence the delay in replying, and found this in the boot up process, the stuff that scrolls up the screen. I'm having to type this in since it is NOT in dmesg or the logs but just printed on the screen. dracut: switching root switch_root: failed to mount moving /dev to /sysroot/dev: Invaild argument switch_root: forcing unmount of /dev switch_root: failed to unlink dev: Directory not empty INIT: version 2.88 booting Do you have /dev listed in your fstab? Actually, can you show us your /etc/fstab file? LABEL=boot /boot ext2 defaults 1 2 LABEL=root / reiserfs defaults 0 1 LABEL=swap none swap sw 0 0 LABEL=var /var ext3 defaults 0 2 LABEL=portage /usr/portage ext3 defaults 0 2 LABEL=home /home reiserfs defaults 0 2 LABEL=data /data ext4 defaults 0 2 tmpfs /var/tmp/portage tmpfs noatime 0 0 shm /dev/shm tmpfs nodev,nosuid,noexec 0 0 I have never had /dev in fstab that I recall. I also removed all the things that were commented out since they should be ignored anyway. I have a lot of old lines that are no longer needed, CD drive, old partitions and such. Keep in mind, the three middle lines with the problems are NOT shown in dmesg, messages or anywhere else but the screen. I had to boot with nox to even see this. This is what ticks me on this mess. With the way it logs things, you better hope you got video buffer to scroll up with or you don't get to see the failure. Add this to your kernel command line: rd.debug rd.udev.debug Got that added. Let me know what to look for. Right now I plan to use nox so that I can look for myself, since boo boos are not logged to dmesg or messages. Also, remove quiet and splash (if any) from the kernel command line. All this info is in the dracut man pages: man dracut man dracut.cmdline I don't use the quiet or the splash stuff. I like it simple remember? I watch the stuff scroll up and that is how I saw the errors posted. If I wasn't watching real close, I would have never noticed them since I was using dmesg, messages and grep. Also, while booted with the init thingy, I made sure the real / partition was mounted. It shows sda3 was mounted and based on the space used, I believe it. I got to clean out some old kernels pretty soon. ;-) Yeah, but it is mounted as it should? As I said last mail, could you check if in the shell that Krusader provides, what it's the result of which su? And also, what happens when (inside the shell from Krusader) you run /bin/su? Also, an ls -l /bin/su would be helpful (even from the virtual console: Ctrl+Alt+F1); it may be a permissions related thing. I think you can make that ls /bin/su; it seems that you have ls aliased to ls -l. I have ls aliased to ls -al. You noticed huh? lol I can't show that because it won't let me get that far. When I tell Krusader to open as root, a pop up window comes up and asks for the root password. When I type in the password, it complains about su not being in the path or missing then goes away. So, I can't post that one. That said, I did a mount some file and then did the same while booted without the init thingy. Here it is then I'll explain. Take note of the / partition which is sda3 here: rootfs / rootfs rw 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0 tmpfs
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Canek Peláez Valdés wrote: SNIP Well damn. Why you do not have devtmpfs? In all the machines I have access to (with or without initramfs, with either systemd or OpenRC), they have devtmps: devtmpfs on /dev type devtmpfs (rw,nosuid,relatime,size=2023140k,nr_inodes=505785,mode=755) devtmpfs on /dev type devtmpfs (rw,nosuid,relatime,size=506680k,nr_inodes=126670,mode=755) devtmpfs on /dev type devtmpfs (rw,nosuid,relatime,size=1939288k,nr_inodes=484822,mode=755) devtmpfs on /dev type devtmpfs (rw,relatime,size=257224k,nr_inodes=64306,mode=755) The one with OpenRC, no initramfs I don't see that one in your mount output. It seems kinda relevant, I think. Please, can you attach your /boot/grub/grub.cfg file? I still haven't seen the kernel command line, and I suppose that it's relevant. Also, I know it's a lot, but could you please include your kernel /usr/src/linux/.config file? Both dracut and udev need some specific kernel config options that maybe you don't have. Regards. Here is my grub lines: title=Initramfs-new_kernel root (hd0,0) kernel /boot/bzImage-3.2.11-1 root=/dev/sda3 init=/sbin/init rd.debug rd.udev.debug initrd /initramfs-3.2.11.img title Gentoo kernel (hd0,0)/bzImage-3.2.11-1 root=/dev/sda3 acpi_enforce_resources=lax raid=noautodetect iommu=noaperture The stuff on the end without the init thingy was added to make sure gkrellm worked. I think it is fixed now and can be removed but I just haven't done it yet. I added that debug stuff to the line for the init thngy but have not booted it yet. Now what? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Mon, Apr 2, 2012 at 4:21 PM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: SNIP Well damn. Why you do not have devtmpfs? In all the machines I have access to (with or without initramfs, with either systemd or OpenRC), they have devtmps: devtmpfs on /dev type devtmpfs (rw,nosuid,relatime,size=2023140k,nr_inodes=505785,mode=755) devtmpfs on /dev type devtmpfs (rw,nosuid,relatime,size=506680k,nr_inodes=126670,mode=755) devtmpfs on /dev type devtmpfs (rw,nosuid,relatime,size=1939288k,nr_inodes=484822,mode=755) devtmpfs on /dev type devtmpfs (rw,relatime,size=257224k,nr_inodes=64306,mode=755) The one with OpenRC, no initramfs I don't see that one in your mount output. It seems kinda relevant, I think. Please, can you attach your /boot/grub/grub.cfg file? I still haven't seen the kernel command line, and I suppose that it's relevant. Also, I know it's a lot, but could you please include your kernel /usr/src/linux/.config file? Both dracut and udev need some specific kernel config options that maybe you don't have. Regards. Here is my grub lines: title=Initramfs-new_kernel root (hd0,0) kernel /boot/bzImage-3.2.11-1 root=/dev/sda3 init=/sbin/init rd.debug rd.udev.debug initrd /initramfs-3.2.11.img title Gentoo kernel (hd0,0)/bzImage-3.2.11-1 root=/dev/sda3 acpi_enforce_resources=lax raid=noautodetect iommu=noaperture The stuff on the end without the init thingy was added to make sure gkrellm worked. I think it is fixed now and can be removed but I just haven't done it yet. I added that debug stuff to the line for the init thngy but have not booted it yet. Why do you have /boot/bzImage-3.2.11-1 in the initramfs kernel, but (hd0,0)/bzImage-3.2.11-1 in the other one? You have /boot in another partition, so in both cases you should have something similar to root (hd0,0) kernel (hd0,1)/bzImage-3.2.11-1 ... isn't? (where (hd0,1) is your /boot partition, since you do use labels, I don't know the exact number). Could it be possible that you are booting with an older kernel when using the initramfs entry without noticing it? Can you umount /boot in your machine and see if there is a kernel in there, and if it's different from the one in the actual /boot partition? In any case, the two grub entries are certainly not identical besides the initrd line (maybe they should be?). Also, can a have a look at your /usr/src/linux/.config file? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Mon, 02 Apr 2012 02:41:12 -0500, Dale wrote: switch_root: failed to mount moving /dev to /sysroot/dev: Invaild argument Do you have DEVTMPFS support in your kernel? What do you get from zgrep DEVTMP /proc/config.gz -- Neil Bothwick After all is said and done let there not be more said than done. signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Neil Bothwick wrote: zgrep DEVTMP /proc/config.gz Ooops, it sort of snipped a bit much. lol Here you go: root@fireball / # zgrep DEVTMP /proc/config.gz # CONFIG_DEVTMPFS is not set root@fireball / # Looks like a nope to me. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Mon, Apr 2, 2012 at 5:21 PM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: zgrep DEVTMP /proc/config.gz Ooops, it sort of snipped a bit much. lol Here you go: root@fireball / # zgrep DEVTMP /proc/config.gz # CONFIG_DEVTMPFS is not set root@fireball / # Looks like a nope to me. ;-) That was the reason for asking for your /usr/src/linux/.config file. The udev ebuild ask for: CONFIG_CHECK=~BLK_DEV_BSG ~DEVTMPFS ~HOTPLUG ~INOTIFY_USER ~NET ~PROC_FS ~SIGNALFD ~SYSFS ~!IDE ~!SYSFS_DEPRECATED ~!SYSFS_DEPRECATED_V2 The dracut ebuild ask for: CONFIG_CHECK=~BLK_DEV_INITRD ~DEVTMPFS ~MODULES So please check that you have all those options (and don't have the ones with !), recompile your kernel, and reboot. Also, the divergence between /boot/kernel... and (hd0,0)/kernel... in your grub could be causing funny things. Check that also. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Canek Peláez Valdés wrote: On Mon, Apr 2, 2012 at 4:21 PM, Dale rdalek1...@gmail.com wrote: Here is my grub lines: title=Initramfs-new_kernel root (hd0,0) kernel /boot/bzImage-3.2.11-1 root=/dev/sda3 init=/sbin/init rd.debug rd.udev.debug initrd /initramfs-3.2.11.img title Gentoo kernel (hd0,0)/bzImage-3.2.11-1 root=/dev/sda3 acpi_enforce_resources=lax raid=noautodetect iommu=noaperture The stuff on the end without the init thingy was added to make sure gkrellm worked. I think it is fixed now and can be removed but I just haven't done it yet. I added that debug stuff to the line for the init thngy but have not booted it yet. Why do you have /boot/bzImage-3.2.11-1 in the initramfs kernel, but (hd0,0)/bzImage-3.2.11-1 in the other one? You have /boot in another partition, so in both cases you should have something similar to root (hd0,0) kernel (hd0,1)/bzImage-3.2.11-1 ... isn't? (where (hd0,1) is your /boot partition, since you do use labels, I don't know the exact number). Could it be possible that you are booting with an older kernel when using the initramfs entry without noticing it? Can you umount /boot in your machine and see if there is a kernel in there, and if it's different from the one in the actual /boot partition? In any case, the two grub entries are certainly not identical besides the initrd line (maybe they should be?). Also, can a have a look at your /usr/src/linux/.config file? Regards. I unmounted /boot and there was nothing there. I'll remove that extra /boot but I doubt it will matter. After all, it just symlinks to itself. At least mine does here anyway. ;-) As to the kernel, it boots the exact same kernel. That is the only kernel I have for that version. If grub was pointing to anything else, it wouldn't be there to even try to boot. What should I add to fstab for /dev? This is a desktopy rig. Thanks. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Canek Peláez Valdés wrote: On Mon, Apr 2, 2012 at 5:21 PM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: zgrep DEVTMP /proc/config.gz Ooops, it sort of snipped a bit much. lol Here you go: root@fireball / # zgrep DEVTMP /proc/config.gz # CONFIG_DEVTMPFS is not set root@fireball / # Looks like a nope to me. ;-) That was the reason for asking for your /usr/src/linux/.config file. The udev ebuild ask for: CONFIG_CHECK=~BLK_DEV_BSG ~DEVTMPFS ~HOTPLUG ~INOTIFY_USER ~NET ~PROC_FS ~SIGNALFD ~SYSFS ~!IDE ~!SYSFS_DEPRECATED ~!SYSFS_DEPRECATED_V2 The dracut ebuild ask for: CONFIG_CHECK=~BLK_DEV_INITRD ~DEVTMPFS ~MODULES So please check that you have all those options (and don't have the ones with !), recompile your kernel, and reboot. Also, the divergence between /boot/kernel... and (hd0,0)/kernel... in your grub could be causing funny things. Check that also. Regards. OK. I hate modules. Can they be built into the kernel? The only module I have is nvidia for my video card. Also, if you can put this in one email, what about the /dev line in fstab? I didn't check the ebuild but I don't recall seeing anything when I emerged dracut either. o_O Maybe we are on to something here. ^_O Thanks Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Apr 3, 2012 7:26 AM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Mon, Apr 2, 2012 at 5:21 PM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: zgrep DEVTMP /proc/config.gz Ooops, it sort of snipped a bit much. lol Here you go: root@fireball / # zgrep DEVTMP /proc/config.gz # CONFIG_DEVTMPFS is not set root@fireball / # Looks like a nope to me. ;-) That was the reason for asking for your /usr/src/linux/.config file. The udev ebuild ask for: CONFIG_CHECK=~BLK_DEV_BSG ~DEVTMPFS ~HOTPLUG ~INOTIFY_USER ~NET ~PROC_FS ~SIGNALFD ~SYSFS ~!IDE ~!SYSFS_DEPRECATED ~!SYSFS_DEPRECATED_V2 The dracut ebuild ask for: CONFIG_CHECK=~BLK_DEV_INITRD ~DEVTMPFS ~MODULES So please check that you have all those options (and don't have the ones with !), recompile your kernel, and reboot. Also, the divergence between /boot/kernel... and (hd0,0)/kernel... in your grub could be causing funny things. Check that also. Regards. OK. I hate modules. Can they be built into the kernel? The only module I have is nvidia for my video card. Also, if you can put this in one email, what about the /dev line in fstab? I didn't check the ebuild but I don't recall seeing anything when I emerged dracut either. o_O Maybe we are on to something here. ^_O AFAIK DEVTMPFS is not a module. You either turn it on or off. Of course, you'll need a whole-kernel compile, but that's it. If you use menuconfig, IIRC there's another option right under DEVTMPFS' one that offers to mount devtmpfs on boot. If you turn that on, you *might* get away without a /dev in fstab. Rgds,
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Mon, Apr 2, 2012 at 7:19 PM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Mon, Apr 2, 2012 at 5:21 PM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: zgrep DEVTMP /proc/config.gz Ooops, it sort of snipped a bit much. lol Here you go: root@fireball / # zgrep DEVTMP /proc/config.gz # CONFIG_DEVTMPFS is not set root@fireball / # Looks like a nope to me. ;-) That was the reason for asking for your /usr/src/linux/.config file. The udev ebuild ask for: CONFIG_CHECK=~BLK_DEV_BSG ~DEVTMPFS ~HOTPLUG ~INOTIFY_USER ~NET ~PROC_FS ~SIGNALFD ~SYSFS ~!IDE ~!SYSFS_DEPRECATED ~!SYSFS_DEPRECATED_V2 The dracut ebuild ask for: CONFIG_CHECK=~BLK_DEV_INITRD ~DEVTMPFS ~MODULES So please check that you have all those options (and don't have the ones with !), recompile your kernel, and reboot. Also, the divergence between /boot/kernel... and (hd0,0)/kernel... in your grub could be causing funny things. Check that also. Regards. OK. I hate modules. Can they be built into the kernel? The only module I have is nvidia for my video card. MODULES is only for the kernel to be *able* to load modules, not to *make* modules. If you use nvidia.ko, you must already have it. All the options can be compiled into the kernel; I had them like that: $ grep BLK_DEV_BSG\\|DEVTMPFS\\|HOTPLUG\\|INOTIFY_USER\\|NET=\\|PROC_FS\\|SIGNALFD\\|SYSFS /usr/src/linux/.config # CONFIG_SYSFS_DEPRECATED is not set CONFIG_HOTPLUG=y CONFIG_SIGNALFD=y CONFIG_BLK_DEV_BSG=y # CONFIG_BLK_DEV_BSGLIB is not set # CONFIG_MEMORY_HOTPLUG is not set CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ACPI_HOTPLUG_CPU=y # CONFIG_HOTPLUG_PCI is not set CONFIG_NET=y CONFIG_INET=y CONFIG_WIRELESS_EXT_SYSFS=y CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y # CONFIG_SCSI_PROC_FS is not set # CONFIG_ISCSI_BOOT_SYSFS is not set CONFIG_ETHERNET=y CONFIG_USB_USBNET=y CONFIG_RTC_INTF_SYSFS=y # CONFIG_DMI_SYSFS is not set CONFIG_INOTIFY_USER=y CONFIG_PROC_FS=y CONFIG_SYSFS=y Also, if you can put this in one email, what about the /dev line in fstab? /dev should not be in /etc/fstab; but since you had this error: switch_root: failed to mount moving /dev to /sysroot/dev: Invaild argument switch_root: forcing unmount of /dev switch_root: failed to unlink dev: Directory not empty I thought that it was maybe because you had /dev on fstab. Now we know it was because you didn't compile DEVTMPFS in your kernel. I didn't check the ebuild but I don't recall seeing anything when I emerged dracut either. o_O Maybe we are on to something here. ^_O The messages appear for sure; CONFIG_CHECK is defined in /usr/portage/eclass/linux-info.eclass, and if a config option is missing, a non-fatal warning will appear. If you have them, check your emerge logs: cat /var/log/portage/sys-fs\:udev-* | less You can look for the string: * Checking for suitable kernel configuration options... [ ok ] (Obviously that's in my case). You could also reemerge udev and dracut; if you haven't changed your kernel config options, they will complain loudly about it. I think that will solve the mistery; however, we will not know until you reboot and actually test it (after recompiling your kernel, of course). Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Mon, Apr 2, 2012 at 7:35 PM, Pandu Poluan pa...@poluan.info wrote: On Apr 3, 2012 7:26 AM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Mon, Apr 2, 2012 at 5:21 PM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: zgrep DEVTMP /proc/config.gz Ooops, it sort of snipped a bit much. lol Here you go: root@fireball / # zgrep DEVTMP /proc/config.gz # CONFIG_DEVTMPFS is not set root@fireball / # Looks like a nope to me. ;-) That was the reason for asking for your /usr/src/linux/.config file. The udev ebuild ask for: CONFIG_CHECK=~BLK_DEV_BSG ~DEVTMPFS ~HOTPLUG ~INOTIFY_USER ~NET ~PROC_FS ~SIGNALFD ~SYSFS ~!IDE ~!SYSFS_DEPRECATED ~!SYSFS_DEPRECATED_V2 The dracut ebuild ask for: CONFIG_CHECK=~BLK_DEV_INITRD ~DEVTMPFS ~MODULES So please check that you have all those options (and don't have the ones with !), recompile your kernel, and reboot. Also, the divergence between /boot/kernel... and (hd0,0)/kernel... in your grub could be causing funny things. Check that also. Regards. OK. I hate modules. Can they be built into the kernel? The only module I have is nvidia for my video card. Also, if you can put this in one email, what about the /dev line in fstab? I didn't check the ebuild but I don't recall seeing anything when I emerged dracut either. o_O Maybe we are on to something here. ^_O AFAIK DEVTMPFS is not a module. You either turn it on or off. Of course, you'll need a whole-kernel compile, but that's it. If you use menuconfig, IIRC there's another option right under DEVTMPFS' one that offers to mount devtmpfs on boot. If you turn that on, you *might* get away without a /dev in fstab. Dale doesn't need /dev on fstab (nobody does); I only asked about it since I had no information about the dracut failure trying to mount /dev. Now I think we have enough information, and I hope that when Dale recompiles his kernel and reboots, everything will work. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Canek Peláez Valdés wrote: On Mon, Apr 2, 2012 at 7:19 PM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Mon, Apr 2, 2012 at 5:21 PM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: zgrep DEVTMP /proc/config.gz Ooops, it sort of snipped a bit much. lol Here you go: root@fireball / # zgrep DEVTMP /proc/config.gz # CONFIG_DEVTMPFS is not set root@fireball / # Looks like a nope to me. ;-) That was the reason for asking for your /usr/src/linux/.config file. The udev ebuild ask for: CONFIG_CHECK=~BLK_DEV_BSG ~DEVTMPFS ~HOTPLUG ~INOTIFY_USER ~NET ~PROC_FS ~SIGNALFD ~SYSFS ~!IDE ~!SYSFS_DEPRECATED ~!SYSFS_DEPRECATED_V2 The dracut ebuild ask for: CONFIG_CHECK=~BLK_DEV_INITRD ~DEVTMPFS ~MODULES So please check that you have all those options (and don't have the ones with !), recompile your kernel, and reboot. Also, the divergence between /boot/kernel... and (hd0,0)/kernel... in your grub could be causing funny things. Check that also. Regards. OK. I hate modules. Can they be built into the kernel? The only module I have is nvidia for my video card. MODULES is only for the kernel to be *able* to load modules, not to *make* modules. If you use nvidia.ko, you must already have it. All the options can be compiled into the kernel; I had them like that: $ grep BLK_DEV_BSG\\|DEVTMPFS\\|HOTPLUG\\|INOTIFY_USER\\|NET=\\|PROC_FS\\|SIGNALFD\\|SYSFS /usr/src/linux/.config # CONFIG_SYSFS_DEPRECATED is not set CONFIG_HOTPLUG=y CONFIG_SIGNALFD=y CONFIG_BLK_DEV_BSG=y # CONFIG_BLK_DEV_BSGLIB is not set # CONFIG_MEMORY_HOTPLUG is not set CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ACPI_HOTPLUG_CPU=y # CONFIG_HOTPLUG_PCI is not set CONFIG_NET=y CONFIG_INET=y CONFIG_WIRELESS_EXT_SYSFS=y CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y # CONFIG_SCSI_PROC_FS is not set # CONFIG_ISCSI_BOOT_SYSFS is not set CONFIG_ETHERNET=y CONFIG_USB_USBNET=y CONFIG_RTC_INTF_SYSFS=y # CONFIG_DMI_SYSFS is not set CONFIG_INOTIFY_USER=y CONFIG_PROC_FS=y CONFIG_SYSFS=y Also, if you can put this in one email, what about the /dev line in fstab? /dev should not be in /etc/fstab; but since you had this error: switch_root: failed to mount moving /dev to /sysroot/dev: Invaild argument switch_root: forcing unmount of /dev switch_root: failed to unlink dev: Directory not empty I thought that it was maybe because you had /dev on fstab. Now we know it was because you didn't compile DEVTMPFS in your kernel. I didn't check the ebuild but I don't recall seeing anything when I emerged dracut either. o_O Maybe we are on to something here. ^_O The messages appear for sure; CONFIG_CHECK is defined in /usr/portage/eclass/linux-info.eclass, and if a config option is missing, a non-fatal warning will appear. If you have them, check your emerge logs: cat /var/log/portage/sys-fs\:udev-* | less You can look for the string: * Checking for suitable kernel configuration options... [ ok ] (Obviously that's in my case). You could also reemerge udev and dracut; if you haven't changed your kernel config options, they will complain loudly about it. I think that will solve the mistery; however, we will not know until you reboot and actually test it (after recompiling your kernel, of course). Regards. I think I got it all sorted and am building a new kernel. It will have a -2 on the end instead of a -1. I'll test it in a bit. I got some things to prepare for tomorrow plus we have storms coming in tonight. The rain is already on the radar and it is a bit windy here. May take a bit before I reboot. Just depends. ;-) I'm hoping to get this sorted so I can then move on to more issues, and maybe a new thread. lol Will reply in a bit on what blows up. ROFL Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Canek Peláez Valdés wrote: On Mon, Apr 2, 2012 at 7:35 PM, Pandu Poluan pa...@poluan.info wrote: On Apr 3, 2012 7:26 AM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Mon, Apr 2, 2012 at 5:21 PM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: zgrep DEVTMP /proc/config.gz Ooops, it sort of snipped a bit much. lol Here you go: root@fireball / # zgrep DEVTMP /proc/config.gz # CONFIG_DEVTMPFS is not set root@fireball / # Looks like a nope to me. ;-) That was the reason for asking for your /usr/src/linux/.config file. The udev ebuild ask for: CONFIG_CHECK=~BLK_DEV_BSG ~DEVTMPFS ~HOTPLUG ~INOTIFY_USER ~NET ~PROC_FS ~SIGNALFD ~SYSFS ~!IDE ~!SYSFS_DEPRECATED ~!SYSFS_DEPRECATED_V2 The dracut ebuild ask for: CONFIG_CHECK=~BLK_DEV_INITRD ~DEVTMPFS ~MODULES So please check that you have all those options (and don't have the ones with !), recompile your kernel, and reboot. Also, the divergence between /boot/kernel... and (hd0,0)/kernel... in your grub could be causing funny things. Check that also. Regards. OK. I hate modules. Can they be built into the kernel? The only module I have is nvidia for my video card. Also, if you can put this in one email, what about the /dev line in fstab? I didn't check the ebuild but I don't recall seeing anything when I emerged dracut either. o_O Maybe we are on to something here. ^_O AFAIK DEVTMPFS is not a module. You either turn it on or off. Of course, you'll need a whole-kernel compile, but that's it. If you use menuconfig, IIRC there's another option right under DEVTMPFS' one that offers to mount devtmpfs on boot. If you turn that on, you *might* get away without a /dev in fstab. Dale doesn't need /dev on fstab (nobody does); I only asked about it since I had no information about the dracut failure trying to mount /dev. Now I think we have enough information, and I hope that when Dale recompiles his kernel and reboots, everything will work. Regards. Storm seems to have slowed down so Dale is about to reboot. Dale hopes this init thingy works too. crosses fingers, toes, eyes and anything else crossable I also saved the old line that works, just in case. This is me after all. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Mon, Apr 2, 2012 at 9:08 PM, Dale rdalek1...@gmail.com wrote: Dale wrote: I think I got it all sorted and am building a new kernel. It will have a -2 on the end instead of a -1. I'll test it in a bit. I got some things to prepare for tomorrow plus we have storms coming in tonight. The rain is already on the radar and it is a bit windy here. May take a bit before I reboot. Just depends. ;-) I'm hoping to get this sorted so I can then move on to more issues, and maybe a new thread. lol Will reply in a bit on what blows up. ROFL Dale :-) :-) Well, I rebooted. I'm also back to my old kernel. The new kernel broke all sorts of things. I thought about writing down the errors until I saw how many there was. It was PAGES of problems. It booted to a prompt tho. One thing I noticed, LVM failed. I have a drive that has LVM on it and it would not mount although LVM service was started. I even restarted it and it reported no errors when starting. I dunno. So, this appears to be nowhere close to fixed. Right now, this is on my nerves again. Let me know what you want me to post but right now, I'm going to go have a sit down. I'll count those things hanging from the ceiling or something. I can't recall what they call them but I count them sometimes. If I was eyeball to eyeball with the dev that started this, I could patent and new color of purple/blue. You know, hands around the neck and all. :/ I'm attaching the dmesg from the failed attempt. It's a whopper. I'm not sure all the errors are in there either. Here's grub line: title=Initramfs-new_kernel root (hd0,0) kernel /bzImage-3.2.11-2 root=/dev/sda3 init=/sbin/init rd.debug rd.udev.debug nox initrd /initramfs-3.2.11.img I also tried other settings for the root line but that was the only one that worked. Thoughts? Should I just switch and save myself the aggravation? Back to my hole. Actually, the initramfs finished without a single error: between [1.962007] dracut: + source_conf /etc/conf.d and [2.395576] dracut: Switching root there is not a single error. The initramfs did what it needed to do; the user space failed *after* initramfs switched root. Did you recreated the initramfs after the kernel recompilation? 1st rule of non-trivial initramfs: you need to recreate it everytime you change kernels. Which partition is the LVM one? /home or /data? Either way, either partition should not matter to boot the system correctly. We need to see the errors *after* the initramfs switched root; maybe you can delete /var/log/messages, reboot, and post it? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Dale wrote: So the init thingy is going to print all that stuff each time? Or is that the debug stuff you had me add to the grub line? Please say it is so. It's one reason I checked my email. I was counting and realized the debug stuff that was added may haver done all that. Taking a deep breath helped tho. ;-) I still want my hands on that neck tho. lol When I booted into the new kernel and got what I thought was errors, I did run dracut -H -f /boot/initthingy here and rebooted with it. When it got booted, I could not get LVM to work. It is /data that has LVM for now. I plan to add /usr and /var later on tho. The /data partition has my videos and such on it. I plan to reorganize all this under /home, which will be on LVM too, later on. Also, while I was booted in the new kernel, I re-emerged lvm2 and then restarted the service. Still a no go. Attaching kernel config file this time, since it could be the issue. Maybe I added something I shouldn't have? Got to get shower and such for tomorrow so back in a bit. No plans to count things right now. Dale :-) :-) OK. I notice this when I build the init thingy with dracut: root@fireball / # dracut -H -f /boot/init-thingy E: Dracut module lvm cannot be found. E: Dracut module lvm cannot be found. I: *** Including module: dash *** I: *** Including module: udev-rules *** I: Skipping udev rule: 50-udev.rules I: Skipping udev rule: 95-late.rules I: *** Including module: base *** I: *** Including module: fs-lib *** I: *** Including module: shutdown *** I: Skipping program kexec as it cannot be found and is flagged to be optional I: *** Including modules done *** I: Wrote /boot/init-thingy: I: -rw-r--r-- 1 root root 2406253 Apr 3 00:03 /boot/init-thingy root@fireball / # So, it is not able to find the lvm module and honestly, I didn't know there was one. Anyway, I googled and only found one reference on this and it has no fix for it. So, if I put /usr on lvm, how is dracut going to be able to find /usr? This is my current versions: root@fireball / # emerge -vp dracut lvm2 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ~] sys-fs/lvm2-2.02.95-r1 USE=lvm1 readline udev (-clvm) (-cman) (-selinux) -static -static-libs 0 kB [ebuild R ~] sys-kernel/dracut-017-r3 USE=device-mapper -debug -net (-selinux) DRACUT_MODULES=lvm -biosdevname -btrfs -caps -crypt -crypt-gpg -dmraid -dmsquash-live -gensplash -iscsi -livenet -mdraid -multipath -nbd -nfs -plymouth -ssh-client -syslog 0 kB Total: 2 packages (2 reinstalls), Size of downloads: 0 kB root@fireball / # I have tried all I know to try. I'm note sure what is broke now. If the init thingy is working, then I guess the new kernel is messing up lvm. Speaking of, I have to boot with my old kernel for lvm to work. It won't work with the kernel I built for the init thingy. I'm thinking there is a conflict somewhere. I just don't know where. Based on the fact the new kernel breaks whether I use a init thingy or not, I'm thinking kernel this time. Ideas? Thoughts? Making sense yet? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
* Dale rdalek1...@gmail.com [120329 17:39]: [..] I already tried making one from scratch and also making the one inside the kernel. Both belly flopped and left me with nothing but errors. It never even tried to leave the init thingy environment. I think I posted them a good long while back but no clue what they were know. I just moved on to what was supposed to be easy. Yea, right. :/ My concern is this, if it is this hard for me to get one working, if it ever breaks, I'm screwed. I know myself pretty well, if it breaks and I can't figure it out, I'll be looking for a install CD/DVD and fix it on a grand scale. This is how I got to Gentoo. I couldn't get Mandrake to work right and be stable, I switched. Well, it's supper time here. Maybe that will help, me at least. lol Dale Do you want to try again to make one from scratch? If you're not using LVM or RAID for root or /usr and you compile your filesystem into the kernel then it's very simple and should be about a five line (tops) init script (and even if those don't hold for you, it's not that much tougher.) If you spend the time now to do it yourself I think you'll find you have the tools and knowledge to track down any problems later. If you're willing to try again, I'm willing to work with you. If you can find your hand-rolled initramfs and the errors you were having we can figure it out. And for the record. I hate this whole /usr must be mounted in an initramfs or on /. It seems that all these arguments about bluetooth keyboards and such have it all exactly bass ackwards. If you have some flavor of hardware that isn't supported in the base kernel then you should be creating an initramfs for support. But I can't argue with people who donate their time getting to work on what they want to and supporting only what they want to. And I'm not ready to make and maintain an overlay that doesn't require this so it's time for me to stop gnashing my teeth and suck it up and get on with life. Todd P.S. - If you don't want to get an hand-rolled initramfs working, it would be interesting to see what an ls -lr /dev shows for the cases where everything works for you and where it doesn't.
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Wed, 28 Mar 2012 21:16:30 -0500, Dale wrote: It's not a blackbox, unlike a kernel or any other binary, it is a simple cpio archive that you can unpack and inspect. If you want total control, build your own, it is not rocket science. cough cough You sure about that? I have tried building one, then building it inside the kernel then using dracut. Still got issues. If not rocket science, what other degree does a person need? ROFL A degree in reading wiki pages help :P -- Neil Bothwick The facts, although interesting, are irrelevant. signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Hi, Mike. On Wed, Mar 28, 2012 at 12:24:14AM -0400, Mike Edenfield wrote: From: Alan Mackenzie [mailto:a...@muc.de] Hi, Alan. On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: On Tue, 27 Mar 2012 21:24:22 + Alan Mackenzie a...@muc.de wrote: Why is nobody else on this thread willing to take up its main point, the exact equivalence between the known, ugly, initramfs solution and the as yet half-baked idea of putting the same binaries into /sbin? Well, for one, the initramfs solution is not generally considered ugly except by a select vocal few who object to it on vague, unarticulated grounds. I'll articulate a few. (i) The initramfs involves having two copies of lots of software around. (ii) What's more, these two copies are often different, one being built with static libraries, the other with dynamic ones. (iii) This situation is not (as far as I know) yet handled by Portage, which means in building such software statically, you've got to save the dynamic version somewhere else whilst you're doing it. (iv) The initramfs requires a potentially long script to make it work. I think that qualifies the initramfs solution as ugly. That notwithstanding: The binaries on the initramfs are not always the same as the ones installed in the system; frequently they are statically linked versions, or stripped-down versions, or otherwise unsuitable for being used after the full system is booted. (Dracut, for example, forces you to add USE=static-libs to a lot of the packages it wants to put into your initramfs image.) Putting those binaries into the execution path of the system is a bad idea because you don't always them to run once the system has booted -- I want the full set of udev rules, not the bare handful that my initramfs has on it. My idea was for /sbin to vanish from $PATH just as soon as the boot had been completed; PATH gets set anyway on the initialisation of something or other, so this would happen automatically, just like the initramfs disappears when the switch_root is done. [ more criticism, a lot of which I accept. ] I think I have the elegant solution: that would be for the kernel to be able to mount several partitions at system initialisation rather than just the root partition. With this, all the issues we've been discussing simply wouldn't arise. I accept that this solution will never happen. Sadly. --Mike -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Thu, 29 Mar 2012 15:56:28 +, Alan Mackenzie wrote: Well, for one, the initramfs solution is not generally considered ugly except by a select vocal few who object to it on vague, unarticulated grounds. I'll articulate a few. (i) The initramfs involves having two copies of lots of software around. Lots? For most people busybox is enough! If you want encrypted filesystems on LVM over RAID that rises to a total of four executables. (ii) What's more, these two copies are often different, one being built with static libraries, the other with dynamic ones. (iii) This situation is not (as far as I know) yet handled by Portage, which means in building such software statically, you've got to save the dynamic version somewhere else whilst you're doing it. That's wrong. For example, LVM builds dynamic executable plus the lvm.static file for use in the initramfs. (iv) The initramfs requires a potentially long script to make it work. Mount /proc, /sys and /dev. Mount root Unmount /proc, /sys and /dev. switch_root I think that qualifies the initramfs solution as ugly. Only if you build the initramfs with USE=fud. I think I have the elegant solution: that would be for the kernel to be able to mount several partitions at system initialisation rather than just the root partition. With this, all the issues we've been discussing simply wouldn't arise. That's an excellent idea. I accept that this solution will never happen. Sadly. It's already happened here. My kernel mounts / and /usr thanks to the inbuilt initramfs -- Neil Bothwick I just bought a microwave fireplace... You can spend an evening in front of it in only eight minutes... signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Thu, Mar 29, 2012 at 12:35 PM, Neil Bothwick n...@digimed.co.uk wrote: On Thu, 29 Mar 2012 15:56:28 +, Alan Mackenzie wrote: Well, for one, the initramfs solution is not generally considered ugly except by a select vocal few who object to it on vague, unarticulated grounds. I'll articulate a few. (i) The initramfs involves having two copies of lots of software around. Lots? For most people busybox is enough! If you want encrypted filesystems on LVM over RAID that rises to a total of four executables. And anything they might conceivably link to. Not everything supports static linking. Don't forget boot-time X-based animation, too. That's an extraordinarily common feature of mainstream desktop distributions. And there will be other things, I'm sure. (ii) What's more, these two copies are often different, one being built with static libraries, the other with dynamic ones. (iii) This situation is not (as far as I know) yet handled by Portage, which means in building such software statically, you've got to save the dynamic version somewhere else whilst you're doing it. That's wrong. For example, LVM builds dynamic executable plus the lvm.static file for use in the initramfs. That's exactly what Alan just noted in (ii), but perhaps portage handles (iii) in the case of LVM. (iv) The initramfs requires a potentially long script to make it work. Mount /proc, /sys and /dev. Mount root Unmount /proc, /sys and /dev. switch_root Things look much simpler when you abstract away the details. You still have to manage lvm, mdraid and whatever else is necessary for mounting things. That's where 'potentially long' came from, I expect. I think that qualifies the initramfs solution as ugly. Only if you build the initramfs with USE=fud. FUD: Fear, uncertainty and doubt In short, three things which are important to rationally examine and deal with on a case-by-case basis. Fear of risk is healthy when trying to maintain something. Uncertainty is expected when you first launch into some brave, new world, and it's necessary to to learn things well enough to be able to rule out uncertain conditions. That's an intrinsic part of systemic stability. Doubt is another word for risk analysis. What are the chances this will fail, versus the chance that that will fail? What's the cost of each of these failures. -- :wq
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Evening, Neil. On Thu, Mar 29, 2012 at 05:35:35PM +0100, Neil Bothwick wrote: On Thu, 29 Mar 2012 15:56:28 +, Alan Mackenzie wrote: I think I have the elegant solution: that would be for the kernel to be able to mount several partitions at system initialisation rather than just the root partition. With this, all the issues we've been discussing simply wouldn't arise. That's an excellent idea. I accept that this solution will never happen. Sadly. It's already happened here. My kernel mounts / and /usr thanks to the inbuilt initramfs That's exactly what I didn't mean, and I think you might have been aware of that. What I did mean was being able to mount subsequent partitions by giving kernel parameters in the boot loader configuration file. Something like mount=8,3:/usr for mount /dev/sda3 /usr. This would avoid the need to spend any effort whatsoever on building an initramfs, yet /usr would be mounted early in boot. -- Neil Bothwick -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Thu, 29 Mar 2012 17:29:11 +, Alan Mackenzie wrote: It's already happened here. My kernel mounts / and /usr thanks to the inbuilt initramfs That's exactly what I didn't mean, and I think you might have been aware of that. Maybe, but it does fit your description. What I did mean was being able to mount subsequent partitions by giving kernel parameters in the boot loader configuration file. Something like mount=8,3:/usr for mount /dev/sda3 /usr. This would avoid the need to spend any effort whatsoever on building an initramfs, yet /usr would be mounted early in boot. That sounds like a simple and elegant idea, and the kernel already contains the code to mount filesystems. However, it doesn't handle dm-crypt or LVM and putting all that in the kernel could be more complex than putting the initramfs to do it in the kernel. However, if it could be made to work , it would be a neat approach. -- Neil Bothwick Master of all I survey (at the moment, empty pizza boxes) signature.asc Description: PGP signature
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Alan Mackenzie [mailto:a...@muc.de] Hi, Mike. On Wed, Mar 28, 2012 at 12:24:14AM -0400, Mike Edenfield wrote: From: Alan Mackenzie [mailto:a...@muc.de] Hi, Alan. On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: On Tue, 27 Mar 2012 21:24:22 + Alan Mackenzie a...@muc.de wrote: Why is nobody else on this thread willing to take up its main point, the exact equivalence between the known, ugly, initramfs solution and the as yet half-baked idea of putting the same binaries into /sbin? Well, for one, the initramfs solution is not generally considered ugly except by a select vocal few who object to it on vague, unarticulated grounds. I'll articulate a few. (i) The initramfs involves having two copies of lots of software around. (ii) What's more, these two copies are often different, one being built with static libraries, the other with dynamic ones. (iii) This situation is not (as far as I know) yet handled by Portage, which means in building such software statically, you've got to save the dynamic version somewhere else whilst you're doing it. (iv) The initramfs requires a potentially long script to make it work. My idea was for /sbin to vanish from $PATH just as soon as the boot had been completed; PATH gets set anyway on the initialisation of something or other, so this would happen automatically, just like the initramfs disappears when the switch_root is done. The criticisms you made about an initramfs are valid, and your basic point is correct: the ugliness of having a shadow /sbin is no worse than the ugliness of an initramfs. I admit that much of my criticism here is not of the idea but of trying to come up with a working implementation. The major benefit of an initramfs solution is that it fits into the existing Linux boot process with minimal impact: all of the ugliness you pointed out vanishes as soon as it has completed its work, and the existing /sbin/init startup code is launched exactly as it would be without an initramfs. Your process would require either changing that existing /sbin/init process, or changing the steps the kernel takes on startup, in ways that I can't articulate because I haven't gone through the exercise of making it work. Taking /sbin out of the path, though works for me. As I understand it, /sbin *used* to be for static binaries, and only later did it retroactively become system binaries, which is silly. That's what DAC is for. The only benefit of a separate /bin and /sbin is to have different binaries with the same name in both places, which is just begging for trouble. Your approach actually seems to be bringing /sbin back to its roots. :) I can think of a few useful options, though; perhaps what you're calling /sbin is actually /boot/bin; like now, /boot is rarely mounted once the live system comes up. Perhaps the kernel is configured to look for and run a /boot/bin/init before it tries to mount it's rootfs. You are basically replicating the initramfs solution, just on the boot partition, as this is almost exactly what happens now. Alternatively, perhaps /sbin/init can get smarter; much of this problems with getting /usr mounted at the right time stems from difficulties in expressing the required order and dependency information in the init scripts. If /sbin/init could be explicitly told this is the 'mount my /usr' script and knew to run it or not, based on the existence of a /usr mount point, that could happen very early in the boot process. [ more criticism, a lot of which I accept. ] I think I have the elegant solution: that would be for the kernel to be able to mount several partitions at system initialisation rather than just the root partition. With this, all the issues we've been discussing simply wouldn't arise. That's one possible solution; I think there are several places where the kernel could potentially be made smarter about what is going on in the userland environment; for example, if udev always received block device events first, *it* could be tasked with mounting /usr when it saw that /dev/sda3 was available and in /etc/fstab, then it could happily run alsaconf or bluetoothd or whatever else when those devices popped up. I also admit I don't really understand autofs too much, but it seems like automounter support should be able to do something like this as well. Keep in mind, though, that the point of an initramfs is not to get /usr mounted. It's to get / mounted; if your rootfs happens to be on some hardware, network, or logical block device that needs special handling before it can be used, you need *somewhere* to put those utilities that the kernel can find them. The fact that you can also use an initramfs for all of these other pre-init steps is just added benefit. --Mike
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Thu, 29 Mar 2012 13:13:40 -0400, Michael Mol wrote: On Thu, Mar 29, 2012 at 12:35 PM, Neil Bothwick n...@digimed.co.uk wrote: I'll articulate a few. (i) The initramfs involves having two copies of lots of software around. Lots? For most people busybox is enough! If you want encrypted filesystems on LVM over RAID that rises to a total of four executables. And anything they might conceivably link to. Not everything supports static linking. Those four all have static version, there are no libraries in my initramfs. Don't forget boot-time X-based animation, too. That's an extraordinarily common feature of mainstream desktop distributions. And there will be other things, I'm sure. I don't get involved with those, but I'd hope something intended to be run so early would have minimal dependencies, if any. (ii) What's more, these two copies are often different, one being built with static libraries, the other with dynamic ones. (iii) This situation is not (as far as I know) yet handled by Portage, which means in building such software statically, you've got to save the dynamic version somewhere else whilst you're doing it. That's wrong. For example, LVM builds dynamic executable plus the lvm.static file for use in the initramfs. That's exactly what Alan just noted in (ii), but perhaps portage handles (iii) in the case of LVM. Exactly, there are static and dynamic files, all handled by portage. (iv) The initramfs requires a potentially long script to make it work. Mount /proc, /sys and /dev. Mount root Unmount /proc, /sys and /dev. switch_root Things look much simpler when you abstract away the details. You still have to manage lvm, mdraid and whatever else is necessary for mounting things. That's where 'potentially long' came from, I expect. I think that qualifies the initramfs solution as ugly. Only if you build the initramfs with USE=fud. FUD: Fear, uncertainty and doubt In short, three things which are important to rationally examine and deal with on a case-by-case basis. Yes, ideally before you start spreading them instead of vague handwaving about initramfs being ugly and using lots of files (four only counts at lots when applied to wives). -- Neil Bothwick Loose bits sink chips. signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Thu, Mar 29, 2012 at 2:11 PM, Neil Bothwick n...@digimed.co.uk wrote: On Thu, 29 Mar 2012 13:13:40 -0400, Michael Mol wrote: On Thu, Mar 29, 2012 at 12:35 PM, Neil Bothwick n...@digimed.co.uk wrote: I'll articulate a few. (i) The initramfs involves having two copies of lots of software around. Lots? For most people busybox is enough! If you want encrypted filesystems on LVM over RAID that rises to a total of four executables. And anything they might conceivably link to. Not everything supports static linking. Those four all have static version, there are no libraries in my initramfs. Which is good. Don't forget boot-time X-based animation, too. That's an extraordinarily common feature of mainstream desktop distributions. And there will be other things, I'm sure. I don't get involved with those, but I'd hope something intended to be run so early would have minimal dependencies, if any. There's a pretty firm distinction between what things get used for, and what they're intended for. The udev developers presumably were reacting to this when they decided to support an anything goes policy regarding plugscript behavior. And while I'm generally the kind of person to find unintended (but perfectly compatible with their spec) uses for things, I don't figure on being one to do so in my init sequence. That said, someone else will. That's been a long tradition in open source software and hacker culture. In short, depending on things only being used when they're intended to be used, in the circumstances they're intended to be used in, is sticking one's head into the sand. Workarounds will always arise to break such expectations and assumptions. (ii) What's more, these two copies are often different, one being built with static libraries, the other with dynamic ones. (iii) This situation is not (as far as I know) yet handled by Portage, which means in building such software statically, you've got to save the dynamic version somewhere else whilst you're doing it. That's wrong. For example, LVM builds dynamic executable plus the lvm.static file for use in the initramfs. That's exactly what Alan just noted in (ii), but perhaps portage handles (iii) in the case of LVM. Exactly, there are static and dynamic files, all handled by portage. (iv) The initramfs requires a potentially long script to make it work. Mount /proc, /sys and /dev. Mount root Unmount /proc, /sys and /dev. switch_root Things look much simpler when you abstract away the details. You still have to manage lvm, mdraid and whatever else is necessary for mounting things. That's where 'potentially long' came from, I expect. I think that qualifies the initramfs solution as ugly. Only if you build the initramfs with USE=fud. FUD: Fear, uncertainty and doubt In short, three things which are important to rationally examine and deal with on a case-by-case basis. Yes, ideally before you start spreading them instead of vague handwaving about initramfs being ugly and using lots of files (four only counts at lots when applied to wives). Fine. NFS clients. Samba clients. Crypto. SSHFS. NTFS-3g. Security auditing. Virtualization tools. Perl, python or whatever is necessary to handle some case which required scripting. X. Graphics loading libraries. Cupsd, because some graphics library required by a bootsplash expressed a dependency on cairo, which expressed a dependency on something else, which expressed a dependency on cups. Perhaps crypto required a crypto daemon to be loaded, which required a smartcard, or required auth from a serial port or network connection. Perhaps an accurate clock is needed. Or perhaps a network policy demands that a machine be authorized to boot, so an LDAP client is required. It's easy to imagine entirely plausible circumstances which would bloat initramfs size and maintenance. At some point in time, these various things would normally be the simplest and most straightforward way to reach a quick end to some problem or another for some poor guy stuck in a private hell. And this initramfs crap increases the amount of work he has to do to solve his unique case. -- :wq
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Canek Peláez Valdés wrote: Can you try doing dracut -H /boot/initramfs-kernel version here ?? The man page from dracut says that -H is for the current host instead of a generic host. Maybe the generic host configuration is messing up something with su that your actual host configuration needs. I use -H. As I have ben saying, my initramfs it's pretty up in sync with my normal system. Regards. Notice, I make the distinction between Console and Konsole by making the first letter capitalized. It kind of gets confusing. :/ I had to reboot so I made a new init thingy with the -H switch. It works in Console but nothing root works in KDE. I get the same error. Heck, Konsole won't even try to come up much less ask for my password. Krusader asks for password and says that su is not in the path. This is similar to what I got when I was in a Console too. So, boot without init thingy, everything works fine. Boot with the init thingy, I can't access things in KDE as root. All I do is reboot. I don't change or edit anything other than selecting a different entry in grub. I use Konsole when I emerge and such as that. I use Krusader, since Konqueror developed a bug, to edit config files. I don't care to switch to a Console to emerge something or edit a config file. This is not going to work for me long term. Also, keep in mind, I boot the EXACT same kernel whether I use the init thingy or not. All I do is remove the stuff the init thingy needs to work. Go figure. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Thu, Mar 29, 2012 at 2:15 PM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: Can you try doing dracut -H /boot/initramfs-kernel version here ?? The man page from dracut says that -H is for the current host instead of a generic host. Maybe the generic host configuration is messing up something with su that your actual host configuration needs. I use -H. As I have ben saying, my initramfs it's pretty up in sync with my normal system. Regards. Notice, I make the distinction between Console and Konsole by making the first letter capitalized. It kind of gets confusing. :/ I had to reboot so I made a new init thingy with the -H switch. It works in Console but nothing root works in KDE. I get the same error. Heck, Konsole won't even try to come up much less ask for my password. Krusader asks for password and says that su is not in the path. This is similar to what I got when I was in a Console too. So, boot without init thingy, everything works fine. Boot with the init thingy, I can't access things in KDE as root. All I do is reboot. I don't change or edit anything other than selecting a different entry in grub. I use Konsole when I emerge and such as that. I use Krusader, since Konqueror developed a bug, to edit config files. I don't care to switch to a Console to emerge something or edit a config file. This is not going to work for me long term. Also, keep in mind, I boot the EXACT same kernel whether I use the init thingy or not. All I do is remove the stuff the init thingy needs to work. Go figure. I'm a little confused: you log in KDE as a regular user, open a Konsole, type su -, and what happens? What do you mean with Konsole won't even try to come up? In the shell that Krusader provides (which I assume you run as a regular user), what it's the result of which su? And also, what happens when (inside the shell from Krusader) you run /bin/su? If not for the fact that you say that in a virtual console su works, I would be willing to suggest that your initramfs never does the switch_root, and so you end up with the minimal / from the initramfs, and your normal /usr. That would be beyond bizarre, but if you *can* use su in a virtual console, then it should be there. I usally log in in GNOME, open a gnome-terminal, and set a fixed number of tabs in gnome-terminal where I su -, and work as root in there. I also can run an X11 program as root with su -lc /usr/bin/gedit, but I almost never do that (although it works; I just checked). I don't think I understand how do you use su. Could you explain it to me, please? One last thing: create a directory /tmp/whatever, and inside it unpack your initramfs: zcat /boot/init-thingie | cpio -i Could you do a ls -R /tmp/whatever so we can see what actually ends up in yout initramfs? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
* Dale rdalek1...@gmail.com [120329 16:22]: Canek Peláez Valdés wrote: Can you try doing dracut -H /boot/initramfs-kernel version here ?? The man page from dracut says that -H is for the current host instead of a generic host. Maybe the generic host configuration is messing up something with su that your actual host configuration needs. I use -H. As I have ben saying, my initramfs it's pretty up in sync with my normal system. Regards. Notice, I make the distinction between Console and Konsole by making the first letter capitalized. It kind of gets confusing. :/ I had to reboot so I made a new init thingy with the -H switch. It works in Console but nothing root works in KDE. I get the same error. Heck, Konsole won't even try to come up much less ask for my password. Krusader asks for password and says that su is not in the path. This is similar to what I got when I was in a Console too. So, boot without init thingy, everything works fine. Boot with the init thingy, I can't access things in KDE as root. All I do is reboot. I don't change or edit anything other than selecting a different entry in grub. I use Konsole when I emerge and such as that. I use Krusader, since Konqueror developed a bug, to edit config files. I don't care to switch to a Console to emerge something or edit a config file. This is not going to work for me long term. Also, keep in mind, I boot the EXACT same kernel whether I use the init thingy or not. All I do is remove the stuff the init thingy needs to work. Go figure. Dale :-) :-) My dracut initramfs (created with just hostonly=yes changed from the config installed by Gentoo) is quite heavy and starts up udevd in the initramfs. That along with other things that happen in there could possibly be leading to your permission problems. If I were you, I'd manually create an initramfs the way that Neil has mentioned that simply mounts /usr and then does a switch_root and see if you still have problems. It's really not too hard if you can muddle through simple shell scripts. Todd
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Todd Goodman wrote: * Dale rdalek1...@gmail.com [120329 16:22]: Canek Peláez Valdés wrote: Can you try doing dracut -H /boot/initramfs-kernel version here ?? The man page from dracut says that -H is for the current host instead of a generic host. Maybe the generic host configuration is messing up something with su that your actual host configuration needs. I use -H. As I have ben saying, my initramfs it's pretty up in sync with my normal system. Regards. Notice, I make the distinction between Console and Konsole by making the first letter capitalized. It kind of gets confusing. :/ I had to reboot so I made a new init thingy with the -H switch. It works in Console but nothing root works in KDE. I get the same error. Heck, Konsole won't even try to come up much less ask for my password. Krusader asks for password and says that su is not in the path. This is similar to what I got when I was in a Console too. So, boot without init thingy, everything works fine. Boot with the init thingy, I can't access things in KDE as root. All I do is reboot. I don't change or edit anything other than selecting a different entry in grub. I use Konsole when I emerge and such as that. I use Krusader, since Konqueror developed a bug, to edit config files. I don't care to switch to a Console to emerge something or edit a config file. This is not going to work for me long term. Also, keep in mind, I boot the EXACT same kernel whether I use the init thingy or not. All I do is remove the stuff the init thingy needs to work. Go figure. Dale :-) :-) My dracut initramfs (created with just hostonly=yes changed from the config installed by Gentoo) is quite heavy and starts up udevd in the initramfs. That along with other things that happen in there could possibly be leading to your permission problems. If I were you, I'd manually create an initramfs the way that Neil has mentioned that simply mounts /usr and then does a switch_root and see if you still have problems. It's really not too hard if you can muddle through simple shell scripts. Todd I already tried making one from scratch and also making the one inside the kernel. Both belly flopped and left me with nothing but errors. It never even tried to leave the init thingy environment. I think I posted them a good long while back but no clue what they were know. I just moved on to what was supposed to be easy. Yea, right. :/ My concern is this, if it is this hard for me to get one working, if it ever breaks, I'm screwed. I know myself pretty well, if it breaks and I can't figure it out, I'll be looking for a install CD/DVD and fix it on a grand scale. This is how I got to Gentoo. I couldn't get Mandrake to work right and be stable, I switched. Well, it's supper time here. Maybe that will help, me at least. lol Dale :-) :-) P. S. Canek, will post in a bit for yours. -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Dale [mailto:rdalek1...@gmail.com] I had to reboot so I made a new init thingy with the -H switch. It works in Console but nothing root works in KDE. I get the same error. Heck, Konsole won't even try to come up much less ask for my password. Krusader asks for password and says that su is not in the path. This is similar to what I got when I was in a Console too. It sounds like your path might be getting messed up. What are the output/results of the following commands: $ which su $ echo $PATH $ su - For each of the following: logged in to a normal virtual console as root, logged in to a normal virtual console as a normal user, and running Konsole as a standard user when logged in via KDM? --Mike
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Thu, 29 Mar 2012 14:35:36 -0400, Michael Mol wrote: Don't forget boot-time X-based animation, too. That's an extraordinarily common feature of mainstream desktop distributions. And there will be other things, I'm sure. I don't get involved with those, but I'd hope something intended to be run so early would have minimal dependencies, if any. There's a pretty firm distinction between what things get used for, and what they're intended for. The udev developers presumably were reacting to this when they decided to support an anything goes policy regarding plugscript behavior. And while I'm generally the kind of person to find unintended (but perfectly compatible with their spec) uses for things, I don't figure on being one to do so in my init sequence. That said, someone else will. I know what you mean, but here we are discussing something being used for its intended purpose. If a bootsplash program is not designed to work well a the start of the boot process, you have to wonder what it will be good for. -- Neil Bothwick Electrocution, n.: Burning at the stake with all the modern improvements. signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Thu, 29 Mar 2012 14:35:36 -0400, Michael Mol wrote: Fine. NFS clients. Samba clients. Crypto. SSHFS. NTFS-3g. Security auditing. Virtualization tools. Perl, python or whatever is necessary to handle some case which required scripting. X. Graphics loading libraries. Cupsd, because some graphics library required by a bootsplash expressed a dependency on cairo, which expressed a dependency on something else, which expressed a dependency on cups. Perhaps crypto required a crypto daemon to be loaded, which required a smartcard, or required auth from a serial port or network connection. Perhaps an accurate clock is needed. Or perhaps a network policy demands that a machine be authorized to boot, so an LDAP client is required. It's easy to imagine entirely plausible circumstances which would bloat initramfs size and maintenance. At some point in time, these various things would normally be the simplest and most straightforward way to reach a quick end to some problem or another for some poor guy stuck in a private hell. And this initramfs crap increases the amount of work he has to do to solve his unique case. Setting up such a boot environment is decidedly non-standard and trying to put all that into a tool designed to get the core filesystem(s) loaded is ludicrous. But would you really want all of that available before init started to run? Mount / and /usr in the initramfs and run init. If you really need all that so early on, before /usr is mounted, maybe combining / and /usr is the cleanest approach. -- Neil Bothwick Fer sail cheep, Windows spel chekcer, wurks grate signature.asc Description: PGP signature
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Neil Bothwick [mailto:n...@digimed.co.uk] Sent: Thursday, March 29, 2012 8:04 PM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs? On Thu, 29 Mar 2012 14:35:36 -0400, Michael Mol wrote: Don't forget boot-time X-based animation, too. That's an extraordinarily common feature of mainstream desktop distributions. And there will be other things, I'm sure. I don't get involved with those, but I'd hope something intended to be run so early would have minimal dependencies, if any. There's a pretty firm distinction between what things get used for, and what they're intended for. The udev developers presumably were reacting to this when they decided to support an anything goes policy regarding plugscript behavior. And while I'm generally the kind of person to find unintended (but perfectly compatible with their spec) uses for things, I don't figure on being one to do so in my init sequence. That said, someone else will. I know what you mean, but here we are discussing something being used for its intended purpose. If a bootsplash program is not designed to work well a the start of the boot process, you have to wonder what it will be good for. splashutils, which is the package dracut uses to generate a boot splash image, has a lot of dependencies but requires they all be built USE=static-libs. Plymouth, which does animated boot splash, is a bit worse; it installs a few dozen files, about half of that data. Then again, if you're putting an animated boot splash image on your initramfs, I don't think you're all that worried about space :) --Mike
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Mar 30, 2012 9:14 AM, Mike Edenfield kut...@kutulu.org wrote: 8 snip splashutils, which is the package dracut uses to generate a boot splash image, has a lot of dependencies but requires they all be built USE=static-libs. Plymouth, which does animated boot splash, is a bit worse; it installs a few dozen files, about half of that data. Then again, if you're putting an animated boot splash image on your initramfs, I don't think you're all that worried about space :) Sometimes I wonder why people want eye candy during boot... Linux startup -- sans splash screen -- brings back nostalgic memories of my early computing days using DOS... Plus, sharp-eyed users can catch a glimpse of something wrong ;-) Rgds,
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Mar 28, 2012 11:27 AM, Mike Edenfield kut...@kutulu.org wrote: Well, for one, the initramfs solution is not generally considered ugly except by a select vocal few who object to it on vague, unarticulated grounds. Check out the email from William Kenworth in this mailing list; he's having trouble with initramfs being a blackbox. As a (mostly) server guy, I much prefer using a whitebox. I happen to have /usr on a VHD, so I don't need an initramfs for booting (that, plus my production servers are all udev-less). If push comes to shove, what I'll do is create a vestigial /usr in the root partition, and have it overlaid by mounting the actual root over it. Synchronizing can be automated by bindmounting root, after which I can access its (vestigial) usr directory. Rgds,
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Mar 28, 2012 1:17 PM, Pandu Poluan pa...@poluan.info wrote: On Mar 28, 2012 11:27 AM, Mike Edenfield kut...@kutulu.org wrote: Well, for one, the initramfs solution is not generally considered ugly except by a select vocal few who object to it on vague, unarticulated grounds. Check out the email from William Kenworth in this mailing list; he's having trouble with initramfs being a blackbox. As a (mostly) server guy, I much prefer using a whitebox. I happen to have /usr on a VHD, so I don't need an initramfs for booting (that, plus my production servers are all udev-less). If push comes to shove, what I'll do is create a vestigial /usr in the root partition, and have it overlaid by mounting the actual root over it. That should be: mounting the actual /usr over it. Rgds,
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Wed, 28 Mar 2012 13:17:56 +0700, Pandu Poluan wrote: Check out the email from William Kenworth in this mailing list; he's having trouble with initramfs being a blackbox. As a (mostly) server guy, I much prefer using a whitebox. It's not a blackbox, unlike a kernel or any other binary, it is a simple cpio archive that you can unpack and inspect. If you want total control, build your own, it is not rocket science. -- Neil Bothwick If a book about failures doesn't sell, is it a success? signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, 27 Mar 2012 23:32:22 +, Alan Mackenzie wrote: We're going to be stuck with some issues anyway, no matter how we cope with things. At the moment, I've got my /usr on RAID1, which I think doubles up the speed things load at. Use 0.90 metadata and you can put / on RAID1 too. (It's on LVM2 too, but that's by the way.) I really don't want a fragile initramfs. Sooner or later, I'd put some slight glitch into it and the result would be a dead PC. Either that or I'll be scared stiff of touching it, which isn't how a Gentoo user is supposed to be. An initramfs doesn't really need any maintenance, it does a couple of simple tasks, basically mounting stuff, and then exits. Once working there's no reason to change it. Even if you do and break things, it's exactly the same as the situation with a broken kernel update, you just boot with the previous one (that's one reason I leave the initramfs inside the kernel, a working kernel will always work without any reliance on other files). -- Neil Bothwick We demand rigidly defined areas of doubt and uncertainty! signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Wed, Mar 28, 2012 at 12:55:20AM +0200, Alan McKinnon wrote: On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: On Tue, 27 Mar 2012 21:24:22 + Alan Mackenzie a...@muc.de wrote: That is precisely what the question was NOT about. The idea was to copy (not move) booting software to /sbin instead of an initramfs - the exact same programs, modulo noise - to have the SW in /sbin necessary to mount /usr. Two words: shared libraries Copying binaries is not enough. You have to find and copy every shared library those binaries use. Plus all the data and other files they might need. This is non-trivial. silently screams. It's equally non-trivial for initramfs, yet nobody seems to be raising this objection for that. Why is nobody else on this thread willing to take up its main point, the exact equivalence between the known, ugly, initramfs solution and the as yet half-baked idea of putting the same binaries into /sbin? Read my other mail and pay attention to the difference between transient and persistent. In my proposed solution, the executables in /sbin would only exist until /usr had been mounted and the runtime PATH set up. After the unification of /usr, /sbin won't even exist (apart from in schemes like mine). initramfs is an elegant engineering solution (albeit over-engineered for our specific case of being Gentoo users). Maybe, maybe not. It couples the various bits of booting more tighly together. I look at Allan Gottlieb's bug WARNING latest lvm2 breaks systems with older udev, and note that he recovered, essentially, by mounting non-/ partitions by hand and going back to an old lvm2 version. I had a similar problem when I was first trying out Walter's mdev solution, which I also recovered by mounting by hand. I look forward with foreboding to the time when such recovery will not be possible. Only a legacy Gentoo system or a recovery CD will help then. I think it highly probable that can't boot bugs will continue to happen occasionally. I'd like to carry on having a bootable skeleton system for when this happens. Your questions are about an extremely ill-advised action that has no sound basis. It copies stuff around to make one very specific thing work but with zero consideration for what it will do to everything else. That is bad, bad engineering. I don't think that's a fair summary. If you want all this stuff in /, then do it correctly and modify the ebuilds to put the originals there (and troubleshoot the fallout from other faulty hard-coded stuffs). This is a lot of work, but it is sound. I doubt that would work, for the reasons you give. I feel I've been needlessly slammed, all for articulating an interesting idea. -- Alan McKinnnon alan.mckin...@gmail.com -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Wed, 28 Mar 2012 14:01:32 +, Alan Mackenzie wrote: Read my other mail and pay attention to the difference between transient and persistent. In my proposed solution, the executables in /sbin would only exist until /usr had been mounted and the runtime PATH set up. After the unification of /usr, /sbin won't even exist (apart from in schemes like mine). What happens to files that are installed to /bin, /sbin or /lib by default? Where do kernel modules go? I look forward with foreboding to the time when such recovery will not be possible. Only a legacy Gentoo system or a recovery CD will help then. I think it highly probable that can't boot bugs will continue to happen occasionally. I'd like to carry on having a bootable skeleton system for when this happens. When an initramfs fails to boot, it drops you to a busybox shell, although I also have a SystemRescueCD ISO in /boot for such situations. -- Neil Bothwick Top Oxymorons Number 12: Plastic glasses signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Hi, Neil. On Wed, Mar 28, 2012 at 03:56:36PM +0100, Neil Bothwick wrote: On Wed, 28 Mar 2012 14:01:32 +, Alan Mackenzie wrote: Read my other mail and pay attention to the difference between transient and persistent. In my proposed solution, the executables in /sbin would only exist until /usr had been mounted and the runtime PATH set up. After the unification of /usr, /sbin won't even exist (apart from in schemes like mine). What happens to files that are installed to /bin, /sbin or /lib by default? Aren't they getting shoved into /usr? I thought that was the whole point of the excercise. Where do kernel modules go? I hadn't actually thought of that - I've never built a kernel with modules enabled. Where do kernel modules go? Won't they be going into /usr somewhere? Incidentally, dracut says it won't work on a kernel without modules. I don't know if it's true or not. I look forward with foreboding to the time when such recovery will not be possible. Only a legacy Gentoo system or a recovery CD will help then. I think it highly probable that can't boot bugs will continue to happen occasionally. I'd like to carry on having a bootable skeleton system for when this happens. When an initramfs fails to boot, it drops you to a busybox shell, ... You know, that cheers me up a lot. ...although I also have a SystemRescueCD ISO in /boot for such situations. I suppose I could do with that, too. And I should learn how to use it. -- Neil Bothwick Top Oxymorons Number 12: Plastic glasses I wear spectacular glasses. -- Alan Mackenzie (Nuremberg, Germany).
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Canek Peláez Valdés [mailto:can...@gmail.com] I agree with most of what you say; however, I believe you are mistaken about the static nature of the binaries in the initramfs created by dracut. I use dracut with the whole bang (plymouth, systemd, udev, you name it), and I don't have *any* of my packages compiled with static-libs. Even more, my system right now runs everything with -static-libs. I like to think (and, unless I missed something, that's in fact the truth) that my initramfs is actually more or less in sync with my running system, and I update it a lot, since it's trivial to do so with dracut. You're right, it wasn't plymouth, it was gensplash and crypt that wanted me to add static-libs. It was a USE-flag dependency so I could not proceed with the dracut install until I rebuilt those other packages. plymouth just needed wanted USE=libkms on libdrm.
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Pandu Poluan [mailto:pa...@poluan.info] On Mar 28, 2012 11:27 AM, Mike Edenfield kut...@kutulu.org wrote: Well, for one, the initramfs solution is not generally considered ugly except by a select vocal few who object to it on vague, unarticulated grounds. Check out the email from William Kenworth in this mailing list; he's having trouble with initramfs being a blackbox. I don't see how you can really call initramfs a 'black box; it's certainly as open, or moreso, as the kernel, or grub, or /sbin/init; it's just a mini-filesystem with its own init: apollo kutulu # lsinitrd /boot/initramfs-3.2.7-hardened-apollo-0.img /boot/initramfs-3.2.7-hardened-apollo-0.img: 2.6M drwxr-xr-x 15 root root0 Mar 28 13:32 . drwxr-xr-x 2 root root0 Mar 28 13:32 dev drwxr-xr-x 2 root root0 Mar 28 13:32 root drwxr-xr-x 2 root root0 Mar 28 13:32 bin -rws--x--x 1 root root 105584 Feb 28 17:46 bin/mount -rwxr-xr-x 1 root root26536 Feb 28 17:46 bin/dmesg -rwxr-xr-x 1 root root30696 Feb 21 17:12 bin/uname -rwxr-xr-x 1 root root34776 Feb 21 17:12 bin/chroot -rwxr-xr-x 1 root root 137624 Mar 27 13:14 bin/dash -rwxr-xr-x 1 root root71640 Feb 21 17:12 bin/stty -rwxr-xr-x 1 root root30680 Feb 21 17:12 bin/basename -rwxr-xr-x 1 root root34776 Feb 21 17:12 bin/mknod lrwxrwxrwx 1 root root4 Mar 28 13:32 bin/sh - dash . . . -rwxr-xr-x 1 root root14176 Feb 28 17:46 sbin/switch_root -rwxr-xr-x 1 root root12622 Feb 15 12:05 init drwxr-xr-x 2 root root0 Mar 28 13:32 tmp drwxr-xr-x 2 root root0 Mar 28 13:32 proc drwxr-xr-x 5 root root0 Mar 28 13:32 lib64
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Alan Mackenzie [mailto:a...@muc.de] Incidentally, dracut says it won't work on a kernel without modules. I don't know if it's true or not. dracut wants you to have loadable module /support/ in your kernel so it can scan for modules needed by the rootfs. The kernel-module support in dracut is just another module; you could omit that module and I believe dracut will carry on fine. Of course, if you have nothing compiled as a module then your initramfs just won't have any modules built into it either way. --Mike
[gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Alan McKinnon alan.mckin...@gmail.com writes: I offer you two choices: a. Move a few commands into an initramfs, truly only the ones you really do need, or b. Move 7G of files onto / (i.e. everything) and lose any benefit you (and everyone else with different ideas to you) may want by having a separate /usr. Oh, and you get to deal with finding the hardcoded paths and fixing the code yourself. Those are your choices. Pick one. In that case I pick a. It's not a big deal. I don't have anything against initrd, and use it on several places. It's useful for many things including enabling / on raid or lvm. But I also see the usefulnes of having / on a real partition, and being able to start a kernel with init=/bin/bash when I have screwed something up, which I tend to do quite often, :) -- Christer
[gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Mike Edenfield kut...@kutulu.org writes: Yes , of course it's /possible/, it's just not /practical/. Perhaps, but still? I don't se how that is less practical than collecting them to a ramdisk? Just do exactly the same steps up to the cpio | gzip -part I do agree with most of what you say Most Linux users, by a vast but very silent majority, are plenty happy to put / and /usr on one partition, wipe their hands on their pants, and move on with life. Thus, the people developing and packaging those required boot packages can leave them right where they are, and everything works. I agree with that. Some Linux users have reasons (largely legitimate ones) why this is not a valid option. Those users have three choices * Move the required packages away from their default installation locations on their machines, as you're suggestion, and fix the order of your boot scripts to mount /usr earlier than anything that needs it. * Install (or develop) alternative versions of the tools that do not have the same boot-time requirements, thus allowing you to ignore the whole mess. This is what Walt and his mdev team are making happen. * Use an initramfs to do whatever specific thing your machine(s) need to do to make the rest of the software work out-of-the-box. So, it's not a matter of one choice working and one not. It's a matter of one choice being much lower maintenance for the people donating their time to produce the software in the first place. Yes, that is a very valid point. If someone (maybe you) were to figure out the actual steps needed to mount /usr early in the boot, without and initramfs, without swapping out udev for busybox or whatever, I'm sure a lot of people would be interested in seeing how that's done. There's a possibility that it turns out to be way easier than anyone thought, and that supporting a split /usr becomes no big deal. In practice, I'm going to guess that it turns out to be a way bigger maintenance nightmare (and probably more fragile) than: root # emerge dracut root # dracut -H That's probably the way I'll proceed when I update udev later. But I'll wait a while longer before doing that. I'll going to miss the posibility of starting a kernel with only init=/bin/bash for rescue purposes. But it's not a big deal. And probably won't be something that the developers or package maintainers are going to commit to supporting. --Mike Thanks Mike. This is my migration-plan Today I have two disks with both three partitions sda1 /-- sdb1 reserve-root. Regulary rsynced from sda1 sda2 swap -- sdb2 swap sda3 lvm -- sdb3 lvm sda3 and sdb3 is combined to the volume-group vg0, and I have all my other filesystems in vg0. I'm planing to create a vg0/root and copy the contents of / to that, and later remove everything but /boot from the old / How does that sound? -- Christer
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Wed, 28 Mar 2012 17:07:33 +, Alan Mackenzie wrote:
What happens to files that are installed to /bin, /sbin or /lib by
default?
Aren't they getting shoved into /usr? I thought that was the whole
point of the excercise.
That /may/ happen at some time, but not now, so we need a solution that
supports the current mish-mash of /*/*bin directories.
Where do kernel modules go?
I hadn't actually thought of that - I've never built a kernel with
modules enabled. Where do kernel modules go? Won't they be going into
/usr somewhere?
How will you mount /usr if it needs a module? This is the sort of chicken
and egg situation that an initramfs can avoid, by making sure everything
the boot process needs is available.
When an initramfs fails to boot, it drops you to a busybox shell, ...
You know, that cheers me up a lot.
...although I also have a SystemRescueCD ISO in /boot for such
situations.
I suppose I could do with that, too. And I should learn how to use it.
Since someone has already asked about this off-list, the method is
described on sysrescd.org and involves a GRUB menu entry like
echo Adding: System Rescue CD
menuentry System Rescue CD {
set sysresiso=/systemrescuecd-x86-2.5.1.iso
loopback loop $sysresiso
linux (loop)/isolinux/rescue64 rootpass=whatever setkmap=uk
isoloop=$sysresiso
initrd (loop)/isolinux/initram.igz
}
--
Neil Bothwick
IMPORTANT: The entire physical universe, including this message, may
one day collapse back into an infinitesimally small space. Should
another universe subsequently re-emerge, the existence of this message
in that universe cannot be guaranteed.
signature.asc
Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Wednesday 28 March 2012 22:47:09 Neil Bothwick wrote:
Since someone has already asked about this off-list, the method is
described on sysrescd.org and involves a GRUB menu entry like
echo Adding: System Rescue CD
menuentry System Rescue CD {
set sysresiso=/systemrescuecd-x86-2.5.1.iso
loopback loop $sysresiso
linux (loop)/isolinux/rescue64 rootpass=whatever setkmap=uk
isoloop=$sysresiso initrd (loop)/isolinux/initram.igz
}
Am I right in thinking that this only works with GRUB-2, not the legacy
GRUB? I'm not ready yet to go to the next generation of GRUB.
--
Rgds
Peter
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Wed, 28 Mar 2012 23:45:40 +0100, Peter Humphrey wrote:
echo Adding: System Rescue CD
menuentry System Rescue CD {
set sysresiso=/systemrescuecd-x86-2.5.1.iso
loopback loop $sysresiso
linux (loop)/isolinux/rescue64 rootpass=whatever setkmap=uk
isoloop=$sysresiso initrd (loop)/isolinux/initram.igz
}
Am I right in thinking that this only works with GRUB-2, not the legacy
GRUB?
AFAIK, yes.
I'm not ready yet to go to the next generation of GRUB.
There's little point in change fore change's sake. When I install a new
system I use GRUB2, but those that were set up with GRUB1 will continue
to use it until I have a good reason to change - even though the change
is quite trivial.
For new systems, it is a lot easier - emerge grub and run grub2-mkconfig
and you have a bootable system. If you want to fart around with menu
files (as I generally do) you can play with them after the system has
booted the first time.
--
Neil Bothwick
Loose bits sink chips.
signature.asc
Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Alan Mackenzie wrote: Incidentally, dracut says it won't work on a kernel without modules. I don't know if it's true or not. Oh really? I don't use modules and I am the one having issues with not being able to su to root from a user. I wonder if that is related somehow. o_O Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Wed, Mar 28, 2012 at 7:53 PM, Dale rdalek1...@gmail.com wrote: Alan Mackenzie wrote: Incidentally, dracut says it won't work on a kernel without modules. I don't know if it's true or not. Oh really? I don't use modules and I am the one having issues with not being able to su to root from a user. I wonder if that is related somehow. o_O I don't use modules either (except scsi_wait_scan.ko; you cannot get rid of that one), I use dracut, and I can su just fine. Dale, can you please post the dracut comand you used to create your initramfs? Also, the DRACUT_MODULES you have defined, and the contents of /etc/dracut.conf? Not being able to su sounds incredible weird. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Neil Bothwick wrote: It's not a blackbox, unlike a kernel or any other binary, it is a simple cpio archive that you can unpack and inspect. If you want total control, build your own, it is not rocket science. cough cough You sure about that? I have tried building one, then building it inside the kernel then using dracut. Still got issues. If not rocket science, what other degree does a person need? ROFL Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Canek Peláez Valdés wrote: On Wed, Mar 28, 2012 at 7:53 PM, Dale rdalek1...@gmail.com wrote: Alan Mackenzie wrote: Incidentally, dracut says it won't work on a kernel without modules. I don't know if it's true or not. Oh really? I don't use modules and I am the one having issues with not being able to su to root from a user. I wonder if that is related somehow. o_O I don't use modules either (except scsi_wait_scan.ko; you cannot get rid of that one), I use dracut, and I can su just fine. Dale, can you please post the dracut comand you used to create your initramfs? Also, the DRACUT_MODULES you have defined, and the contents of /etc/dracut.conf? Not being able to su sounds incredible weird. Regards. Here is one: root@fireball / # cat /etc/dracut.conf # Sample dracut config file logfile=/var/log/dracut.log fileloglvl=6 # Exact list of dracut modules to use. Modules not listed here are not going # to be included. If you only want to add some optional modules use # add_dracutmodules option instead. #dracutmodules+= # Dracut modules to omit #omit_dracutmodules+= # Dracut modules to add to the default #add_dracutmodules+=lvm fstab-sys usrmount # additional kernel modules to the default #add_drivers+= # list of kernel filesystem modules to be included in the generic initramfs filesystems+=ext2 reiserfs ext3 # build initrd only to boot current hardware #hostonly=yes # # install local /etc/mdadm.conf mdadmconf=yes # install local /etc/lvm/lvm.conf lvmconf=yes # A list of fsck tools to install. If it's not specified, module's hardcoded # default is used, currently: umount mount /sbin/fsck* xfs_db xfs_check # xfs_repair e2fsck jfs_fsck reiserfsck btrfsck. The installation is # opportunistic, so non-existing tools are just ignored. #fscks= # inhibit installation of any fsck tools #nofscks=yes root@fireball / # +++ The command I use is: dracut /boot/initramfs-kernel version here I name each one according to kernel versions. I try to keep a few back up kernels in case one gets borked or something. It makes cleaning easier if I know which files belong to what. Anyway. I also looked back at the log for the last build. The only thing I found that may resemble a error would be it skipping file systems that I don't have installed or built into the kernel, in other words, things I don't use to begin with. I didn't see it complain about anything missing or broken. I agree it is weird that su to root doesn't work. I have not been able to find anything related with SP, read as Google replacement search tool www.startpage.com since Google got nosey. lol From what I have read, it shouldn't matter but I can boot with the init thingy and it fails everytime. When I boot without the init thingy, it works fine. Weird is a good word to describe it. I noticed dracut just got updated. I have dracut-017-r3 installed now. I may stick a small drive in my old rig, x86, and try to figure this mess out on it. Maybe try putting /usr and /var on LVM and really make a mess of things. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Wed, Mar 28, 2012 at 8:39 PM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Wed, Mar 28, 2012 at 7:53 PM, Dale rdalek1...@gmail.com wrote: Alan Mackenzie wrote: Incidentally, dracut says it won't work on a kernel without modules. I don't know if it's true or not. Oh really? I don't use modules and I am the one having issues with not being able to su to root from a user. I wonder if that is related somehow. o_O I don't use modules either (except scsi_wait_scan.ko; you cannot get rid of that one), I use dracut, and I can su just fine. Dale, can you please post the dracut comand you used to create your initramfs? Also, the DRACUT_MODULES you have defined, and the contents of /etc/dracut.conf? Not being able to su sounds incredible weird. Regards. Here is one: root@fireball / # cat /etc/dracut.conf # Sample dracut config file logfile=/var/log/dracut.log fileloglvl=6 # Exact list of dracut modules to use. Modules not listed here are not going # to be included. If you only want to add some optional modules use # add_dracutmodules option instead. #dracutmodules+= # Dracut modules to omit #omit_dracutmodules+= # Dracut modules to add to the default #add_dracutmodules+=lvm fstab-sys usrmount # additional kernel modules to the default #add_drivers+= # list of kernel filesystem modules to be included in the generic initramfs filesystems+=ext2 reiserfs ext3 # build initrd only to boot current hardware #hostonly=yes # # install local /etc/mdadm.conf mdadmconf=yes # install local /etc/lvm/lvm.conf lvmconf=yes # A list of fsck tools to install. If it's not specified, module's hardcoded # default is used, currently: umount mount /sbin/fsck* xfs_db xfs_check # xfs_repair e2fsck jfs_fsck reiserfsck btrfsck. The installation is # opportunistic, so non-existing tools are just ignored. #fscks= # inhibit installation of any fsck tools #nofscks=yes root@fireball / # +++ The command I use is: dracut /boot/initramfs-kernel version here I name each one according to kernel versions. I try to keep a few back up kernels in case one gets borked or something. It makes cleaning easier if I know which files belong to what. Anyway. I also looked back at the log for the last build. The only thing I found that may resemble a error would be it skipping file systems that I don't have installed or built into the kernel, in other words, things I don't use to begin with. I didn't see it complain about anything missing or broken. I agree it is weird that su to root doesn't work. I have not been able to find anything related with SP, read as Google replacement search tool www.startpage.com since Google got nosey. lol From what I have read, it shouldn't matter but I can boot with the init thingy and it fails everytime. When I boot without the init thingy, it works fine. Weird is a good word to describe it. I noticed dracut just got updated. I have dracut-017-r3 installed now. I may stick a small drive in my old rig, x86, and try to figure this mess out on it. Maybe try putting /usr and /var on LVM and really make a mess of things. lol Can you try doing dracut -H /boot/initramfs-kernel version here ?? The man page from dracut says that -H is for the current host instead of a generic host. Maybe the generic host configuration is messing up something with su that your actual host configuration needs. I use -H. As I have ben saying, my initramfs it's pretty up in sync with my normal system. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
[gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Neil Bothwick n...@digimed.co.uk writes: On Tue, 27 Mar 2012 14:26:46 +, Alan Mackenzie wrote: As you move more and more software off of /usr into / you start to realize that the idea of tiny partition that contains just what I need to boot and mount /usr is becoming not so tiny anymore. The distinction between what is boot software versus user software gets less clear. Again, isn't this the same for an initramfs? No, because an initramfs only needs enough to mount / and /usr, then everything else comes from the usual source. If you're not using and fancy block devices, the initramfs only needs busybox and an init script. Even adding LVM, RAID and encryption only requires three more binaries - and those are all disposed of once switch_root is run and the tmpfs released. The question remains. If it's possible to do that from an initramfs, then shouldn't it be possible to put the same tools and binarias on /, and mount /usr early?
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, 27 Mar 2012 19:55:37 +0200 c...@chrekh.se wrote: Neil Bothwick n...@digimed.co.uk writes: On Tue, 27 Mar 2012 14:26:46 +, Alan Mackenzie wrote: As you move more and more software off of /usr into / you start to realize that the idea of tiny partition that contains just what I need to boot and mount /usr is becoming not so tiny anymore. The distinction between what is boot software versus user software gets less clear. Again, isn't this the same for an initramfs? No, because an initramfs only needs enough to mount / and /usr, then everything else comes from the usual source. If you're not using and fancy block devices, the initramfs only needs busybox and an init script. Even adding LVM, RAID and encryption only requires three more binaries - and those are all disposed of once switch_root is run and the tmpfs released. The question remains. If it's possible to do that from an initramfs, then shouldn't it be possible to put the same tools and binarias on /, and mount /usr early? Of course it's possible, it's merely a gigantic list of cd commands. The question is, is it advisable? I offer you two choices: a. Move a few commands into an initramfs, truly only the ones you really do need, or b. Move 7G of files onto / (i.e. everything) and lose any benefit you (and everyone else with different ideas to you) may want by having a separate /usr. Oh, and you get to deal with finding the hardcoded paths and fixing the code yourself. Those are your choices. Pick one. -- Alan McKinnnon alan.mckin...@gmail.com
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: c...@chrekh.se [mailto:c...@chrekh.se] Neil Bothwick n...@digimed.co.uk writes: On Tue, 27 Mar 2012 14:26:46 +, Alan Mackenzie wrote: As you move more and more software off of /usr into / you start to realize that the idea of tiny partition that contains just what I need to boot and mount /usr is becoming not so tiny anymore. The distinction between what is boot software versus user software gets less clear. Again, isn't this the same for an initramfs? No, because an initramfs only needs enough to mount / and /usr, then everything else comes from the usual source. If you're not using and fancy block devices, the initramfs only needs busybox and an init script. Even adding LVM, RAID and encryption only requires three more binaries - and those are all disposed of once switch_root is run and the tmpfs released. The question remains. If it's possible to do that from an initramfs, then shouldn't it be possible to put the same tools and binarias on /, and mount /usr early? Yes , of course it's /possible/, it's just not /practical/. Changing the contents of your initramfs is a decision you, as an admin, make that affects your system(s). Changing the installed location of, say, udevd and bluetoothd and whatever other tools need to get pulled out of /usr is a decision that affects everyone who is using those packages. Changing the order of init scripts is an even bigger mess, but mostly because of the software requirements to make it function. Most Linux users, by a vast but very silent majority, are plenty happy to put / and /usr on one partition, wipe their hands on their pants, and move on with life. Thus, the people developing and packaging those required boot packages can leave them right where they are, and everything works. Some Linux users have reasons (largely legitimate ones) why this is not a valid option. Those users have three choices * Move the required packages away from their default installation locations on their machines, as you're suggestion, and fix the order of your boot scripts to mount /usr earlier than anything that needs it. * Install (or develop) alternative versions of the tools that do not have the same boot-time requirements, thus allowing you to ignore the whole mess. This is what Walt and his mdev team are making happen. * Use an initramfs to do whatever specific thing your machine(s) need to do to make the rest of the software work out-of-the-box. So, it's not a matter of one choice working and one not. It's a matter of one choice being much lower maintenance for the people donating their time to produce the software in the first place. If someone (maybe you) were to figure out the actual steps needed to mount /usr early in the boot, without and initramfs, without swapping out udev for busybox or whatever, I'm sure a lot of people would be interested in seeing how that's done. There's a possibility that it turns out to be way easier than anyone thought, and that supporting a split /usr becomes no big deal. In practice, I'm going to guess that it turns out to be a way bigger maintenance nightmare (and probably more fragile) than: root # emerge dracut root # dracut -H And probably won't be something that the developers or package maintainers are going to commit to supporting. --Mike
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Hi, Mike. On Tue, Mar 27, 2012 at 03:56:01PM -0400, Mike Edenfield wrote: From: c...@chrekh.se [mailto:c...@chrekh.se] Neil Bothwick n...@digimed.co.uk writes: On Tue, 27 Mar 2012 14:26:46 +, Alan Mackenzie wrote: As you move more and more software off of /usr into / you start to realize that the idea of tiny partition that contains just what I need to boot and mount /usr is becoming not so tiny anymore. The distinction between what is boot software versus user software gets less clear. Again, isn't this the same for an initramfs? No, because an initramfs only needs enough to mount / and /usr, then everything else comes from the usual source. If you're not using and fancy block devices, the initramfs only needs busybox and an init script. Even adding LVM, RAID and encryption only requires three more binaries - and those are all disposed of once switch_root is run and the tmpfs released. The question remains. If it's possible to do that from an initramfs, then shouldn't it be possible to put the same tools and binarias on /, and mount /usr early? I don't think you've understood the question - you certainly haven't answered it. Yes , of course it's /possible/, it's just not /practical/. Why not? Changing the contents of your initramfs is a decision you, as an admin, make that affects your system(s). s%initramfs%/sbin%, then how does the sentence not apply? Changing the installed location of, say, udevd and bluetoothd and whatever other tools need to get pulled out of /usr is a decision that affects everyone who is using those packages. Changing the order of init scripts is an even bigger mess, but mostly because of the software requirements to make it function. That is precisely what the question was NOT about. The idea was to copy (not move) booting software to /sbin instead of an initramfs - the exact same programs, modulo noise - to have the SW in /sbin necessary to mount /usr. Our loveable upstream suppliers are making us mount /usr early in the boot process. Why can't this be done as well from /sbin as from initramfs? [ ] --Mike -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, 27 Mar 2012 21:24:22 +, Alan Mackenzie wrote: That is precisely what the question was NOT about. The idea was to copy (not move) booting software to /sbin instead of an initramfs - the exact same programs, modulo noise - to have the SW in /sbin necessary to mount /usr. Your package manager only knows about the copy in the original location. When you update you'll have multiple versions of the same program or library in your path. -- Neil Bothwick In space, no one can hear you fart. signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, 27 Mar 2012 21:24:22 + Alan Mackenzie a...@muc.de wrote: That is precisely what the question was NOT about. The idea was to copy (not move) booting software to /sbin instead of an initramfs - the exact same programs, modulo noise - to have the SW in /sbin necessary to mount /usr. Two words: shared libraries Copying binaries is not enough. You have to find and copy every shared library those binaries use. Plus all the data and other files they might need. This is non-trivial. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Hello, Neil. On Tue, Mar 27, 2012 at 10:41:53PM +0100, Neil Bothwick wrote: On Tue, 27 Mar 2012 21:24:22 +, Alan Mackenzie wrote: That is precisely what the question was NOT about. The idea was to copy (not move) booting software to /sbin instead of an initramfs - the exact same programs, modulo noise - to have the SW in /sbin necessary to mount /usr. Your package manager only knows about the copy in the original location. So? The same applies to a copy in the initramfs. When you update you'll have multiple versions of the same program or library in your path. Well, with the manual/script copying which needs doing either for /sbin or initramfs, that will be several copies of a program, not several versions. I'm still trying to see the reason why an /sbin with the same contents as a putative initramfs won't work. -- Neil Bothwick -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Hi, Alan. On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: On Tue, 27 Mar 2012 21:24:22 + Alan Mackenzie a...@muc.de wrote: That is precisely what the question was NOT about. The idea was to copy (not move) booting software to /sbin instead of an initramfs - the exact same programs, modulo noise - to have the SW in /sbin necessary to mount /usr. Two words: shared libraries Copying binaries is not enough. You have to find and copy every shared library those binaries use. Plus all the data and other files they might need. This is non-trivial. silently screams. It's equally non-trivial for initramfs, yet nobody seems to be raising this objection for that. Why is nobody else on this thread willing to take up its main point, the exact equivalence between the known, ugly, initramfs solution and the as yet half-baked idea of putting the same binaries into /sbin? -- Alan McKinnnon alan.mckin...@gmail.com -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, 27 Mar 2012 22:01:28 + Alan Mackenzie a...@muc.de wrote: Hello, Neil. On Tue, Mar 27, 2012 at 10:41:53PM +0100, Neil Bothwick wrote: On Tue, 27 Mar 2012 21:24:22 +, Alan Mackenzie wrote: That is precisely what the question was NOT about. The idea was to copy (not move) booting software to /sbin instead of an initramfs - the exact same programs, modulo noise - to have the SW in /sbin necessary to mount /usr. Your package manager only knows about the copy in the original location. So? The same applies to a copy in the initramfs. No it doesn't. The initramfs is a transient file system contained within a single file. To the package manager, it is just a file, one with a rather unique name that portage is highly unlikely to try and overwrite. Copying binaries into / means you are copying a large number of files into an area managed by the package manager. Those files have names and locations that are rather likely to be used by ebuilds. Do we really have to spell out to you why this is a bad idea? When you update you'll have multiple versions of the same program or library in your path. Well, with the manual/script copying which needs doing either for /sbin or initramfs, that will be several copies of a program, not several versions. Your copies will be used in preference to the originals in /usr. You will have to detect this yourself when this occurs and re-copy them and portage cannot help you. Remember the primary difference between / and an initramfs: The initramfs is transient and it's contents are not available to confuse the system once early boot is over. / is a permanent file system that is always around, and always there to confuse the issue. This is not a small trivial issue, it is huge, and a magnificent bug-injection system. I'm still trying to see the reason why an /sbin with the same contents as a putative initramfs won't work. Oh, it will work for booting all right. It's the issues it will cause after booting when it should no longer be there that is the problem. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, 27 Mar 2012 22:01:28 +, Alan Mackenzie wrote: Your package manager only knows about the copy in the original location. So? The same applies to a copy in the initramfs. No it does not. the initramfs is built using the versions installed on your system, and unloaded as soon as root is switched to /. At no time are two different versions available in your path. When you update you'll have multiple versions of the same program or library in your path. Well, with the manual/script copying which needs doing either for /sbin or initramfs, that will be several copies of a program, not several versions. Multiple copies of the same version is inefficient, multiple versions is potentially disastrous. I'm still trying to see the reason why an /sbin with the same contents as a putative initramfs won't work. You seem to be trying very hard to ignore the point that the initramfs does not need to contain as much as /usr or even /. It only needs to contain the files required to mount / and /usr. this can be as few as 2, busybox and the init script. Even with encrypted filesystems on LVM volumes running on RAID, this box's initramfs contains only 5 files. % grep file /usr/src/init.cfg file /bin/busybox /bin/busybox 755 0 0 file /sbin/lvm.static /sbin/lvm.static 755 0 0 file /sbin/mdadm /sbin/mdadm 755 0 0 file /sbin/cryptsetup /sbin/cryptsetup 755 0 0 file /init /usr/src/init.sh 755 0 0 -- Neil Bothwick Press Return to Continue - known as The Mail Menupause. signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, 27 Mar 2012 22:35:44 +, Alan Mackenzie wrote: Why is nobody else on this thread willing to take up its main point, the exact equivalence between the known, ugly, initramfs solution and the as yet half-baked idea of putting the same binaries into /sbin? Bewause everyone else realises they are in no way equivalent, or even comparable? -- Neil Bothwick Access denied--nah nah na nah nah! signature.asc Description: PGP signature
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, 27 Mar 2012 22:35:44 + Alan Mackenzie a...@muc.de wrote: Hi, Alan. On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: On Tue, 27 Mar 2012 21:24:22 + Alan Mackenzie a...@muc.de wrote: That is precisely what the question was NOT about. The idea was to copy (not move) booting software to /sbin instead of an initramfs - the exact same programs, modulo noise - to have the SW in /sbin necessary to mount /usr. Two words: shared libraries Copying binaries is not enough. You have to find and copy every shared library those binaries use. Plus all the data and other files they might need. This is non-trivial. silently screams. It's equally non-trivial for initramfs, yet nobody seems to be raising this objection for that. Why is nobody else on this thread willing to take up its main point, the exact equivalence between the known, ugly, initramfs solution and the as yet half-baked idea of putting the same binaries into /sbin? Read my other mail and pay attention to the difference between transient and persistent. initramfs is an elegant engineering solution (albeit over-engineered for our specific case of being Gentoo users). Your questions are about an extremely ill-advised action that has no sound basis. It copies stuff around to make one very specific thing work but with zero consideration for what it will do to everything else. That is bad, bad engineering. If you want all this stuff in /, then do it correctly and modify the ebuilds to put the originals there (and troubleshoot the fallout from other faulty hard-coded stuffs). This is a lot of work, but it is sound. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
Hello again, Alan. On Wed, Mar 28, 2012 at 12:39:27AM +0200, Alan McKinnon wrote: On Tue, 27 Mar 2012 22:01:28 + Alan Mackenzie a...@muc.de wrote: Hello, Neil. On Tue, Mar 27, 2012 at 10:41:53PM +0100, Neil Bothwick wrote: On Tue, 27 Mar 2012 21:24:22 +, Alan Mackenzie wrote: That is precisely what the question was NOT about. The idea was to copy (not move) booting software to /sbin instead of an initramfs - the exact same programs, modulo noise - to have the SW in /sbin necessary to mount /usr. Your package manager only knows about the copy in the original location. So? The same applies to a copy in the initramfs. No it doesn't. The initramfs is a transient file system contained within a single file. To the package manager, it is just a file, one with a rather unique name that portage is highly unlikely to try and overwrite. Copying binaries into / means you are copying a large number of files into an area managed by the package manager. Those files have names and locations that are rather likely to be used by ebuilds. Ah. I was looking forward to the sad time when package managers will be installing things exclusively on /usr. Well, OK, on /etc too, but certainly not to /sbin (which will probably have been abolished). Do we really have to spell out to you why this is a bad idea? No, I can get that. ;-) When you update you'll have multiple versions of the same program or library in your path. Well, with the manual/script copying which needs doing either for /sbin or initramfs, that will be several copies of a program, not several versions. Your copies will be used in preference to the originals in /usr. You will have to detect this yourself when this occurs and re-copy them and portage cannot help you. I was thinking of using /sbin for booting, then removing it from $PATH as soon as /usr gets mounted. Remember the primary difference between / and an initramfs: The initramfs is transient and it's contents are not available to confuse the system once early boot is over. / is a permanent file system that is always around, and always there to confuse the issue. OK. I take /sbin off $PATH, like I said above. This is not a small trivial issue, it is huge, and a magnificent bug-injection system. OK2. I don't like BI systems. I'm still trying to see the reason why an /sbin with the same contents as a putative initramfs won't work. Oh, it will work for booting all right. It's the issues it will cause after booting when it should no longer be there that is the problem. We're going to be stuck with some issues anyway, no matter how we cope with things. At the moment, I've got my /usr on RAID1, which I think doubles up the speed things load at. (It's on LVM2 too, but that's by the way.) I really don't want a fragile initramfs. Sooner or later, I'd put some slight glitch into it and the result would be a dead PC. Either that or I'll be scared stiff of touching it, which isn't how a Gentoo user is supposed to be. Do I really want to take my /usr off RAID1, just so I can amalgamate it with /? There's no getting round duplicating executables once the single /usr crowd have got their way. The only question is where you put the duplicates, and how you make sure they don't foul things up. -- Alan McKinnnon alan.mckin...@gmail.com -- Alan Mackenzie (Nuremberg, Germany).
RE: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Alan Mackenzie [mailto:a...@muc.de] Hi, Alan. On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: On Tue, 27 Mar 2012 21:24:22 + Alan Mackenzie a...@muc.de wrote: That is precisely what the question was NOT about. The idea was to copy (not move) booting software to /sbin instead of an initramfs - the exact same programs, modulo noise - to have the SW in /sbin necessary to mount /usr. Two words: shared libraries Copying binaries is not enough. You have to find and copy every shared library those binaries use. Plus all the data and other files they might need. This is non-trivial. silently screams. It's equally non-trivial for initramfs, yet nobody seems to be raising this objection for that. Why is nobody else on this thread willing to take up its main point, the exact equivalence between the known, ugly, initramfs solution and the as yet half-baked idea of putting the same binaries into /sbin? Well, for one, the initramfs solution is not generally considered ugly except by a select vocal few who object to it on vague, unarticulated grounds. That notwithstanding: The binaries on the initramfs are not always the same as the ones installed in the system; frequently they are statically linked versions, or stripped-down versions, or otherwise unsuitable for being used after the full system is booted. (Dracut, for example, forces you to add USE=static-libs to a lot of the packages it wants to put into your initramfs image.) Putting those binaries into the execution path of the system is a bad idea because you don't always them to run once the system has booted -- I want the full set of udev rules, not the bare handful that my initramfs has on it. You could fix this by arranging for them to be put somewhere outside the normal path, where they can be found by the init system at boot-time but then ignored once /usr was up. This would also mean managing two copies of these packages on your system, which means the package manager would need to ensure that both static and dynamic versions, or full and minimal version, or whatever else, were built and installed in the correct locations. And this is ignoring the possible side-effects of reordering the boot scripts to unilaterally try to mount /usr very early; I don't know what, if any, those would be but someone would need to figure those out. The initramfs solution doesn't change the order of boot scripts, so people who are not using one see no change. Again, this is all *possible*. It is one option for solving the missing-/usr-at-boot problem, it is just not the option that has taken hold in the community. The people who are writing the software consider an initramfs a more elegant, cleaner, *less* ugly solution that what you are proposing, in the context of a general-purpose solution suitable for the most number of users. As they are the ones doing all the work, they get to make that call. The fact that most of us seem to agree with, or at least not actively disagree with, that opinion is just an added bonus. Your solution would be equally as successful at solving the problem, once someone put in the effort to actually make it work, make it repeatable, make it stable, and document/automate it for others to use. All of those steps have /already happened/ for an initramfs, so until someone comes up with a concrete reason why initramfs will not work, there is absolutely no motivation to waste time on anything else. --Mike
Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, Mar 27, 2012 at 10:24 PM, Mike Edenfield kut...@kutulu.org wrote: From: Alan Mackenzie [mailto:a...@muc.de] Hi, Alan. On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: On Tue, 27 Mar 2012 21:24:22 + Alan Mackenzie a...@muc.de wrote: That is precisely what the question was NOT about. The idea was to copy (not move) booting software to /sbin instead of an initramfs - the exact same programs, modulo noise - to have the SW in /sbin necessary to mount /usr. Two words: shared libraries Copying binaries is not enough. You have to find and copy every shared library those binaries use. Plus all the data and other files they might need. This is non-trivial. silently screams. It's equally non-trivial for initramfs, yet nobody seems to be raising this objection for that. Why is nobody else on this thread willing to take up its main point, the exact equivalence between the known, ugly, initramfs solution and the as yet half-baked idea of putting the same binaries into /sbin? Well, for one, the initramfs solution is not generally considered ugly except by a select vocal few who object to it on vague, unarticulated grounds. That notwithstanding: The binaries on the initramfs are not always the same as the ones installed in the system; frequently they are statically linked versions, or stripped-down versions, or otherwise unsuitable for being used after the full system is booted. (Dracut, for example, forces you to add USE=static-libs to a lot of the packages it wants to put into your initramfs image.) Putting those binaries into the execution path of the system is a bad idea because you don't always them to run once the system has booted -- I want the full set of udev rules, not the bare handful that my initramfs has on it. I agree with most of what you say; however, I believe you are mistaken about the static nature of the binaries in the initramfs created by dracut. I use dracut with the whole bang (plymouth, systemd, udev, you name it), and I don't have *any* of my packages compiled with static-libs. Even more, my system right now runs everything with -static-libs. I like to think (and, unless I missed something, that's in fact the truth) that my initramfs is actually more or less in sync with my running system, and I update it a lot, since it's trivial to do so with dracut. Outside of that, I agree with everything you say. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
