You are not logged in.
Pages: 1
Heya!
Here's what I did yesterday before turning off my computer:
pacman -Syu
(there was a kernel update, if I remeber correctly)
Now I am screwed, Arch Linux won't boot anymore and gives me this:
checking filesystems [busy]
fsck.ext3: no such file or directory while trying to open /dev/discs/disc0/part5
/dev/discs/disc0/part5:
the superblock could not be read or does not describe a correct ext2 filesystems. if the device is valid and it really contains an ext2 filesystem (can not swap or ufs or something else) then the suprerblock is corrupt and you might try running e2fsck with and alternate superblock.
perfect
What I tried:
I searched google for this problem and found that a proper strategy is to boot with a rescue disc and try to fix it with fsck.ext3 (resp. 2)
as suggested I booted with a rescue disc (grml 0.4) and entered:
fsck.ext3 -c /dev/hda5
This is what I got:
/dev/hda5 293903/4823840 files (4.5% non-contageous), 6844769/9636984 blocks
fsck.ext3 -c /dev/hda5 2.82s user 14.08s system 1% cpu 19:26.28 total
I don't now how to interpret this result, but those 4.5% non contageous sound dangerous enough .
Here's some aditional info, that might come in handy:
fstab:
#
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
none /proc proc defaults 0 0
none /dev/pts devpts defaults 0 0
none /dev/shm tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
#sysfs /sys sysfs defaults 0 0
usbfs /proc/bus/usb usbfs defaults 0 0
# windows partitions
/dev/hda1 /mnt/win ntfs ro,gid=100,umask=007 0 0
/dev/hdb1 /mnt/spiele ntfs ro,gid=100,umask=007 0 0
/dev/hdb5 /mnt/storage ntfs ro,gid=100,umask=007 0 0
# removable media
/dev/cdroms/cdrom1 /mnt/cd iso9660 ro,user,noauto,unhide 0 0
/dev/cdroms/cdrom1 /mnt/dvd udf ro,user,noauto,unhide 0 0
/dev/floppy/0 /mnt/fl vfat user,noauto 0 0
/dev/sda1 /mnt/usbstick vfat user,noauto 0 0
#
/dev/discs/disc0/part6 swap swap defaults 0 0
/dev/discs/disc0/part5 / ext3 defaults 0 1
and my grub menu.lst
# Config file for GRUB - The GNU GRand Unified Bootloader
# /boot/grub/menu.lst
# DEVICE NAME CONVERSIONS
#
# Old /dev DevFS Grub
# -----------------------------------------------
# /dev/fd0 /dev/floppy/0 (fd0)
# /dev/hda /dev/discs/disc0/disc (hd0)
# /dev/hdb2 /dev/discs/disc1/part2 (hd1,1)
# /dev/hda3 /dev/discs/disc0/part3 (hd0,2)
#
# FRAMEBUFFER RESOLUTION SETTINGS
# +----------------------------------------+
# | 640x480 800x600 1024x768 1280x1024
# ----+-----------------------------------
# 256 | 0x301 0x303 0x305 0x307
# 32K | 0x310 0x313 0x316 0x319
# 64K | 0x311 0x314 0x317 0x31A
# 16M | 0x312 0x315 0x318 0x31B
# +----------------------------------------+
# general configuration:
timeout 5
default 0
color light-blue/black light-cyan/blue
# boot sections follow
# each is implicitly numbered from 0 in the order of appearance below
#-*
# (0) Arch Linux
title Arch Linux [/boot/vmlinuz26-2.6.13]
root (hd0,4)
kernel /boot/vmlinuz-2.6.13 root=/dev/hda5 ro devfs=nomount
title Arch Linux [/boot/vmlinuz26archck]
root (hd0,4)
kernel /boot/vmlinuz26archck root=/dev/hda5 ro devfs=nomount
title Arch Linux [/boot/vmlinuz26]
root (hd0,4)
kernel /boot/vmlinuz26 root=/dev/discs/disc0/part5 ro devfs=nomount
title Windows XP
root (hd0,0)
chainloader +1
the other two Arch Linux kernels do not work anymore, I just did not yet remove them from grub (first kept them as backup).
Ok, I hope I do not need to reinstall Arch Linux and this problem can somehow be solved.
Thanks for your time and thoughts
If there's any other info you need about my system, just ask.
Ah yes, right now I booted the Windows partition you see in the grub menu.lst, it is on the same HDD, so I guess the HDD is working correctly.
Offline
With the latest kernel, you can no longer use devfs device name formats i.e. /dev/discs/disc0/part5. Change it /dev/hda5 and you should be fine.
This information would have been displayed on your screen following the kernel upgrade, and is also available in the Announcements forum, and on the ArchLinux website News page.
Offline
Hey tomk,
I just copied my menu.lst here.
The second and third Arch entries are old ones, that I simply did not remove and which do not work or do anything useful.
If you do a second look at my post, you will see that the first Arch bootentry correctly containes /dev/hda5
Offline
Sorry - I ignored the first two menu entries because only the third one tries to boot vmlinuz26, the kernel provided by the stock kernel package. Looking at it again, though, I have to ask - how long since your last update? The stock kernel migrated to initrd in mid-December, but I don't see any initrd lines in your grub setup. Have a look on the News page for the initrd piece on 16 Dec, and everything posted since then.
Back to your immediate problem. The first grub menu entry will only work if you still have a kernel called vmlinuz-2.6.13 in your boot directory. This is a non-standard name as far as Arch is concerned, so the kernel upgrade would not have affected it. That's not all though - you also need to get rid of the devfs stuff in /etc/fstab. Try a reboot after that. If it still doesn't work, downgrade udev to to 079 or 078. If pacman doesn't have these versions cached, I have them here.
Let me know how it goes, and sorry again for not paying attention earlier.
Offline
I should probably add that the above should be regarded as a rescue suggestion, so that you can boot your system, and then get it back to a normal, up-to-date configuration.
Offline
also tomk was talking about fstab, dont forget to change fstab, your filesystem check failed simply because there is no such device...
[My Blog] | [My Repo] | [My AUR Packages]
Offline
Gandalf is right.
I had the same problem, fixed it by fixing fstab.
I don't get how this problem pops up now, though. I've been using udev for ages.
Offline
Gandalf is right.
I had the same problem, fixed it by fixing fstab.I don't get how this problem pops up now, though. I've been using udev for ages.
That's because older versions of udev were providing symlinks (perhaps to help with the transition devfs -> udev) so the devfs scheme was still working. The new udev doesn't create the symlinks anymore. There could be other reasons too as udev is currently changing quite rapidely.
Offline
I had exams till yestereve, so I let the problem on ice till today.
Well I changed
/dev/discs/disc0/part6 swap swap defaults 0 0
/dev/discs/disc0/part5 / ext3 defaults 0 1
to
/dev/hda6 swap swap defaults 0 0
/dev/hda5 / ext3 defaults 0 1
same errpr just with /dev/hda5 instead of /dev/discs/disc0/part5
I will try to compile and use another kernel and thentell you the results
michi
Offline
okay,
I /usr/src compiled the 2.6.15 stock kernel and it solved the problem, while procuring all the problems I fixed with the custom-kernel I had.
before I compiled the bzimage, I searched the Makefile for SMP and PREEMPT, because I know that these enabled cause my wirless network adapter to cease functioning. But I couldn't find these two options anymore and thus could not disable them.
Any Ideas where they are hiding with the 15 Kernel?
Also alsa doesn't work again, I hope I can remeber how I fixed that last time
Anyway thank you for your ideas
michael
Offline
I did a pacman -Syu yesterday and now I have this same error. Is something wrong with the latest kernel?
Offline
OK, some more info on that. So, at basically every boot process, I get this error message about my root file system being corrupted (superblock could not be read). Until now, I always got it to work by using fsck.ext3. fsck does something, reboot and all works fine.
However, if I shutdown the system, the problem start all over again. How can I durably repair this file system?
Offline
I am in the same boat with axethelion. After upgrading I get the superblock error. I'm not really concerned about being able to reboot and all that jazz. I just want to be able to access the drive to more my most important data off. Then I'm going to do a clean wipe and fresh install. Any help would be appreciated.
Offline
Just wonder why this suddenly happens...? A thought: beagle crashed on me several times lately, is it possible that it screwed something up by using XATTR? Maybe a bug in the XATTR implementation in the latest kernel or the like?
Offline
I was btw always using stock kernel.
Offline
Pages: 1