fsck.ext3: No such file or directory while trying to open...

Message

gfaccin · Post by **gfaccin** » Tue Jan 17, 2006 9:21 pm

Hi there

Today I turned on my computer, everything was working fine. I logged on, did an emerge sync && emerge world, worked for a few hours and then nicely restarted the machine (no power failures or hardware rebooting):

Code: Select all

#reboot

Upon reboot, I'm getting this:

Code: Select all

CHECKING ROOT FILESYSTEM...

fsck.ext3: No such file or directory while trying to open /dev/sda7

/dev/sda7:

The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock:

e2fsck -b 8193 <device>

* filesystem could not be fixed.

I'm given the choice to log in as root. Upon doing it, I'm thrown in the /dev/sda7 partition in read-only mode. However, there's no sda directory in /dev anymore; the closest thing to it I could find was:

Code: Select all

/dev/discs/disc0/part7

My fstab has not changed from what it used to be before this error; the sda7 line is:

Code: Select all

/dev/sda7       /     ext3      noauto,noatime    0  2

I tried this:

Code: Select all

e2fsck -b 32768 /dev/discs/disc0/part7

Which, after about 3.000 (I'm not exagerating the number) confirmations for bug corrections, leads me to a reboot and back to the same error. I'm still being thrown at what used to be the /dev/sda7 partition, and can access it's files in read-only mode.

Can anyone give me directions on how to proceed? What's going on?

Thanks!!

desultory · Post by **desultory** » Wed Jan 18, 2006 1:44 am

Surely someone can, whether or not I happen to be that one....

If you can not be bothered to beat them, join them:
Modify your /etc/fstab and your boot configuration to use the /dev/discs/ nomeclature.

If you do feel like beating them, I have a question.

Could your update have somehow stomped your udev configuration?

gfaccin · Post by **gfaccin** » Wed Jan 18, 2006 2:48 am

Hello desultory, thank you very much for the reply!

First of all, let me update what's going on since my last post:

--> I've downloaded and burned a knoppix media, and used it to boot the PC

--> Knoppix automatically locates /dev/sda7 . If I mount it, it works out of the box. Then I've run badblocks on the partition (with it unmounted, of course), and found zero badblocks. Also ran:

Code: Select all

e2fsck -f /dev/sda7

and no error message came by.

Thus I believe that there's no error with the disc. This must really be something related to the emerge world I've done today...

I'm following your advice, and thus going to look after the documentation for the udev configuration. Let's see if I anything interesting drops by. Any further ideas are highly appreciated!

Thanks!

desultory · Post by **desultory** » Fri Jan 20, 2006 9:22 pm

Under Gentoo what is output by:

Code: Select all

ls -l /dev/discs/disc0/

I have symlinks back to [hs]d.?.? from entries under /dev/discs and /dev/disk for example.

ianw · Post by **ianw** » Fri Jan 20, 2006 11:01 pm

Same things happening in this thread, could be a sys-apps/baselayout and sys-process/psmisc problem by the looks of things...

gfaccin · Post by **gfaccin** » Sat Jan 21, 2006 8:33 pm

Hello there, thanks for the replies!

I've "fixed" the problem by changing my fstab:

Code: Select all


###########################################################################################
#This is the new setup:
/sys                    /sys            sysfs           noauto                          0 0
/dev/discs/disc0/part7  /               ext3            noauto,noatime                  0 2
/dev/discs/disc0/part1  /mnt/c          vfat            users,uid=1000,gid=100          0 0
/dev/discs/disc0/part5  /mnt/d          vfat            users,uid=1000,gid=100          0 0
/dev/cdroms/cdrom0      /mnt/cdrom      iso9660         users,uid=1000,noauto,ro        0 0
none                    /proc           proc            defaults                        0 0
###########################################################################################
#This is what I had before the crash:
#/dev/sda7              /               ext3            noauto,noatime                  0 2
#/dev/sda6               none            swap            sw                             0 0
#/dev/sda1              /mnt/c          vfat            users,uid=1000,gid=100  0 0
#/dev/sda5              /mnt/d          vfat            users,uid=1000,exec,gid=100     0 0
#/dev/cdroms/cdrom0      /mnt/cdrom      iso9660         users,uid=1000,noauto,ro        0 0
#none                    /proc           proc            defaults                        0 0

Now things are working again. It's interesting to notice that, after the system boots up, I can find "/dev/sda*". But during boot time, it's not there.

The data desultory asked:

Code: Select all

gfaccin@conan ~ $ ls -l /dev/discs/disc0/
total 0
brw-------  1 root root 8, 0 Jan  1  1970 disc
brw-------  1 root root 8, 1 Jan  1  1970 part1
brw-------  1 root root 8, 2 Jan  1  1970 part2
brw-------  1 root root 8, 5 Jan  1  1970 part5
brw-------  1 root root 8, 6 Jan  1  1970 part6
brw-------  1 root root 8, 7 Jan  1  1970 part7

It's now clear to me that this happened due to the emerge world I did (I remember having baselayout in the list!). The thread ianw posted explains it better. Thanks very much for the help people!

moob7 · Post by **moob7** » Mon Jan 23, 2006 4:03 am

Code: Select all

###########################################################################################
#This is the new setup:
/sys                    /sys            sysfs           noauto                          0 0
/dev/discs/disc0/part7  /               ext3            noauto,noatime                  0 2
/dev/discs/disc0/part1  /mnt/c          vfat            users,uid=1000,gid=100          0 0
/dev/discs/disc0/part5  /mnt/d          vfat            users,uid=1000,gid=100          0 0
/dev/cdroms/cdrom0      /mnt/cdrom      iso9660         users,uid=1000,noauto,ro        0 0
none                    /proc           proc            defaults                        0 0

You know, when I used to use arch linux, it had the same problem: it defaulted to using that "disc" naming scheme. Yuck. Eventually I found out that a parameter added to the kenrel line in the grub.conf fixed matters so that I woudl get "/dev/hda" type names. The line I had was

Code: Select all

kernel /vmlinuz26 devfs=nomount root=/dev/hdd3 vga=0x317

The key parameter was the "devfs=nomount" line.

Not sure it it will work in gentoo as it did in arch. I have not tried this yet.

H.Humpel · Post by **H.Humpel** » Sun Jan 29, 2006 11:25 pm

moob7 wrote: The key parameter was the "devfs=nomount" line.

GREAT! Worked/works for me here and saved my day/week

. Thanks a lot!

genterminl · Post by **genterminl** » Wed Feb 01, 2006 11:05 pm

This fix (devfs=nomount) does not work for me. Does it depend on kernel or configuration? (I'm pretty sure I'm not using devfs anyway - I'm on udev 79 something) I do have the /dev/disks/disc0 entried - but they are all symlinks to the nonexistant /dev/hda nodes.

I'd also really love to see an explanation of exactly what changed in baselayout to cause this.

Paapaa · Post by **Paapaa** » Wed Feb 01, 2006 11:55 pm

genterminl wrote:This fix (devfs=nomount) does not work for me.

Make sure you have Hotplug support enabled in the kernel. I got the "fsck.ext3: No such..." error when I upgraded to gentoo-sources-2.6.15-r1. The reason was that I had Hotplug disabled. If you use udev, Hotplug support must be enabled.

genterminl · Post by **genterminl** » Thu Feb 02, 2006 3:59 am

Hotplug and coldplug are both enabled. I haven't changed my kernel in quite a while. The issue seems to be a recent upgrade of baselayout.

Also - note when in the boot process this happens. It seems to be after all the initial, kernel based stuff, right when it checks the partitions before remounting from read-only to read-write. What is strange in my case (I haven't noticed specific mention of it in other posts) is that once I get the error and give the root password, 'mount' shows all my partitions mounted 'rw' but trying to write to any of them gives an error that the partition is read-only.

genterminl · Post by **genterminl** » Fri Feb 03, 2006 12:53 am

Well, I don't know whether scream or laugh. I apparently did something not so obviously stupid (at least not to me). In my kernel config, I set my CONFIG_LOCALVERSION to '02'. I should have used '-02' or something without a leading digit. Should I have known this would be dangerous? Why? I'll try to explain as brieflly as I can, but the path is convoluted.

In tracking down why I don't get /dev/hda* on boot, I downgraded to baselayout 1.11.14. It looked like going to 1.11.13-r1 (actually what I upgraded to 1.11.14-r3 from) wouldn't have worked because udev 079 and 079-r1 both require baselayout >=1.11.14.

Based on some other hints, when I got into the minimal shell after the error, I tried running udevstart, which created all the missing nodes. I could then mount all my partitions fine. (I did need to 'mount -o remount,rw /' first.) So I tried to track down why that wasn't happening. I ended up tracing through /sbin/rc, through /etc/functions.sh to /lib/rcscripts/addons/udevstart.sh. In the function that does the main populating of /dev, it uses udevstart for kernels before 2.6.15, and uevents otherwise. The test for kernel version number converts the version to a single integer, and my version of 2.6.1002 ended up higher than 2.6.15. Of course uevents doesn't work for a 2.10 kernel. My solution was to manually change the script until I can recompile my kernel with a better localversion (and upgrade at the same time).

Which fine manual did I missread or simply miss?

sgtrock · Post by **sgtrock** » Tue Feb 14, 2006 6:18 pm

Please look at bug 119894. I think I got bit hard by the same issue. Older kernel, never turned on CONFIG_HOTPLUG, converted from devfs to udev, etc.

<sigh> Not looking forward to cleaning this one up.

genterminl · Post by **genterminl** » Tue Feb 14, 2006 9:25 pm

That bug does not seem to apply to me, although it's not really clear. I DID have hotplug configured in the kernel, and all the devfs stuff was turned off. Simply modifying the startup script to force udevstart instead of uevents worked fine. I then recompiled the kernel (2.6.10 with same settings) to change my CONFIG_LOCALVERSION to not confuse the version comparisons, switched back to the original udev startup script, and everything is fine. (udev 079-r1 and baselayout 1.11.14-r3) I suspect I did change something else, but I have no idea what, and I've now also upgraded to 2.6.15 kernel, things seem fine, and I'm off to fix other problems that have been hanging around for a while.

hoschi · Post by **hoschi** » Tue Apr 18, 2006 6:00 pm

Same ugly problem here:
Kernel 2.6.15.5
GLIBC 2.4-r1
Stable UDEV/ Baselayout 1.12

But my "second" Devicenames are not very pretty:

Code: Select all

ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 Apr 18  2006 1dc878ed-10dc-4c6f-b03a-7553cacf76fc -> ../../sda6lrwxrwxrwx 1 root root 10 Apr 18  2006 59265537-54b4-40a7-b3cd-8302ffa9ab87 -> ../../sda7lrwxrwxrwx 1 root root 10 Apr 18  2006 5a5217a1-7955-48da-9619-2cca8607a624 -> ../../sda1lrwxrwxrwx 1 root root 10 Apr 18  2006 9371502c-c678-4cc4-999d-e3c8a45b56ef -> ../../sda8lrwxrwxrwx 1 root root 10 Apr 18  2006 bc1f17f3-291a-4d16-967d-06c105880146 -> ../../sda2lrwxrwxrwx 1 root root 10 Apr 18  2006 da20f4e4-b72f-4d7d-b7b0-6aaf4700

I will no switch via "/etc/conf.d/rc" to a UDEV only system with a tarball.

<edit> Here is a other reason and solution:
The new baselayout (series 1.12.x) doen't check udev status in the boot process, if you are using "Parallel Startup" the init-process is simply to fast for udev. It cant creat the devices fast enough.
Switch of "Parallel Startup" or try the thing with the tarball.

UberLord · Post by **UberLord** » Tue Apr 25, 2006 7:34 am

hoschi wrote:<edit> Here is a other reason and solution:
The new baselayout (series 1.12.x) doen't check udev status in the boot process, if you are using "Parallel Startup" the init-process is simply to fast for udev. It cant creat the devices fast enough.
Switch of "Parallel Startup" or try the thing with the tarball.

No it's not. Parallel startup only happens after udev has finished AND we've started some critical services sequentially. Then parallel starts.

Are any of you guys with this problem using LDAP or NIS or something else to load usernames?

hoschi · Post by **hoschi** » Thu May 04, 2006 6:19 pm

Hmm, scary. You've seem to be right, but since my last post I've got not problems.
Since the last baselayout-update (this week) I've got this error again

trupoet · Post by **trupoet** » Fri Feb 25, 2011 6:30 am

Thanks for this post! By disabling devfs in the kernel, I was able to get it working again =)

dE_logics · Post by **dE_logics** » Fri Feb 25, 2011 1:36 pm

moob7 wrote:
Code: Select all
###########################################################################################
#This is the new setup:
/sys                    /sys            sysfs           noauto                          0 0
/dev/discs/disc0/part7  /               ext3            noauto,noatime                  0 2
/dev/discs/disc0/part1  /mnt/c          vfat            users,uid=1000,gid=100          0 0
/dev/discs/disc0/part5  /mnt/d          vfat            users,uid=1000,gid=100          0 0
/dev/cdroms/cdrom0      /mnt/cdrom      iso9660         users,uid=1000,noauto,ro        0 0
none                    /proc           proc            defaults                        0 0
You know, when I used to use arch linux, it had the same problem: it defaulted to using that "disc" naming scheme. Yuck. Eventually I found out that a parameter added to the kenrel line in the grub.conf fixed matters so that I woudl get "/dev/hda" type names. The line I had was
Code: Select all
kernel /vmlinuz26 devfs=nomount root=/dev/hdd3 vga=0x317
The key parameter was the "devfs=nomount" line.

Not sure it it will work in gentoo as it did in arch. I have not tried this yet.

Sounds like an initrd problem. Do you use it?

dE_logics · Post by **dE_logics** » Fri Feb 25, 2011 1:37 pm

SHIT!! This was an OLD post!!