Bug 570606 - blkid (and related) should be a bit more robust
Summary: blkid (and related) should be a bit more robust
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux-ng
Version: 12
Hardware: i686
OS: Linux
low
high
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-04 20:39 UTC by Piergiorgio Sartor
Modified: 2010-03-11 13:26 UTC (History)
1 user (show)

Fixed In Version: util-linux-ng-2.17.1-3.fc13
Clone Of:
: 572122 (view as bug list)
Environment:
Last Closed: 2010-03-10 06:55:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
First 4k of one of the two mirrors in the RAID (4.00 KB, application/octet-stream)
2010-03-04 22:06 UTC, Piergiorgio Sartor
no flags Details

Description Piergiorgio Sartor 2010-03-04 20:39:11 UTC
Description of problem:
Few days ago a PC, having a RAID-10 f2, could not mount anymore the root filesystem (/dev/md2) at boot.

This seemed due to problems with MD, but after submitting some information to the linux-raid mailing list, it turned out, thanks to Neil Brown, that the mechanism to identify the filesystem in a partition is, let's say, weak.

For details, please see:

http://marc.info/?l=linux-raid&m=126750584921930&w=2

Version-Release number of selected component (if applicable):
util-linux-ng-2.16.2-6.fc12.x86_64
file-5.03-12.fc12.x86_64

How reproducible:
Very difficult, but succeeding could be fatal

Steps to Reproduce:
1.
Allocate enough i-nodes on an ext3 filesystem
2.
Check the partition with "blkid" or try to mount it without specifying the filesystem type
  
Actual results:
No result from "blkid", error (must specify filesystem) from "mount".
"file" seems to be more friendly, but still wrong.

Expected results:
Well, the correct info should be returned or the mount should succeed.

Additional info:
Well, this seems to be quite a floating mine, since it could lead to a sudden death of a PC with no apparent reason.

bye,

pg

Comment 1 Piergiorgio Sartor 2010-03-04 22:06:38 UTC
Created attachment 397938 [details]
First 4k of one of the two mirrors in the RAID

Maybe useful.

These are the first 4k of the partition, they should contain the ext3 superblock.

Something like: "blkid disk1.raw" does return nothing, while "file disk1.raw" returns "disk1.raw: Minix filesystem".

One more thing, I tried to reproduce the issue by creating enough files into a partition so that the 2 lower bytes of the free inodes count were 0x137f.

On the dumped 4k I tried "file", which returned the same as above, and "blkid", which identified correctly the ext3 filesystem.

So, I'm not anymore sure the explanation is fully correct, even if something is still fishy, at least for "file".

Hope this helps,

bye,

pg

Comment 2 Karel Zak 2010-03-04 22:30:29 UTC
This sounds like a bug

  * Wed Feb 17 2010 Karel Zak <kzak> 2.16.2-6
  - fix #557831 - blkid detects ext4 fs as minix fs

unfortunately, with your disk is the problem still reproducible :-(

The libblkid does not check for the magic string at 0x410 only. It uses more checks now. Unfortunately, it's still not enough. I'll try to fix it ASAP.

Tanks for the report!

Comment 3 Piergiorgio Sartor 2010-03-05 08:03:00 UTC
Hi,

well, good that is something somehow known.

A couple of things.

Would it be better to check first for ext2/3/4 and only if this fails check the other (Minix) filesystems?

Second thing, what about "file"? This does not seem to use (ldd file does not say anything useful) "libblkid", but "libmagic".
Maybe this bug should be re-assigned, once fixed in "blkid", to "file".

What do you think?

Thanks,

bye,

pg

Comment 4 Karel Zak 2010-03-05 11:06:59 UTC
(In reply to comment #3)
> Would it be better to check first for ext2/3/4 and only if this fails check the
> other (Minix) filesystems?

 No, it's necessary to check for all possible filesystems to avoid situations
 where on the device are more valid superblocks. 

 The problem must be fixed by more robust minix detection.

> Second thing, what about "file"? This does not seem to use (ldd file does not
> say anything useful) "libblkid", but "libmagic".
> Maybe this bug should be re-assigned, once fixed in "blkid", to "file".

 Please, file a new bug report against the "file" package.

Comment 5 Fedora Update System 2010-03-08 13:10:05 UTC
util-linux-ng-2.16.2-7.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/util-linux-ng-2.16.2-7.fc12

Comment 6 Fedora Update System 2010-03-08 14:40:24 UTC
util-linux-ng-2.17.1-3.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/util-linux-ng-2.17.1-3.fc13

Comment 7 Fedora Update System 2010-03-10 06:50:28 UTC
util-linux-ng-2.17.1-3.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update util-linux-ng'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/util-linux-ng-2.17.1-3.fc13

Comment 8 Fedora Update System 2010-03-10 06:55:27 UTC
util-linux-ng-2.16.2-7.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Fedora Update System 2010-03-11 13:26:35 UTC
util-linux-ng-2.17.1-3.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.