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.
Hey Grischuna,
I had the same problem after last upgrade, but with kernel 3.4.4 my BCM4318 wireless card works again.
Thank you sandb0y for your info. As mentioned in my post I have now installed the Broadcom-sta kernel modules from Slackbuilds.org with the patch and with this the card is working fine again. I will still test out the new 3.4.6 kernel that is out now.
First of all, what part of Alabama (how close are you to me)?
Quote:
Originally Posted by catfoo
Anyone having difficulty with a custom built kernel after all these upgrades? More specifically, kernel 3.4.4 or 3.4.5?
Setup: /dev/sda1 = /boot partition (ext2), /dev/sda2 = luks encrypted LVM (groups root, swap, home, var, tmp, all are ext4)
Did a clean install of -current using a dvd created with all updates up through July 17 changelog. I then upgraded everything up to yesterday's packages which included mkinitrd-1.4.7-i486-4.txz.
Compiled and installed the new kernel and its modules, then created the initrd with the following command:
All is well here, and I'm on a fully encrypted system. Mikhail Zotov has mailed me privately about what appears to be this same issue, and he ran across it quite some time ago (after having done some local upgrades iirc). To quote him:
Code:
Luckily, the fix is exactly the same: to replace cryptroot in
/etc/fstab, /etc/lilo.conf and in the mkinitrd command with, say,
/dev/mapper/lukssda2.
Here's the fun part though: everything is fine here, but for the sake of comparison, I'll post some snippets of local config...
Here's my /etc/mkinitrd.conf -- note that the intel_agp, drm, and i915 modules aren't strictly needed to boot, but I like getting the kms console early :-)
When I try to boot the new kernel, it fails when trying to decrypt the luks encrypted drive, then the 'init' script exits and I get dropped to a shell of some sort. I can see in the '/boot/initrd-tree/init' script where it is failing, I just can't figure out why.
Once you get dropped to that shell, poke around and see where things broke down -- i.e., is the luks container unlocked (did you enter a passphrase? If not, then the answer is no and you can start there)...
Quote:
The strange part is that during installation, I created the initrd for the generic-smp kernel using the same command as above, and it boots fine.
Now I'm confused - you mean an initrd created during installation works fine, but one created on the running system does not??
Quote:
To recap, since I feel like an incoherent twit: Clean install of -current which had mkinitrd-1.4.7-i486-3, using generic kernel 3.2.23-smp. Made initrd using that version. Then, upgraded to mkinitrd-1.4.7-i486-4, and used that to make initrd for custom kernel 3.4.5 and can't boot it.
Ohh, so to follow up on my own question above, the previous version of mkinitrd created a working initrd while the current version does not? If that's the case, then this makes no sense at all :/
Oh man do I feel like the prize idiot now! In defense though, this was working before the upgrade so I had to have been in the audio group previously. Why or how this would have changed is beyond me.
Oh man do I feel like the prize idiot now! In defense though, this was working before the upgrade so I had to have been in the audio group previously. Why or how this would have changed is beyond me.
Actually, it probably happened after the upgrade and all the new files you told it to overwrite. I do that a lot.
Don't know if this was the case before this update since I grabbed current iso from slackware.no (slackware64-current-17_Jul_2012-DVD.iso), but xfce application shortcuts are not working. I can't assign any custom shortcut (not even Alt-F2 is working), but window manager shortcuts are fine.
Other than that, bunch of ponce's slackbuld scripts for current are broken too.
First of all, what part of Alabama (how close are you to me)?
Hi Robby, and Roll Tide! I'm in the Huntsville area, just another ol' redneck. Huge 'Bama fan!
Quote:
Originally Posted by rworkman
Once you get dropped to that shell, poke around and see where things broke down -- i.e., is the luks container unlocked (did you enter a passphrase? If not, then the answer is no and you can start there)...
My luks container never gets unlocked. If I try to run 'cryptsetup' from that shell, the error message is 'Cannot initialize crypto RNG backend.'
At this point I'm beginning to think that my kernel config is the problem. I'm seeing that some things I've always built as modules (i.e. ext4, mbcache, etc.) are now built into the kernel. I need to check this out before investigating anything else. I just don't know how those items got changed from modules to built-in. I've been using the same .config file for ages. When I build a new kernel, I 'make oldconfig' and save the resulting .config file. But, I am pushing 40 now, so maybe I just can't remember that I actually changed it myself!
My luks container never gets unlocked. If I try to run 'cryptsetup' from that shell, the error message is 'Cannot initialize crypto RNG backend.'
At this point I'm beginning to think that my kernel config is the problem.
Could be. That was the first thing that came to mind. There are several crypto modules that are built into both the generic and huge kernels to handle cryptsetup without having to add those modules to the initramfs. You might want to compare your kernel config to one of the official ones:
Could be. That was the first thing that came to mind. There are several crypto modules that are built into both the generic and huge kernels to handle cryptsetup without having to add those modules to the initramfs. You might want to compare your kernel config to one of the official ones:
I am compiling 3.4.6 using /boot/config-generic-smp-3.2.23-smp at the moment, just to see what happens.
Quote:
Originally Posted by volkerdi
It could also possibly be the lack of /dev/random or /dev/urandom device nodes on the initramfs.
I read something about this earlier today. Those nodes were not present, as you suggest. I copied them into the dev folder of the initramfs, then re-ran mkinitrd without the 'clear' option, and rebooted. I'm not sure if I needed to something else there or not. This is one of those dark scary parts of Linux that I have never had to touch, so if nothing else it'll be enlightening! Anyway, when it failed and dropped to the shell this time (is the proper term 'rescue' shell, by the way?), I was able to manually run cryptsetup, however it gave some errors about a messed up semaphore. Probably should have written that down.
We'll see what happens when compiling with your generic config file.
--Edit
To clarify, running cryptsetup did not actually work, it just spit out the semaphore error. However, it at least asked me for the passphrase this time, which it hasn't done in prior attempts.
Also, running 'diffconfig' as suggested above showed no differences in crypto settings.
Last edited by bamalabs; 07-20-2012 at 02:43 PM.
Reason: Clarity
I am compiling 3.4.6 using /boot/config-generic-smp-3.2.23-smp at the moment, just to see what happens.
Up and running 3.4.6 now after using the default /boot/config-generic-smp-3.2.23-smp file.
I do find it curious that the new /boot/initrd-tree/dev folder still doesn't have the random and urandom nodes. I'll just assume it has to do with differences in the kernel configuration until someone tells me otherwise.
Up and running 3.4.6 now after using the default /boot/config-generic-smp-3.2.23-smp file.
Good to hear.
Quote:
I do find it curious that the new /boot/initrd-tree/dev folder still doesn't have the random and urandom nodes. I'll just assume it has to do with differences in the kernel configuration until someone tells me otherwise.
They actually aren't supposed to be in /boot/initrd-tree/dev, as that's just the mount point for udev's devramfs. They're supposed to be in /boot/initrd-tree/lib/udev/devices, which contains a few devices that udev won't create (but will move into place from there). Looking in there, I see only urandom is present. Probably that's the required one.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,095
Rep:
Upside Down & Backwards.
I've spent the last 24 hours trying to do a fresh install of 13.37 (64bit) and then "upgrade" (Ha) to -current. I've made at least 3 attempts from scratch. Might be four. At this point I'm so tired I don't remember. Each time there was a problem and I finally figured it out....
But this is the last straw... I had everything working well, except Xfce, but KDE 4.8.4 was working OK. NetworkManager still doesn't work, but wicd is doing the job for now.
Just when I thought all was nearly done, I fired up KDE and the whole desktop went upside down and backwards. You can see it start from the splash screen. It happens to both user and root.
Picture attached. I didn't crop out the HP logo so you can see this isn't some sort of trick.
No offense to you cwizardone (I know you're having a real problem), but that's hilarious. There seems to be a lot of things with SCSI drivers though, and I've run into one of them too it seems:
Code:
# cdrecord -scanbus
Cdrecord-ProDVD-ProBD-Clone 3.01a07 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2012 Joerg Schilling
cdrecord: No such file or directory. Cannot open '/dev/pg*'. Cannot open or use SCSI driver.
cdrecord: For possible targets try 'cdrecord -scanbus'.
cdrecord: For possible transport specifiers try 'cdrecord dev=help'.
#
So I went looking into /dev:
Code:
# ls /dev/pg*
/bin/ls: cannot access /dev/pg*: No such file or directory.
I'm not sure if a rebuild of cdrtools would fix this, but seeing as how it's looking for something in /dev I'm going to think it wouldn't.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.