Just upgraded, now nothing in /dev !!
 

Hello,
just upgraded my slackware system to current (well most of it, I didn't bother with X11 packages)
Now my boot process gets stuck at fsck. It says it can't find /dev/hda3 (in my /etc/fstab, /dev/hda3 is /), and offers me the choice to login as root and fix the problem.
I logged in, and discovered that there was nothing in /dev at all! I'm no expert on the boot process, but this is somewhat troubling... Does anyone know how to resolve this?

thanks in advance.

From which version did you upgrade, which kernel are you using and last but not least: Did you install the udev package and chmod the /etc/rc.d/rc.udev to execute during boot?

have you renamed rc.udev.new to rc.udev?

titopoquito:
1) I upgraded from whatever was "current" back in May or June (I haven't done a "complete" install of a slackware version since, hmmm 2 years ago? Ever since then I just upgrade whatever packages to "current" that I want, which is usually most of them)
2)I'm using Kernel 2.6.15.4 (I'm pretty sure, I'll double check when I get home)
3) Yeah I probably installed udev, and I probably did not chmod the /etc/rc.d/rc.udev to execute during boot. I guess I should try that when I get back home. Who should have execute permissions on it?

Willysr: I don't think I did, maybe the package installed it like that? Should I rename it like this?

You should rename the rc.udev.new (if any) to rc.udev and make it executable so that it can create the /dev entries when booting.

Pat puts rc.udev.new so it won't overwrite the original rc.udev in case people have modified the original rc.udev for their needs

titopoquito: Well, it turns out I have BOTH of these files, and they're both set to executable. Now what?? :confused:
I noticed that rc.udev has a line at the begining:
. /etc/udev/udev.conf
IS it trying to execute this file? /etc/udev/udev.conf doesn't have execute permissions, but should I add them?

I've had similar problems (no eth0) doing this in the last day or two. I used Kdiff3 and went through all the updates in /etc/rc.d/ .

I thought I'd got them all and things weren't right still ... I'd missed an update to rc.S.

So, for me at least, I had to update a lot besides just chmod-ing the rc.udev.

I would replace rc.udev with rc.udev.new (the newer one is probably the one you want anyway).

I would also make sure that rc.udev is executable.

either
chmod +x /etc/rc.d/rc.udev
or
chmod 744 /etc/rc.d/rc.udev

You can then start udev with
/etc/rc.d/rc.udev start

and check /dev

Garry

hello,
Yes, I can execute rc.udev and it doesn't work (returns an error, I forget) , but when I execute rc.udev.new, everything works! My /dev/ is full of...the stuff it should be full of! ;)

Now, the problem is that I cannot replace or rename any of the files. My system gets booted as read-only and remains this way, even AFTER I execute rc.udev.new. So now I need some way to make my system read-write, wihtout rebooting (because of course when I reboot, I'm back to the begining again).

replace over *all* the .new files in the rc.d directory over the originals, unless you made some specific changes to them (which I'm assuming you didn't).

Sounds like the rc.S is not remounting as rw during the boot.

And is your rc.udev (after you over write it from rc.udev.new) executable, or did you just execute it manually with 'sh ...'. There's a difference.

If none of this works, post the output from 'dmesg'

regards,
...drkstr

drkstr:
replace all my original rc.d files with the *.new files? See, when I try to do that I get the "read-only filesystem" error.

"And is your rc.udev (after you over write it from rc.udev.new) executable, or did you just execute it manually with 'sh ...'. There's a difference."
I executed it as "./rc.udev.new", and YES it has execute permission.


rc.S not mounting as rw... umm... I guess something's wrong with this file, but as to how to fix it, I'm not sure since I can't save any changes...

I'll go reboot and check dmesg. I can't get the exact text since I can't save it anywhere, but I'll try to remember any lines that stick out! ;)
(I'm posting from a Windows box, btw, not the messed up linux installation)

Boot using Slackware CD 1 or some Live CD, mount the partition and change the files.

look for something after it says "Remounting root device with read-write enabled after you boot your computer." (If you don't know this allready, you can scroll up in the terminal with shift+PgUp)

And uppgrading was all you changed right? Nothing in the fstab? I just wanted to make sure we can rule this out as a possability.

...drkstr

I fixed the read-only problem: I executed "/etc/rc.d/rc.udev.new" to get the devices, then executed "/etc/rc.d/rc.S.new" to remount the system as read-write. Then I just copied all the rc.*.new files to be just rc.*...
The system seems to be booting fine now, KDE loads, etc... the only problem NOW is that the mouse doesn't work. At all. As if it weren't plugged in (but it is). The output of dmesg and /var/log/Xorg.0.log both look normal (well, I was tired so I just grepped them for "mouse")...
I'll have another stab at this tomorrow.

oh, and artsd seems to be running the CPU at full load for a bit after KDE logs in, then failing. There was an artsd package in that monster upgrade I did too, so that also probably has some issues...