seems to me
 

since ext4 is the recommended filesystem when formatting disks in the slackware install dialogue.
It should be set as built-in for the generic kernel configuration.
Since this seems to be a very common "system won't boot" complaint.
Just a suggestion
Thanks
John

But the vmlinuz-huge kernel supports ext4, so you can always boot this kernel. I'm using also the generic kernel, but have additionally an entry for vmlinuz-huge in my lilo.conf, so I can boot my system even if the configuration for the generic kernel is missing something. Here the part of my lilo.conf
Markus

I have this problem too.
I made initrd like always
mkinitrd -c -k 3.2.23-smp -m reiserfs
and system not started - error is:
mount: mounting /dev/ on /mnt failed: No such device

Then I try
mount -t reiserfs /dev/sda2 /mtn
but
mount: mounting /dev/sda2 on /mnt failed: No such device

I don't now why?
ls /dev/sda*
/dev/sda /dev/sda1 /dev/sda2 /dev/sda3 /dev/sda4 /dev/sda5 /dev/sda6

mkinitrd -c -k 3.2.23-smp -m reiserfs -u
The same problem.

kernel-huge starts OK.

The generic kernel has them built as modules so that the kernel is lighter and faster on boot. The fact that the filesystems aren't built-in is not likely to be the problem.

But the drivers for the filesystem musst be built into the kernel, not as a module! that's very likely the reason when the system does not boot (with "no such device"). Therefore it is necessary to tell mkinitrd which modules are necessary when the system boots. For example here my mkinitrd.conf
When a new kernel comes with current, I'll only have to boot the huge kernel and then buid a new initrd with the following command
Booting with the huge kernel is necessary so that the uname-command in mkinitrd.conf has the correct value.

Markus

For the current situation, it does seem that way. But I'm not sure if you're saying this is how it should always be, or if you're referring to only the current situation. I haven't used the new mkinitrd yet but my / filesystem is not built-in which is why I'm looking for some clarification.

I've noticed that things have started being mounted with UUID for example /media/ed192c1c-d9fc-4e9d-b57c-723abdfbd6a4 as opposed to /media/disk this is really annoying. Is there a way to change it.

Also, when mounting this other drive I'm asked for my password. This used to be my root password now it is only accepting my ordinary user password. This feels like a potential security breach just waiting to happen.

samac

No, they don't. That is one thing what the initrd is for, loading modules that are necessary but not built into the kernel.
I specified that ext4 should be built into the initrd when I created it, so this really shouldn't be the problem. I rather think that this is a problem with mkinitrd, since there is also an error-message about missing udevadm, which shouldn't be a problem since the init script is testing if udev is present.

Well, I think I have wrote unclear what I meant. The drivers musst be compiled into the kernel or if one uses the generic kernel he has to tell mkinitrd explicitly that the ext4-module is needed.

BTW: after performing the upgrades from July 13 I am running the generic kernel 3.2.23 without any problems. I did what I wrote in my poste above.

Markus

failed to execute '/lib/udev/vol_id' 'vol_id --export /dev/dm-0': No such file or directory

vol_id seems missing in the udevd package

I found the problem.
There isn't symbolic link /boot/initrd-tree/lib/libz.so.1 -> libz.so.1.2.6

This link is only in /lib directory.

I made this link manualy and made new initrd by mkinitrd without the -c option.
Now generic kernel works!

I checked the /var/log/packages file and libnl3 was installed, but I downloaded a fresh copy and re-installed it anyway. Unfortunately, it didn't solve the problem.


I checked the file and the card is properly listed as wlan0.

I un-installed (removepkg) the new version of NetworkManager (0.9.4) and re-installed the previous version (0.9.2) and upon reboot there was an error message saying networkmanager couldn't find libgnutls26.... something like that, it flew by quickly. Which reminds me, I do NOT like the way you are thrown to a new screen with only the 'welcome' and the sign-on prompt. Makes it almost impossible to read the last several lines of the boot process which are not in the dmesg file.

After seeing the error message I checked and gnutls-whatever is installed. So, I un-installed networkmanager-0.9.2 and installed wicd. Hopefully I'll figure out the problem soon as wicd is about as reliable as a politician.
:)

Me either, which is why I disabled that in /etc/inittab. If you move your .new file over the annoying behavior will cease.

Ah,so..... (He said, as the light dawned :) )
Thank you very much!
Greatly appreciated!
:hattip:

I also get this, even at boot. And everything is screwed up. Cannot launch volumeicon, glxinfo, glxgears e.t.c.. Gaaaaah

*EDIT:

Well, I deleted all the files that are not symbolic, those can be found in the /usr/lib64/seamonkey-2.10.1/ instead. I'm not sure how those files were installed in the /usr/lib64 anyways... I hope this does not screw up something now.

For the glx-part, I reinstalled the NVIDIA-driver...

And now for the volumeicon I get this:
bash-4.2$ volumeicon
volumeicon: error while loading shared libraries: libnotify.so.1: cannot open shared object file: No such file or directory