Friday the 13th Massive Upgrade

alekow · 07-21-2012, 01:35 AM

Quote:

Originally Posted by cwizardone

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.

I've had this problem before. You'll have to rebuild your nvidia drivers I suppose.

rpedrica · 07-21-2012, 08:27 AM

Quote:

Originally Posted by cwizardone

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.

If you are using a binary video driver, have you reinstalled it?

cwizardone · 07-21-2012, 08:39 AM

Quote:

Originally Posted by TommyC7

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

If you like that one, you'll love this one. This was back on 8 May 2012. I started a fresh install and went to the corner market for a few minutes. I came back, grabbed a cup of coffee, and sat down in front of the monitor to find the installation had frozen and this is what was on the screen. Seems there are some bugs or old data hidden in the installation software somewhere.

cwizardone · 07-21-2012, 08:42 AM

@Alekow & Rpedrica,

I deleted the ~.kde directory and re-started. So far, so good.

AlleyTrotter · 07-21-2012, 11:39 AM

Quote:

Originally Posted by cwizardone

@Alekow & Rpedrica,

I deleted the ~.kde directory and re-started. So far, so good.

I had the upside down reverse screen a few months ago.
It happened when messing with the Nvidia driver.
I normally use nouveau.
I remember deleting the .kde directory and doing a:
"upgradepkg --reinstall" kde, x, and maybe l also. I really don't remember anymore. It certainly was shocking. I immediately thought some one was playing a cruel joke

john

dr.s · 07-21-2012, 01:14 PM

Not sure if this is a result of the latest upgrades, everything is running smoothly here but noticed that the /dev/root link is not there anymore, found out when running lilo after compiling a custom 3.4 kernel, it failed since lilo.conf has "boot = /dev/root", workaround is easy but why has /dev/root disappeared?
Thanks.

Quote:

# ls -lh /dev/root
/bin/ls: cannot access /dev/root: No such file or directory

volkerdi · 07-21-2012, 02:06 PM

Quote:

Originally Posted by dr.s

Not sure if this is a result of the latest upgrades, everything is running smoothly here but noticed that the /dev/root link is not there anymore, found out when running lilo after compiling a custom 3.4 kernel, it failed since lilo.conf has "boot = /dev/root", workaround is easy but why has /dev/root disappeared?
Thanks.

How did "boot = /dev/root" end up in lilo.conf? Did liloconfig do that somehow?

Upstream udev dropped the /dev/root symlink because it was really never supposed to be used for anything. Frankly, I'm not sure why the kernel ever provided it in the first place. It used to know what the actual root partition was without requiring an initrd to figure it out, but perhaps that's because the kernel used to need to be prepped with "rdev", which is long obsolete.

Didier Spaier · 07-21-2012, 02:40 PM

I did a fresh installatin of -current in its state after update dated Wed Jul 18 20:21:15 UTC 2012.

As / has an ext4 file system I made an initrd with the usual command:

Code:

mkinitrd -c -k 3.2.23-smp -m ext4

Updated /etc/lilo.conf, re-ran lilo, rebooted and just after loading the three modules needed for ext4 I see:

Code:

mounting /dev on /mnt failed: Block device required

dr.s · 07-21-2012, 02:40 PM

Quote:

Originally Posted by volkerdi

How did "boot = /dev/root" end up in lilo.conf? Did liloconfig do that somehow?

Upstream udev dropped the /dev/root symlink because it was really never supposed to be used for anything. Frankly, I'm not sure why the kernel ever provided it in the first place. It used to know what the actual root partition was without requiring an initrd to figure it out, but perhaps that's because the kernel used to need to be prepped with "rdev", which is long obsolete.

Running liloconfig fails on my machine with the message below, so I copied (a very old) lilo.conf, edited it manually and ran lilo. That old copy had "boot = /dev/root" in it.

Code:

# liloconfig 
liloconfig: couldn't open /tmp/lilotmp1: No such file or directory

hotchili · 07-21-2012, 03:45 PM

Hello,

Quote:

Originally Posted by hotchili

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

just FYI, I upgraded udev to version 182 and kaffeine works fine again.

I had to make some small changes to the udev.SlackBuild:
--libexecdir=/lib/udev becomes --libexecdir=/lib (else everything ends up in /lib/udev/udev)

just before scsi_id is linked into /sbin:
[ ! -d $PKG/sbin ] && mkdir $PKG/sbin

after udevd gets moved to /sbin, had to move udevadm too:
mv $PKG/usr/bin/udevadm $PKG/sbin
rm -rf $PKG/usr/bin

In the docs section:
extras/keymap/README.keymap.txt becomes src/keymap/README.keymap.txt

And the patch rule_generator.diff.gz had to be reformatted but is more or less the same.

Didier Spaier · 07-21-2012, 03:57 PM

I did notice that I have:

Code:

bash-4.2# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        10G  6.8G  2.7G  72% /
/dev/sda3       103G   48G   51G  49% /13.37
tmpfs           1.5G     0  1.5G   0% /dev/shm
/dev/sda2        32G   30G  2.6G  92% /windows
bash-4.2#

Though the /dev/root link doesn't exist anymore, as pointed out by dr.s in post #186 of this thread.

Could booting with an initrd failing (see my post #188) be related to that?

EDIT

Code:

bash-4.2# cat /etc/fstab
/dev/sda6        swap             swap        defaults         0   0
/dev/sda5        /                ext4        defaults         1   1
/dev/sda3        /13.37           ext4        defaults         1   2
/dev/sda2        /windows         ntfs-3g     fmask=133,dmask=022 1   0
#/dev/cdrom      /mnt/cdrom       auto        noauto,owner,ro  0   0
/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0
tmpfs            /dev/shm         tmpfs       defaults         0   0
bash-4.2#

So I don't know why "df -h" writes /dev/root instead of /dev/sda5

hotchili · 07-21-2012, 04:29 PM

This is from mkinitrd:

Quote:

and if "mount" returns /dev/root as the root device,
use readlink to resolve the device pointed to by the /dev/root
symlink

Maybe it tried to resolve /dev/root but fails and then gets something wrong.
cat /boot/initrd-tree/rootdev to see what mkinitrd set as rootdev.

You could try mkinitrd with -f ext4 -r /dev/sda5 and see if your initrd error goes away.

Didier Spaier · 07-21-2012, 05:02 PM

Quote:

Originally Posted by hotchili

You could try mkinitrd with -f ext4 -r /dev/sda5 and see if your initrd error goes away.

Thanks hocthili, that did the trick.

I did "cat /boot/initrd-tree/rootdev" before running mkinitrd again and it returned /dev/

I guess you are right, at first mkinitrd tried to resolve /dev/root but failed as /dev/root did not exist.

EDIT I just looked at /sbin/mkinitrd and can confirm your assumption

Code:

# If $ROOTDEV and $ROOTFS are not set, assume we want the
# values for the currently mounted /
# (unless we find that values are already set in the initrd-tree):
if [ -z "$ROOTDEV" -a -z "$(cat $SOURCE_TREE/rootdev 2>/dev/null)" ]; then
  ROOTDEV=$(mount | grep ' on / ' | cut -f 1 -d ' ')
  if [ "$ROOTDEV" = "/dev/root" ]; then # find real root device
    ROOTDEV="/dev/$(readlink /dev/root)"
  fi
fi

In my case $ROOTDEV was not set and the source tree didn't exist yet, but "mount" returned /dev/root as / filesystem hence $(readlink /dev/root) was null and $ROOTDEV was set to /dev/

So the real problem seems to be "why do the mount command return /dev/root as filesystem for / here?"

PS for Pat: maybe the script could issue a warning in case $(readlink /dev/root) be null? Or look at /etc/fstab in that case?

PS2 I notice that whilst a generic kernel is used "mount" report the real device name for / (in my case /dev/sda5). Unfortunately chances are that mkinitrd be run whilst using a huge kernel...

imitheos · 07-22-2012, 10:12 AM

Quote:

Originally Posted by catfoo

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.

Quote:

Originally Posted by catfoo

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.

Is CONFIG_DEVTMPFS disabled in the kernel that is failing ?

udevd (according to the manpage) should copy the devices from /lib/udev/devices so /dev/urandom should be in /dev. However, for some reason it doesn't get copied (at least in my case and yours) and cryptsetup fails. If CONFIG_DEVTMPFS is enabled (as it is in the generic slackware kernel) then the devices are present and everything works fine.

rworkman · 07-22-2012, 12:25 PM

devtmpfs is *required* - go ahead and enable it.