Bug 570606

Summary: blkid (and related) should be a bit more robust
Product: [Fedora] Fedora Reporter: Piergiorgio Sartor <piergiorgio.sartor>
Component: util-linux-ngAssignee: Karel Zak <kzak>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 12CC: kzak
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: util-linux-ng-2.17.1-3.fc13 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 572122 (view as bug list) Environment:
Last Closed: 2010-03-10 06:55:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
First 4k of one of the two mirrors in the RAID none

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.