© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
So, both the kernel code and blkid look surprisingly similar (what a coincidence :-P). I also checked the MBR spec [1], and if we allow 0 offset/type partitions for empty partitions we can't indeed reliably detect an MSDOS partition table by itself, we have to check whether it is a valid FAT header (which has a much more rigid structure), and if we don't find one, assume that we have an MBR.
Now, I see two possibilities:
1) We can copy the FAT detection logic from blkid (which is a tad more rigid than the kernel's)
2) We can assume that blkid is reliable (I don't see much evidence that it isn't), and skip partition probing if we already have a fs:
ENV{ID_
(2) is essentially the same logic as (1) but avoids the overhead of calling part-id if we already know that there's a file system. It's also one step closer to getting rid of part-id in favor of a blkid based partition probing.
I verified that this rule brings back automounting, and the automatic tests are happy again as well.
So I'd favor (2), but if you see a reason to always call part-id, I can also work on (1).
[1] http://