LinuxQuestions.org - Friday the 13th Massive Upgrade

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Friday the 13th Massive Upgrade (https://www.linuxquestions.org/questions/slackware-14/friday-the-13th-massive-upgrade-4175416622/)

Quote:

Originally Posted by sandb0y (Post 4732849)

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.

Regards,
Grischuna

Quote:

Originally Posted by catfoo (Post 4732900)

Anyone having difficulty with a custom built kernel after all these upgrades? More specifically, kernel 3.4.4 or 3.4.5?

I just tried it with 3.4.6 on 32 bit -current, using the generic config-file, booting with initrd works fine here.

Quote:

Originally Posted by TobiSGD (Post 4733233)

I just tried it with 3.4.6 on 32 bit -current, using the generic config-file, booting with initrd works fine here.

Are you using a Luks encrypted LVM by chance? If so, I'd say I've screwed up something somewhere. Thanks.

First of all, what part of Alabama (how close are you to me)?

Quote:

Originally Posted by catfoo (Post 4732900)

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:

Code:

mkinitrd -c -k 3.4.5 -f ext4 -m mbcache:jbd:ext4:aes-generic:sha256-generic -C /dev/sda2 -r /dev/cvg0/root -h /dev/cvg0/swap -L -o /boot/initrd-3.4.5.gz

and edited lilo (or grub).

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...

First, /etc/fstab:

Code:

root@liberty:~# cat /etc/fstab 

/dev/cryptvg/swap          swap          swap    defaults              0 0

/dev/cryptvg/root          /            ext4    defaults              1 1

/dev/cryptvg/var          /var          ext4    defaults              1 2

devpts                    /dev/pts      devpts  gid=5,mode=620        0 0

proc                      /proc        proc    defaults              0 0

tmpfs                      /dev/shm      tmpfs    defaults,nosuid,nodev  0 0

tmpfs                      /tmp          tmpfs    size=4G                0 0

/dev/sda1                  /boot        ext4    defaults              1 2

/dev/cryptvg/home          /home        ext4    defaults              1 2

/dev/disk/by-label/VMS    /home/VMS    ext4    defaults              1 2

/dev/disk/by-label/STORE  /home/source  ext4    defaults              1 2

stora:/shared              /shared      nfs      noauto,tcp            0 0

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 :-)

Code:

root@liberty:~# cat /etc/mkinitrd.conf

KEYMAP="us"

MODULE_LIST="ext4:intel_agp:drm:i915"

LUKSDEV="/dev/sda2"

ROOTDEV="/dev/cryptvg/root"

ROOTFS="ext4"

RESUMEDEV="/dev/cryptvg/swap"

RAID="0"

LVM="1"

UDEV="1"

MODCONF="1"

Quote:

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 :/

Quote:

Originally Posted by sandb0y (Post 4733137)

Add your user to the audio group, and try again.

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.

Quote:

Originally Posted by rpedrica (Post 4733421)

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.

Quote:

Originally Posted by rworkman (Post 4733296)

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 (Post 4733296)

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!

Thanks for the help, and I'll report back later.

Quote:

Originally Posted by catfoo (Post 4733887)

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:

Code:

/usr/src/linux/scripts/diffconfig /boot/config-generic-3.2.23 [your .config] | grep CONFIG_CRYPTO

It could also possibly be the lack of /dev/random or /dev/urandom device nodes on the initramfs.

Quote:

Originally Posted by volkerdi (Post 4733982)

Code:

/usr/src/linux/scripts/diffconfig /boot/config-generic-3.2.23 [your .config] | grep CONFIG_CRYPTO

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 (Post 4733982)

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.

Hello,

since the big update, Kaffeine can't play video from my DVB-S Card.
It claims "No Device", but I can still watch DVB-S channels with mplayer.

Have already recompiled Kaffeine, but didn't help. If anyone has an idea...

EDIT: Found out more, this seems to be a bug in udev or kaffeine
https://bugs.gentoo.org/show_bug.cgi?id=372489

Kaffeine gets the path to the dvb device wrong...

Quote:

Originally Posted by catfoo (Post 4734000)

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.

Thanks for the help.

Quote:

Originally Posted by catfoo (Post 4734053)

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.

Quote:

Thanks for the help.

Glad it was helpful!

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.