[arch-general] udev and/or device-mapper problem
I updated to udev, cryptsetup and device mapper from testing the installed kernel 2.6.32.6 and rebooted. now /dev/mapper/root and /dev/dm-0 are not there but /etc/mtab mentions /dev/mapper/root /dev/mapper/home and /dev/dm-1 exist The computer boots till the fsck part then stops because there is no /dev/mapper/root to fsck. I'm trying not to touch any libpng/libjpeg stuff in testing but non of those messes up booting anyway. After fsck fails, it dropped me to a shell. I downgraded udev and device-mapper, recreated the kernel image and I can boot now. Any ideas?
Am 28.01.2010 18:00, schrieb Hussam Al-Tayeb:
I updated to udev, cryptsetup and device mapper from testing the installed kernel 2.6.32.6 and rebooted. now /dev/mapper/root and /dev/dm-0 are not there but /etc/mtab mentions /dev/mapper/root /dev/mapper/home and /dev/dm-1 exist The computer boots till the fsck part then stops because there is no /dev/mapper/root to fsck. I'm trying not to touch any libpng/libjpeg stuff in testing but non of those messes up booting anyway.
You need the latest initscripts too, otherwise it will definitely fail.
On Thu, 2010-01-28 at 18:25 +0100, Thomas Bächler wrote:
Am 28.01.2010 18:00, schrieb Hussam Al-Tayeb:
I updated to udev, cryptsetup and device mapper from testing the installed kernel 2.6.32.6 and rebooted. now /dev/mapper/root and /dev/dm-0 are not there but /etc/mtab mentions /dev/mapper/root /dev/mapper/home and /dev/dm-1 exist The computer boots till the fsck part then stops because there is no /dev/mapper/root to fsck. I'm trying not to touch any libpng/libjpeg stuff in testing but non of those messes up booting anyway.
You need the latest initscripts too, otherwise it will definitely fail.
Thank you. updating initscripts fixed it. :)
Thursday 28 January 2010 skrev Hussam Al-Tayeb:
I updated to udev, cryptsetup and device mapper from testing the installed kernel 2.6.32.6 and rebooted.
Something similar, or the same thing, happened to me. I updated my system, and then on reboot it could not find the disk /dev/sda anymore. A pity, since it hold the boot and root file systems. I have a custom kernel, for various reasons, but now I could not get my custom kernel, of 2.6.32 series, to work with the new udev features, and have no idea what it can be. (The stock kernel does recognize the disks, but instead crashes on my radeon card, with or without the "fixes" described in the wiki. ) Without the /boot patition it was quite hard to get the system working again. Kernel update/downgrade does not work. I tried to downgrade packages, one after another, until I came to "udev", and after I downgraded it, the system worked normally. So now udev is locked it in a downgraded state. What is going on?
Am 10.02.2010 16:00, schrieb karolina.lindqvist@kramnet.se:
I updated my system, and then on reboot it could not find the disk /dev/sda anymore. A pity, since it hold the boot and root file systems. I have a custom kernel, for various reasons, but now I could not get my custom kernel, of 2.6.32 series, to work with the new udev features, and have no idea what it can be.
(The stock kernel does recognize the disks, but instead crashes on my radeon card, with or without the "fixes" described in the wiki. )
Without the /boot patition it was quite hard to get the system working again. Kernel update/downgrade does not work. I tried to downgrade packages, one after another, until I came to "udev", and after I downgraded it, the system worked normally. So now udev is locked it in a downgraded state.
What is going on?
First, this is an entirely different problem from the original one, which results from changes in udev rules concerning the device-mapper - the latter is not usedin your setup at all. Your custom kernel is misconfigured, the most likely candidate being: $ zgrep CONFIG_SYSFS_DEPRECATED /proc/config.gz # CONFIG_SYSFS_DEPRECATED_V2 is not set If this option is set to yes, udev will fail to create devices properly. If the option is unset in your kernel, we have to look for the reason further.
Wednesday 10 February 2010 skrev Thomas Bächler:
Your custom kernel is misconfigured, the most likely candidate being:
$ zgrep CONFIG_SYSFS_DEPRECATED /proc/config.gz # CONFIG_SYSFS_DEPRECATED_V2 is not set
If this option is set to yes, udev will fail to create devices properly. If the option is unset in your kernel, we have to look for the reason further.
Thank you for the fast help. That was exectly what I was looking for! I have rebuilt the kernel with that change, and now it appears to work. Karolina
Am 11.02.2010 11:56, schrieb Karolina Lindqvist:
Your custom kernel is misconfigured, the most likely candidate being:
$ zgrep CONFIG_SYSFS_DEPRECATED /proc/config.gz # CONFIG_SYSFS_DEPRECATED_V2 is not set
If this option is set to yes, udev will fail to create devices properly. If the option is unset in your kernel, we have to look for the reason further.
Thank you for the fast help. That was exectly what I was looking for! I have rebuilt the kernel with that change, and now it appears to work.
Glad my crystal ball was right. This option is needed if you run very old userspace (udev, ...), but is fatal if you run very recent software. With udev prior to 150, it mostly worked, but udev complained about it. With udev 150 and later, things will simply fail.
On Thu, 2010-02-11 at 12:50 +0100, Thomas Bächler wrote:
Am 11.02.2010 11:56, schrieb Karolina Lindqvist:
Your custom kernel is misconfigured, the most likely candidate being:
$ zgrep CONFIG_SYSFS_DEPRECATED /proc/config.gz # CONFIG_SYSFS_DEPRECATED_V2 is not set
If this option is set to yes, udev will fail to create devices properly. If the option is unset in your kernel, we have to look for the reason further.
Thank you for the fast help. That was exectly what I was looking for! I have rebuilt the kernel with that change, and now it appears to work.
Glad my crystal ball was right. This option is needed if you run very old userspace (udev, ...), but is fatal if you run very recent software. With udev prior to 150, it mostly worked, but udev complained about it. With udev 150 and later, things will simply fail.
It will also be a headache for the debian devs in uprading stable to squeeze in a few months. The stable kernel needs this option, but the new kernel and udev don't and upgrading from an old environment causes an error in the dist-upgrade. Just a FYI. It is not Archlinux-related... Vincent
participants (5)
-
Hussam Al-Tayeb
-
Karolina Lindqvist
-
karolina.lindqvist＠kramnet.se
-
Thomas Bächler
-
Vincent Van Houtte