mount ext fileystem fails, booting fails, blkid produces no output
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
util-linux (Ubuntu) |
Fix Released
|
High
|
Kees Cook | ||
Lucid |
Fix Released
|
High
|
Kees Cook |
Bug Description
Symptoms: (Ubuntu 9.10 on an ext4 partition /dev/sda1)
1. Booting fails with error message:
Gave up waiting for root device. common problems
-Boot args(cat/
-check rootdelay=(did the system wait long enough?)
-check root=(did the system wait for the right device?)
Missing modules(
Alert!
2. "mount /dev/sda1 /mnt" gives "mount: you must specify the filesystem type"
but "mount -t ext4 /dev/sda1" is successful
3. "blkid /dev/sda1" returns nothing
4. "blkid -p /dev/sda1" gives "ambivalent result (probably more filesystems on the device)"
5. "hexdump -s 0x410 -n 2 /dev/sda1" returns on of the four numbers hexadecimals 137f, 138f, 2468,2478,
6. "sudo BLKID_DEBUG=0xffff blkid -p /dev/sda1 | grep "minix: magic" returns
"ambivalent result (probably more filesystems on the device)"
minix: magic sboff=16, kboff=1
7. After installing util-linux-ng-2.17 from source: "wipefs /dev/sda1" returns:
offset type
-------
0x410 minix [filesystem]
0x438 ext4 [filesystem]
I was able to cure the problem by creating a file on "/dev/sda1" and whereby changing the number of free inodes.
There have been seven of these case in the Ubuntu forums by now:
http://
http://
http://
http://
My diagnosis:
Minix uses the "magic number" 137f, 138f, 2468,2478, at the location 0x410 to mark a Minix file system.
0x410 is also the location any ext filesystem uses to record the number of free inodes.
In decimals those four numbers are 4991,5007,9320,9336
If the number of free inodes happens to be one of those four numbers plus a multiple of 65536, then the ext filesystem will write one of the four Minix magic numbers to the 0x410 location.
So blkid gets confused and does not know whether the files system is Minix or Ext.
In particular, if this happens on the root partition, Ubuntu will no longer boot.
Cure:
Boot from the Ubuntu LiveCD and create a file on the affected partition:
sudo mount /dev/sda1 /mnt
sudo touch /mnt/empty_file
This solution works for an ext4 filesystem. But does not work for ext2. For ext2 one needs to replace the UUID in fstab and grub.cfg by the device name. See https:/
description: | updated |
description: | updated |
description: | updated |
description: | updated |
summary: |
- mount ext fileystem fails, booting fails, blkid produces no putput + mount ext fileystem fails, booting fails, blkid produces no output |
description: | updated |
description: | updated |
description: | updated |
affects: | ubuntu → util-linux (Ubuntu) |
Changed in util-linux (Ubuntu Lucid): | |
milestone: | none → ubuntu-10.04-beta-2 |
importance: | Undecided → High |
Changed in util-linux (Ubuntu): | |
status: | Fix Released → Confirmed |
Here is another case:
http:// ubuntuforums. org/showthread. php?t=1414662
Minix uses four different magic numbers:
# Minix filesystems - Juan Cespedes
0x410 leshort 0x137f Minix filesystem
0x410 leshort 0x138f Minix filesystem, 30 char names
0x410 leshort 0x2468 Minix filesystem, version 2
0x410 leshort 0x2478 Minix filesystem, version 2, 30 char nam
es
Any of these four magic numbers will trigger the bug. So there is 1: 16384 chance to be affected be this bug after any reboot. This really needs to get some attention