You are not logged in.
So fsck kept fscking up. It seems that Arch is failing to properly recognize my partitions. I can boot into live cd fine, and the partition contents are fine, so what should I do?
FINAL UPDATE: Ok, it's all good. It was a combination of an improper upgrade and an udev bug.
Last edited by Anikom15 (2010-02-16 02:49:47)
Personally, I'd rather be back in Hobbiton.
Offline
What are the relevant lines in ..../grub/menu.lst?
At what stage does booting fail?
Good ideas do not need lots of lies told about them in order to gain public acceptance.
Offline
Is this just after finishing an install? I installed from the usb image and the device mapping set the wrong drive in grub. Edit the grub entry to check what hard drive is being used. I needed to change (hd1,0)->(hd0,0).
Offline
Those are all stupid questions I thought I answered in my first post but whatever.
menu.lst is fine. fstab's fine. I didn't change anything, I just rebooted. It fails when it runs fsck.
Personally, I'd rather be back in Hobbiton.
Offline
Did you fsck from the liveCD, or did you just mount and have a look?
Good ideas do not need lots of lies told about them in order to gain public acceptance.
Offline
I booted into live, mounted and fscked and everything was fine, so it's not the partition itself. I tried to manually fsck in the console (not live) but there was no /dev/sda. So I think it may have to do with that.
Personally, I'd rather be back in Hobbiton.
Offline
So what is there - /dev/sdb, /dev/hda?
Also: I know you didn't touch menu.lst, but are you using root=/dev/sda* on the kernel line?
Good ideas do not need lots of lies told about them in order to gain public acceptance.
Offline
There are no harddrive files in the console, but they're there in the live cd! IT DOESN'T MAKE ANY SENSE! I'm kind of freaking out. Maybe it has to do with the kernel?
Personally, I'd rather be back in Hobbiton.
Offline
If it was the kernel, why would fsck fail?
By console you mean recovery shell?
Good ideas do not need lots of lies told about them in order to gain public acceptance.
Offline
Yeah, recovery shell. It seems to fail because /dev/sda* apparently doesn't exist.
Personally, I'd rather be back in Hobbiton.
Offline
I had that a while ago after inserting an additional hard disk into the system. The fix was not to rely on /dev/{h,s}d{a,b,c,d} naming anywhere. I used /dev/disk/by-label/ instead. UUID=... would also work.
If you think that's worth trying, remember /etc/fstab.
Good ideas do not need lots of lies told about them in order to gain public acceptance.
Offline
So I change the entries in fstab to the uuid? How do I find out the UUID? Could you give me an example line?
Personally, I'd rather be back in Hobbiton.
Offline
ls -l /dev/disk/by-uuid
I remember running across this but don't have a clue to help further , sorry .
Forgot the link ! http://bbs.archlinux.org/viewtopic.php?id=89857
Last edited by wesley_of_course (2010-02-12 02:00:18)
Offline
The wiki is quite good: http://wiki.archlinux.org/index.php/Per … ice_naming.
Here are some lines from my system. I use labels:
$ blkid
/dev/sdb5: LABEL="arch64root" UUID="faa39047-31ea-4e5b-8973-920363b86299" TYPE="ext4"
$ cat /etc/fstab |grep arch64root
LABEL=arch64root / ext4 defaults,noatime 0 1
$ grep -A 4 "main OS" /boot/grub/menu.lst
# my main OS
title Arch Linux x86_64
root (hd0,1)
kernel /vmlinuz26 root=/dev/disk/by-label/arch64root ro
initrd /kernel26.img
Good ideas do not need lots of lies told about them in order to gain public acceptance.
Offline
Well that didn't work.
Personally, I'd rather be back in Hobbiton.
Offline
Yep i had to use UUID after i installed my archbox, seems if you have alot of hdd it gets confused, whats teh exact error you are getting?
Hopefully the UUID thing is fixed on the new install cd, i am going to test it tonight.
Make sure you have them typed correct in fstab
Example
/dev/disk/by-uuid/34988511-cc3e-4d69-ba0f-36336bdce0d1 /boot ext2 defaults 0 1
/dev/disk/by-uuid/746a7c7b-bf99-4710-88e8-3e9953ee267b swap swap defaults 0 0
/dev/disk/by-uuid/0335ee8e-681b-478c-b053-dd0dee2246cb / ext4 defaults 0 1
/dev/disk/by-uuid/31766988-eb5b-4c43-a1c5-d871a3f33076 /home ext4 defaults 0 1
Certified Android Junkie
Arch 64
Offline
I typed it out fine. It's certainly not the partitions themselves either. Maybe it's udev.
Personally, I'd rather be back in Hobbiton.
Offline
It's happening the same to me on a new pc I'm building up.
Live-cd works just fine, fsck run from there on my hd finds no problems.
I had /dev/sdaX in my fstab, and I got the "The superblock could not be read or does not describe a correct ext2 filesystem." error. After swtching to UUID= it doesn't say that anymore, but it still fails, and there is no harddrive files under /dev either.
fsck run from the recovery shell says 'impossible to resolve UUID=XXX'.
At the moment I'm stuck. Yesterday it used to do every other boot, but it's gotten worse. It doesn't seem to be a hardware problem, since Grub reads the boot partition just fine, and so does the Live cd with the whole disk.
Offline
It is a long shot in the dark, but maybe the kernel does not load the correct module? It might be a problem in the recent kernel since the livecds work well.
See your mobo manual and this page. Try to find the correct module name for you and add its name to /etc/rc.conf MODULES array.
Offline
Interesting. I actually have the old IDE drives. (ribbon cable) And other distros I used had /dev/hdxx rather than sdxx. When I came to Arch, I figured it wasn't a big deal. Anyways, I'm gonna try working some more. If anyone finds a solution please help!
Personally, I'd rather be back in Hobbiton.
Offline
Alright, I chrooted into my system via livecd and rebuilt the kernel image using ide rather than pata, and it still failed. Now, a broken, defeated man, I have opened my case and pushed in the cables as a last resort, and it still failed. I officially give up!
Personally, I'd rather be back in Hobbiton.
Offline
When you chroot in from the livecd, what does mount say the type of the partition is and does that match the type in /etc/fstab? Have you tried with acpi disabled? On some of my older systems I can't even detect a hard drive with acpi enabled.
Offline
Apparently, adding ide to the hooks section in /etc/mkinitcpio.conf solved my problem.
Could it be that the kernel doesn't recognize my mobo' southbridge SATA controller?
In case this could be useful to anyone, my mobo is a GA MA-790XT-UD4P with an AMD SB750 chipset.
Offline
Interesting. I actually have the old IDE drives. ..
Hi, don't give up, your grub should be fine. Just try to reinstall, and while at it, also adding 'ide' to the HOOKS section in your /etc/mkinitcpio.conf
I've just struggled today to instal Arch also on a removable USB HDD, and it took me hours to get to that wiki section(http://wiki.archlinux.org/index.php/Mkinitcpio#Available_hooks), to add the 'usb' hook (in my case). Very happy now!
Last edited by no-daemon (2010-02-13 14:50:46)
less is a lot more!
Offline
yep I added the hooks and failed again. I had a long chat session trying to fix this on the arch irc channel; still nothing. I'm thinking it's a bug.
Personally, I'd rather be back in Hobbiton.
Offline