SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
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.
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
Yeah, I see the same thing and now my slackware -current won't boot. I'm using lvm and I get some error like could not mount myvg to /mnt. Had to use systemrescue to boot slackware. I still don't have a fix for this. Anyone?
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.
AlleyTrotter:
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
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.
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
Code:
# mkinitrd.conf.sample
# See "man mkinitrd.conf" for details on the syntax of this file
#
SOURCE_TREE="/boot/initrd-tree"
#CLEAR_TREE="0"
OUTPUT_IMAGE="/boot/initrd.gz"
KERNEL_VERSION="$(uname -r)"
KEYMAP="de"
MODULE_LIST="ext4:ahci"
#LUKSDEV="/dev/sda2"
#LUKSKEY="LABEL=TRAVELSTICK:/keys/alienbob.luks"
ROOTDEV="/dev/sda5"
ROOTFS="ext4"
RESUMEDEV="/dev/sda9"
#RAID="0"
#LVM="0"
#UDEV="1"
#MODCONF="0"
WAIT="1"
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
Code:
mkinitrd -F -c
Booting with the huge kernel is necessary so that the uname-command in mkinitrd.conf has the correct value.
markush:
But the drivers for the filesystem musst be built into the kernel, not as a module!
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.
But the drivers for the filesystem musst be built into the kernel, not as a module!
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.
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.
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.
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!
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,123
Rep:
Quote:
Originally Posted by escaflown
I had the same issue when I first upgraded too. I fount out it was because I was somehow missing libnl3. Everything's working fine now.
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.
Quote:
Originally Posted by willysr
also check /etc/udev/rules.d/70-persistent-net.rules as WLAN card name might get changed there just like in my case from wlan0 to wlan1
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.
Last edited by cwizardone; 07-15-2012 at 12:40 PM.
Reason: Typo.
Which remains 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.
Me either, which is why I disabled that in /etc/inittab. If you move your .new file over the annoying behavior will cease.
ldconfig: /usr/lib64/libnssutil3.so is not a symbolic link
ldconfig: /usr/lib64/libnspr4.so is not a symbolic link
ldconfig: /usr/lib64/libplc4.so is not a symbolic link
These are not dead links, and they are also present in /usr/lib64/seamonkey-2.10.1
Something didn't go right, but it does not seem to be a problem yet. Got more lookin' to do.
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
Last edited by Bindestreck; 07-15-2012 at 01:15 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.