On Tue, Oct 28, 2014 at 07:46:04PM -0400, Phillip Susi wrote:
[...]
> I see, very strange.
With Davids latest followup I would say things are just getting more and
more strange.
findmnt reports ext* in the filesystem column, which comes from
case COL_FSTYPE:
str = xstrdup(mnt_fs_get_fstype(fs));
break;
... and mnt_fs_get_fstype is the exact same call used by fsck.
> Even though it dropped the use of fsck -a,
I don't think systemd ever did fsck -a .... and if I'm not mistaken
neither does sysvinit (anymore?) (but please check to make sure if you're
really interested in the details).
> it does still use fsck, even though it does know the proper fs fsck
> tool's name and checks to make sure it exists. In that case, I'd bet
> that blkid -p run on that device will report that it is fat because it
> does in fact, still contain a fat boot sector.
You're right, I missed the type checking stuff in my quick glance...
although the type reported by udev is never used for anything else
then checking if the filesystem specific fsck is available (with
a warning if not).
David, could you please give us the output from:
# udevadm info -n /dev/whatever1 -q property | grep ID_FS_TYPE
...and...
# blkid -p /dev/whatever1
(Although I asked for findmnt since blkid doesn't seem to use
libmount (as fsck).... but I guess the more information we have
the better.)
> In that case, this bug can be closed and David just needs to remove
> the bogus fat boot sector with wipefs.
(Or surgical precision, to not lose the existing filesystem?!)
Regards,
Andreas Henriksson
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
