Unable to boot after upgrading to latest kernel

axes · 2012-02-13 15:06:19

Hello.
So basically to sum things up, all I do is install the arch linux version found on www.archlinux.org which I have on my usb device, on an Asus K732S laptop with a clean 750GB hdd.
All goes well during the installation without any problems at all, I boot into my freshly installed arch, I upgrade pacman to version 4, I do a pacman -Sy and a full system upgrade with pacman -Suf.
During the upgrade I get a " failed to parse hook udev" error, and after I reboot grub can't boot my kernel with ERROR : Unable to find root device '/dev/disk/by-uuid/the_uuid' . You are being dropped to a recovery shell "
I have no idea what I am supposed to do from this point on, I tried re-installing several times, but the same thing keeps happening.
As an additional note, when I do the pacman -Suf , pacman prompts me that i have to Replace module-init-tools with core/kmod which I answer with a Y .

Has anybody else encountered this, or does anybody know what I'm doing wrong or what I'm not doing ? Please help .

Regards,
axes

Unia · 2012-02-13 15:23:31

I think the .iso you use is outdated. I suggest you to take a look at the Download page for the newer .iso's and try with those instead; it has all the things that you have to do (and that go wrong) "pre-installed".

Pres · 2012-02-13 15:48:38

Force (-f) should never be used except in rare cases. Update with pacman -Syu instead.

You might run into this error if you are updating from a fresh install of the lastest iso:
http://www.archlinux.org/news/filesyste … -required/

If so, just follow the instructions using the force flag and then run pacman -Syu again.

stryder · 2012-02-14 00:57:57

I'm with Pres. Don't use -f unless you have to. As for your problem try changing the root line in your grub (press "e" at the grub menu) to /dev/sda1, or whichever number that corresponds to your root partition.

PreparationH67 · 2012-02-14 22:14:26

I had a similar problem after a package update today, it appears to be related to udev, after the upgrade the udev hook went missing and my machine was unusable when tring to boot. I had to downgrade udev and the related packages that were upgraded using an arch install disk and then i was able to regenerate my kernel image with the udev hook and I was finallly able to boot into my Arch install. I have an Asus 1215b with the E-350 and I was freaking out since after the grub menu and the ramdisk message the screen just went black then I eventually just ended up with colored lines accross the screen. I have not seen any alerts or annoucements about udev or the mkinit related packages and I'm not sure which one exactly is the cause, but has anyone heard anything about this?

PreparationH67 · 2012-02-14 22:30:06

I confirmed that it is a problem with just the mkinitcpio package, downgraded it and let the others upgrade and the udev hook was found. I have been looking for a mention on the udev hook getting removed in the package upgrade, but, as I said, I have not found one.

conan · 2012-02-15 00:21:28

Thanks PreparationH67 I really tried hard today to get my system bootable again, I've been searching and reading many bug reports, but this one was the one that worked.

What didn't worked:

I started the day with a message from udevd: error while loading shared libraries: libkmod.so.1: cannot open shared object file

Indeed it was not there since I upgraded yesterday to kmod-5-2.

Tried downgrading, needed to downgrade to kmod-4-1, udev-175-1, mkinitcpio-0.8.0.3, and udev claimed initscripts also. This didn't worked.

Then, after new reboot I noticed later in the boot messages, after the one I posted above, that it was complaining about not being able to find /dev/disk/by-label, so I redirected my search to that path.

Tried upgrading to udev-git.

Tried changing bootline to root=/dev/sda2 which is my root device

Tried reconstructing initramfs with mkinitcpio -p linux and found ERROR: no udev hook.

So I tried getting mkinitcpio from git repository, only to confirm there's was no udev hook there either.

Edited /etc/mkinitcpio.conf to remove 'autodetect' and 'udev' (idea taken from some bug report around), image got built, but didn't boot, same error.

Upgraded again to mkinitcpio-0.8.2-2 and copied from archiso live cd /lib/initcpio/hooks/udev, rebuilt initramfs, but same error about no udev hooks, even when the file was there. An mkinitcpio -L didn't list udev hook.

Downgraded kernel from 3.2.5 to 3.2.2 and then I found this thread and after checking /var/cache/pacman/pkg I found that in my previous donwgrade of mkinitcpio I went from 0.8.2-2 to 0.8.0-3, but there was another package in the middle: 0.8.2-1. That's the one that has proper udev hooks and the one that finally, after several hours, allowed me to boot my machine.

Couldn't find any reference either about remotion of udev from mkinitcpio. Just this thread.

I'm posting my odyssey with error messages just in case someone else upgrades and get into this problem. I looked into several dead ends which had nothing to do with my problem.

So in the end I got these packages: udev-git (maybe not necessary since the problem is with mkinitcpio), mkinitcpio-0.8.2-1 and linux 3.2.2-1 and kmod 5-2 and there was no need to remove 'autodetect' and 'udev' from /etc/mkinitcpio.conf

Maybe the only one needing downgrading is mkinitcpio. Try that first before touching the others.

Mr.Elendig · 2012-02-15 02:30:59

Your use of udev-git without paying attention to the updates is the cause of your errors.

1. You did not rebuild it after the kmod update, which is why you were getting libkmod.so.1 not found errors. Downgrading kmod is not the solution, updating/rebuilding udev-git is (or using udev from core)
2. udev hook was moved from the mkinitcpio package to the udev package, but your old udev-git package ofcourse does not contain the udev hook.

Last edited by Mr.Elendig (2012-02-15 02:31:28)

root.otavio · 2012-02-15 16:29:22

Im having the same problem as Axes I installed the new arch system in my Asus At3n7a-i and in boot time or udev cannot find /dev/sda3 (my / partition) or it freezes
during the compiling some warning messagens and using mkinitcpio wich i think is the bad guy here I get these:

  -> Parsing hook: [base]
  -> Parsing hook: [udev]
  -> Parsing hook: [autodetect]
libkmod: index_mm_open: open(/lib/modules/3.2.6-Aquario/modules.dep.bin, O_RDONLY|O_CLOEXEC): No such file or directory
  -> Parsing hook: [scsi]
  -> Parsing hook: [sata]
  -> Parsing hook: [filesystems]
  -> Parsing hook: [usbinput]
==> WARNING: No modules were added to the image. This is probably not what you want.
==> Creating gzip initcpio image: /boot/initramfs-linux-Aquario.img
==> Image generation successful

Versions
udev = 181-2
mkinitcpio = 0.8.2-2
uname -r =3.2.5-1-ARCH
kmod = 5

any ideias??

falconindy · 2012-02-15 17:28:06

root.otavio wrote:

uname -r =3.2.5-1-ARCH
any ideias??

Sure, you can start by clarifying which kernel you're trying to create an initramfs for, and what flags you passed to mkinitcpio. Your code block shows a much different story than what you claim here to be your kernel.

exitus_ · 2012-02-26 21:53:56

Hi,

I had exactly the same problem and I think I fixed it by installing the package hwdetect. After that the kernel image could be compiled without the "udev hook" error by reinstalling linux.
Maybe that was not the solution, I also tried reinstalling the packages udev, mkinitcpio and of course linux.
Anyway one of that worked out for me.

falconindy · 2012-02-27 00:00:39

exitus_ wrote:

Hi,
I had exactly the same problem and I think I fixed it by installing the package hwdetect. After that the kernel image could be compiled without the "udev hook" error by reinstalling linux.
Maybe that was not the solution, I also tried reinstalling the packages udev, mkinitcpio and of course linux.
Anyway one of that worked out for me.

What the fuck? hwdetect?

udev. Reinstalling udev fixed your problem by way of your initramfs images being regenerated when you reinstalled linux.

Stop using anything but pacman (directly) to update your system. Stop using -f or --force with -Su under any circumstances. The number of threads that have spawned off because I simply moved the udev hooks is absurd. Pacman handles this transition properly when you don't try to outsmart it (and fail miserably).

vortex59 · 2012-02-29 10:12:46

http://www.archlinux.org/news/filesyste … -required/

Why is --force used?

falconindy · 2012-02-29 13:26:49

vortex59 wrote:

http://www.archlinux.org/news/filesyste … -required/
Why is --force used?

Exactly for the reasons prescribed in the news item. We deemed it safe to use --force with this one specfic upgrade.

ednos · 2012-03-01 20:44:59

falconindy wrote:

What the fuck? hwdetect?
udev. Reinstalling udev fixed your problem by way of your initramfs images being regenerated when you reinstalled linux.

Actually, I didn't have hwdetect installed, which apparently didn't matter before the update. Installing it fixed the udev hook. Reinstalling udev and mkinitcpio did nothing. I haven't done any research aside from looking at the list of packages depending on hwdetect (which is just archboot), but this indicates (to me) that this is a missing dependency of either udev or mkinitcpio, perhaps because it's assumed that hwdetect is installed on every system. Probably this is related to the thousand other incompatibilities between the latest "core" install image and any pacman-upgraded package (mostly programs and libraries moving from /bin and /lib to /usr/bin and /usr/lib).

falconindy · 2012-03-01 21:34:16

ednos wrote:

Actually, I didn't have hwdetect installed, which apparently didn't matter before the update. Installing it fixed the udev hook. Reinstalling udev and mkinitcpio did nothing. I haven't done any research aside from looking at the list of packages depending on hwdetect (which is just archboot), but this indicates (to me) that this is a missing dependency of either udev or mkinitcpio, perhaps because it's assumed that hwdetect is installed on every system. Probably this is related to the thousand other incompatibilities between the latest "core" install image and any pacman-upgraded package (mostly programs and libraries moving from /bin and /lib to /usr/bin and /usr/lib).

This is entirely FUD.

ednos · 2012-03-01 22:00:18

I just reproduced the problem exactly. It didn't happen at all on my 64-bit net-installed systems, but maybe this is a VMware-specific issue? I understand that you feel your reputation is at stake, considering you were spewing profanity earlier in the thread, but there's no need to start throwing the "FUD" buzzword around (especially if you don't know how to use it).

litemotiv · 2012-03-01 22:20:22

*grabs popcorn*

falconindy · 2012-03-01 23:40:26

ednos wrote:

I just reproduced the problem exactly. It didn't happen at all on my 64-bit net-installed systems, but maybe this is a VMware-specific issue? I understand that you feel your reputation is at stake, considering you were spewing profanity earlier in the thread, but there's no need to start throwing the "FUD" buzzword around (especially if you don't know how to use it).

Oh crap, my reputation on the internet is at stake. Please point out where hwdetect is called from in mkinitcpio, udev, or wherever you think it's supposedly needed, and I'll be sure to fix the package dependency myself.

ednos · 2012-03-02 03:16:23

falconindy wrote:

Please point out where hwdetect is called from in mkinitcpio, udev, or wherever you think it's supposedly needed, and I'll be sure to fix the package dependency myself.

I don't know where it's needed, but I'll look. What I do know is that after installing from the core image, then installing the VMware tools (open-vm-tools package) using ABS, the udev hook breaks. Running "pacman -S hwdetect" resolves the problem. If that step is the solution, then where is the problem?

If I was familiar with the system, I'd have submitted a bug report already. Like I said before, I haven't done my research. Based on the information above, what I posted was obviously the most probable cause. If you have information to demonstrate otherwise, I'm happy to hear it. I'm only defensive because FUD is a pretty weighty accusation in the open source world...

falconindy · 2012-03-02 03:49:26

hwdetect is a bash script that was written by an Arch dev, and as far as I'm aware, only exists in Arch Linux. It has exactly one reverse dependency (a project by the same dev). You'll have to excuse me for shrugging you off for claiming that a project like udev or vmware depends on it. There's surely a simpler explanation, though I don't know what that is.

rzs0502 · 2012-03-10 20:52:29

Hi all,

Is there a fix for this. I have installed Arch countless times in the past 6 years and this one has me stumped.
Today I decided to re-install my laptop with the latest ISO at 16:00.
All went fine until I updated and I now have an unbootable system exactly as axes.
Now at 22:30 I've installed Windows as it's the only other OS I currenly have :-(
BTW, the --force option was used as stated on the Arch website to overcome the /etc/mtab conflict. And that was the only package with an issue.
Something seems to be wrong with mkinitcpio/udev. Archbang users also have the issue.

Any idea?

falconindy · 2012-03-10 20:56:40

rzs0502 wrote:

BTW, the --force option was used as stated on the Arch website to overcome the /etc/mtab conflict. And that was the only package with an issue.

The --force option was recommend in conjunction with a single package, not a full upgrade.

rzs0502 wrote:

Something seems to be wrong with mkinitcpio/udev. Archbang users also have the issue.

Archbang also, until extremely recently, provided a keybinding by default that updated the system using "packer -Syyfu". There's a reason we ignore support requests on this forum when ArchBang is mentioned.

Nothing is wrong with mkinitcpio, udev, or pacman. The user is wrong in 100% of the cases.

ednos · 2012-03-12 03:46:52

falconindy wrote:

The user is wrong in 100% of the cases.

Of course. No one who develops Arch Linux could ever make a mistake. Their releases have provably complete regression testing.

Arch Linux

#1 2012-02-13 15:06:19

Unable to boot after upgrading to latest kernel

#2 2012-02-13 15:23:31

Re: Unable to boot after upgrading to latest kernel

#3 2012-02-13 15:48:38

Re: Unable to boot after upgrading to latest kernel

#4 2012-02-14 00:57:57

Re: Unable to boot after upgrading to latest kernel

#5 2012-02-14 22:14:26

Re: Unable to boot after upgrading to latest kernel

#6 2012-02-14 22:30:06

Re: Unable to boot after upgrading to latest kernel

#7 2012-02-15 00:21:28

Re: Unable to boot after upgrading to latest kernel

#8 2012-02-15 02:30:59

Re: Unable to boot after upgrading to latest kernel

#9 2012-02-15 16:29:22

Re: Unable to boot after upgrading to latest kernel

#10 2012-02-15 17:28:06

Re: Unable to boot after upgrading to latest kernel

#11 2012-02-26 21:53:56

Re: Unable to boot after upgrading to latest kernel

#12 2012-02-27 00:00:39

Re: Unable to boot after upgrading to latest kernel

#13 2012-02-29 10:12:46

Re: Unable to boot after upgrading to latest kernel

#14 2012-02-29 13:26:49

Re: Unable to boot after upgrading to latest kernel

#15 2012-03-01 20:44:59

Re: Unable to boot after upgrading to latest kernel

#16 2012-03-01 21:34:16

Re: Unable to boot after upgrading to latest kernel

#17 2012-03-01 22:00:18

Re: Unable to boot after upgrading to latest kernel

#18 2012-03-01 22:20:22

Re: Unable to boot after upgrading to latest kernel

#19 2012-03-01 23:40:26

Re: Unable to boot after upgrading to latest kernel

#20 2012-03-02 03:16:23

Re: Unable to boot after upgrading to latest kernel

#21 2012-03-02 03:49:26

Re: Unable to boot after upgrading to latest kernel

#22 2012-03-10 20:52:29

Re: Unable to boot after upgrading to latest kernel

#23 2012-03-10 20:56:40

Re: Unable to boot after upgrading to latest kernel

#24 2012-03-12 03:46:52

Re: Unable to boot after upgrading to latest kernel

Board footer