Filesystem check failed, root partition not found

walderich · 2011-04-28 15:09:17

Hi all,

Since yesterday I receive the following error message when booting into Arch:

:: Mounting root filesystem read-only  [ OK ]
:: Checking filesystems                [BUSY]
/dev/sda4: no such file or directory

*************** FILESYSTEM CHECK FAILED *******************
* Please repair manually and reboot ...

The device /dev/sda4 is my root partition, which is - after entering the root
password - mounted as /dev/root. Checking the partition with 'reiserfsck
/dev/sda4' does not give any error or warning messages. I can also
successfully remount and access it with 'mount -n -o remount,rw /'.

'ls -l /dev/sda*' gives me the following:

brw-rw---- 1 root disk 8, 0 Apr 28 16:32 /dev/sda
brw-rw---- 1 root disk 8, 1 Apr 28 16:32 /dev/sda1
brw-rw---- 1 root disk 8, 2 Apr 28 16:32 /dev/sda2
brw-rw---- 1 root disk 8, 3 Apr 28 16:32 /dev/sda3
brw-rw---- 1 root disk 8, 4 Apr 28 16:32 /dev/sda4

So the device itself seems to be there. Rebooting doesn't help, neither does
using older, working kernel versions.

I also checked other topics on similar subjects, but I couldn't find any solution.

Leonid.I · 2011-04-28 20:13:01

Check the filesystem with the verbose output:

fsck -V -C /dev/sda4

and see the error code

echo $?

These are the three possibilities, triggering the recovery session (see man fsck and /etc/rc.sysinit):

4 - File system errors left uncorrected
8 - Operational error
16 - Usage or syntax error

walderich · 2011-04-29 08:44:01

Hi Leonid,

After finishing the check it says:

No corruptions found

The last error code also is '0'.

I am wondering about the line after ':: Checking filesystems' which is:

Failed to open the device '/dev/sda4: No such file or directory

How is it possible that the device is mounted read-only but doesn't exist?
Can it be mapped to the wrong position?

Can I start the Arch filesystem check manually, maybe this is a
temporary problem, until the device is created correctly?

Any other ideas?

Leonid.I · 2011-04-29 18:33:24

Sorry, missed that

Can you change in your fstab from /dev/sda* to the UUID=* notation (on startup fsck is called with -A and parses the entire fstab)? For examble

UUID=0ee865a6-6f3c-4a9c-a0b9-34f677d6db71 /tmp ext4 rw,nosuid,nodev,noexec,auto,nouser,async 0 0

UUIDs should be invariant, but perhaps your root is not /dev/sda4 yet. You can see the correspondence table by running /sbin/blkid.

Or, you could hack r.csysinit to disable the fsck line, but this isn't a good idea...

walderich · 2011-04-30 07:19:59

Hmm, it doesn't work even with the UUID. But the error looks similar:

Failed to open the device UUID=672f076e-131c-4220-81ba-b30639ef9285: No such file or directory

But when I call rc.sysinit manually directly after entering the root password,
everything works fine. It does work with sda as well as uuid notation.

I manually added some code before the output of the '*** FILESYSTEM CHECK FAILED ***' message:

ls -l /dev/sda*
sleep 1
ls -l /dev/sda*

The result was:

ls: cannot access /dev/sda*: No such file or directory
brw-rw---- 1 root disk 8, 0 Apr 30 09:12 /dev/sda
brw-rw---- 1 root disk 8, 1 Apr 30 09:12 /dev/sda1
brw-rw---- 1 root disk 8, 2 Apr 30 09:12 /dev/sda2
brw-rw---- 1 root disk 8, 3 Apr 30 09:12 /dev/sda3
brw-rw---- 1 root disk 8, 4 Apr 30 09:12 /dev/sda4

So it seems that the devices are really not yet created. Is it a udev problem?
I am not aware of changing anything udev specific, maybe an updated version?

gkal · 2011-04-30 07:53:18

Hi Walderich,

I'm experiencing a very similar problem which started after my last system upgrade (about an hour ago). (my last system upgrade cause KDE to totally freeze. When I switched to another tty I entered my root pass and it stacked there with the cursor blinking - very strange)

After booting a couple of seconds I get the message:

.... 
Waiting 10 seconds for device /dev/sda1
Root Device '/dev/sda1' doesn't exist. Attempting to create it.
ERROR: Unable to determine major/minor number of root device '/dev/sda1'
You are being dropped to a recovery shell
...
[ramfs /]#
...

My devices /dev/sda* are not yet created, too. Could you please tell me how you mounted your root partition for checking?

Thanks

walderich · 2011-04-30 08:45:07

In my case the root partition is already mounted read-only as /dev/root. I
just remounted writable it with

mount -n -o remount,rw /

I don't know if this works for you, because it looks like you are still
working on your initial ramfs.

When I am left in the root shell and Arch was not booted correctly, I just let
it finish boot it by calling '/etc/rc.sysinit' manually as root.

I hope this helps, and we get a solution soon :-)

jean-paul · 2011-04-30 13:29:47

Hi,

I run into the same error on my CRUX-Box.
Kernel: 2.6.38.4, no initrd.

It seams to be udev related. I updated yesterday to udev-168 and got this error.
In /var/log/messages I found lines like this: "can not read '/lib/udev/rules.d/xx-yyyy.rules"

Maybe it helps to find a solution.

EDIT:
A downgrade to udev-167 recognize my root-partition (sda6).
System booted fine, also pekwm, but keyboard and mouse are refrigerated.

Jean-Paul

Last edited by jean-paul (2011-04-30 13:49:54)

walderich · 2011-05-01 16:09:18

Since I've never looked very closely over the Arch boot process, I'm not sure
about this, but as I can see, the system log is not yet started. Only minilogd
is working as the root partition is not yet mounted. So how can I check for
error messages of udev?

I'm also not sure about udev itself. In the file '/etc/rc.sysinit' the tool
'udevadm' is called to add the devices. Later on 'udevadm' is asked to settle.
As I understand the man pages, 'udevadm' waits until all the udev events are
processed. How is it possible that no devices for the partitions are created?
Am I missing something? If it needs some seconds to create the devices,
shouldn't 'udevadm' wait until these are created with the 'settle' command?

I also found some threads that covered the slow udev startup process, but in
my case, it seems that udev isn't given enough time at all.

As version 168 is not yet in the repository, I am still using udev 167-1.

fraantik · 2011-05-01 18:59:48

Hey, I had also similar problem. That isn't normal. I upgraded. FSCK for ext4 couldn't be completed at boot, because it claimed that partition is mounted (I have only partitions 'root' and 'swap'). So I had to fsck it from live USB. Now I can boot but really dont know why it happened. Maybe I 'helped' my disk that I confirmed that I want fsck on mounted disk before I checked it. So some files were moved to /lost+found, so now I can boot but in X I cant use keyboard, mouse nor touchpad (to get out SysRq help).

fraantik · 2011-05-01 19:00:23

Hey, I had also similar problem. That isn't normal. I upgraded. FSCK for ext4 couldn't be completed at boot, because it claimed that partition is mounted (I have only partitions 'root' and 'swap'). So I had to fsck it from live USB. Now I can boot but really dont know why it happened. Maybe I 'helped' my disk that I confirmed that I want fsck on mounted disk before I checked it. So some files were moved to /lost+found, so now I can boot but in X I cant use keyboard, mouse nor touchpad (to get out SysRq help).

walderich · 2011-05-02 20:36:43

Since I have no other idea. I used Leonid's suggestion and hacked 'rc.sysinit'
(Thanks Leonid for the useful hint, where to find this!), by adding the
following code after the udev settle command:

while [ ! -e /dev/sda ]; do
  echo "Waiting for another second!"
  sleep 1
done

Is there anyone who knows what goes wrong here? Should I start a new thread,
that is more udev related?

Leonid.I · 2011-05-03 00:49:37

walderich wrote:

Is there anyone who knows what goes wrong here? Should I start a new thread,
that is more udev related?

... and how long does it take to settle? You could add --timeout=N after settle (see man udevadm). One should be able to run udevadm --debug, but I am not sure whether the right place is before or after the settle line.

walderich · 2011-05-03 07:27:40

I don't know exactly how long it takes, but when watching the messages, it
seems to be fast (less than a second). There is no '--debug' switch for the
settle command, but what I tried was the following:

/sbin/udevadm trigger --action=add --type=devices --verbose

The '--verbose' switch shows all triggered devices. There is indeed an entry
for 'sda4', but it looks like this:

/sys/devices/pci0000:00/0000:00:1f.2/host2/target2:0:0/2:0:0:0/block/sda/sda4

There is no simple '/dev/sda*' in the list. So I think the settle command
finishes successfully, but the actual device is created later on. Directly
after the settle command the sys entry does exist, but the device does not.

So, is there something wrong with the device list? How are the listed devices
determined?

walderich · 2011-05-06 04:30:16

Eventually, a new udev version arrived when upgrading my system. It silently solved my problem.

Arch Linux

#1 2011-04-28 15:09:17

Filesystem check failed, root partition not found

#2 2011-04-28 20:13:01

Re: Filesystem check failed, root partition not found

#3 2011-04-29 08:44:01

Re: Filesystem check failed, root partition not found

#4 2011-04-29 18:33:24

Re: Filesystem check failed, root partition not found

#5 2011-04-30 07:19:59

Re: Filesystem check failed, root partition not found

#6 2011-04-30 07:53:18

Re: Filesystem check failed, root partition not found

#7 2011-04-30 08:45:07

Re: Filesystem check failed, root partition not found

#8 2011-04-30 13:29:47

Re: Filesystem check failed, root partition not found

#9 2011-05-01 16:09:18

Re: Filesystem check failed, root partition not found

#10 2011-05-01 18:59:48

Re: Filesystem check failed, root partition not found

#11 2011-05-01 19:00:23

Re: Filesystem check failed, root partition not found

#12 2011-05-02 20:36:43

Re: Filesystem check failed, root partition not found

#13 2011-05-03 00:49:37

Re: Filesystem check failed, root partition not found

#14 2011-05-03 07:27:40

Re: Filesystem check failed, root partition not found

#15 2011-05-06 04:30:16

Re: Filesystem check failed, root partition not found

Board footer