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.
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
Created attachment 354615 [details] storage.log (/boot partition and / lv)
Created attachment 354616 [details] anaconda.log (/boot partition and / lv)
Created attachment 354617 [details] storage.log (/boot partition and / lv)
Created attachment 354618 [details] syslog (/boot partition and / lv)
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
Created attachment 354621 [details] storage.log (/boot on raid-1 and / lv on raid-1)
Created attachment 354622 [details] syslog (/boot on raid-1 and / lv on raid-1)
(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)
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.
Created attachment 355899 [details] Screen Cap of F11 Custom Layout (for comparison)
Created attachment 355900 [details] 12.7: anaconda.log (/boot partition and / lv)
Created attachment 355901 [details] 12.7: storage.log (/boot partition and / lv)
Created attachment 355902 [details] 12.7: syslog (/boot partition and / lv)
Update: better summary
Created attachment 357060 [details] 12.13: anaconda.log (/boot partition and / lv)
Created attachment 357061 [details] 12.13: storage.log (/boot partition and / lv)
Created attachment 357062 [details] 12.13: syslog (/boot partition and / lv)
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.
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.
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.
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?
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
In sda1-add: '/sbin/blkid' not found Suggestive?
(In reply to comment #24) > In sda1-add: '/sbin/blkid' not found > > Suggestive? Not suggestive. It just runs from /usr/sbin, instead. Oh, well.
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?
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?
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.
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.
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.
(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.
(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
(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?
*** Bug 517458 has been marked as a duplicate of this bug. ***
*** Bug 517885 has been marked as a duplicate of this bug. ***
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....)
(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?
Created attachment 358028 [details] 12.16: Screen Cap of F12 Custom Layout (ext2 module pre-loaded)
Created attachment 358029 [details] 12.16: Screen Cap of F12 Custom Layout (ext2 module NOT pre-loaded)
(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?
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?
(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.
(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.