Description of problem: installing a new Fedora 12 OS on my acer aspire one fails when using the default settings presented by anaconda. The cause seems to be that the blkid command does not recognise the ext2 formatted partition that contains the original linpus linux installation. Version-Release number of selected component (if applicable): blkid from util-linux-ng 2.16 (libblkid 2.16.0, 10-Feb-2009) How reproducible: on my machine always. Note however that I also tried to install a fresh linpus copy from the original dvd, and in that case the problem disappears. So it seems during the use of this machine something has happended to the filesystem that triggers this problem. (I saved a dd copy of the 8GB ssd disk containing this linpus installation on an external usb harddisk, so could return to the old situation to reproduce it). Steps to Reproduce: 1. attach external dvd reader/writer to the computer 2. insert fedora 12 x386 install dvd 3. turn on computer, and choose all defaults presented by anaconda. Actual results: anaconda crashes. See bug https://bugzilla.redhat.com/show_bug.cgi?id=557389 for details. Apart from the fact that anaconda does not catch the problem nicely, the cause seems to be that blkid does not find the filesystem on /dev/sda1. If I switch to one of the terminals (ctrl-alt-f2) and type blkid I get this output: /dev/loop0: TYPE="squashfs" /dev/sda2: TYPE="swap" If I start fdisk on /dev/sda and give the print command I get this output: Device Boot Start End Blocks Id System /dev/sda1 * 1 1831 14707476 83 Linux /dev/sda2 1832 1962 1052257* 82 Linux swap / Solaris If I then restart again without external usb dvd reader, the old linpus boots again without problems from /dev/sda1, so there really is a filesystem installed there. Expected results: The existing ext2 filesystem should be recognised, even if it might be partially corrupt. Additional info: If you need any additional information I will be happy to provide it.
(In reply to comment #0) > Version-Release number of selected component (if applicable): > blkid from util-linux-ng 2.16 (libblkid 2.16.0, 10-Feb-2009) We have util-linux-ng 2.16.2 in Fedora-12 now. It would be nice to know exact version of the blkid util (as returned by rpm -qf /sbin/blkid) on the install dvd. Please see also bug #513104 and bug #518572. Please, try BLKID_PROBE=0xffff blkid -p -o udev /dev/sda1 or if you have an image of the whole sda disk, try to use losetup /dev/loop0 wholedisk.img kpartx -a /dev/loopN to map partitions from the image to /dev/mapper/loop0pN devices and then call BLKID_PROBE=0xffff blkid -p -o udev /dev/mapper/loop0p1 or you can send me the begin of the disk (or image) dd if=/dev/sda of=begin.img bs=1024 count=100 (or if=wholedisk.img). Thanks.
oops... the env.variable name is BLKID_DEBUG=. Sorry.
running rpm -qf /sbin/blkid on does not work, the rpm command responds with: file /usr/sbin/blkid is not owned by any package. The install dvd itself contains this version: /mnt/stage2/Packages/util-linux-ng-2-16-10.2.fc12.i686.rpm the command: BLKID_PROBE=0xffff blkid -p -o udev /dev/sda1 returns with: /dev/sda1: ambivalent result (probably more filesystems on the device) the command: BLKID_DEBUG=0xffff blkid -p -o udev /dev/sda1 > output_blkid.txt returns on stderr with: /dev/sda1: ambivalent result (probably more filesystems on the device) The stdout output is attached. I also attached 2 versions of the file begin.img, produced by the command dd if=wholedisk.img of=begin.img bs=1024 count=100 begin.img is the start of the problematic disk image (factory installed linpus). begin_ok.img is the start of the freshly from dvd installed linpus on the same machine. I hope this is sufficient for you to diagnose the problem.
Created attachment 388739 [details] output of the blkid command with debug output switched on
Created attachment 388742 [details] start of the problematic diskimage
Created attachment 388744 [details] start of diskimage of freshly installed lipus on the same machine
It seems that your sda1 contains a valid FAT32 superblock and also ext2 superblock. The blkid(8) cannot provide ambivalent results for udev, so we ignore such disks. You need to properly format your sda1 or try to remove unwanted FAT signature from sda1. In Fedora-13 we have wipefs(8) command that is able to remove unwanted signatures. The command is available in the latest util-linux-ng package (it should be possible to install this package from F13 to system with F12). For more details see: http://karelzak.blogspot.com/2009/11/wipefs8.html. You need: wipefs --offset 0x52 /dev/sda1 wipefs --offset 0x0 /dev/sda1 wipefs --offset 0x1fe /dev/sda1 because FAT is detectable by three different signatures. The other way is to use dd(1) command -!!!- but be very careful -!!!- you can lost your data on sda1: dd if=/dev/zero of=/dev/sda1 bs=1 seek=$((0x52)) count=8 conv=notrunc dd if=/dev/zero of=/dev/sda1 bs=1 seek=$((0x0)) count=1 conv=notrunc dd if=/dev/zero of=/dev/sda1 bs=1 seek=$((0x1fe)) count=2 conv=notrunc
(In reply to comment #6) > Created an attachment (id=388744) [details] > start of diskimage of freshly installed lipus on the same machine It seem that this image contains ext2 superblock only.
Thanks a lot for your diagnose, and the suggested workarounds/fixes. It might be nice if blkid would report something in the case of corrupted or unrecognised filesystems, to allow the user to decide to wipe it (or not), but this is more a feature request than a bug I guess. So, I think this one can indeed be closed. thanks again, Jos.
(In reply to comment #9) > It might be nice if blkid would report something in the case of corrupted or > unrecognised filesystems, to allow the user to decide to wipe it (or not), but > this is more a feature request than a bug I guess. This is already implemented for F-13, the information about ambivalent probing result will be exported to udevd and in future it should be available for udisk (DevKit) and GUI.