Bug 569057

Created attachment 396784 [details]
Attached traceback automatically from anaconda.

Created attachment 396852 [details]
e2fsck -nv /dev/sdb5 script session

script session with "e2fsck -nv" on all partitions on /dev/sdb.

Not in the session: From F12, /dev/sdb3 and /dev/mapper/vg_pluto-lv_fir_root can be mounted, while /dev/sdb5 cannot be mounted. All three were configured in the installer to be formatted as ext4. (With sdb3 and sdb5 to be deleted and recreated with new sizes.)

Before the install failure, /dev/sdb5 was an ext4 partition with a working F13 installation.

It is possible I have a hardware problem with my optical drive (sr0). These are from the attached report:
20:24:05,792 ERR kernel:end_request: I/O error, dev sr0, sector 399360
20:24:05,792 ERR kernel:Buffer I/O error on device sr0, logical block 99840
20:24:05,792 ERR kernel:Buffer I/O error on device sr0, logical block 99841

And from /var/log/messages while running F12:
Feb 27 12:03:32 localhost kernel: sr 5:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Feb 27 12:03:32 localhost kernel: sr 5:0:1:0: [sr0] Sense Key : Illegal Request [current] 
Feb 27 12:03:32 localhost kernel: sr 5:0:1:0: [sr0] Add. Sense: Illegal mode for this track
Feb 27 12:03:32 localhost kernel: end_request: I/O error, dev sr0, sector 399360
Feb 27 12:03:32 localhost kernel: Buffer I/O error on device sr0, logical block 49920

Created attachment 396865 [details]
hexdump of beginning of /dev/sdb5

$ sudo dd if=/dev/sdb5 bs=1K count=900 | hexdump -C >dd-sdb5.1.log

Created attachment 396917 [details]
Attached traceback automatically from anaconda.

(In reply to comment #4)
> Created an attachment (id=396917) [details]
> Attached traceback automatically from anaconda.    

This bug seems to be reproducible. This time I attempted to merge /dev/sdb3 and /dev/sdb5 into one ext4 partition. Was on the live system (USB stick).

However, the failure corrupted both partitions.

[root@localhost liveuser]# e2fsck -nv /dev/sdb3
e2fsck 1.41.10 (10-Feb-2009)
e2fsck: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Clear? no

e2fsck: Illegal inode number while checking ext3 journal for fir_boot
[root@localhost liveuser]# 

[root@localhost liveuser]# e2fsck -nv /dev/sdb5 | head -20
e2fsck 1.41.10 (10-Feb-2009)
e2fsck: Superblock invalid, trying backup blocks...
One or more block group descriptor checksums are invalid.  Fix? no

Group descriptor 10 checksum is invalid.  IGNORED.
Group descriptor 11 checksum is invalid.  IGNORED.
Group descriptor 12 checksum is invalid.  IGNORED.
Group descriptor 13 checksum is invalid.  IGNORED.
Group descriptor 14 checksum is invalid.  IGNORED.
Group descriptor 15 checksum is invalid.  IGNORED.
Group descriptor 16 checksum is invalid.  IGNORED.
Group descriptor 17 checksum is invalid.  IGNORED.
Group descriptor 18 checksum is invalid.  IGNORED.
Group descriptor 19 checksum is invalid.  IGNORED.
Group descriptor 20 checksum is invalid.  IGNORED.
Group descriptor 21 checksum is invalid.  IGNORED.
Group descriptor 22 checksum is invalid.  IGNORED.
Group descriptor 23 checksum is invalid.  IGNORED.
F13-Alpha-x86_64 contains a file system with errors, check forced.
Resize inode not valid.  Recreate? no

==
anaconda-13.32-1.fc13.x86_64
parted-2.1-5.fc13.x86_64
kernel-2.6.33-0.52.rc8.git6.fc13.x86_64

(In reply to comment #5)
 
> However, the failure corrupted both partitions.

Left out a detail -- I reinstalled F13 on /dev/sdb5 before the merge attempt. F13 booted and ran fine -- used it to file more bugs.

The errors you noted in comment #2 certainly are suspicious, as once we start getting read errors from the CD-ROM it's hard to trust anything that's being run off the disc.  When you're on the live USB image, can you run dmesg and see if you are also getting read errors from it?

Created attachment 397223 [details]
dmesg while booted from live USB stick

(In reply to comment #7)
> The errors you noted in comment #2 certainly are suspicious, as once we start
> getting read errors from the CD-ROM it's hard to trust anything that's being
> run off the disc.  When you're on the live USB image, can you run dmesg and see
> if you are also getting read errors from it?    

dmesg while booted from the live USB stick doesn't show any of those errors. Also, in comment 5 I reproduced this bug while booted from the live USB. The duplicate bug detection works great, BTW.
 
The Lexar USB stick I am using is proving to be very reliable. I had been using a Kingston DataTraveler, and it was a nightmare. Sometimes livecd-iso-to-disk would stall while copying files. Often the kernel would hang while booting.

For the record: the CDRWs are new and they pass the media test.

FYI, you helped me figure out why I am not getting any abrt dumps -- low disk space. :-)

What's happening here is this: parted tells us that sdb5 contains a disklabel even though it does not. You then perform some operations that include specifying that any formatting on sdb5 should be removed. Since we made the mistake of believing parted when it told us that formatting is a disklabel, removing the formatting means removing a disklabel, which we try to do via parted. I can't say just why parted isn't allowing us to do a parted.Device.clobber() on the sdb5 partition, but that's a secondary problem. The primary problem has been addressed in bug 567832, and will be fixed in the next build of anaconda (13.33-1).

Thanks, Dave!

(In reply to comment #9)
...
> The primary problem has been addressed in bug 567832, and will be fixed in the
> next build of anaconda (13.33-1).    

Will that version also fix the exceptions and disk corruption being reported in this bug? If so, this could be duped to bug 567832.

(In reply to comment #9)
> I can't say just why parted isn't allowing us to do a
> parted.Device.clobber() on the sdb5 partition, but that's a secondary problem.
> The primary problem has been addressed in bug 567832, and will be fixed in the
> next build of anaconda (13.33-1).    

The clobber is working fine, it is the commit() call that is failing, as
that leads to a re-read partition table ioctl on /dev/sdb5 which the kernel
denies.

As it stands now it seems that disklabel.destroy() is not destroying the
disklabel, but is writing an empty table. To destroy the disklabel a
single self.partedDevice.clobber(), without all the create a freshdisk and commit
it magic, would suffice. And remove the problem of trying to commit a table
to a partition instead of to a disk.

Dave,

Assigning this to you, as explained in comment #12, I believe part of the problem is disklabel.destroy() calling partedDisk.commit() when the device is a partition.

Even with your fix for false positive identification of partition tables, this can still happen if a partition really contains a partition table.

Regards,

Hans

Created attachment 397795 [details]
Attached traceback automatically from anaconda.

Created attachment 397797 [details]
dmesg.1.log after exception in Live env. off USB stick

Created attachment 397798 [details]
messages.1.log after exception in Live env. off USB stick

Created attachment 397799 [details]
screenshot with "tail -f /var/log/messages" after exception in Live env. off USB stick

I have removed the questionable DVD burner from my system. It was an IDE device on the same bus as the install target hard drive. I have replaced the drive with a SATA optical drive.

I reproduced the bug by deleting and creating /dev/sdb3 using anaconda's custom partitioning. /dev/sdb3 had a working F13 installation before the exception.

The attached dmesg, messages, and screenshot are all from the point at which anaconda displayed the exception dialog.

"e2fsck -nv /dev/sdb3" reports corruption.

I would like to test for this bug with anaconda 13.33-1 in the live environment (13-Alpha-RC4). It is not on the mirrors or in koji. Can you provide a package?

fdisk says /dev/sdb has DOS-compatible mode enabled. Here, /dev/sdb is in the state it was in after the anaconda exception.

[root@localhost liveuser]# fdisk /dev/sdb

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').

Command (m for help): p

Disk /dev/sdb: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xff3d5e55

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          13      104391   83  Linux
/dev/sdb2              14        4418    35383162+  8e  Linux LVM
/dev/sdb3            4419        4865     3590527+  83  Linux

Command (m for help): x

Expert command (m for help): p

Disk /dev/sdb: 255 heads, 63 sectors, 4865 cylinders

Nr AF  Hd Sec  Cyl  Hd Sec  Cyl     Start      Size ID
 1 80   1   1    0 254  63   12         63     208782 83
 2 00   0   1   13 254  63 1023     208845   70766325 8e
 3 00 254  63 1023 254  63 1023   70975170    7181055 83
 4 00   0   0    0   0   0    0          0          0 00

Expert command (m for help):

Created attachment 400533 [details]
Attached traceback automatically from anaconda.

The problem of misidentifying partitions as containing disklabels was resolved in bug 567832. The problem of trying to unnecessarily use commit when destroying a disklabel was resolved in bug 576145.

Created attachment 425460 [details]
Attached traceback automatically from anaconda.