waiting for root file system
Hi, I changed motherboards and now when I boot I get waiting for root file system. But the disks have not changed, they are the same ones as with the old motherboard. All partitions are labelled. One disk had a USB connection on the old motherboard and now has a SATA connection. Fstab and grub use labels for everything. Debian's stock kernel boots correctly without problems, just my homegrown kernel doesn't boot, but it booted with the old motherboard. So there is *something* in my homegrown kernel that causes that message. Anybody venture a guess as to what it might be? This is with Sid updated. Hugo -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/icbfi9$m4...@dough.gmane.org
Re: waiting for root file system
Camaleón wrote: On Sun, 21 Nov 2010 09:58:00 -0600, Hugo Vanwoerkom wrote: I changed motherboards and now when I boot I get waiting for root file system. (...) Same motherboard or a different (brand/model) one? Different motherboard/cpu/memory old:epox 8VTAI new:asus M4N98TD EVO + AthlonII AM3 + 4GB How are the sata BIOS settings now and then (sata/ahci/raid)? Maybe you need to load a kernel module that was present in the old system (sata) but now is not available in the new one (ahci)? Old mobo could not use sata, did not use it + no raid. New mobo uses sata, still don't use raid. New mobo has 1 sata disk that was USB in old mobo and sata dvd burner. Or maybe your GRUB has to be properly updated for looking into the right root (hdx,n) device? Let me do a grub-install, but it finds the root device and boots it, but it hangs after initrd with waiting for root file system Hugo -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/icbivf$4n...@dough.gmane.org
Re: waiting for root file system
On Sun, 21 Nov 2010 09:58:00 -0600, Hugo Vanwoerkom wrote: I changed motherboards and now when I boot I get waiting for root file system. (...) Same motherboard or a different (brand/model) one? How are the sata BIOS settings now and then (sata/ahci/raid)? Maybe you need to load a kernel module that was present in the old system (sata) but now is not available in the new one (ahci)? Or maybe your GRUB has to be properly updated for looking into the right root (hdx,n) device? Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.11.21.16.28...@gmail.com
Re: waiting for root file system
On Sun, 21 Nov 2010 10:55:53 -0600, Hugo Vanwoerkom wrote: Camaleón wrote: (...) Or maybe your GRUB has to be properly updated for looking into the right root (hdx,n) device? Let me do a grub-install, but it finds the root device and boots it, but it hangs after initrd with waiting for root file system So, you have changed not only the board but also the disk interface (it was ide and now is sata)? Does the new kernel has libata module loaded? Maybe now is a good time for you to put your Grub's menu config (either upload the full file to an external server or attach the file to the message). Also, include the output of fdisk -l that will help us to get a better understanding of your current system structure :-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.11.21.18.07...@gmail.com
Re: waiting for root file system
Camaleón wrote: On Sun, 21 Nov 2010 10:55:53 -0600, Hugo Vanwoerkom wrote: Camaleón wrote: (...) Or maybe your GRUB has to be properly updated for looking into the right root (hdx,n) device? Let me do a grub-install, but it finds the root device and boots it, but it hangs after initrd with waiting for root file system So, you have changed not only the board but also the disk interface (it was ide and now is sata)? Does the new kernel has libata module loaded? It was a sata disk in an external enclosure connected with USB, now it is in the same enclosure but conneceted with SATA cable. Maybe now is a good time for you to put your Grub's menu config (either upload the full file to an external server or attach the file to the message). Also, include the output of fdisk -l that will help us to get a better understanding of your current system structure :-) I can't attach files: TB hangs forever then, will register via yahoo! After 'waiting for root file system' and the 5 minute wait, initrd drops to a shell and says /dev/dis/by-label/wd80_0jd-60.06 does not exist and sure enough it don't and that us the new sata connection. So there is a sata module missing fro initrd. Hugo -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/icbnrd$qc...@dough.gmane.org
Re: waiting for root file system
Maybe now is a good time for you to put your Grub's menu config (either upload the full file to an external server or attach the file to the message). Also, include the output of fdisk -l that will help us to get a better understanding of your current system structure :-) I use SGD. I attach it's menu.lst 2.6.36-trunk-686-bigmem from E03/04 on SDA6 [SDB6]*gen'd here* runs fine, that's where I am now. 2.6.36-hvw bigmem from E03/04 on SDA6 [SDB6]*gen'd here* is the one I have prob. with. I also attach fdisk -l, the partition I am trying to boot is sda6, with my own kernel: it boots fine with Debian 2.6.36-trunk-686-bigmem menu.lst Description: Binary data 11.fdisk Description: Binary data
Re: waiting for root file system
On Sun, 21 Nov 2010 12:19:24 -0600, Hugo Vanwoerkom wrote: Camaleón wrote: So, you have changed not only the board but also the disk interface (it was ide and now is sata)? Does the new kernel has libata module loaded? It was a sata disk in an external enclosure connected with USB, now it is in the same enclosure but conneceted with SATA cable. O.k. Maybe now is a good time for you to put your Grub's menu config (either upload the full file to an external server or attach the file to the message). Also, include the output of fdisk -l that will help us to get a better understanding of your current system structure :-) I can't attach files: TB hangs forever then, will register via yahoo! You mean Thunderbird is facing any problem? :-? You can still upload the content of the files to www.pastebin.com After 'waiting for root file system' and the 5 minute wait, initrd drops to a shell and says /dev/dis/by-label/wd80_0jd-60.06 does not exist and sure enough it don't and that us the new sata connection. So there is a sata module missing fro initrd. It should exist, but maybe now Grub detects it in another location (hd1,0) or (hd0,1) or... Ah, I forgot to say that you can always play with GRUB at booting menu. You have to reach GRUB console (by pressing c?) and try to manually get further information about the new location of the device, for example: grub find /boot/vmlinuz find /boot/vmlinuz (hd0,1) And compare that information with the current root (hdx,n) stanza. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.11.21.18.47...@gmail.com
Re: waiting for root file system
Camaleón wrote: On Sun, 21 Nov 2010 12:19:24 -0600, Hugo Vanwoerkom wrote: Camaleón wrote: So, you have changed not only the board but also the disk interface (it was ide and now is sata)? Does the new kernel has libata module loaded? It was a sata disk in an external enclosure connected with USB, now it is in the same enclosure but conneceted with SATA cable. O.k. Maybe now is a good time for you to put your Grub's menu config (either upload the full file to an external server or attach the file to the message). Also, include the output of fdisk -l that will help us to get a better understanding of your current system structure :-) I can't attach files: TB hangs forever then, will register via yahoo! You mean Thunderbird is facing any problem? :-? I dislike TB,ID. At any moment it will not post but is waiting You can still upload the content of the files to www.pastebin.com After 'waiting for root file system' and the 5 minute wait, initrd drops to a shell and says /dev/dis/by-label/wd80_0jd-60.06 does not exist and sure enough it don't and that us the new sata connection. So there is a sata module missing fro initrd. It should exist, but maybe now Grub detects it in another location (hd1,0) or (hd0,1) or... Ah, I forgot to say that you can always play with GRUB at booting menu. You have to reach GRUB console (by pressing c?) and try to manually get further information about the new location of the device, for example: grub find /boot/vmlinuz find /boot/vmlinuz (hd0,1) And compare that information with the current root (hdx,n) stanza. I found the culprit: something you mentioned: AHCI. After making the an M I can boot the system. Now find out why my USB devices are not connected. Pretty good. Thanks. Hugo -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/icbsfa$ge...@dough.gmane.org
Waiting for root file system ...
(NOTE: please ignore my earlier and utterly misinformed plea for help. turns out that, in attempting to mount /dev/sda1 as the alleged root filesystem, the new 2.6 kernel was finding the external backup hard drive at /dev/sda1. no surprise that that wasn't bootable. ack.) so now i'm getting what appears to be another common diagnostic as seen in the subject line. i can see that a common reason is the remapping of device names from hda - sda. however, even under the old 2.4 kernel on this upgraded etch system, the devices were accessed via sda (megaraid raid controller). so the advice to rename from hda to sda isn't relevant. (but is there something else about the megaraid controller that might be relevant? i've opened up the relevant initrd image and it does in fact contain megaraid modules.) thoughts? the last few lines of boot diagnostics are: Done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Done. Begin: Waiting for root file system ... then ... hang. it's pretty clearly a problem in just seeing/accessing the sole hard drive in the system. i just can't see what it is. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
Robert P. J. Day 写道: (NOTE: please ignore my earlier and utterly misinformed plea for help. turns out that, in attempting to mount /dev/sda1 as the alleged root filesystem, the new 2.6 kernel was finding the external backup hard drive at /dev/sda1. no surprise that that wasn't bootable. ack.) so now i'm getting what appears to be another common diagnostic as seen in the subject line. i can see that a common reason is the remapping of device names from hda - sda. however, even under the old 2.4 kernel on this upgraded etch system, the devices were accessed via sda (megaraid raid controller). so the advice to rename from hda to sda isn't relevant. (but is there something else about the megaraid controller that might be relevant? i've opened up the relevant initrd image and it does in fact contain megaraid modules.) thoughts? the last few lines of boot diagnostics are: Done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Done. Begin: Waiting for root file system ... then ... hang. it's pretty clearly a problem in just seeing/accessing the sole hard drive in the system. i just can't see what it is. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday How about dig into your system with a live CD to see the device mapping in your system? And by the way, have you ever upgraded a sarge system with 2.4 kernel to a 2.6 lenny system? Will changing from hda to sda be sufficient? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
On Fri, 21 Aug 2009, Niu Kun wrote: Robert P. J. Day 写道: (NOTE: please ignore my earlier and utterly misinformed plea for help. turns out that, in attempting to mount /dev/sda1 as the alleged root filesystem, the new 2.6 kernel was finding the external backup hard drive at /dev/sda1. no surprise that that wasn't bootable. ack.) so now i'm getting what appears to be another common diagnostic as seen in the subject line. i can see that a common reason is the remapping of device names from hda - sda. however, even under the old 2.4 kernel on this upgraded etch system, the devices were accessed via sda (megaraid raid controller). so the advice to rename from hda to sda isn't relevant. (but is there something else about the megaraid controller that might be relevant? i've opened up the relevant initrd image and it does in fact contain megaraid modules.) thoughts? the last few lines of boot diagnostics are: Done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Done. Begin: Waiting for root file system ... then ... hang. it's pretty clearly a problem in just seeing/accessing the sole hard drive in the system. i just can't see what it is. How about dig into your system with a live CD to see the device mapping in your system? already did that with a gentoo-based rescue CD, the current sda nomenclature worked just fine. i could mount /dev/sda1, and it is the root filesystem i'm going after, and it's what's in the grub conf file. And by the way, have you ever upgraded a sarge system with 2.4 kernel to a 2.6 lenny system? that is the *ultimate* goal, but i'm doing this in steps. on the chance that it's the default 2.6.18 etch kernel, i just upgraded that to the 2.6.24 etchnhalf kernel. we'll see if that fixes things. Will changing from hda to sda be sufficient? even the 2.4.27 kernel under sarge was using sda notation already, since the single hard drive was on a megaraid controller. so the standard solution of s/hda/sda/g wasn't relevant here. anyway, time to test the newly-installed 2.6.24 kernel. we'll see if that fixed anything. rday p.s. this system started out as a not-fully-upgraded sarge system. in steps, i brought it up to a fully-upgraded etch system but still running the 2.4.27 kernel, after which i followed the docs to upgrade the kernel to the default 2.6.18 etch kernel. and that's when things failed to boot. so, just for the heck of it, i installed the 2.6.24 etchnhalf kernel as well. now we'll see. -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: Waiting for root file system ...
Robert P. J. Day 写道: On Fri, 21 Aug 2009, Niu Kun wrote: Robert P. J. Day 写道: (NOTE: please ignore my earlier and utterly misinformed plea for help. turns out that, in attempting to mount /dev/sda1 as the alleged root filesystem, the new 2.6 kernel was finding the external backup hard drive at /dev/sda1. no surprise that that wasn't bootable. ack.) so now i'm getting what appears to be another common diagnostic as seen in the subject line. i can see that a common reason is the remapping of device names from hda - sda. however, even under the old 2.4 kernel on this upgraded etch system, the devices were accessed via sda (megaraid raid controller). so the advice to rename from hda to sda isn't relevant. (but is there something else about the megaraid controller that might be relevant? i've opened up the relevant initrd image and it does in fact contain megaraid modules.) thoughts? the last few lines of boot diagnostics are: Done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Done. Begin: Waiting for root file system ... then ... hang. it's pretty clearly a problem in just seeing/accessing the sole hard drive in the system. i just can't see what it is. How about dig into your system with a live CD to see the device mapping in your system? already did that with a gentoo-based rescue CD, the current sda nomenclature worked just fine. i could mount /dev/sda1, and it is the root filesystem i'm going after, and it's what's in the grub conf file. And by the way, have you ever upgraded a sarge system with 2.4 kernel to a 2.6 lenny system? that is the *ultimate* goal, but i'm doing this in steps. on the chance that it's the default 2.6.18 etch kernel, i just upgraded that to the 2.6.24 etchnhalf kernel. we'll see if that fixes things. Will changing from hda to sda be sufficient? even the 2.4.27 kernel under sarge was using sda notation already, since the single hard drive was on a megaraid controller. so the standard solution of s/hda/sda/g wasn't relevant here. anyway, time to test the newly-installed 2.6.24 kernel. we'll see if that fixed anything. rday p.s. this system started out as a not-fully-upgraded sarge system. in steps, i brought it up to a fully-upgraded etch system but still running the 2.4.27 kernel, after which i followed the docs to upgrade the kernel to the default 2.6.18 etch kernel. and that's when things failed to boot. so, just for the heck of it, i installed the 2.6.24 etchnhalf kernel as well. now we'll see. -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday Have you ever run update-initramfs command manually on the pre-compiled kernel? I remember that I fixed such a problem once. Hope this will help. And look forward to your feedback. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
On Fri, 21 Aug 2009, Robert P. J. Day wrote: that is the *ultimate* goal, but i'm doing this in steps. on the chance that it's the default 2.6.18 etch kernel, i just upgraded that to the 2.6.24 etchnhalf kernel. we'll see if that fixes things. upgrading to the 2.6.24 etchnhalf kernel didn't fix anything, same error at same location. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
On Fri, 21 Aug 2009, Niu Kun wrote: Have you ever run update-initramfs command manually on the pre-compiled kernel? I remember that I fixed such a problem once. Hope this will help. And look forward to your feedback. nope -- as i mentioned earlier, i'm fairly new to debian so a good deal of this i'm doing for the first time. i'm certainly willing to try this and, to play it safe, i'll try to update *only* the initramfs for that earlier 2.6.18 kernel (i don't want to touch the working initrd for the 2.4.27 kernel, for obvious reasons). is it as simple as # update-initramfs -k 2.6.18 ??? rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
Robert P. J. Day wrote: On Fri, 21 Aug 2009, Niu Kun wrote: Have you ever run update-initramfs command manually on the pre-compiled kernel? I remember that I fixed such a problem once. Hope this will help. And look forward to your feedback. nope -- as i mentioned earlier, i'm fairly new to debian so a good deal of this i'm doing for the first time. i'm certainly willing to try this and, to play it safe, i'll try to update *only* the initramfs for that earlier 2.6.18 kernel (i don't want to touch the working initrd for the 2.4.27 kernel, for obvious reasons). is it as simple as # update-initramfs -k 2.6.18 ??? Hi, I'm using custom kernel but I played also with the default one. I already posted once that there is a problem with the update-initramfs ro the make equivalent. The problem is that if you are using let say 2.6.18 and upgrade to 2.6.24 the program is using the information available to the system (which modules would be included in the initrd disk). So if I haved some module compiled in in 2.6.18 it will not be included in the new initrd. Seems that here the opposite happens. You get your megaraid drivers included and you don't want to have them in. I'm not sure if blacklist is working in initram. I think it's safe to remove them from the archive. The other think would be possibly to set the bios not to map the magaraid device to the first bootable. and last but not least it's pretty tricky to boot broken initram but not too hard if you know the steps. regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
Emanoil Kotsev 写道: Robert P. J. Day wrote: On Fri, 21 Aug 2009, Niu Kun wrote: Have you ever run update-initramfs command manually on the pre-compiled kernel? I remember that I fixed such a problem once. Hope this will help. And look forward to your feedback. nope -- as i mentioned earlier, i'm fairly new to debian so a good deal of this i'm doing for the first time. i'm certainly willing to try this and, to play it safe, i'll try to update *only* the initramfs for that earlier 2.6.18 kernel (i don't want to touch the working initrd for the 2.4.27 kernel, for obvious reasons). is it as simple as # update-initramfs -k 2.6.18 ??? Hi, I'm using custom kernel but I played also with the default one. I already posted once that there is a problem with the update-initramfs ro the make equivalent. The problem is that if you are using let say 2.6.18 and upgrade to 2.6.24 the program is using the information available to the system (which modules would be included in the initrd disk). So if I haved some module compiled in in 2.6.18 it will not be included in the new initrd. Seems that here the opposite happens. You get your megaraid drivers included and you don't want to have them in. I'm not sure if blacklist is working in initram. I think it's safe to remove them from the archive. The other think would be possibly to set the bios not to map the magaraid device to the first bootable. and last but not least it's pretty tricky to boot broken initram but not too hard if you know the steps. Would you please say something about this? Or any useful link that can be referenced? regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
ok, here's what i think i've discovered (given that, again, i'm a
relative newcomer to debian), so i'm going to ask some dumb questions
which might go a long way to clarifying some things.
no matter what i tried, when i booted this (recently upgraded to)
etch system to the newly-installed 2.6 kernel (either 2.6.18 or
2.6.24, either original or rebuilt), i got:
Waiting for root file system...
and it hung, with all evidence pointing to the fact that the booting
system simply couldn't see the hard drive, which it could see under
the earlier (devfs-enabled) 2.4.27 kernel given the right megaraid
drivers being loaded in that earlier kernel.
so i ripped open the initrd file (something i have done
many, many times under other circumstances), and went looking for
the script that printed Waiting for root file system..., which i
found at scripts/local, specifically this excerpt:
=
# If the root device hasn't shown up yet, give it a little while
# to deal with removable devices
if [ ! -e ${ROOT} ]; then
log_begin_msg Waiting for root file system...
# Default delay is 180s
if [ -z ${ROOTDELAY} ]; then
slumber=180
else
slumber=${ROOTDELAY}
fi
if [ -x /sbin/usplash_write ]; then
/sbin/usplash_write TIMEOUT ${slumber} || true
fi
slumber=$(( ${slumber} * 10 ))
while [ ${slumber} -gt 0 ] [ ! -e ${ROOT} ]; do
/bin/sleep 0.1
slumber=$(( ${slumber} - 1 ))
done
if [ ${slumber} -gt 0 ]; then
log_end_msg 0
else
log_end_msg 1 || true
fi
if [ -x /sbin/usplash_write ]; then
/sbin/usplash_write TIMEOUT 15 || true
fi
fi
# We've given up, but we'll let the user fix matters if they can
while [ ! -e ${ROOT} ]; do
echo Check root= bootarg cat /proc/cmdline
echo or missing modules, devices: cat /proc/modules ls /dev
panic ALERT! ${ROOT} does not exist. Dropping to a shell!
done
=
that's when i noticed the 180 second delay, and since i'd never
actually waited that long previously, this time i was patient and,
sure enough, after 3 minutes, i got those diagnostics shown at the
end and dumped into busybox.
and once i was in busybox, i verified that:
* there were no /dev/sda* entries
* /proc/cmdline did indeed contain root=/dev/sda1, which is
correct
* the modules megaraid_mm and megaraid_mbox were loaded
* there are no megaraid rules in /etc/udev
this seems to be a pretty clear indication that i just need to add
a udev rule file for the megaraid modules to create the /dev/sda*
entries, yes? because without *something* creating those /dev/sda*
entries, i'm pretty well doomed to failure, yes?
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
Niu Kun wrote:
and last but not least it's pretty tricky to boot broken initram but not
too hard if you know the steps.
Would you please say something about this?
Or any useful link that can be referenced?
regards
First of all I would try to provide the root kernel option. If you know your
root is now on sdb1 you could say root=/dev/sdb1 (see step 1 below). This
should work.
The harder way is, assuming you have bootable kernel and initrd, to run the
shell instead of executing the init file
1) you have something in the bootloader (here grub as example)
root(hd0,0)
kernel /vmlinuz-2.6.30eko2 quiet ro splash
initrd /initrd-2.6.30eko2
1a) press 'e' for edit
1b) move to kernel line and press 'e' for edit again
1c) write at the end of the line
init=/bin/sh
1d) press enter
1e) press b (for boot)
= you are in the limited shell
2) here identify your disk (start mds. lvm crypt or whatever)
mount -t proc none /proc
3) mount root somewhere
mkdir /new
mount -ro path_to_your_root /new
cd /new
4) (you could actually do anything with your system at this stage, because
you have all the commands, so) type following to run through the boot
process
exec /usr/sbin/chroot . /bin/sh - EOF dev/console 21
exec /sbin/init ${CMDLINE}
EOF
the three lines above are just great. I don't remember if it was used before
in debian or somewhere else, where I've got it years ago.
now debian is using
exec run-init ${rootmnt} ${init} $@ ${rootmnt}/dev/console
${rootmnt}/dev/console
Which you may prefer, but have to decifer what all those variables are good
for
5) after booting your system recreate initrd (update/mkinitramfs)
(watch out to backup the initrd with which you could at least reach the
limited shell), so if the new one does not work you can repeat the
procedure.
I hope this helps
regards
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
Emanoil Kotsev 写道:
Niu Kun wrote:
and last but not least it's pretty tricky to boot broken initram but not
too hard if you know the steps.
Would you please say something about this?
Or any useful link that can be referenced?
regards
First of all I would try to provide the root kernel option. If you know your
root is now on sdb1 you could say root=/dev/sdb1 (see step 1 below). This
should work.
The harder way is, assuming you have bootable kernel and initrd, to run the
shell instead of executing the init file
1) you have something in the bootloader (here grub as example)
root(hd0,0)
kernel /vmlinuz-2.6.30eko2 quiet ro splash
initrd /initrd-2.6.30eko2
1a) press 'e' for edit
1b) move to kernel line and press 'e' for edit again
1c) write at the end of the line
init=/bin/sh
1d) press enter
1e) press b (for boot)
= you are in the limited shell
2) here identify your disk (start mds. lvm crypt or whatever)
mount -t proc none /proc
3) mount root somewhere
mkdir /new
mount -ro path_to_your_root /new
cd /new
4) (you could actually do anything with your system at this stage, because
you have all the commands, so) type following to run through the boot
process
exec /usr/sbin/chroot . /bin/sh - EOF dev/console 21
exec /sbin/init ${CMDLINE}
EOF
the three lines above are just great. I don't remember if it was used before
in debian or somewhere else, where I've got it years ago.
now debian is using
exec run-init ${rootmnt} ${init} $@ ${rootmnt}/dev/console
${rootmnt}/dev/console
Which you may prefer, but have to decifer what all those variables are good
for
5) after booting your system recreate initrd (update/mkinitramfs)
(watch out to backup the initrd with which you could at least reach the
limited shell), so if the new one does not work you can repeat the
procedure.
I hope this helps
regards
Pretty cool.
Really appreciate your detailed reply.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
Niu Kun wrote: Pretty cool. Really appreciate your detailed reply. NP. hope it helps or gives you at least an idea how I'm doing this. I've had several times related issues as I've been using raid/lvm and also encryption, so years ago I wrote my own scripts to create initrd etc... and despite debian improved and I'm not using it, it's still good to know. regards PS: It's pretty hot here (friday afternoon) and I gave my part to the community ;-) ... think it's getting party time soon though. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
Robert P. J. Day 写道:
ok, here's what i think i've discovered (given that, again, i'm a
relative newcomer to debian), so i'm going to ask some dumb questions
which might go a long way to clarifying some things.
no matter what i tried, when i booted this (recently upgraded to)
etch system to the newly-installed 2.6 kernel (either 2.6.18 or
2.6.24, either original or rebuilt), i got:
Waiting for root file system...
and it hung, with all evidence pointing to the fact that the booting
system simply couldn't see the hard drive, which it could see under
the earlier (devfs-enabled) 2.4.27 kernel given the right megaraid
drivers being loaded in that earlier kernel.
so i ripped open the initrd file (something i have done
many, many times under other circumstances), and went looking for
the script that printed Waiting for root file system..., which i
found at scripts/local, specifically this excerpt:
=
# If the root device hasn't shown up yet, give it a little while
# to deal with removable devices
if [ ! -e ${ROOT} ]; then
log_begin_msg Waiting for root file system...
# Default delay is 180s
if [ -z ${ROOTDELAY} ]; then
slumber=180
else
slumber=${ROOTDELAY}
fi
if [ -x /sbin/usplash_write ]; then
/sbin/usplash_write TIMEOUT ${slumber} || true
fi
slumber=$(( ${slumber} * 10 ))
while [ ${slumber} -gt 0 ] [ ! -e ${ROOT} ]; do
/bin/sleep 0.1
slumber=$(( ${slumber} - 1 ))
done
if [ ${slumber} -gt 0 ]; then
log_end_msg 0
else
log_end_msg 1 || true
fi
if [ -x /sbin/usplash_write ]; then
/sbin/usplash_write TIMEOUT 15 || true
fi
fi
# We've given up, but we'll let the user fix matters if they can
while [ ! -e ${ROOT} ]; do
echo Check root= bootarg cat /proc/cmdline
echo or missing modules, devices: cat /proc/modules ls
/dev
panic ALERT! ${ROOT} does not exist. Dropping to a shell!
done
=
that's when i noticed the 180 second delay, and since i'd never
actually waited that long previously, this time i was patient and,
sure enough, after 3 minutes, i got those diagnostics shown at the
end and dumped into busybox.
and once i was in busybox, i verified that:
* there were no /dev/sda* entries
* /proc/cmdline did indeed contain root=/dev/sda1, which is
correct
* the modules megaraid_mm and megaraid_mbox were loaded
* there are no megaraid rules in /etc/udev
this seems to be a pretty clear indication that i just need to add
a udev rule file for the megaraid modules to create the /dev/sda*
entries, yes? because without *something* creating those /dev/sda*
entries, i'm pretty well doomed to failure, yes?
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
So here, your best choice seems to try.
here's my z60_hdparm.rules file:
ACTION==add, SUBSYSTEM==block, KERNEL==[sh]d[a-z],
RUN+=/etc/init.d/hdparm hotplug
Hope this helps.
At least it's been working with me for at least one year without any
problem.
I'm using debian testing branch.
But etch's udev seems to be 0.105.
Mine is 0.125.
Don't know if the rule is the same.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
On Sat, 22 Aug 2009, Niu Kun wrote: (with respect to getting my /dev/sda* device files built) So here, your best choice seems to try. here's my z60_hdparm.rules file: i'm assuming that's a brand new rules file, right? not just adding to an existing rules file since i have no such file. ACTION==add, SUBSYSTEM==block, KERNEL==[sh]d[a-z], RUN+=/etc/init.d/hdparm hotplug Hope this helps. um ... i have no config file /etc/init.d/hdparm. at all. does that belong to a package i should install? and would that explain why i have no hdparm udev rules file? At least it's been working with me for at least one year without any problem. I'm using debian testing branch. But etch's udev seems to be 0.105. Mine is 0.125. Don't know if the rule is the same. on this system, it's 0.105. and i'm assuming that, after i modify my udev rules, i have to rebuild my initrd, yes? do i understand correctly that that would bundle my entire udev directory inside the initrd, so that i get the effect of those changes? that would make sense. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
On Fri, 21 Aug 2009, Robert P. J. Day wrote: On Sat, 22 Aug 2009, Niu Kun wrote: (with respect to getting my /dev/sda* device files built) So here, your best choice seems to try. here's my z60_hdparm.rules file: i'm assuming that's a brand new rules file, right? not just adding to an existing rules file since i have no such file. ACTION==add, SUBSYSTEM==block, KERNEL==[sh]d[a-z], RUN+=/etc/init.d/hdparm hotplug Hope this helps. um ... i have no config file /etc/init.d/hdparm. at all. does that belong to a package i should install? and would that explain why i have no hdparm udev rules file? i just installed the hdparm package and i now have all of the above. but i still need to verify that i have to recreate my initrd with that new content, otherwise it won't do me any good just sitting on the hard drive, correct? rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
Robert P. J. Day 写道: On Fri, 21 Aug 2009, Robert P. J. Day wrote: On Sat, 22 Aug 2009, Niu Kun wrote: (with respect to getting my /dev/sda* device files built) So here, your best choice seems to try. here's my z60_hdparm.rules file: i'm assuming that's a brand new rules file, right? not just adding to an existing rules file since i have no such file. ACTION==add, SUBSYSTEM==block, KERNEL==[sh]d[a-z], RUN+=/etc/init.d/hdparm hotplug Hope this helps. um ... i have no config file /etc/init.d/hdparm. at all. does that belong to a package i should install? and would that explain why i have no hdparm udev rules file? i just installed the hdparm package and i now have all of the above. but i still need to verify that i have to recreate my initrd with that new content, otherwise it won't do me any good just sitting on the hard drive, correct? You're right at least for me.:) Wish you good luck. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system ...
On Sat, 22 Aug 2009, Niu Kun wrote: Robert P. J. Day 写道: On Fri, 21 Aug 2009, Robert P. J. Day wrote: On Sat, 22 Aug 2009, Niu Kun wrote: (with respect to getting my /dev/sda* device files built) So here, your best choice seems to try. here's my z60_hdparm.rules file: i'm assuming that's a brand new rules file, right? not just adding to an existing rules file since i have no such file. ACTION==add, SUBSYSTEM==block, KERNEL==[sh]d[a-z], RUN+=/etc/init.d/hdparm hotplug Hope this helps. um ... i have no config file /etc/init.d/hdparm. at all. does that belong to a package i should install? and would that explain why i have no hdparm udev rules file? i just installed the hdparm package and i now have all of the above. but i still need to verify that i have to recreate my initrd with that new content, otherwise it won't do me any good just sitting on the hard drive, correct? You're right at least for me.:) Wish you good luck. nope, that failed, and here's why: there's no /etc/init.d directory in the initrd. /etc/udev is there, and the hdparm-related files are there in /etc/udev, and they look correct, but how could that possibly have any effect unless the corresponding /etc/init.d/hdparm script was in the initrd as well? i only noticed that after the boot once again timed out, fell into busybox, after which i tried to run # /etc/init.d/hdparm hotplug manually, and noticed it was missing. how is this supposed to work without that script in the initrd? or am i just totally confused by now? rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Hang on reboot with: Waiting for root file system
Dear all, I've got an old Debian sarge box. And I want to upgrade it to the newest lenny stable version. I've encountered the problem mentioned in the following link: http://www200.pair.com/mecham/spam/kernel.html I had tried to upgrade my system to etch once, but the system failed to boot after that. Fortunately, the old 2.4.27 kernel can still be used. Surprisingly, I found my libc6 version was 2.3.6.ds1-13etch5. This means that the old 2.4.27 kernel can do well with a new libc6. Now I want to upgrade my system to the latest stable lenny. So it'll be a little risky for me to use the old kernel with the new libc6 library, if the new 2.6.26 kernel still fails to boot this time. Since I'm thousands of kilometers away from the system, I can't protect my system after a boot failure. So I'm here to see if anyone has the same problem with me. And if so, would you please share your upgrade experience with me? Thanks for any attention and your precious time in advance. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system...
On Jan 23, 4:00 pm, lovecreatesbeauty.g-mail.c0m lovecreatesbea...@gmail.com wrote: kernel /boot/vmlinuz-2.6.28.1 root=/dev/sda1 ro initrd /boot/initrd.img-2.6.28.1 sorry the occurences of 28.1 above should be 28 . -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Waiting for root file system...
On Friday 2009 January 23 01:38:57 lovecreatesbeauty.g-mail.c0m wrote: I updated kernel on debian-40r6 (2.6.18) to 2.6.28 from kernel.org, and got the error* Waiting for root file system... when booting the new kernel. Ah, I've seen that a few times, myself. The linux's hosted in VMware Workstation 6.0. The commands I issued were: make defconfig, make, make modules_install install, update- initramfs -c -k 2.6.28. I don't use VMWare, so I'm just going to ignore that specific piece of information, assuming it is irrelevant. So, I guess not a Debian kernel then. Have you tried this setup with the kernel packages available in Lenny/Sid? Most likely, you are missing the module for the virtual disk. make defconfig is something I've never used, but it is certainly possible that the kernel configuration that it generated is missing something you need to access your drives. If you need a more recent kernel than is currently packaged by Debian, you might try using make menuconfig *after* make defconfig and enabling more options. The /etc/fstab contains: /dev/sda1 / ext3defaults,errors=remount-ro 0 1 /dev/sda5 noneswapsw 0 0 Simple enough. The /boot/grub/menu.lst contains: root(hd0,0) kernel /boot/vmlinuz-2.6.18-6-686 root=/dev/sda1 ro initrd /boot/initrd.img-2.6.18-6-686 root(hd0,0) kernel /boot/vmlinuz-2.6.28.1 root=/dev/sda1 ro initrd /boot/initrd.img-2.6.28.1 So, 2.6.18-6-686 is your Debian kernel I guess. Still Etch from the looks of it. Does that GRUB option work, or does it also leave you at Waiting for root file system...? If it works you might try taking the config-2.6.18-6-686 from /boot and using it as a basis for make oldconfig on the new kernel. No guarantees though, make oldconfig is not necessarily robust when making such large changes (.18 - .28). Some said that** there will be no /dev/sda1 for the new kernel, but how can i know the replacement for it in new kernel? After the message Waiting for root file system..., the new kernel dropped into BusyBox ash: Well, that's most likely the issue. In your specific setup (virtualized single disk) though, the name is probably the same (/dev/sda1) its just that you have to make sure the correct driver is loaded. You could be missing your filesystem driver as well, but ext3 is included in make defconfig, AFAIK. (initramfs) cat /etc/fstab cat: /etc/fstab: No such file or directory Yeah, the initramfs doesn't use an fstab. The /etc/fstab you are familiar with resides on /dev/sda1 and that is not mounted yet. Busybox is invoked when the Waiting... times out. (initramfs) cat /proc/partitions major minor #blocks name That's not good, and does seem to indicate that the driver for your disk is not being loaded. Right now, I don't know how to apply volume label or UUID to solve this problem. Thanks for your time and help. From within the initramfs, try: ls -l /dev/[shm]d* /dev/mapper /dev/disk/by-* That should list most of the block devices available to the initramfs. If yours in not there, you either missed a driver using the kernel configuration process (most likely), it didn't get placed into the initramfs (possible), or the initramfs did not load it for some unknown reason (probably not). -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ signature.asc Description: This is a digitally signed message part.
Waiting for root file system...
[I'm sorry if it's boring you] I updated kernel on debian-40r6 (2.6.18) to 2.6.28 from kernel.org, and got the error* Waiting for root file system... when booting the new kernel. The linux's hosted in VMware Workstation 6.0. The commands I issued were: make defconfig, make, make modules_install install, update- initramfs -c -k 2.6.28. The /etc/fstab contains: /dev/sda1 / ext3defaults,errors=remount-ro 0 1 /dev/sda5 noneswapsw 0 0 The /boot/grub/menu.lst contains: root(hd0,0) kernel /boot/vmlinuz-2.6.18-6-686 root=/dev/sda1 ro initrd /boot/initrd.img-2.6.18-6-686 root(hd0,0) kernel /boot/vmlinuz-2.6.28.1 root=/dev/sda1 ro initrd /boot/initrd.img-2.6.28.1 Some said that** there will be no /dev/sda1 for the new kernel, but how can i know the replacement for it in new kernel? After the message Waiting for root file system..., the new kernel dropped into BusyBox ash: (initramfs) cat /etc/fstab cat: /etc/fstab: No such file or directory (initramfs) cat /proc/partitions major minor #blocks name (initramfs) _ Right now, I don't know how to apply volume label or UUID to solve this problem. Thanks for your time and help. * http://seuofg.bay.livefilestore.com/y1pwb5OxK6exFQC9aQiV3UpYos-Xl9aoe-mMmC61y5PaonOPKX76buV29PSxr1gHf20SzOdGb9WWrojmTnKibSNAg/debian-40r6_linux-2.6.18_to_linux-2.6.28.jpg ** http://groups.google.com/group/linux.debian.user/msg/41d62fec9cdd8003?hl=en -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Waiting for root file system ....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bonjour, Petit problème avec un noyau compilé par mes soins, je me retrouve au démarrage avec le message Waiting for root file system et à vrai dire j'attends toujours Je démarre sans problème avec les images debian. Et jusqu'à voici peu de temps je n'avais pas de problème avec mes propres noyaux. En cherchant j'ai cru comprendre qu'il y avait un problème avec le paquet initramfs-tools mais la dernière version n'améliore pas les choses. Sur le PC à la maison, changer la ligne de boot de /dev/hdaX en /dev/sdaX solutionne semble t-il le problème mais il faut modifier le fstab et quelques autres fichiers, et je ne trouve pas cela satisfaisant. Sur le portable avec un disque SATA la parcontre j'ai déjà la ligne de commande en /dev/sdaX mais il ne trouve même pas le disque !!! Bref : avez vous déjà rencontré ce problème ? Avez vous des suggestions salvatrices ? Aurais-je oublié quelque chose ?? Merci mahashakti89 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklmREIACgkQS8dD2kMGDc32dQCggq5pwn5oKJZdWsCGPIUV0QHY Kv0An1qqxutdsOlzTnIoGYB2DJ3w4yGL =ClpG -END PGP SIGNATURE-
Re: Booting kernel 2.6.25 from Debian40r3 prompts: Waiting for root file system
On May 5, 5:40 am, Alex Samad [EMAIL PROTECTED] wrote: On Sun, May 04, 2008 at 03:50:28AM -0700, [EMAIL PROTECTED] wrote: $ cat /proc/partitions major minor #blocks name 8 08388608 sda 8 1 273073 sda1 8 2 1 sda2 8 53060351 sda5 8 61477948 sda6 8 7 273073 sda7 8 8 265041 sda8 8 93036253 sda9 $ ls -al /dev/sda brw-rw 1 root disk 8, 0 2008-05-05 02:46 /dev/sda $ was this done whilst trying to boot 2.6.25, if so mount /dev/sda1 and exit out and initramfs should continue on its way Did you mean I can run $ mount /dev/sda1 / if I had sda in the above record? In fact the above came with the 2.6.18. Sorry that I didn't state it clearly. The result after I boot the new built 2.6.25 is below. How can I correct it? Thank you. (initramfs) cat /proc/partitions major minor #blocks name 1 0 4096ram0 1 1 4096ram0 1 2 4096ram0 1 3 4096ram0 [output snipped] 1 15 4096ram15 (initramfs) ls /dev/sda ls: /dev/sda: No such file or directory (initramfs) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Booting kernel 2.6.25 from Debian40r3 prompts: Waiting for root file system
On May 4, 7:20 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [...] The mount reports this inside that broken newly built 2.6.25 (initramfs) mount none on /sys type sysfs (rw) none on /proc type proc (rw) udev on /udev type tmpfs (rw, size=10240k,mode=755) (initramfs) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Booting kernel 2.6.25 from Debian40r3 prompts: Waiting for root file system
On Mon, May 05, 2008 at 10:04:12AM -0700, [EMAIL PROTECTED] wrote: On May 5, 5:40 am, Alex Samad [EMAIL PROTECTED] wrote: On Sun, May 04, 2008 at 03:50:28AM -0700, [EMAIL PROTECTED] wrote: $ cat /proc/partitions major minor #blocks name 8 08388608 sda 8 1 273073 sda1 8 2 1 sda2 8 53060351 sda5 8 61477948 sda6 8 7 273073 sda7 8 8 265041 sda8 8 93036253 sda9 $ ls -al /dev/sda brw-rw 1 root disk 8, 0 2008-05-05 02:46 /dev/sda $ was this done whilst trying to boot 2.6.25, if so mount /dev/sda1 and exit out and initramfs should continue on its way Did you mean I can run $ mount /dev/sda1 / if I had sda in the above record? In fact the above came with the 2.6.18. Sorry that I didn't state it clearly. initramfs loads up a mini rootfs one of the directories is /rootfs (I think, haven't looked at it in a while), this is the location that it loads the root fs before doing a pivot root and then starting the system. The result after I boot the new built 2.6.25 is below. How can I correct it? Thank you. (initramfs) cat /proc/partitions major minor #blocks name 1 0 4096ram0 1 1 4096ram0 1 2 4096ram0 1 3 4096ram0 [output snipped] 1 15 4096ram15 (initramfs) ls /dev/sda ls: /dev/sda: No such file or directory (initramfs) by the looks of it initrd can't see your hard drives, are the proper modules loaded into initramfs ? try a lsmod and/or a ls -lR /lib/modules/*, whilst in initrd have a look in /etc/initramfs-tools/initramfs.conf especially at MODULES=most maybe yours is set to dep and initramfs is getting it wrong, then rebuild the initrd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- I promise you I will listen to what has been said here, even though I wasn't here. - George W. Bush 08/13/2002 Waco, TX Speaking at the President's Economic Forum signature.asc Description: Digital signature
Booting kernel 2.6.25 from Debian40r3 prompts: Waiting for root file system
Hi, It presents the following error when I'm booting kernel 2.6.25 from Debian40r3 with built-in kernel 2.6.18-6-486 in VMWare: Begin: Waiting for root file system... ... Done. Check root= bootarg cat /proc/cmdline or missing modules. devices: cat /proc/modules ls /dev ALERT! /dev/sda1 does not exist. /bin/sh: can't access tty: job control turned off (initramfs) uname -r 2.6.25 I read this post: Waiting for root file system... hang solved, then modify /boot/grub/menu.lst: title Debian GNU/Linux, kernel 2.6.18-6-486 root(hd0,0) #kernel /boot/vmlinuz-2.6.18-6-486 root=/dev/sda1 ro kernel /boot/vmlinuz-2.6.18-6-486 root=LABEL=LSDA1 ro initrd /boot/initrd.img-2.6.18-6-486 savedefault title Debian GNU/Linux, kernel 2.6.18-6-486 (single-user mode) root(hd0,0) kernel /boot/vmlinuz-2.6.18-6-486 root=/dev/sda1 ro single initrd /boot/initrd.img-2.6.18-6-486 savedefault title Debian GNU/Linux, kernel 2.6.25, udev not devfs root(hd0,0) kernel /boot/vmlinuz-2.6.25 root=LABEL=LSDA1 ro devfs=nomount initrd /boot/initrd.img-2.6.25 savedefault and the file /etc/fstab: proc/proc procdefaults0 0 #/dev/sda1 / ext3defaults,errors=remount-ro 0 1 LABEL=LSDA1 / ext3defaults,errors=remount-ro 0 1 /dev/sda9 /home ext3defaults0 2 And issue these commands: $ su -c 'e2label /dev/sda1 LSDA1' $ su -c 'update-initramfs -u -k all' The above one command report 2.6.18-6-486 but not 2.6.25 $ su -c 'update-initramfs -u -k 2.6.25' The above says /boot/initrd.img-2.6.25 was been altered. Cannot update. Then I try the following: $ su -c 'update-initramfs -c -k 2.6.25' $ su -c 'mkinitramfs -d /etc/initramfs-tools -o /boot/ initrd.img-2.6.25 2.6.25' I don't find /etc/uswsusp.conf mentioned in Cameron's post on my machine. This time, it can not find the LABEL prompting the similar error when I boot with 2.6.25: Begin: Waiting for root file system... ... Done. Check root= bootarg cat /proc/cmdline or missing modules. devices: cat /proc/modules ls /dev ALERT! /dev/disk/by-label/LSDA1 does not exist. But I can boot with the 2.6.18 kernel including the single mode, even I only use the LABEL way for one entry not the the other one - the single mode entry. The menu.lst is listed above. Under the (initramfs) prompt, the uname -r reports 2.6.25. Thank you for your time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Booting kernel 2.6.25 from Debian40r3 prompts: Waiting for root file system
On Sat, May 03, 2008 at 11:35:29PM -0700, [EMAIL PROTECTED] wrote: Hi, [snip] Under the (initramfs) prompt, the uname -r reports 2.6.25. what is the output of cat /proc/partitions, can you see /dev/sda. maybe the driver for you had is not in .25 Thank you for your time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Every man has his price. Mine is $3.95. signature.asc Description: Digital signature
Re: Booting kernel 2.6.25 from Debian40r3 prompts: Waiting for root file system
On May 4, 6:40 pm, Alex Samad [EMAIL PROTECTED] wrote: On Sat, May 03, 2008 at 11:35:29PM -0700, [EMAIL PROTECTED] wrote: Under the (initramfs) prompt, the uname -r reports 2.6.25. what is the output of cat /proc/partitions, can you see /dev/sda. maybe the driver for you had is not in .25 Hi, this is the result, $ cat /proc/partitions major minor #blocks name 8 08388608 sda 8 1 273073 sda1 8 2 1 sda2 8 53060351 sda5 8 61477948 sda6 8 7 273073 sda7 8 8 265041 sda8 8 93036253 sda9 $ ls -al /dev/sda brw-rw 1 root disk 8, 0 2008-05-05 02:46 /dev/sda $ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Booting kernel 2.6.25 from Debian40r3 prompts: Waiting for root file system
On Sun, May 04, 2008 at 03:50:28AM -0700, [EMAIL PROTECTED] wrote: On May 4, 6:40 pm, Alex Samad [EMAIL PROTECTED] wrote: On Sat, May 03, 2008 at 11:35:29PM -0700, [EMAIL PROTECTED] wrote: Under the (initramfs) prompt, the uname -r reports 2.6.25. what is the output of cat /proc/partitions, can you see /dev/sda. maybe the driver for you had is not in .25 Hi, this is the result, $ cat /proc/partitions major minor #blocks name 8 08388608 sda 8 1 273073 sda1 8 2 1 sda2 8 53060351 sda5 8 61477948 sda6 8 7 273073 sda7 8 8 265041 sda8 8 93036253 sda9 $ ls -al /dev/sda brw-rw 1 root disk 8, 0 2008-05-05 02:46 /dev/sda $ hi was this done whilst trying to boot 2.6.25, if so mount /dev/sda1 and exit out and initramfs should continue on its way -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- We both use Colgate toothpaste. - George W. Bush 02/23/2001 Camp David, MD after a reporter asked what he had in common with British Prime Minister Tony Blair signature.asc Description: Digital signature
Re: Waiting for root file system problem
[EMAIL PROTECTED] skrev: [This message has also been posted to linux.debian.user.] This is becoming a FAQ. There is a problem with udev. Before udev, there was a strong association between device names and devices. With udev, that association is much weaker. There's new randomness in how partitions are named during boot. Debian and other installers have not yet worked around this relatively new problem. What you're seeing is an effect of that. The udeb installer kernel got a different set of device names than the installed kernel did, and the root file system never appears where the installed kernel has been told it would. Yes, I noticed that I had to call the partition /dev/sda5 to boot with GRUB, but when booted Debian showed me the partition as /dev/sdc5 ! The workaround is to use file system labels or UUIDs not device names in /etc/fstab and /boot/grub/menu.lst. But the Debian 4.0 installer doesn't know that. Please read the discussion at http://www.debianhelp.org/node/11653 Yes, this worked fine. In article [EMAIL PROTECTED], dave N wrote: I booted with Knoppix live and there is nothing in /var/log/messages, none of the logs appear to have changed since I last booted 2 days ago. I have not run fsck or anything else on this yet. Apparently Knoppix doesn't use udev. Cameron I tried Knoppix too and found that my partition was called /dev/sda5 and used that information to edit the GRUB configuration in order to boot. And was surprised when the partition was called sdc5 after boot, exactly what was preventing boot in the GRUB configuration! Thanks for your explanation! I hope this inconsistency will be fixed in new Debian versions. Per Tunedal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Waiting for root file system problem
Florian Kulzer skrev: On Thu, Jan 03, 2008 at 06:39:11 -0500, dave N wrote: [...] Question: In the menu.lst grub file, how would I use the label assignment in the line: kernel /vmlinuz-2.6.18-5-686 root=/dev/sdc2 ro I think this should be OK: kernel /vmlinuz-2.6.18-5-686 root=LABEL=your_root_label ro I have # kopt=root=LABEL=my_root_label ro in my menu.lst and this works for all the auto-generated entries. Thanks for this very useful advice! I had the same problem and managed to log in simply by entering e at the GRUB-menu for editing the failing line. Afterwords I put a label on the partition with e2label and changed the reference in menu.lst It works like a charm! Per Tunedal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Waiting for root file system problem
[This message has also been posted to linux.debian.user.] This is becoming a FAQ. There is a problem with udev. Before udev, there was a strong association between device names and devices. With udev, that association is much weaker. There's new randomness in how partitions are named during boot. Debian and other installers have not yet worked around this relatively new problem. What you're seeing is an effect of that. The udeb installer kernel got a different set of device names than the installed kernel did, and the root file system never appears where the installed kernel has been told it would. The workaround is to use file system labels or UUIDs not device names in /etc/fstab and /boot/grub/menu.lst. But the Debian 4.0 installer doesn't know that. Please read the discussion at http://www.debianhelp.org/node/11653 In article [EMAIL PROTECTED], dave N wrote: I've installed Etch r1 and the only real thing I've done to the system is updated the system, though during the update it updated the kernel to the same kernel that was installed during the installation (used the medium to try and get more control over Grub install). During boot the system appears to find all the drives OK when I am reading as fast as I can, but then I get the following (from a photo of the screen messages) Begin: Mounting root file system... ... Begin: running /scripts/local-top ... ide0: I/O resource 0x1F0-0x1F7 not free. ide0: ports already in use, skipping probe ide1: I/O resource 0x170-0x177 not free. ide1: ports already in use, skipping probe Done. Begin: Waiting for root file system... ... And it stops right there. 0's above may be 8's, can't tell from the picture. I booted with Knoppix live and there is nothing in /var/log/messages, none of the logs appear to have changed since I last booted 2 days ago. I have not run fsck or anything else on this yet. Apparently Knoppix doesn't use udev. Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3rd SATA scrambles drive order? Begin: Waiting for root file system . . . . . .
- Original Message - From: NN_il_Confusionario [EMAIL PROTECTED] To: debian-user@lists.debian.org Sent: Friday, January 04, 2008 1:15 AM Subject: Re: 3rd SATA scrambles drive order? Begin: Waiting for root file system . . . . . . On Thu, Jan 03, 2008 at 11:52:29AM -0600, Jonathan Wilson wrote: Someone else said using IDs in fstab only works with ext2/3, obviously tune2fs does, and I use ReiserFS. What then? from man mount: It is possible to indicate a block special device using its volume label or UUID (see the -L and -U options below). One can set such a label for ext2 or ext3 using the e2label(8) utility, or for XFS using xfs_admin(8), or for reiserfs using reiserfstune(8). http://64.233.183.104/search?q=cache:r-vvdhBMOZAJ:www.namesys.com/faq.html+reiserfs+label+fstabhl=enct=clnkcd=4ie=UTF-8#fs-label (using this thread now, one thread by topic ...) My system seems to be one of those that periodically has the drive assignments changed so I am switching over to using LABEL=... I've been trying to find what the UUID of my swap file is but can't find it, been searching with Google for instructions but nothing works to get it. It's not listed under /dev/disk/by-uid either. I'm using ext3 file system but I believe swap is entirely different anyways. Should I somehow redo the swap partition specifying for it to create a UUID somehow or? Thanks Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3rd SATA scrambles drive order? Begin: Waiting for root file system . . . . . .
On Fri, Jan 04, 2008 at 07:23:06AM -0500, [EMAIL PROTECTED] wrote: I've been trying to find what the UUID of my swap file is but can't find blkid (as it was already suggested in this thread) from man blkid The blkid program is the command-line interface to working with libuuid(3) library. It can determine the type of content (e.g. filesystem, swap) a block device holds, and also attributes (tokens, NAME=value pairs) from the content metadata (e.g. LABEL or UUID fields). Should I somehow redo the swap partition specifying for it to create a UUID somehow or? Only if you want. From man mkswap -L label Specify a label, to allow swapon by label. (Only for new style swap areas.) -- Chi usa software non libero avvelena anche te. Digli di smettere. Informatica=arsenico: minime dosi in rari casi patologici, altrimenti letale. Informatica=bomba: intelligente solo per gli stupidi che ci credono. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Waiting for root file system problem
--- Daniel Burrows [EMAIL PROTECTED] wrote: On Wed, Jan 02, 2008 at 10:24:07AM -0800, Andrew Sackville-West [EMAIL PROTECTED] was heard to say: On Wed, Jan 02, 2008 at 06:24:07AM -0500, dave N wrote: If you wait long enough (at least 30 seconds, maybe a couple minutes, I can't remember) you should get dropped to a busybox shell. Then look at /scripts/local-top and see what it's trying to run there. That may provide a clue. You can also pass break at the kernel command line. See initramfs-tools(8) for more boot options, including places you can break the init script. Daniel Well finally got in, followed somewhat what the other user did who had a similar problem and the messages on this thread. I've also found that the drive assignment varies depending on the boot device in my BIOS. If CDROM is 1st boot device and Hard drive is second: - my root partition, etc is on /dev/sda If Hard drive is 1st boot device and CDROM is second - my root partition, etc is on /dev/sdc ODD!! Setting labels in fstab caused many fsck errors and other problems, going back to device assignments everything worked fine. It seems that the partition devices and labels showed up differently with the older knoppix DVD I'm using and what is showing up with the Debian install. I'll need to verify this get an updated live DVD. Question: In the menu.lst grub file, how would I use the label assignment in the line: kernel /vmlinuz-2.6.18-5-686 root=/dev/sdc2 ro Thanks to everyone for the help. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3rd SATA scrambles drive order? Begin: Waiting for root file system . . . . . .
In article [EMAIL PROTECTED], Jonathan Wilson [EMAIL PROTECTED] wrote: I have a computer with an Intel mainboard (Ill look up the exact model later if it matters) running Etch. / is an 80G SATA on SATA1. /data is a 500G SATA drive on SATA2. I've never had any trouble with the system. I ran out of space on /data so I've installed a 3rd drive, 750G. I've only got 2 SATA ports left, 3 and 4. If I plug the new drive into either one, the machine boots, the bios recognizes the new drive just fine, the boot info shows sdc, but after all the drive and ethernet detection, I get the following message: Begin: Waiting for root file system . . .. . . (I'll note here that as soon as I unplug the SATA cable from the new drive and reboot everything works again, so the original two drives file systems are still just fine.) After some delay (two minutes?) I get this: Done. Check root= bootarg cat /proc/cmdline or missing modules, devices: cat /proc/modules ls /dev ALERT! /dev/sda2 does not exist. Dropping to a shell! Then I get a busybox/initramfs shell. ls /dev/sd* only shows: sda sdb sdb1 sdb2 sdc sdc1 From that I guessed that the boot order hand changed (obviously sdb now has the swap and root partitions, and c had the 1 data partition, and a is the blank new drive. So I rebooted and edited the GRUB commandline to make root=sdb2 and sure enough it works. Now, I guess I /can/ use this setup, and just modify /etc/fstab so that the thing will boot and mount properly on it's own, but I'd rather do something to it so that it doesn't get so confused about the order of the drives. The new drive should be sdc, and the old drives should be sda, and sdb, like they already were. Is there something I can do about this? To make the new drive be sdc, I mean? Thanks, JW Count yourself lucky. I have a system where the sata controllers come up in random order. sda is sometimes moved to sde. You can only use LABEL= for ext2/ext3 filesystems. Not for swap. So when my controllers get switched The system wont boot, drops to ramfs. Is there no way to control the order that the sata controllers get mapped ? Stuart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3rd SATA scrambles drive order? Begin: Waiting for root file system . . . . . .
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/08 08:05, Stuart Gall wrote: In article [EMAIL PROTECTED], Jonathan Wilson [EMAIL PROTECTED] wrote: I have a computer with an Intel mainboard (Ill look up the exact model later if it matters) running Etch. / is an 80G SATA on SATA1. /data is a 500G SATA drive on SATA2. I've never had any trouble with the system. I ran out of space on /data so I've installed a 3rd drive, 750G. I've only got 2 SATA ports left, 3 and 4. If I plug the new drive into either one, the machine boots, the bios recognizes the new drive just fine, the boot info shows sdc, but after all the drive and ethernet detection, I get the following message: [snip] Now, I guess I /can/ use this setup, and just modify /etc/fstab so that the thing will boot and mount properly on it's own, but I'd rather do something to it so that it doesn't get so confused about the order of the drives. The new drive should be sdc, and the old drives should be sda, and sdb, like they already were. Is there something I can do about this? To make the new drive be sdc, I mean? Thanks, JW Count yourself lucky. I have a system where the sata controllers come up in random order. sda is sometimes moved to sde. You can only use LABEL= for ext2/ext3 filesystems. Not for swap. So when my controllers get switched The system wont boot, drops to ramfs. Try mkswap -L. But if you don't want to recreate your swap partitions, you can still refer to them by UUID. # tune2fs -l /dev/sda1 | grep UUID Then edit /etc/fstab: UUID=3324e03c-f071-47da-b5eb-3889836d802e swap swap pri=1 0 0 Is there no way to control the order that the sata controllers get mapped ? Maybe, but labels and UUIDs obviate the need. - -- Ron Johnson, Jr. Jefferson LA USA I'm not a vegetarian because I love animals, I'm a vegetarian because I hate vegetables! unknown -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHfQQKS9HxQb37XmcRAoTBAKCms/Vk4kX/y8nouHZ5mnDzRr0/YwCgyIHK 0o/FWD84EPue4xHH21ywI8k= =mQnl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3rd SATA scrambles drive order? Begin: Waiting for root file system . . . . . .
On Wednesday 02 January 2008 23:40, Paul Johnson wrote: On Jan 2, 2008 9:37 PM, Jonathan Wilson [EMAIL PROTECTED] wrote: Is there something I can do about this? To make the new drive be sdc, I mean? Why not mount by filesystem label instead of device name? The filesystem label doesn't change just because disks decided to detect in a different order. On Thursday 03 January 2008 09:49, Ron Johnson wrote: [Are you Johnson's related? :-D] But if you don't want to recreate your swap partitions, you can still refer to them by UUID. # tune2fs -l /dev/sda1 | grep UUID Then edit /etc/fstab: UUID=3324e03c-f071-47da-b5eb-3889836d802e swap swap pri=1 0 0 Is there no way to control the order that the sata controllers get mapped ? Maybe, but labels and UUIDs obviate the need. Someone else said using IDs in fstab only works with ext2/3, obviously tune2fs does, and I use ReiserFS. What then? I'm interested in the Maybe part, since UUIDs won't work for my situation. P.S. I hadn't noticed that dave N had started a thread with the same question. Duh :-) JW -- -- System Administrator - Cedar Creek Software http://www.cedarcreeksoftware.com http://jwadmin.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3rd SATA scrambles drive order? Begin: Waiting for root file system . . . . . .
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/08 11:52, Jonathan Wilson wrote: On Wednesday 02 January 2008 23:40, Paul Johnson wrote: On Jan 2, 2008 9:37 PM, Jonathan Wilson [EMAIL PROTECTED] wrote: Is there something I can do about this? To make the new drive be sdc, I mean? Why not mount by filesystem label instead of device name? The filesystem label doesn't change just because disks decided to detect in a different order. On Thursday 03 January 2008 09:49, Ron Johnson wrote: [Are you Johnson's related? :-D] But if you don't want to recreate your swap partitions, you can still refer to them by UUID. # tune2fs -l /dev/sda1 | grep UUID Then edit /etc/fstab: UUID=3324e03c-f071-47da-b5eb-3889836d802e swap swap pri=1 0 0 Is there no way to control the order that the sata controllers get mapped ? Maybe, but labels and UUIDs obviate the need. Someone else said using IDs in fstab only works with ext2/3, obviously tune2fs does, and I use ReiserFS. What then? I'm interested in the Maybe part, since UUIDs won't work for my situation. I believe that either Someone else is mistaken, or you are misreading something. Or I gave you the wrong command... Obviously, tune2fs won't work on swap partitions. So, instead use /sbin/blkid. # blkid /dev/sda1 (I use swap *files*, so can't give you an example from my own system.) P.S. I hadn't noticed that dave N had started a thread with the same question. Duh :-) - -- Ron Johnson, Jr. Jefferson LA USA I'm not a vegetarian because I love animals, I'm a vegetarian because I hate vegetables! unknown -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHfTEuS9HxQb37XmcRAlPwAKDrUnqDQeSNLNS8ZTTsbDPHy8DlHwCgmJbp byFtYr9XY1UKGOEg20Ec544= =kEyK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Waiting for root file system problem
On Thu, Jan 03, 2008 at 06:39:11 -0500, dave N wrote: [...] Question: In the menu.lst grub file, how would I use the label assignment in the line: kernel /vmlinuz-2.6.18-5-686 root=/dev/sdc2 ro I think this should be OK: kernel /vmlinuz-2.6.18-5-686 root=LABEL=your_root_label ro I have # kopt=root=LABEL=my_root_label ro in my menu.lst and this works for all the auto-generated entries. -- Regards,| http://users.icfo.es/Florian.Kulzer Florian | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3rd SATA scrambles drive order? Begin: Waiting for root file system . . . . . .
On Thursday 03 January 2008 13:02, Ron Johnson wrote: On 01/03/08 11:52, Jonathan Wilson wrote: Someone else said using IDs in fstab only works with ext2/3, obviously tune2fs does, and I use ReiserFS. What then? I'm interested in thre Maybe part, since UUIDs won't work for my situation. I believe that either Someone else is mistaken, or you are misreading something. Or I gave you the wrong command... Obviously, tune2fs won't work on swap partitions. So, instead use /sbin/blkid. # blkid /dev/sda1 FWIW, I just reordered the SerialATA cables and changed the BIOS boot order to match. Kinda dumb but it works, and it's easy to put back if I have to :-D I'm curious though, since the BIOS saw the drives in the correct order, why doesn't Debian? I'll assume it's a kernel issue. I consider this a bug, where should I report it? Thanks, JW -- -- System Administrator - Cedar Creek Software http://www.cedarcreeksoftware.com http://jwadmin.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3rd SATA scrambles drive order? Begin: Waiting for root file system . . . . . .
On Thu, Jan 03, 2008 at 11:52:29AM -0600, Jonathan Wilson wrote: Someone else said using IDs in fstab only works with ext2/3, obviously tune2fs does, and I use ReiserFS. What then? from man mount: It is possible to indicate a block special device using its volume label or UUID (see the -L and -U options below). One can set such a label for ext2 or ext3 using the e2label(8) utility, or for XFS using xfs_admin(8), or for reiserfs using reiserfstune(8). http://64.233.183.104/search?q=cache:r-vvdhBMOZAJ:www.namesys.com/faq.html+reiserfs+label+fstabhl=enct=clnkcd=4ie=UTF-8#fs-label -- Chi usa software non libero avvelena anche te. Digli di smettere. Informatica=arsenico: minime dosi in rari casi patologici, altrimenti letale. Informatica=bomba: intelligente solo per gli stupidi che ci credono. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Waiting for root file system problem
Hi: I've installed Etch r1 and the only real thing I've done to the system is updated the system, though during the update it updated the kernel to the same kernel that was installed during the installation (used the medium to try and get more control over Grub install). The computer is about 2 years old, dual CPU Xeons, with 2 SATA drives and 2 SCSI drives. The system has not been highly used over the past 2 years. The system drive where Debian is installed is on a SATA 36 Gb Raptor that is just for the OS, drive was reformatted during install using ext3. During boot the system appears to find all the drives OK when I am reading as fast as I can, but then I get the following (from a photo of the screen messages) Begin: Mounting root file system... ... Begin: running /scripts/local-top ... ide0: I/O resource 0x1F0-0x1F7 not free. ide0: ports already in use, skipping probe ide1: I/O resource 0x170-0x177 not free. ide1: ports already in use, skipping probe Done. Begin: Waiting for root file system... ... And it stops right there. 0's above may be 8's, can't tell from the picture. I booted with Knoppix live and there is nothing in /var/log/messages, none of the logs appear to have changed since I last booted 2 days ago. I have not run fsck or anything else on this yet. Ideas? Thanks Dave
Re: Waiting for root file system problem
dave N [EMAIL PROTECTED] wrote: Hi: I've installed Etch r1 and the only real thing I've done to the system is updated the system, though during the update it updated the kernel to the same kernel that was installed during the installation (used the medium to try and get more control over Grub install). The computer is about 2 years old, dual CPU Xeons, with 2 SATA drives and 2 SCSI drives. The system has not been highly used over the past 2 years. The system drive where Debian is installed is on a SATA 36 Gb Raptor that is just for the OS, drive was reformatted during install using ext3. During boot the system appears to find all the drives OK when I am reading as fast as I can, but then I get the following (from a photo of the screen messages) Begin: Mounting root file system... ... Begin: running /scripts/local-top ... ide0: I/O resource 0x1F0-0x1F7 not free. ide0: ports already in use, skipping probe ide1: I/O resource 0x170-0x177 not free. ide1: ports already in use, skipping probe Done. Begin: Waiting for root file system... ... And it stops right there. 0's above may be 8's, can't tell from the picture. I booted with Knoppix live and there is nothing in /var/log/messages, none of the logs appear to have changed since I last booted 2 days ago. I have not run fsck or anything else on this yet. Ideas? Thanks Dave e2fsck -f /dev/sda8 reported no errors for the 5 different passes when done from a superuser window in Knoppix. I'm stumped! Dave
Re: Waiting for root file system problem
On Wed, Jan 02, 2008 at 06:04:18AM -0500, dave N wrote: I booted with Knoppix live and there is nothing in /var/log/messages, none of the logs appear to have changed since I last booted 2 days ago. I have not run fsck or anything else on this yet. Ideas? This is usually a root device misnaming (is this a word?). Try setting up your fstab/menu.lst by uuid or labels. (If you have no idea what I'm talking about then I totally misjudged your knowledge level. Please report back with any questions you might have). Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Waiting for root file system problem
On Wed, Jan 02, 2008 at 06:24:07AM -0500, dave N wrote: dave N [EMAIL PROTECTED] wrote: Hi: I've installed Etch r1 and the only real thing I've done to the system is updated the system, though during the update it updated the kernel to the same kernel that was installed during the installation (used the medium to try and get more control over Grub install). The computer is about 2 years old, dual CPU Xeons, with 2 SATA drives and 2 SCSI drives. The system has not been highly used over the past 2 years. The system drive where Debian is installed is on a SATA 36 Gb Raptor that is just for the OS, drive was reformatted during install using ext3. During boot the system appears to find all the drives OK when I am reading as fast as I can, but then I get the following (from a photo of the screen messages) Begin: Mounting root file system... ... Begin: running /scripts/local-top ... ide0: I/O resource 0x1F0-0x1F7 not free. ide0: ports already in use, skipping probe ide1: I/O resource 0x170-0x177 not free. ide1: ports already in use, skipping probe Done. Begin: Waiting for root file system... ... And it stops right there. 0's above may be 8's, can't tell from the picture. If you wait long enough (at least 30 seconds, maybe a couple minutes, I can't remember) you should get dropped to a busybox shell. Then look at /scripts/local-top and see what it's trying to run there. That may provide a clue. Also, in the busybox shell, look at what modules are inserted and see if you've got some conflict there. I booted with Knoppix live and there is nothing in /var/log/messages, none of the logs appear to have changed since I last booted 2 days ago. I have not run fsck or anything else on this yet. you might try chrooting into the system and rebuilding the initrd from the knoppix boot. also use knoppix to compare modules... hth A signature.asc Description: Digital signature
Re: Waiting for root file system problem
Andrei Popescu [EMAIL PROTECTED] wrote: On Wed, Jan 02, 2008 at 06:04:18AM -0500, dave N wrote: I booted with Knoppix live and there is nothing in /var/log/messages, none of the logs appear to have changed since I last booted 2 days ago. I have not run fsck or anything else on this yet. Ideas? This is usually a root device misnaming (is this a word?). Try setting up your fstab/menu.lst by uuid or labels. (If you have no idea what I'm talking about then I totally misjudged your knowledge level. Please report back with any questions you might have). Regards, Andrei Thanks, I'll try this a little later using lables or devices (/dev/sda2) I didn't know there were uuid's for devices, how do I find that for a partition?
3rd SATA scrambles drive order? Begin: Waiting for root file system . . . . . .
I have a computer with an Intel mainboard (Ill look up the exact model later if it matters) running Etch. / is an 80G SATA on SATA1. /data is a 500G SATA drive on SATA2. I've never had any trouble with the system. I ran out of space on /data so I've installed a 3rd drive, 750G. I've only got 2 SATA ports left, 3 and 4. If I plug the new drive into either one, the machine boots, the bios recognizes the new drive just fine, the boot info shows sdc, but after all the drive and ethernet detection, I get the following message: Begin: Waiting for root file system . . .. . . (I'll note here that as soon as I unplug the SATA cable from the new drive and reboot everything works again, so the original two drives file systems are still just fine.) After some delay (two minutes?) I get this: Done. Check root= bootarg cat /proc/cmdline or missing modules, devices: cat /proc/modules ls /dev ALERT! /dev/sda2 does not exist. Dropping to a shell! Then I get a busybox/initramfs shell. ls /dev/sd* only shows: sda sdb sdb1 sdb2 sdc sdc1 From that I guessed that the boot order hand changed (obviously sdb now has the swap and root partitions, and c had the 1 data partition, and a is the blank new drive. So I rebooted and edited the GRUB commandline to make root=sdb2 and sure enough it works. Now, I guess I /can/ use this setup, and just modify /etc/fstab so that the thing will boot and mount properly on it's own, but I'd rather do something to it so that it doesn't get so confused about the order of the drives. The new drive should be sdc, and the old drives should be sda, and sdb, like they already were. Is there something I can do about this? To make the new drive be sdc, I mean? Thanks, JW -- -- System Administrator - Cedar Creek Software http://www.cedarcreeksoftware.com http://jwadmin.blogspot.com/
Re: 3rd SATA scrambles drive order? Begin: Waiting for root file system . . . . . .
On Jan 2, 2008 9:37 PM, Jonathan Wilson [EMAIL PROTECTED] wrote: Is there something I can do about this? To make the new drive be sdc, I mean? Why not mount by filesystem label instead of device name? The filesystem label doesn't change just because disks decided to detect in a different order. -- Paul Johnson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Waiting for root file system problem
On Wed, Jan 02, 2008 at 10:24:07AM -0800, Andrew Sackville-West [EMAIL PROTECTED] was heard to say: On Wed, Jan 02, 2008 at 06:24:07AM -0500, dave N wrote: If you wait long enough (at least 30 seconds, maybe a couple minutes, I can't remember) you should get dropped to a busybox shell. Then look at /scripts/local-top and see what it's trying to run there. That may provide a clue. You can also pass break at the kernel command line. See initramfs-tools(8) for more boot options, including places you can break the init script. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Waiting for root file system... hang solved
Hi [This message has also been posted to linux.debian.user.] In article [EMAIL PROTECTED], Johannes Wiedersich wrote: Cameron L. Spitzer wrote: [snip upgrade instructions] Thanks for posting your experience! I am sure it will be useful to others. You could have a debate about whether this is an installer bug, a kernel package bug, a udev bug, or operator error. If I understand correctly, you upgraded the kernel and the new kernel would not boot. Then it would be a kernel bug. That was my initial conclusion. But then I spent some time googling for the error messages. A lot of people have had this same hang, and most of them got there by some other path than I did. So I think it may be a more general problem than that. Yes, and I is one of them who just experienced it. Just installed Etch but on first boot after installation I got the Waiting for root file system... My (old) mainbord (BE6) have two IDE hardisk controlles onboard. One generic IDE controller (piix) and a hpt366 controller. It seems that in default kernel in Etch that all IDE drivers are loaded as modules. If you then have multiple IDE controllers you are in trouble because the IDE kernel modules will be loaded in random order. In my case, if the hpt366 kernel module is loaded first, the disks attached to it will be named hda, hdb, hdc and hdd. It the piix kernel module is loaded first, then those disks will be named hda, hdb, hdc and hdd (the hpt366 disks will then be named hde, hdf, hdg and hdh) . This was never a problem with Sarge kernel images because there the generic IDE controller drivers was compiled into the kernel (thus loaded before any modules) while other IDE drivers (like hpt366) was compiled as modules. I guess everyone with multiple IDE controllers will end up with the same problem and the debian installer doesn't warn you about this. I was going to report this as bug report but not sure in which package the bug report should be assigned to. I guess relevant packages are kernel, debian installer, mkinitrd? Not sure how this should be fixed either. Using ext2/ext3 labels in fstab and grub config is one way I guess. Using UUID ( http://michael-prokop.at/blog/2006/08/11/stable-root-device-aka-uuid/ ) in fstab and grub config is probably another way. A 3rd solution would be to enforce that that one kernel module (piix in my case) is loaded before an other (hpt366 in my case) but that is not possible AFAIK. Or is it ? Not sure if it is possible to fix this with udev rules. I suspect the IDE kernel modules are loaded before udev daemon is started though.. PS Please CC me on any reply as I am not subscribed to the list. Sorry for also messing up the threading but had to cutpast from the archive ( http://lists.debian.org/debian-user/2007/11/msg00215.html ) and had no idea how to set the message-id correctly when replying... Best regards, Vidar L -- [EMAIL PROTECTED] | eZ systems | ez.no -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Waiting for root file system... hang solved
Vidar Langseid wrote: Hi In article [EMAIL PROTECTED], Johannes Wiedersich wrote: Cameron L. Spitzer wrote: [snip upgrade instructions] Thanks for posting your experience! I am sure it will be useful to others. You could have a debate about whether this is an installer bug, a kernel package bug, a udev bug, or operator error. If I understand correctly, you upgraded the kernel and the new kernel would not boot. Then it would be a kernel bug. That was my initial conclusion. But then I spent some time googling for the error messages. A lot of people have had this same hang, and most of them got there by some other path than I did. So I think it may be a more general problem than that. Yes, and I is one of them who just experienced it. Just installed Etch but on first boot after installation I got the Waiting for root file system... My (old) mainbord (BE6) have two IDE hardisk controlles onboard. One generic IDE controller (piix) and a hpt366 controller. It seems that in default kernel in Etch that all IDE drivers are loaded as modules. If you then have multiple IDE controllers you are in trouble because the IDE kernel modules will be loaded in random order. I guess everyone with multiple IDE controllers will end up with the same problem and the debian installer doesn't warn you about this. Not sure how this should be fixed either. Using ext2/ext3 labels in fstab and grub config is one way I guess. Using UUID ( http://michael-prokop.at/blog/2006/08/11/stable-root-device-aka-uuid/ ) in fstab and grub config is probably another way. A 3rd solution would be to enforce that that one kernel module (piix in my case) is loaded before an other (hpt366 in my case) but that is not possible AFAIK. Or is it ? It seems to me the real issue isn't the association between drivers and partitions. The problem is that the association between device names and partitions isn't stable. Suppose I built a machine with a PIIX motherboard and an Adaptec add-in card. Then my PIIX motherboard shorts out, and the only available replacement is a VIA motherboard. If my device names to partitions association depended on PIIX getting loaded first, I just lost that stability. I've got a 50/50 chance I'll have to rescue that machine before it will boot correctly. Volume labels or UUIDs in grub/menu.lst and /etc/fstab is the only way I can see to fix that. Not sure if it is possible to fix this with udev rules. I suspect the IDE kernel modules are loaded before udev daemon is started though.. Udev is a secondary issue. It would be nice to have the association between device names and partitions stable. Then the device icons on your desktop wouldn't break when you replace your motherboard. That can be nailed down in the udev rules. Multiple sound cards can be dealt with in /etc/modules because sound is never in the boot path. NIC cards have the same problem as the broken motherboard. If I associate an ethN name with a MAC address in udev rules, then my network, and possibly my boot, break when I have to replace the NIC card. But maybe there is no way around that. It would also be nice to have a minimal set of permanent device nodes that survive without udev. Once upon a time you could boot a unix system with only /bin/sh installed. Now we need an initrd and an automatic module loader because there are too many device types to compile them all in. It seems to me that requiring for boot a user space daemon which is difficult to configure and poorly documented is a bad idea in general. Needlessly failure prone. The fact that it broke the upgrade from Sarge to Etch is a strong signal. Perhaps udev is worth it. In that case the Debian installer should use volume labels or UUIDs. Cameron
Re: Waiting for root file system... hang solved
On Sat, Nov 03, 2007 at 09:14:44PM -0700, Andrew Sackville-West wrote: it turns out you can do a reasonable amount of stuff in that busybox shell and if the system is close to booting, you can get it to go. What I was missing, and desperately wanted, was some kind of text editor. I ended up have to do some funky 'cat'ing of files and text input to tweak an encryption-key script. Not fun without an editor, but you sure can do it... You mean that the busybox doesn't have any editor at all? The busybox package (not necessarily the same as the initrd version) has vi and ed. No ed in the initrd? Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Waiting for root file system... hang solved
On Mon, Nov 05, 2007 at 09:14:18AM -0500, Douglas A. Tutty wrote: On Sat, Nov 03, 2007 at 09:14:44PM -0700, Andrew Sackville-West wrote: it turns out you can do a reasonable amount of stuff in that busybox shell and if the system is close to booting, you can get it to go. What I was missing, and desperately wanted, was some kind of text editor. I ended up have to do some funky 'cat'ing of files and text input to tweak an encryption-key script. Not fun without an editor, but you sure can do it... You mean that the busybox doesn't have any editor at all? The busybox package (not necessarily the same as the initrd version) has vi and ed. No ed in the initrd? I didn't look real hard, but I did look. I thought of ed, but maybe I just didn't see it. I can induce a waiting for root situation easily on my laptop... I'll confirm it. A signature.asc Description: Digital signature
Re: Waiting for root file system... hang solved
On Sat, Nov 03, 2007 at 02:38:36AM +, Cameron L. Spitzer wrote: In article [EMAIL PROTECTED], Andrew Sackville-West wrote: I've had to learn my way around that having just reconfigured my laptop. The critical item is the contents of $ROOT. The value of $ROOT gets set by the kernel command line and if it doesn't match, then you have trouble. If you change that to the appropriate value you can then 'exit' busybox and the boot will carry on. I didn't know that. If I hadn't had a working option in GRUB I would have tried editing the kernel command line next. I've also rescued Debian by booting Knoppix, mounting stuff, and running a chroot shell. it turns out you can do a reasonable amount of stuff in that busybox shell and if the system is close to booting, you can get it to go. What I was missing, and desperately wanted, was some kind of text editor. I ended up have to do some funky 'cat'ing of files and text input to tweak an encryption-key script. Not fun without an editor, but you sure can do it... Once you're up and running, then rebuil the initrd's. I actually tried that before going to volume labels. Rebuilding the initrd puts the same old /etc/fstab in the new initrd image. sorry, updating /etc/fstab apparently doesn't go without saying... ;). That doesn't get you past the udev hang. I guess a more sophisticated update-initrd would alert you to the difference between the current mtab and the /etc/fstab contents. There are a handful of issues I've seen with currnet initramsfs-tools that probably need addressing. The one I ran across: the lvm and encrypted root scripts expect /dev/mapper/ names with hyphens in them. I have /dev/mapper/vgcrypt-root (an LVM volume on top of encrypted partition). I prefer to access these things through /dev/vgcrypt/root (or whatever it was), but the scripts are expecting that hyphenated name... it appears to only be documented in the code itself. oh well. it works now... I've been using Debian for a long time. It's just *weird* to see anything broken like that. somewhere Linus talks about breaking UUID names as well, on purpose, because he thinks there should be some other persistent naming method and since UUID is generated in user space, its not reliable. I don't know, but watch out for that. A signature.asc Description: Digital signature
Re: Waiting for root file system... hang solved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cameron L. Spitzer wrote: [snip upgrade instructions] Thanks for posting your experience! I am sure it will be useful to others. You could have a debate about whether this is an installer bug, a kernel package bug, a udev bug, or operator error. If I understand correctly, you upgraded the kernel and the new kernel would not boot. Then it would be a kernel bug. - From the installation/upgrade instructions from sarge to etch I remember, that one was supposed to upgrade the kernel and just the kernel, then reboot and upgrade other packages. Is this still the case? Did you follow the upgrade instructions? Johannes NB: Unfortunately, I could not find any recent installation / upgrade instructions for lenny. The development version [1] still claims to be about the upgrade from sarge to etch and always refers to etch and never to lenny [2]. [1] http://d-i.alioth.debian.org/manual/ [2] http://d-i.alioth.debian.org/manual/en.i386/install.en.pdf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHKui+C1NzPRl9qEURAngHAJ4zz3A0yAKkaa9WT0Qhj5nBvnCFGgCcDbQY Fgr/+suvTpjAEmDs1WPYkK4= =mHxd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Waiting for root file system... hang solved
[This message has also been posted to linux.debian.user.] In article [EMAIL PROTECTED], Johannes Wiedersich wrote: Cameron L. Spitzer wrote: [snip upgrade instructions] Thanks for posting your experience! I am sure it will be useful to others. You could have a debate about whether this is an installer bug, a kernel package bug, a udev bug, or operator error. If I understand correctly, you upgraded the kernel and the new kernel would not boot. Then it would be a kernel bug. That was my initial conclusion. But then I spent some time googling for the error messages. A lot of people have had this same hang, and most of them got there by some other path than I did. So I think it may be a more general problem than that. My friend in Los Angeles tried to install Ubuntu for a friend, and got stuck waiting for root file system in the middle of a fresh install from CD. When he booted his trusty Knoppix CD it revealed the root file system was just fine. I suspect udev device names are less persistent than we have assumed they are. - From the installation/upgrade instructions from sarge to etch I remember, that one was supposed to upgrade the kernel and just the kernel, then reboot and upgrade other packages. Is this still the case? Did you follow the upgrade instructions? That's what I did. When I installed an Etch kernel on Sarge, it pulled in a new libc, locales, and a few other things. It replaced module-utils. I think it replaced devfs with udev. When I installed a Lenny kernel on a fresh Etch, it just put the new kernel in along side the old one. Nothing else new. I agree udev is an improvement over devfs or just having all possible static device nodes. But would it be unreasonable to create static device nodes for the devices in the boot path? Or in /etc/fstab? Can I do that, or will udev just take them away? I've read the udev manpages and I just get more and more confused. It's that old unix documentation canard that examples will just limit your creativity. Udev needs a top-down explanation and an introductory tutorial with complete examples. There's a view from ten thousand feet overview (the conference paper), and lots of details (the manpages), but no bridge between them. Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Waiting for root file system... hang solved
On Fri, Nov 02, 2007 at 03:33:06PM -0700, [EMAIL PROTECTED] wrote: [This message has also been posted to linux.debian.user.] In article [EMAIL PROTECTED], Johannes Wiedersich wrote: Cameron L. Spitzer wrote: [snip upgrade instructions] Thanks for posting your experience! I am sure it will be useful to others. You could have a debate about whether this is an installer bug, a kernel package bug, a udev bug, or operator error. If I understand correctly, you upgraded the kernel and the new kernel would not boot. Then it would be a kernel bug. That was my initial conclusion. But then I spent some time googling for the error messages. A lot of people have had this same hang, and most of them got there by some other path than I did. So I think it may be a more general problem than that. My friend in Los Angeles tried to install Ubuntu for a friend, and got stuck waiting for root file system in the middle of a fresh install from CD. When he booted his trusty Knoppix CD it revealed the root file system was just fine. I suspect udev device names are less persistent than we have assumed they are. yeah, this is probably *not* a kernel bug but more likely either a udev bug or initramsf-tools bug. Something got changed there in the device naming and that's not really the kernel's fault, so far as I know. BTW, were you able to boot through the busybox? I've had to learn my way around that having just reconfigured my laptop. The critical item is the contents of $ROOT. The value of $ROOT gets set by the kernel command line and if it doesn't match, then you have trouble. If you change that to the appropriate value you can then 'exit' busybox and the boot will carry on. Once you're up and running, then rebuil the initrd's. A signature.asc Description: Digital signature
Re: Waiting for root file system... hang solved
In article [EMAIL PROTECTED], Andrew Sackville-West wrote: On Fri, Nov 02, 2007 at 03:33:06PM -0700, [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Johannes Wiedersich wrote: Cameron L. Spitzer wrote: [ when I upgraded Etch to Lenny, device names changed and the Lenny kernel wouldn't boot, but the Etch kernel still worked. ] If I understand correctly, you upgraded the kernel and the new kernel would not boot. Then it would be a kernel bug. [cls:] My friend in Los Angeles tried to install Ubuntu for a friend, and got stuck waiting for root file system in the middle of a fresh install from CD. When he booted his trusty Knoppix CD it revealed the root file system was just fine. I suspect udev device names are less persistent than we have assumed they are. yeah, this is probably *not* a kernel bug but more likely either a udev bug or initramsf-tools bug. Something got changed there in the device naming and that's not really the kernel's fault, so far as I know.=20 BTW, were you able to boot through the busybox? I didn't have to try. The Etch kernel+initrd still worked. As soon as the system was up I changed /etc/fstab and grub/menu.lst to use volume labels which make the Lenny kernel+initrd work too. I've had to learn my way around that having just reconfigured my laptop. The critical item is the contents of $ROOT. The value of $ROOT gets set by the kernel command line and if it doesn't match, then you have trouble. If you change that to the appropriate value you can then 'exit' busybox and the boot will carry on. I didn't know that. If I hadn't had a working option in GRUB I would have tried editing the kernel command line next. I've also rescued Debian by booting Knoppix, mounting stuff, and running a chroot shell. Once you're up and running, then rebuil the initrd's. I actually tried that before going to volume labels. Rebuilding the initrd puts the same old /etc/fstab in the new initrd image. That doesn't get you past the udev hang. I guess a more sophisticated update-initrd would alert you to the difference between the current mtab and the /etc/fstab contents. It wouldn't know whether the difference was intended, so it would have to ask what to do. And if I'd put a new device-names fstab in the Etch initrd then my Etch kernel wouldn't have worked any more. Come to think of it, I only learned about volume labels a few months ago, solving a similar problem. I installed an Etch web server on /dev/hde (a drive on an add-in ATA interface card), in a test machine that already had an Etch workstation on /dev/hda. And when I launched the hde kernel with GRUB it booted the workstation instead! I fiddled around with the udev rules but they were so poorly documented I wasn't confident I could upgrade the machine remotely. I've been using Debian for a long time. It's just *weird* to see anything broken like that. Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Waiting for root file system... hang solved
I googled for the answer and didn't find it, and lots of people asking, so this is for the next person with the same problem. I installed a Debian Etch workstation, tasksel: desktop, guided partitioning, the six partitions (/ /usr /var /home /tmp swap) way. Works great. I upgraded to Lenny, the October 29 2007 weekly CD. This leaves a GRUB menu with an Etch kernel and a Lenny kernel. The Etch kernel boots just fine. The Lenny kernel hangs at Waiting for root file system... and eventually you get that (initramfs) prompt from the Busybox shell, which means it never found the root FS. Turns out this is because Etch thinks this PATA drive is /dev/hda, but Lenny thinks the exact same drive is /dev/sda. So the /etc/fstab and /boot/grub/menu.lst files have the root file system as /dev/hda1, which no longer exists. I hear ubuntu Fiesty has the same problem. The fix is to edit /etc/fstab and /boot/grub/menu.lst and change all the hard drive partition device names to unique file system volume labels. /dev/hda1 becomes LABEL=a-root or whatever you like. Then use e2label(8) to add volume labels to all the file systems. I also labeled the swap image. While you're at it, /etc/uswsusp.conf is wrong, too. (Can that file use a swap volume label instead of a device name? The manpage doesn't say.) This causes a pause during boot, where resume: is looking for the wrong swap device. Once all the partitions are labeled, you can make new initrd images. update-initramfs -u -k all You could have a debate about whether this is an installer bug, a kernel package bug, a udev bug, or operator error. Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Waiting for root file system... ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I am trying to make a smooth transition fom windows to Debian in my work PC. I needed to be sure that not having win on this machine wouldn't affect my work, since unfortunatelly we use many windows-based applications. For that, I thought of first installing a proof-of-concept Debian inside a VM. This way, I could go on installing Debian and all the tools I needed without having to break my workflow. Since I wanted to make the move from MS to freedom, before I started with the adventure, I freed space in my HD and told the VM to use my physical disk instead of creating a virtual one. At the moment, I have a fully working Debian Lenny that runs smoothly inside the VM. The current situation is as follows: When I boot the PC, I am presented with a GRUB menu with three options: Debian's stock kernel, the same kernel but single-user, and Windows. Currently, I am only able to boot Windows. After doing that, When I boot the VM, I get the same GRUB menu and can boot Debian without a problem. The problem is when I want to boot Debian directly on the PC and not inside the VM. The boot process starts normally, but then hangs. The last lines that appear in the boot are: Begin: Mounting root file system... ... Begin: Running /scripts/local-top ... Done. Begin: Waiting for root file system... ... And from there, I can only Control-Alt-Delete or do a cold reset. The machine is a Dell Optiplex GX280 P4-HT with 2GB RAM and a 80Gb IDE HD. Any ideas? Cheers, Cassiano Leal -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHIOvNq4Bz51JiUuERAlodAKCMJ74CWTXwVDJrSdTpMyBc7/a5fQCdHRzA /I31IGFgE05UMYK9U8TF5Yg= =rZLg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Waiting for root file system... ...
Cassiano Bertol Leal wrote: Begin: Mounting root file system... ... Begin: Running /scripts/local-top ... Done. Begin: Waiting for root file system... ... And from there, I can only Control-Alt-Delete or do a cold reset. The machine is a Dell Optiplex GX280 P4-HT with 2GB RAM and a 80Gb IDE HD. Any ideas? First off what VM are you using? The most common would be VMWare but that is not the only option. If we talk about solutions based on a bad presumption it would lead to frustration. When I last messed with running Debian inside a VM as well as booting natively (back in, *cough*'01*cough*) I recall it taking some doing to get the mounts to line up inside the VM and outside the VM. -- Steve Lamb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Waiting for root file system... ...
On Thu, Oct 25, 2007 at 04:17:33PM -0300, Cassiano Bertol Leal wrote: Hi I am trying to make a smooth transition fom windows to Debian in my work PC. :) I needed to be sure that not having win on this machine wouldn't affect my work, since unfortunatelly we use many windows-based applications. For that, I thought of first installing a proof-of-concept Debian inside a VM. This way, I could go on installing Debian and all the tools I needed without having to break my workflow. Since I wanted to make the move from MS to freedom, before I started with the adventure, I freed space in my HD and told the VM to use my physical disk instead of creating a virtual one. At the moment, I have a fully working Debian Lenny that runs smoothly inside the VM. The current situation is as follows: When I boot the PC, I am presented with a GRUB menu with three options: Debian's stock kernel, the same kernel but single-user, and Windows. Currently, I am only able to boot Windows. After doing that, When I boot the VM, I get the same GRUB menu and can boot Debian without a problem. the path to the root partition is different depending on whether you are in the VM or not. Probably its one of two things: 1. a driver issue. the drivers needed to boot in the VM don't work on the actual hardware but since the initrd was built inside the VM, the actual hardware drivers aren't present and it can't boot or 2. the devices are named differently depending on whether you're in the VM or the actual hardware resulting in the kernel looking in the wrong place to mount the root file system. The problem is when I want to boot Debian directly on the PC and not inside the VM. The boot process starts normally, but then hangs. The last lines that appear in the boot are: Begin: Mounting root file system... ... Begin: Running /scripts/local-top ... Done. Begin: Waiting for root file system... ... And from there, I can only Control-Alt-Delete or do a cold reset. actually, from there you can *wait* and it should drop you to a busybox shell. it takes a few minutes before it gives up. (this assumes busybox is built into your initrd. I think that's the default). from there you can poke around and see what there is too see. look at the contents of $ROOT (echo $ROOT) to see where it thinks root should be located. look in /dev and see what partitions are available and see if they match up. you *might* be able to just reset $ROOT to the right partition, exit, and carry on with the boot. I suspect its the second of the two problems and you simply need to develop two boots stanzas for debian, one for the VM and one for the hardware. then you just choose the one you need. A signature.asc Description: Digital signature
Re: Etch hangs on startup at: waiting on root file system ?
On Tue, 2006-05-16 at 10:24 +1000, mustard lee wrote: lostson wrote: On Mon, 2006-05-15 at 21:02 +1000, mustard lee wrote: I put together a brand new Etch install today, which was working flawlessly for the first few boots. I think I may have done an apt-get upgrade prior to the last reboot and now its hanging on the startup with the message 'waiting on root file system'. If I try recovery mode, its the same. I've also tried noapic, nolapic, with no effect. Has anyone heard of this error recently? I'm not at the computer atm, or I would put in some more details like the kernel version. The best I can say is it is the most current 'testing' 486 kernel, as I installed an updated all this today. I suspect its something like 2.6.15.?-486. Any ideas or comments would be appreciated. Chris L. I had this problem as well. When you do an upgrade make sure to upgrade udev as well. Initramfs-tools is the package that screws things up. Personally I think it should pull in udev as well, but it doesnt. So be sure to upgrade udev and it will eliminate this problem. LostSon Thanks for the input on that. Googling around, I had started to think the problem was initramfs-tools related, but I hadn't found a specific course of action. I've been trying to think of how I'm going to get into the system to fix it. I suppose the only way is to chroot in, and upgrade udev that way? Would that be correct? Chris L. chroot would be the easiest yes. LostSon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Etch hangs on startup at: waiting on root file system ?
I put together a brand new Etch install today, which was working flawlessly for the first few boots. I think I may have done an apt-get upgrade prior to the last reboot and now its hanging on the startup with the message 'waiting on root file system'. If I try recovery mode, its the same. I've also tried noapic, nolapic, with no effect. Has anyone heard of this error recently? I'm not at the computer atm, or I would put in some more details like the kernel version. The best I can say is it is the most current 'testing' 486 kernel, as I installed an updated all this today. I suspect its something like 2.6.15.?-486. Any ideas or comments would be appreciated. Chris L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch hangs on startup at: waiting on root file system ?
On Mon, 2006-05-15 at 21:02 +1000, mustard lee wrote: I put together a brand new Etch install today, which was working flawlessly for the first few boots. I think I may have done an apt-get upgrade prior to the last reboot and now its hanging on the startup with the message 'waiting on root file system'. If I try recovery mode, its the same. I've also tried noapic, nolapic, with no effect. Has anyone heard of this error recently? I'm not at the computer atm, or I would put in some more details like the kernel version. The best I can say is it is the most current 'testing' 486 kernel, as I installed an updated all this today. I suspect its something like 2.6.15.?-486. Any ideas or comments would be appreciated. Chris L. I had this problem as well. When you do an upgrade make sure to upgrade udev as well. Initramfs-tools is the package that screws things up. Personally I think it should pull in udev as well, but it doesnt. So be sure to upgrade udev and it will eliminate this problem. LostSon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch hangs on startup at: waiting on root file system ?
Replace initramfs-tools with yaird and then do any kernel upgrades. mustard lee wrote: I put together a brand new Etch install today, which was working flawlessly for the first few boots. I think I may have done an apt-get upgrade prior to the last reboot and now its hanging on the startup with the message 'waiting on root file system'. If I try recovery mode, its the same. I've also tried noapic, nolapic, with no effect. Has anyone heard of this error recently? I'm not at the computer atm, or I would put in some more details like the kernel version. The best I can say is it is the most current 'testing' 486 kernel, as I installed an updated all this today. I suspect its something like 2.6.15.?-486. Any ideas or comments would be appreciated. Chris L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch hangs on startup at: waiting on root file system ?
lostson wrote: On Mon, 2006-05-15 at 21:02 +1000, mustard lee wrote: I put together a brand new Etch install today, which was working flawlessly for the first few boots. I think I may have done an apt-get upgrade prior to the last reboot and now its hanging on the startup with the message 'waiting on root file system'. If I try recovery mode, its the same. I've also tried noapic, nolapic, with no effect. Has anyone heard of this error recently? I'm not at the computer atm, or I would put in some more details like the kernel version. The best I can say is it is the most current 'testing' 486 kernel, as I installed an updated all this today. I suspect its something like 2.6.15.?-486. Any ideas or comments would be appreciated. Chris L. I had this problem as well. When you do an upgrade make sure to upgrade udev as well. Initramfs-tools is the package that screws things up. Personally I think it should pull in udev as well, but it doesnt. So be sure to upgrade udev and it will eliminate this problem. LostSon Thanks for the input on that. Googling around, I had started to think the problem was initramfs-tools related, but I hadn't found a specific course of action. I've been trying to think of how I'm going to get into the system to fix it. I suppose the only way is to chroot in, and upgrade udev that way? Would that be correct? Chris L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch hangs on startup at: waiting on root file system ?
rusi pathan wrote: Replace initramfs-tools with yaird and then do any kernel upgrades. mustard lee wrote: I put together a brand new Etch install today, which was working flawlessly for the first few boots. I think I may have done an apt-get upgrade prior to the last reboot and now its hanging on the startup with the message 'waiting on root file system'. If I try recovery mode, its the same. I've also tried noapic, nolapic, with no effect. Has anyone heard of this error recently? I'm not at the computer atm, or I would put in some more details like the kernel version. The best I can say is it is the most current 'testing' 486 kernel, as I installed an updated all this today. I suspect its something like 2.6.15.?-486. Any ideas or comments would be appreciated. Chris L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ Thanks for the info. I'll post the results when I access the machine next. Chris L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
