Bug 513104 - blkid returns no fstype for ext2 device when ext2 module not loaded
Summary: blkid returns no fstype for ext2 device when ext2 module not loaded
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux-ng
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 517458 517885 (view as bug list)
Depends On:
Blocks: F12Beta, F12BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2009-07-21 23:46 UTC by Allen Kistler
Modified: 2009-08-20 21:22 UTC (History)
8 users (show)

Fixed In Version: util-linux-ng-2.16-5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-08-20 21:22:20 UTC


Attachments (Terms of Use)
anaconda.log (/boot partition and / lv) (48.42 KB, text/plain)
2009-07-21 23:52 UTC, Allen Kistler
no flags Details
storage.log (/boot partition and / lv) (62.81 KB, text/plain)
2009-07-21 23:53 UTC, Allen Kistler
no flags Details
anaconda.log (/boot partition and / lv) (15.16 KB, text/plain)
2009-07-21 23:55 UTC, Allen Kistler
no flags Details
storage.log (/boot partition and / lv) (19.81 KB, text/plain)
2009-07-21 23:56 UTC, Allen Kistler
no flags Details
syslog (/boot partition and / lv) (23.60 KB, text/plain)
2009-07-21 23:56 UTC, Allen Kistler
no flags Details
anaconda.log (/boot on raid-1 and / lv on raid-1) (48.42 KB, text/plain)
2009-07-22 00:07 UTC, Allen Kistler
no flags Details
storage.log (/boot on raid-1 and / lv on raid-1) (62.81 KB, text/plain)
2009-07-22 00:08 UTC, Allen Kistler
no flags Details
syslog (/boot on raid-1 and / lv on raid-1) (28.56 KB, text/plain)
2009-07-22 00:09 UTC, Allen Kistler
no flags Details
Screen Cap of F12 Custom Layout (32.67 KB, image/png)
2009-08-01 21:47 UTC, Allen Kistler
no flags Details
Screen Cap of F11 Custom Layout (for comparison) (32.24 KB, image/png)
2009-08-01 21:48 UTC, Allen Kistler
no flags Details
12.7: anaconda.log (/boot partition and / lv) (25.87 KB, text/plain)
2009-08-01 21:50 UTC, Allen Kistler
no flags Details
12.7: storage.log (/boot partition and / lv) (37.35 KB, text/plain)
2009-08-01 21:51 UTC, Allen Kistler
no flags Details
12.7: syslog (/boot partition and / lv) (23.63 KB, text/plain)
2009-08-01 21:52 UTC, Allen Kistler
no flags Details
12.13: anaconda.log (/boot partition and / lv) (15.89 KB, text/plain)
2009-08-11 18:29 UTC, Allen Kistler
no flags Details
12.13: storage.log (/boot partition and / lv) (22.12 KB, text/plain)
2009-08-11 18:30 UTC, Allen Kistler
no flags Details
12.13: syslog (/boot partition and / lv) (23.16 KB, text/plain)
2009-08-11 18:30 UTC, Allen Kistler
no flags Details
12.13: program.log (/boot partition and / lv) (10.91 KB, text/plain)
2009-08-12 21:59 UTC, Allen Kistler
no flags Details
12.13: Screen Cap of F12 Custom Layout (51.51 KB, image/png)
2009-08-12 22:17 UTC, Allen Kistler
no flags Details
12.13: udevadm test output (sda1-add in Comment #22) (8.71 KB, text/plain)
2009-08-12 22:41 UTC, Allen Kistler
no flags Details
12.16: Screen Cap of F12 Custom Layout (ext2 module pre-loaded) (50.64 KB, image/png)
2009-08-20 03:46 UTC, Allen Kistler
no flags Details
12.16: Screen Cap of F12 Custom Layout (ext2 module NOT pre-loaded) (50.51 KB, image/png)
2009-08-20 03:47 UTC, Allen Kistler
no flags Details

Description Allen Kistler 2009-07-21 23:46:03 UTC
Description of problem:
Attempting to install to a machine with existing formatted devices, anaconda does not appear to detect or retain the existing formatting.  It does detect the individual partitions, RAID, and LVM (including LVM on RAID).

Version-Release number of selected component (if applicable):
anaconda-12.3

How reproducible:
Always

Steps to Reproduce:
1. Boot using rawhide boot.iso
2. Have existing formatted partitions, RAID, or LVs
  
Actual results:
Partitions, RAID, and LVs are detected, but their formatting is not.

Expected results:
Existing formats should be detected.

Additional info:
Interestingly SELinux (according to syslog) appears to detect the correct formatting.

I'll attach log files for two different setups.

Comment 1 Allen Kistler 2009-07-21 23:52:56 UTC
Created attachment 354614 [details]
anaconda.log (/boot partition and / lv)

First existing setup:

/dev/sda1 /boot (ext2)
/dev/sda2 swap
/dev/sda3 LVM

/dev/vg0/f9 / for F9 (ext2)
plus empty space in vg0

Comment 2 Allen Kistler 2009-07-21 23:53:58 UTC
Created attachment 354615 [details]
storage.log (/boot partition and / lv)

Comment 3 Allen Kistler 2009-07-21 23:55:36 UTC
Created attachment 354616 [details]
anaconda.log (/boot partition and / lv)

Comment 4 Allen Kistler 2009-07-21 23:56:16 UTC
Created attachment 354617 [details]
storage.log (/boot partition and / lv)

Comment 5 Allen Kistler 2009-07-21 23:56:51 UTC
Created attachment 354618 [details]
syslog (/boot partition and / lv)

Comment 6 Allen Kistler 2009-07-22 00:07:55 UTC
Created attachment 354619 [details]
anaconda.log (/boot on raid-1 and / lv on raid-1)

Second existing setup

/dev/sda1 & /dev/sdb1 RAID-1 md0 /boot (ext2)
/dev/sda2 & /dev/sdb2 swap
/dev/sda3 & /dev/sdb3 RAID-1 md1 LVM

/dev/vg0/f9 / for F9 (ext2)
plus empty space in vg0

Comment 7 Allen Kistler 2009-07-22 00:08:41 UTC
Created attachment 354621 [details]
storage.log (/boot on raid-1 and / lv on raid-1)

Comment 8 Allen Kistler 2009-07-22 00:09:13 UTC
Created attachment 354622 [details]
syslog (/boot on raid-1 and / lv on raid-1)

Comment 9 Allen Kistler 2009-07-22 00:11:33 UTC
(In reply to comment #1)
> 
> First existing setup:
> 
> /dev/sda1 /boot (ext2)
> /dev/sda2 swap
> /dev/sda3 LVM
> 
> /dev/vg0/f9 / for F9 (ext2)
> plus empty space in vg0  

Oops.  Make that first VG be:

/dev/vg0/f9  / for F9  (ext2)
/dev/vg0/f11 / for F11 (ext2)
(no free space)

Comment 10 Allen Kistler 2009-08-01 21:47:50 UTC
Created attachment 355898 [details]
Screen Cap of F12 Custom Layout

PNG Attachment uses boot.iso of 01-Aug-2009 with anaconda-12.7.

Although the capture only shows the LVs, filesystems on partitions aren't detected, either.

Comment 11 Allen Kistler 2009-08-01 21:48:49 UTC
Created attachment 355899 [details]
Screen Cap of F11 Custom Layout (for comparison)

Comment 12 Allen Kistler 2009-08-01 21:50:45 UTC
Created attachment 355900 [details]
12.7: anaconda.log (/boot partition and / lv)

Comment 13 Allen Kistler 2009-08-01 21:51:31 UTC
Created attachment 355901 [details]
12.7: storage.log (/boot partition and / lv)

Comment 14 Allen Kistler 2009-08-01 21:52:50 UTC
Created attachment 355902 [details]
12.7: syslog (/boot partition and / lv)

Comment 15 Allen Kistler 2009-08-11 02:51:00 UTC
Update: better summary

Comment 16 Allen Kistler 2009-08-11 18:29:40 UTC
Created attachment 357060 [details]
12.13: anaconda.log (/boot partition and / lv)

Comment 17 Allen Kistler 2009-08-11 18:30:09 UTC
Created attachment 357061 [details]
12.13: storage.log (/boot partition and / lv)

Comment 18 Allen Kistler 2009-08-11 18:30:42 UTC
Created attachment 357062 [details]
12.13: syslog (/boot partition and / lv)

Comment 19 David Lehman 2009-08-11 22:07:17 UTC
Can you also attach /tmp/program.log? For some reason, udev is not importing information about the formatting of your lvs. Everything else appears to be getting detected/represented correctly AFAICT.

Comment 20 Allen Kistler 2009-08-12 21:59:19 UTC
Created attachment 357249 [details]
12.13: program.log (/boot partition and / lv)

(In reply to comment #19)
> Can you also attach /tmp/program.log? For some reason, udev is not importing
> information about the formatting of your lvs. Everything else appears to be
> getting detected/represented correctly AFAICT.

/boot is on regular partition /dev/sda1 and is ext2.
The fs is also not detected there.

Comment 21 Allen Kistler 2009-08-12 22:17:54 UTC
Created attachment 357252 [details]
12.13: Screen Cap of F12 Custom Layout

I spliced 2 screenshots so you can see the whole custom layout.

Notice the "Unknown" device types for /dev/sda1, /dev/vg0/f9, and /dev/vg0/f11.

Comment 22 David Lehman 2009-08-12 22:22:42 UTC
Hmm, yes. So it would seem as though it detects swap, lvmpv, and mdraid member
correctly, but not ext[234].

On tty2, please run the following command:

  udevadm test --action=add /class/block/sda1 > /tmp/sda1-add 2>&1

and then attach the file /tmp/sda1-add to this bug.


Is there something non-standard about your environment? Is this some sort of
custom spin?

Comment 23 Allen Kistler 2009-08-12 22:41:04 UTC
Created attachment 357254 [details]
12.13: udevadm test output (sda1-add in Comment #22)

(In reply to comment #22)
> Hmm, yes. So it would seem as though it detects swap, lvmpv, and mdraid member
> correctly, but not ext[234].
> 
> On tty2, please run the following command:
> 
>   udevadm test --action=add /class/block/sda1 > /tmp/sda1-add 2>&1
> 
> and then attach the file /tmp/sda1-add to this bug.
> 
> Is there something non-standard about your environment? Is this some sort of
> custom spin?

Other than VMware (hence the just-enough disk size), there's nothing special.
The "spin" is the regular rawhide boot.iso dated Aug 11 12:32.

For good measure, the output of "fdisk -l /dev/sda" is:

255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000824cd

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14          78      522112+  82  Linux swap / Solaris
/dev/sda3              79        1044     7759395   8e  Linux LVM

Comment 24 Allen Kistler 2009-08-12 22:48:57 UTC
In sda1-add:  '/sbin/blkid' not found

Suggestive?

Comment 25 Allen Kistler 2009-08-12 23:35:18 UTC
(In reply to comment #24)
> In sda1-add:  '/sbin/blkid' not found
> 
> Suggestive?  

Not suggestive.  It just runs from /usr/sbin, instead.  Oh, well.

Comment 26 David Lehman 2009-08-13 03:00:46 UTC
It still exited with an error code instead of providing filesystem information. According to the blkid man page, an exit code of 2 indicates that "the specified token was not found, or no (specified) devices could be identified".

What is the output if you just run 'blkid' ? Does the device file /dev/sda1 exist?

Comment 27 Allen Kistler 2009-08-13 17:21:05 UTC
Poor man's terminal capture from tty2 (bash -x 2>&1 | tee bash.log)

I ran blkid twice, once at the beginning and once at the end, with different results.

+ pwd
/tmp
+ blkid /dev/sda1
+ ls /dev/sda /dev/sda1 /dev/sda2 /dev/sda3  [Actually it was "ls /dev/sd*"]
/dev/sda
/dev/sda1
/dev/sda2
/dev/sda3
+ mkdir sda1
+ mount /dev/sda1 sda1
mount: you must specify the filesystem type
+ mount -t ext2 /dev/sda1 sda1
+ ls sda1
System.map-2.6.25-14.fc9.i686
System.map-2.6.29.4-167.fc11.i586
config-2.6.25-14.fc9.i686
config-2.6.29.4-167.fc11.i586
efi
grub
initrd-2.6.25-14.fc9.i686.img
initrd-2.6.29.4-167.fc11.i586.img
lost+found
vmlinuz-2.6.25-14.fc9.i686
vmlinuz-2.6.29.4-167.fc11.i586
+ umount sda1
+ blkid /dev/sda1
/dev/sda1: LABEL="/boot" UUID="af5b7530-8a07-4de6-8a8f-9baa670620e4" TYPE="ext2"

If I then go back into Custom Layout and hit Reset, /dev/sda1 is still Unknown, but /dev/vg0/f9 and /dev/vg0/f11 are identified as ext2.

If I hit Reset again, then /dev/sda1 is identified as ext2, as well.  (I don't get why twice is necessary, but I've noticed from reading the logs that anaconda always seems to do it twice on its own.)

If I don't do the stuff above in tty2, there's no change no matter how many times I hit Reset.

Epiphany strikes.

There's no mention of "modprobe ext2" in program.log.  lsmod doesn't list ext2 as loaded on a "clean" boot.

Just before "Finding storage devices" (at the pre-release nag) I switch to tty2, modprobe ext2, and switch back to continue.

Everything works perfectly.  Along the way, I'm even presented with the "Install or Upgrade" screen, which I hadn't noticed before was missing.

So, EasyFix?

Comment 28 David Lehman 2009-08-13 19:18:22 UTC
It seems as though blkid cannot identify an ext2 filesystem unless the ext2 module is loaded, which seems sub-optimal given that one might want to use blkid to determine what fstype to mount their ext2 device as. We load filesystem modules on demand in anaconda.

Reassigning to util-linux-ng in the hope that it will come up with a way to determine fstype w/o having fs modules preloaded.

Comment 29 Karel Zak 2009-08-13 20:15:24 UTC
Yeah, it's libblkid bug. Fixed upstream:
http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=commit;h=92cf3ab964266603cf36272d0eec96cd07fa083c

Unfortunately Fedora CVS has outage right now, so I'll fix it later.

Comment 30 Karel Zak 2009-08-13 22:35:57 UTC
The problem should be fixed. Please, try mount(8) and blkid(8) from util-linux-ng-2.16-5. I look forward to your feedback.

Comment 31 Allen Kistler 2009-08-13 23:05:33 UTC
(In reply to comment #30)
> The problem should be fixed. Please, try mount(8) and blkid(8) from
> util-linux-ng-2.16-5. I look forward to your feedback.  

Can you tag it for rawhide so a boot.iso gets built with it?

Thanks.

Comment 32 Radek Vokál 2009-08-14 05:35:52 UTC
(In reply to comment #31)
> (In reply to comment #30)
> > The problem should be fixed. Please, try mount(8) and blkid(8) from
> > util-linux-ng-2.16-5. I look forward to your feedback.  
> 
> Can you tag it for rawhide so a boot.iso gets built with it?
> 
> Thanks.  

It was built yesterday for rawhide - see build http://koji.fedoraproject.org/koji/buildinfo?buildID=127229

Comment 33 Allen Kistler 2009-08-14 18:16:59 UTC
(In reply to comment #32)
> It was built yesterday for rawhide - see build
> http://koji.fedoraproject.org/koji/buildinfo?buildID=127229  

But 2.16-5 is not in rawhide as of the push today at about 1200 UTC.
The current version is 2.16-3.  Would that be for the Alpha freeze?

Comment 34 Jesse Keating 2009-08-17 16:18:08 UTC
*** Bug 517458 has been marked as a duplicate of this bug. ***

Comment 35 Jeremy Katz 2009-08-17 20:41:01 UTC
*** Bug 517885 has been marked as a duplicate of this bug. ***

Comment 36 Allen Kistler 2009-08-19 18:57:42 UTC
I tested with the 19-Aug-2009 boot iso, which contains the blkid from util-linux-ng-2.16-5.

anaconda now reports/interprets blkid output for ext2 filesystems as ext4.

blkid output itself for an ext2 partition is:

# blkid /dev/sda1
/dev/sda1: LABEL="/boot" UUID="af5b7530-8a07-4de6-8a8f-9baa670620e4" SEC_TYPE="e
xt2" TYPE="ext4"

More work for util-linux-ng or back to anaconda with a different bug?

(Back to Assigned via Closed....)

Comment 37 Karel Zak 2009-08-19 21:11:24 UTC
(In reply to comment #36) 
> blkid output itself for an ext2 partition is:
> 
> # blkid /dev/sda1
> /dev/sda1: LABEL="/boot" UUID="af5b7530-8a07-4de6-8a8f-9baa670620e4"
> SEC_TYPE="ext2" TYPE="ext4"

That's correct. I guess you have system without ext2 module. From libblkid changelog:

    blkid: add fallback to ext4 for 2.6.29+ kernels if ext2 is not present
    
    Starting in 2.6.29, ext4 can be used to support filesystems without a
    journal.  So if ext2 is not present, and the kernel version is greater
    than 2.6.29, and ext4 is present, return a filesystme type of ext4.

Please, can you confirm that your system with ext2 /boot partition works as expected?

Comment 38 Allen Kistler 2009-08-20 03:46:56 UTC
Created attachment 358028 [details]
12.16: Screen Cap of F12 Custom Layout (ext2 module pre-loaded)

Comment 39 Allen Kistler 2009-08-20 03:47:57 UTC
Created attachment 358029 [details]
12.16: Screen Cap of F12 Custom Layout (ext2 module NOT pre-loaded)

Comment 40 Allen Kistler 2009-08-20 04:14:33 UTC
(In reply to comment #37)
> 
> That's correct. I guess you have system without ext2 module. From libblkid
> changelog:
> 
>     blkid: add fallback to ext4 for 2.6.29+ kernels if ext2 is not present
> 
>     Starting in 2.6.29, ext4 can be used to support filesystems without a
>     journal.  So if ext2 is not present, and the kernel version is greater
>     than 2.6.29, and ext4 is present, return a filesystme type of ext4.
> 
> Please, can you confirm that your system with ext2 /boot partition works as
> expected?  

The ext2 module exists, but it isn't loaded.  My system is anaconda.  Anaconda doesn't load the ext2 module unless blkid says there's an ext2 filesystem.

If I pre-load ext2 using modprobe, the blkid says:
/dev/sda1: LABEL="/boot" UUID="af5b7530-8a07-4de6-8a8f-9baa670620e4" TYPE="ext2"

If I do *NOT* preload ext2 using modprobe, then blkid says:
/dev/sda1: LABEL="/boot" UUID="af5b7530-8a07-4de6-8a8f-9baa670620e4" SEC_TYPE="ext2" TYPE="ext4"

So there's a chicken and egg problem.

1. Anaconda does not load ext2 unless blkid says TYPE="ext2"
2. blkid does not say TYPE="ext2" unless the ext2 module is loaded.

I've attached screenshots of anaconda's custom layout for each case.  The one which shows filesystems as ext2 is what I expect.  I do not expect the one showing file systems as ext4 (but which are not ext4).  I think everyone who has ext2 filesystems would expect them to display as ext2, not ext4.  However, what they're going to get is a dialog telling them they've got ext4.

So given that the ext2 module is present, but not loaded, what is the bug and what needs to be done?  I think the choices are:

1. blkid needs to look the same, whether the ext2 module is loaded or not.
   In this case, util-linux-ng needs more work.

2. anaconda needs to be able to interpret both forms of blkid output for
   ext2.
   In this case, util-linux-ng is fixed, but anaconda needs more work.

3. The ext2 module is obsolete.  ext4 will always be used in its place for
   all ext2 filesystems.

I'm inclined to think option 2 is the choice to make.

Option 1 seems contrary to ext4 supporting ext2.

Option 3 seems like something that needs a Fedora feature decision.

Thoughts?

Comment 41 Allen Kistler 2009-08-20 05:28:48 UTC
Upon completing an installation from rawhide:

1. fstab lists /boot as ext4, so mtab lists /boot as ext4
2. blkid says LABEL="/boot" UUID="[edit]" TYPE="ext2"
3. the ext2 module is *not* loaded

So that difference in behavior of blkid seems not self-consistent.

Why does blkid yield one result in anaconda, which has ext2 support compiled but not loaded, but it gives a different result in a booted system, which has ext2 support compiled but not loaded?

Comment 42 Karel Zak 2009-08-20 09:20:35 UTC
(In reply to comment #40)
> The ext2 module exists, but it isn't loaded.  My system is anaconda.  Anaconda
> doesn't load the ext2 module unless blkid says there's an ext2 filesystem.
> 
> If I pre-load ext2 using modprobe, the blkid says:
> /dev/sda1: LABEL="/boot" UUID="af5b7530-8a07-4de6-8a8f-9baa670620e4"
> TYPE="ext2"
> 
> If I do *NOT* preload ext2 using modprobe, then blkid says:
> /dev/sda1: LABEL="/boot" UUID="af5b7530-8a07-4de6-8a8f-9baa670620e4"
> SEC_TYPE="ext2" TYPE="ext4"

The libblkid library checks:

  /proc/filesystems
  /lib/modules/$(uname -r)/modules.dep

it means the library ***does not require loaded ext2 module***. That's enough
if the module is installed in /lib/modules.

For example:

system without loaded and installed ext2:

  $ grep ext2 /proc/filesystems
  $ grep ext2 /lib/modules/$(uname -r)/modules.dep

  $ ./blkid -p  /home/images/filesystems/ext2.img
  /home/images/filesystems/ext2.img: LABEL="COOL" UUID="ed409e8e-44cc-4c2e-a31a-cd98f54eff36" SEC_TYPE="ext2" VERSION="1.0" TYPE="ext4" USAGE="filesystem" 

now move ext2 back to system:

  $ grep ext2 /lib/modules/$(uname -r)/modules.dep
  kernel/fs/ext2/ext2.ko:

  $ ./blkid -p  /home/images/filesystems/ext2.img
  /home/images/filesystems/ext2.img: LABEL="COOL" UUID="ed409e8e-44cc-4c2e-a31a-cd98f54eff36" VERSION="1.0" TYPE="ext2" USAGE="filesystem" 



> 3. The ext2 module is obsolete.  ext4 will always be used in its place for
>    all ext2 filesystems.

I don't think we have to make this decision now. We can keep the ext2 in
distribution as a fallback, and the module could be also attractive for people
who use ext2 only.

(In reply to comment #41)
> Upon completing an installation from rawhide:
> 
> 1. fstab lists /boot as ext4, so mtab lists /boot as ext4
> 2. blkid says LABEL="/boot" UUID="[edit]" TYPE="ext2"

This is correct, mount(8) does not call libblkid when filesystem is 
explicitly defined in the fstab file.

> 3. the ext2 module is *not* loaded

Yes, but ext2 module is installed.

From my point of view (=libblkid) everything works as expected.

Comment 43 Allen Kistler 2009-08-20 21:22:20 UTC
(In reply to comment #42)
> 
> [snip]
> 
> The libblkid library checks:
> 
>   /proc/filesystems
>   /lib/modules/$(uname -r)/modules.dep
> 
> it means the library ***does not require loaded ext2 module***. That's enough
> if the module is installed in /lib/modules.
> 
> For example:
> 
> system without loaded and installed ext2:
> 
>   $ grep ext2 /proc/filesystems
>   $ grep ext2 /lib/modules/$(uname -r)/modules.dep
> 
>   $ ./blkid -p  /home/images/filesystems/ext2.img
>   /home/images/filesystems/ext2.img: LABEL="COOL"
> UUID="ed409e8e-44cc-4c2e-a31a-cd98f54eff36" SEC_TYPE="ext2" VERSION="1.0"
> TYPE="ext4" USAGE="filesystem" 
> 
> now move ext2 back to system:
> 
>   $ grep ext2 /lib/modules/$(uname -r)/modules.dep
>   kernel/fs/ext2/ext2.ko:
> 
>   $ ./blkid -p  /home/images/filesystems/ext2.img
>   /home/images/filesystems/ext2.img: LABEL="COOL"
> UUID="ed409e8e-44cc-4c2e-a31a-cd98f54eff36" VERSION="1.0" TYPE="ext2"
> USAGE="filesystem" 
> 
> [snip]
> 
> From my point of view (=libblkid) everything works as expected.  

I agree.  The original "blkid doesn't do anything with ext2" is fixed.

Figuring out why it runs differently in anaconda's installation environment is a different bug (which I suspect may be related to how the CDs and DVDs are composed, but I haven't looked yet).

Since this update is in rawhide, I'm closing this report.


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