[SOLVED]Arch fails to mount drives on boot.

Anikom15 · 2010-02-13 17:44:16

Ok, can someone give me a list of all files that could affect this? menu.lst, rc.conf, mkinicpio.conf, anything else?

Anikom15 · 2010-02-13 22:41:46

Ok, I've retraced my steps and looked for signs of error, did an upgrade and it's still no good. So, I'm just gonna wait.

PeachyPeach · 2010-02-14 01:39:26

I'm also having this problem, and I also have IDE drives. I rebooted after a system upgrade today; last upgrade before this was mid-January and last reboot was probably that same time.

In the recovery environment, I do not have /dev/hd*, /dev/sd*, or /dev/disk/.

I added ide to HOOKS in mkinitcpio.conf; no new devices.

In the interest of full disclosure: root, /boot and /home are ext3 and are sda1, sda2 and sda5, respectively. /boot does not automount. sda7 is XFS and mounts at /misc. My fstab uses "UUID=..." and menu.lst uses "/dev/disk/by-uuid/..." They always have been this way.

Anyone else have ideas?

Last edited by PeachyPeach (2010-02-14 01:51:47)

Anikom15 · 2010-02-14 03:38:14

It probably has to do with the IDE or PATA drivers. I'm so glad there is someone else with my problem.

EDIT: Now I'm thinking it's udev.

Last edited by Anikom15 (2010-02-14 18:23:50)

davidm · 2010-02-14 17:29:30

PeachyPeach wrote:

I'm also having this problem, and I also have IDE drives. I rebooted after a system upgrade today; last upgrade before this was mid-January and last reboot was probably that same time.

It might be helpful to go into your pacman log and list first what was most recently upgraded and then also everything upgraded since mid-January. We might be able to pick out some likely culprits or config file changes. Just a stab int he dark I guess... In theory I'm thinking downgrading to the old packages would have to work too even though that would be extremely messy and not ideal. If we can isolate the cause it would be much better, not to mention easier.

Last edited by davidm (2010-02-14 17:30:38)

Anikom15 · 2010-02-14 18:12:37

Ok, here's some of my upgrades that may have affected the issue:

[2010-02-11 15:02] upgraded udev (151-2 -> 151-3)
[2010-02-10 17:53] upgraded kernel26 (2.6.32.7-1 -> 2.6.32.8-1)
[2010-02-10 17:52] upgraded kernel26-firmware (2.6.32.7-1 -> 2.6.32.8-1)

PeachyPeach · 2010-02-14 18:57:31

OK, never mind, I'm back up and running! This morning I did another system upgrade; the new device-mapper package has fixed it.

Relevant lines from pacman.log, just for kicks:

[2010-02-14 05:51] removed klibc-udev (141-3)
[2010-02-14 05:51] removed klibc-module-init-tools (3.8-1)
[2010-02-14 05:51] removed klibc-kbd (1.15.20080312-10)
[2010-02-14 05:51] removed klibc-extras (2.5-4)
[2010-02-14 05:51] removed klibc (1.5.15-3)
[2010-02-14 05:51] upgraded device-mapper (2.02.60-2 -> 2.02.60-3)

I also updated my kernel for the first time in a long time--I had IgnorePkg kernel26 set because I have an older nvidia card and those packages aren't always updated when the kernels are--because some of the new udev rules required a newer kernel than I had, but that alone didn't fix it (neither did commenting out the offending lines in the rules, but that was also just a stab in the dark).

Anikom15 · 2010-02-14 23:14:25

Same upgrade (sorta) and now I'm even worse off. The kernel doesn't work properly, it starts to complain about being unable to run the udev hook. And I'm dropped into the ramfs shell.

brain0 · 2010-02-15 00:07:17

PeachyPeach wrote:

OK, never mind, I'm back up and running! This morning I did another system upgrade; the new device-mapper package has fixed it.
Relevant lines from pacman.log, just for kicks:
[2010-02-14 05:51] removed klibc-udev (141-3)
[2010-02-14 05:51] removed klibc-module-init-tools (3.8-1)
[2010-02-14 05:51] removed klibc-kbd (1.15.20080312-10)
[2010-02-14 05:51] removed klibc-extras (2.5-4)
[2010-02-14 05:51] removed klibc (1.5.15-3)
[2010-02-14 05:51] upgraded device-mapper (2.02.60-2 -> 2.02.60-3)
I also updated my kernel for the first time in a long time--I had IgnorePkg kernel26 set because I have an older nvidia card and those packages aren't always updated when the kernels are--because some of the new udev rules required a newer kernel than I had, but that alone didn't fix it (neither did commenting out the offending lines in the rules, but that was also just a stab in the dark).

You know, the new device-mapper package doesn't have any changes at all, it is identical to the old one. The only reason there was a new package is that it is a split package from lvm2, which had some minor changes in the initramfs hooks. Furthermore, it is impossible for the device-mapper to have that effect, because the problem was unrelated to it from the beginning.

brain0 · 2010-02-15 00:10:16

Anikom15 wrote:

Same upgrade (sorta) and now I'm even worse off. The kernel doesn't work properly, it starts to complain about being unable to run the udev hook. And I'm dropped into the ramfs shell.

The only reason I can think of why this could happen is a misconfigured (CONFIG_SYSFS_DEPRECATED) or old kernel, or broken udev rules. The problem resides in udev, that much is sure now (it worked in the old initramfs, now it doesn't - the new initramfs has the same udev version as the normal system, and I suspected udev from the beginning).

What exactly is your error message - "starts to complain about being unable to run udev" is a useless report, I need the EXACT words, even better, a photo of the screen.

PeachyPeach · 2010-02-15 08:06:20

brain0 wrote:

You know, the new device-mapper package doesn't have any changes at all, it is identical to the old one. The only reason there was a new package is that it is a split package from lvm2, which had some minor changes in the initramfs hooks. Furthermore, it is impossible for the device-mapper to have that effect, because the problem was unrelated to it from the beginning.

Fair enough. I was thinking if klibc-udev was removed it had to be replaced with something, and I assumed device-mapper was the replacement since it sounded like it was related. *shrug* I haven't had to deal with anything this low level since the early 2.4 kernels. I guess it's a sign that I should get more involved again, maybe do another LFS build and relearn everything.

Anyway, in the end, some combination of the following got my system running again: adding IDE to my mkinitcpio hooks, and/or installing 2.6.32 kernel, and/or the upgrade this morning. It's worth mentioning that my mkinitcpio hooks line is almost identical to the IDE example, minus scsi, plus keymap. And that the mirror I used was up to date.

Anikom15 · 2010-02-15 19:24:06

Ok, I filed a bug report and fixed the udev problem, but I still can't boot. Here's a screenshot (I gimped it to make it more readable).

There was more before, but it got cleared.

Last edited by Anikom15 (2010-02-15 19:24:48)

brain0 · 2010-02-15 21:38:49

Boot the fallback image - no kernel modules have been loaded after running the udev hook, so I assume they were all missing.

That might be caused by an initramfs image generated in an environment where autodetection fails (which happens a lot if you chroot into an arch system without bind-mounting proc, dev and sys). The normal (non-fallback) image should work again once you regenerate it (with mkinitcpio -p kernel26) in your normal system once it is booted.

EDIT: Forgot to add: the good news is, the rest looks fine now from what I can read.

Last edited by brain0 (2010-02-15 21:40:11)

Anikom15 · 2010-02-15 21:57:45

I did build in a chroot, pretty sure I bind-mounted but maybe not.

UPDATE: It doesn't work. I'm getting the same errors when I try to boot the fallback. Even if I rebuild it in chroot (with the bind) it fails. I followed the wiki's chroot instructions.

Last edited by Anikom15 (2010-02-15 22:25:18)

brain0 · 2010-02-16 00:12:29

Anikom15 wrote:

I did build in a chroot, pretty sure I bind-mounted but maybe not.
UPDATE: It doesn't work. I'm getting the same errors when I try to boot the fallback. Even if I rebuild it in chroot (with the bind) it fails. I followed the wiki's chroot instructions.

Weird. The screenshot shows nothing after "Loading Hooks [udev]:" indicating that no modules are being loaded at all. You should really run

find /sbin /bin /usr/sbin /usr/bin -size 0

on your system to see if any more broken binaries are around.

Last edited by brain0 (2010-02-16 00:12:45)

Anikom15 · 2010-02-16 00:24:12

Output of find:

/usr/sbin/chat
/usr/sbin/pppdump
/usr/sbin/ppd
/usr/sbin/ppoe-discovery
/usr/sbin/plog
/usr/sbin/pppstats
/usr/bin/pon
/usr/bin/poff
/usr/bin/ecpg
/usr/bin/brasero

UPDATE: I did an Syu and it outputted a huge list of empty files in /sbin/ldconfig.

Last edited by Anikom15 (2010-02-16 00:28:12)

brain0 · 2010-02-16 00:28:09

You should reinstall the packages that those files belong to, none of them is supposed to have zero size (how did you end up with so many broken files in the first place? Power cut or unclean shutdown directly after a system upgrade on ext4/jfs/xfs?). However, none of them explains why no modules are loaded for you.

I can't think of the reason for the problem now, when I remember something I'll post again. Keep looking for zero-size files that shouldn't be zero size.

Anikom15 · 2010-02-16 00:35:23

Ok, I tried to reinstall brasero and I got a ton of "blah/blah exists in filesystem" greeeat!

UPDATE: pacman -Sf took care of it.

Last edited by Anikom15 (2010-02-16 00:38:15)

Anikom15 · 2010-02-16 00:42:25

Ok, I've figured it out! Somehow the last update before all this began got messed up. So, If I reinstall what I upgraded the errors are going away, not sure if this is gonna help out the booting, but we'll see.

stryder · 2010-02-17 14:50:58

Well, I have the same problem (partition does not exist). Yes there is an IDE disk in my computer, although it is not root. The issue is the image file. Using the fallback option works. I ran mkinitcpio -p kernel26 again but still only the fallback will let me through. All this is just after update, including kernel. Everything up to date. Since there is this change with mkinitcpio perhaps there is a glitch?

*EDIT*
Reinstalled kernel26 mkinitcpio udev - no change.

OK, looking over the messages at boot, it looks like udev named the partitions differently from before, reversing the order of my two hard disks. Since I have already labeled my partitions I changed all the partition references in boot and fstab to labels (forgotten to change earlier!). Everything OK.

Last edited by stryder (2010-02-18 00:53:10)

Arch Linux

#26 2010-02-13 17:44:16

Re: [SOLVED]Arch fails to mount drives on boot.

#27 2010-02-13 22:41:46

Re: [SOLVED]Arch fails to mount drives on boot.

#28 2010-02-14 01:39:26

Re: [SOLVED]Arch fails to mount drives on boot.

#29 2010-02-14 03:38:14

Re: [SOLVED]Arch fails to mount drives on boot.

#30 2010-02-14 17:29:30

Re: [SOLVED]Arch fails to mount drives on boot.

#31 2010-02-14 18:12:37

Re: [SOLVED]Arch fails to mount drives on boot.

#32 2010-02-14 18:57:31

Re: [SOLVED]Arch fails to mount drives on boot.

#33 2010-02-14 23:14:25

Re: [SOLVED]Arch fails to mount drives on boot.

#34 2010-02-15 00:07:17

Re: [SOLVED]Arch fails to mount drives on boot.

#35 2010-02-15 00:10:16

Re: [SOLVED]Arch fails to mount drives on boot.

#36 2010-02-15 08:06:20

Re: [SOLVED]Arch fails to mount drives on boot.

#37 2010-02-15 19:24:06

Re: [SOLVED]Arch fails to mount drives on boot.

#38 2010-02-15 21:38:49

Re: [SOLVED]Arch fails to mount drives on boot.

#39 2010-02-15 21:57:45

Re: [SOLVED]Arch fails to mount drives on boot.

#40 2010-02-16 00:12:29

Re: [SOLVED]Arch fails to mount drives on boot.

#41 2010-02-16 00:24:12

Re: [SOLVED]Arch fails to mount drives on boot.

#42 2010-02-16 00:28:09

Re: [SOLVED]Arch fails to mount drives on boot.

#43 2010-02-16 00:35:23

Re: [SOLVED]Arch fails to mount drives on boot.

#44 2010-02-16 00:42:25

Re: [SOLVED]Arch fails to mount drives on boot.

#45 2010-02-17 14:50:58

Re: [SOLVED]Arch fails to mount drives on boot.

Board footer