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

the above is the trace of an native (no VM) install via boot.iso

with same iso I did a VM install on a another box and reported this here:
https://bugzilla.redhat.com/show_bug.cgi?id=490788

According to your exception report, you are seeing kernel panics when attempting to mount a btrfs volume.  Reassigning.

brtfs ???

my disk layout:

Disk /dev/sda: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000dcf1e

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        1044     8385898+  83  Linux
/dev/sda2   *        1045        3477    19543072+  bf  Solaris
/dev/sda3            3478       10773    58605120   8e  Linux LVM
/dev/sda4           10774       24321   108824310    5  Extended
/dev/sda5           10774       10799      208813+  83  Linux
/dev/sda6           10800       11453     5253223+  83  Linux

Disk /dev/sdb: 40.0 GB, 40060403712 bytes
255 heads, 63 sectors/track, 4870 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000ebcc7

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1         765     6144831    7  HPFS/NTFS
/dev/sdb2             766        3377    20980890    7  HPFS/NTFS
/dev/sdb3            3378        3403      204800    7  HPFS/NTFS
/dev/sdb4            3403        4871    11788288    7  HPFS/NTFS

<6>btrfs bad tree block start 207090438111281 185409536
<6>btrfs bad tree block start 207090438111281 185409536
<6>btrfs bad tree block start 2338324109381103474 185409536
<4>------------[ cut here ]------------
<4>WARNING: at fs/btrfs/disk-io.c:866 read_tree_block+0x60/0x6d [btrfs]() (Not tainted)
<4>Hardware name: System Product Name
<4>Modules linked in: xts lrw gf128mul sha256_generic cbc dm_crypt dm_round_robin dm_multipath btrfs zlib_deflate libcrc32c xfs exportfs jfs reiserfs gfs2 msdos linear raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 prism54 ata_generic pata_acpi p54pci p54common mac80211 cfg80211 pata_atiixp r8169 mii radeon drm i2c_algo_bit i2c_core iscsi_ibft iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ext2 ext4 jbd2 crc16 squashfs pcspkr edd nfs lockd nfs_acl auth_rpcgss sunrpc vfat fat cramfs usb_storage
<4>Pid: 2449, comm: mount Not tainted 2.6.29-0.258.rc8.git2.fc11.i586 #1
<4>Call Trace:
<4> [<c042fae7>] warn_slowpath+0x7c/0xa7
<4> [<f8b4c47a>] ? btrfs_num_copies+0x9d/0xa7 [btrfs]
<4> [<f8b2d213>] ? btree_read_extent_buffer_pages+0xa1/0xb7 [btrfs]
<4> [<f8b2d91a>] read_tree_block+0x60/0x6d [btrfs]
<4> [<f8b300cc>] open_ctree+0x9af/0xd69 [btrfs]
<4> [<c0540c76>] ? strlcpy+0x13/0x3d
<4> [<f8b1a2c7>] btrfs_get_sb+0x208/0x3be [btrfs]
<4> [<c048e814>] ? kstrdup+0x30/0x4c
<4> [<c04ab940>] vfs_kern_mount+0x82/0xfb
<4> [<c04aba08>] do_kern_mount+0x38/0xbe
<4> [<c04bd1ae>] do_mount+0x647/0x680

...

<3>btrfs bad mapping eb start 185409536 len 4096, wanted 2156494237 17
<4>------------[ cut here ]------------
<4>WARNING: at fs/btrfs/extent_io.c:3434 map_private_extent_buffer+0x81/0xb8 [btrfs]() (Tainted: G        W )
<4>Hardware name: System Product Name
<4>Modules linked in: xts lrw gf128mul sha256_generic cbc dm_crypt dm_round_robin dm_multipath btrfs zlib_deflate libcrc32c xfs exportfs jfs reiserfs gfs2 msdos linear raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 prism54 ata_generic pata_acpi p54pci p54common mac80211 cfg80211 pata_atiixp r8169 mii radeon drm i2c_algo_bit i2c_core iscsi_ibft iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ext2 ext4 jbd2 crc16 squashfs pcspkr edd nfs lockd nfs_acl auth_rpcgss sunrpc vfat fat cramfs usb_storage
<4>Pid: 2449, comm: mount Tainted: G        W  2.6.29-0.258.rc8.git2.fc11.i586 #1
<4>Call Trace:
<4> [<c042fae7>] warn_slowpath+0x7c/0xa7
<4> [<c0445651>] ? up+0x11/0x34
<4> [<c044e8c5>] ? trace_hardirqs_off_caller+0x18/0xa3
<4> [<c044e8c5>] ? trace_hardirqs_off_caller+0x18/0xa3
<4> [<c044e95b>] ? trace_hardirqs_off+0xb/0xd
<4> [<c06ef1ee>] ? _spin_unlock_irqrestore+0x3e/0x55
<4> [<f8b463e5>] map_private_extent_buffer+0x81/0xb8 [btrfs]
<4> [<f8b1b480>] generic_bin_search+0xc2/0x1ac [btrfs]
<4> [<c0450844>] ? print_lock_contention_bug+0x11/0xb2
<4> [<f8b1cb60>] ? btrfs_lock_root_node+0x25/0x4e [btrfs]
<4> [<c0420369>] ? kmap_atomic_prot+0x1b8/0x1d7
<4> [<f8b1b5a8>] bin_search+0x3e/0x49 [btrfs]
<4> [<f8b1fa34>] btrfs_search_slot+0x1df/0x4e8 [btrfs]
<4> [<c044f578>] ? trace_hardirqs_on_caller+0x18/0x145
<4> [<f8b1d130>] ? btrfs_alloc_path+0x17/0x24 [btrfs]
<4> [<f8b2a62d>] btrfs_find_last_root+0x5d/0xd9 [btrfs]
<4> [<c05405f5>] ? __init_rwsem+0x40/0x53
<4> [<f8b2dfee>] find_and_setup_root+0x66/0xc1 [btrfs]
<4> [<f8b300ed>] open_ctree+0x9d0/0xd69 [btrfs]
<4> [<c0540c76>] ? strlcpy+0x13/0x3d
<4> [<f8b1a2c7>] btrfs_get_sb+0x208/0x3be [btrfs]
<4> [<c048e814>] ? kstrdup+0x30/0x4c
<4> [<c04ab940>] vfs_kern_mount+0x82/0xfb
<4> [<c04aba08>] do_kern_mount+0x38/0xbe
<4> [<c04bd1ae>] do_mount+0x647/0x680

<1>BUG: unable to handle kernel NULL pointer dereference at (null)
<1>IP: [<c04201cf>] kmap_atomic_prot+0x1e/0x1d7
<4>*pde = 734c4067 
<0>Oops: 0000 [#1] SMP 
<0>last sysfs file: /sys/devices/pci0000:00/0000:00:12.0/host0/target0:0:0/0:0:0:0/block/sda/removable
<4>Modules linked in: xts lrw gf128mul sha256_generic cbc dm_crypt dm_round_robin dm_multipath btrfs zlib_deflate libcrc32c xfs exportfs jfs reiserfs gfs2 msdos linear raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 prism54 ata_generic pata_acpi p54pci p54common mac80211 cfg80211 pata_atiixp r8169 mii radeon drm i2c_algo_bit i2c_core iscsi_ibft iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ext2 ext4 jbd2 crc16 squashfs pcspkr edd nfs lockd nfs_acl auth_rpcgss sunrpc vfat fat cramfs usb_storage
<4>
<4>Pid: 2449, comm: mount Tainted: G        W  (2.6.29-0.258.rc8.git2.fc11.i586 #1) System Product Name
<4>EIP: 0060:[<c04201cf>] EFLAGS: 00010202 CPU: 1
<4>EIP is at kmap_atomic_prot+0x1e/0x1d7
<4>EAX: f3a4f000 EBX: 00000000 ECX: 00000163 EDX: 00000007
<4>ESI: 00000007 EDI: 00000163 EBP: f3a4fc70 ESP: f3a4fc5c
<4> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
<0>Process mount (pid: 2449, ti=f3a4f000 task=f38694f0 task.ti=f3a4f000)
<0>Stack:
<4> f3a4fc78 f8b45d60 f25fc170 00000000 80897dae f3a4fc78 c042039b f3a4fc90
<0> f8b463fa 00080897 f3a4fdab f25fc170 80897d9d f3a4fd00 f8b1b480 f3a4fcf0
<0> f3a4fcec f3a4fce8 f3a4fce4 00000007 00000021 00000065 c0450844 ffffffff
<0>Call Trace:
<0> [<f8b45d60>] ? extent_buffer_page+0x73/0x7d [btrfs]
<0> [<c042039b>] ? kmap_atomic+0x13/0x15
<0> [<f8b463fa>] ? map_private_extent_buffer+0x96/0xb8 [btrfs]
<0> [<f8b1b480>] ? generic_bin_search+0xc2/0x1ac [btrfs]
<0> [<c0450844>] ? print_lock_contention_bug+0x11/0xb2
<0> [<f8b1cb60>] ? btrfs_lock_root_node+0x25/0x4e [btrfs]
<0> [<c0420369>] ? kmap_atomic_prot+0x1b8/0x1d7
<0> [<f8b1b5a8>] ? bin_search+0x3e/0x49 [btrfs]
<0> [<f8b1fa34>] ? btrfs_search_slot+0x1df/0x4e8 [btrfs]
<0> [<c044f578>] ? trace_hardirqs_on_caller+0x18/0x145
<0> [<f8b1d130>] ? btrfs_alloc_path+0x17/0x24 [btrfs]
<0> [<f8b2a62d>] ? btrfs_find_last_root+0x5d/0xd9 [btrfs]
<0> [<c05405f5>] ? __init_rwsem+0x40/0x53
<0> [<f8b2dfee>] ? find_and_setup_root+0x66/0xc1 [btrfs]
<0> [<f8b300ed>] ? open_ctree+0x9d0/0xd69 [btrfs]
<0> [<c0540c76>] ? strlcpy+0x13/0x3d
<0> [<f8b1a2c7>] ? btrfs_get_sb+0x208/0x3be [btrfs]
<0> [<c048e814>] ? kstrdup+0x30/0x4c
<0> [<c04ab940>] ? vfs_kern_mount+0x82/0xfb
<0> [<c04aba08>] ? do_kern_mount+0x38/0xbe
<0> [<c04bd1ae>] ? do_mount+0x647/0x680
<0> [<c05459eb>] ? _raw_spin_lock+0x53/0x106
<0> [<c04bb83b>] ? copy_mount_options+0x2c/0x10d
<0> [<c04bd252>] ? sys_mount+0x6b/0xa5
<0> [<c0403f92>] ? syscall_call+0x7/0xb
<0>Code: 25 00 f0 ff ff ff 48 14 5b 5e 5f 5d c3 55 89 e5 57 56 53 83 ec 08 0f 1f 44 00 00 89 c3 89 e0 25 00 f0 ff ff 89 d6 ff 40 14 89 cf <8b> 03 c1 e8 1e 69 c0 80 14 00 00 05 00 74 89 c0 2b 80 0c 14 00

Did this system have a btrfs partition on it when install was started?

How early in the install did it error out?

A1: 
- no btrfs partitions at all
- but /dev/sda2 is zfs (see in Comment #4)

A2: 
- right now after I choose my keyboard layout. 
- dmesg|more on VT2 looks sane up to this point. [1]
- a popup "Finding storage devices" appears, then the exception occurs.


[1] up to line 829/830 in the attached syslog

it reads:

<13>Mar 18 04:42:53 firmware.sh[1801]: Cannot find  firmware file 'isl3890'
<29>Mar 18 04:42:53 NetworkManager: <info>  (eth1): supplicant interface state:  starting -> ready

Created attachment 335951 [details]
syslog

Can you get to a command prompt and run 'blkid /dev/sda6' from the installation disk? It looks like it thinks that is a btrfs partition.

tested with a boot.iso from 31.03.2009
- kernel 2.6.29-21.fc11.i586
- anaconda 11.5.0.38
- NO OOPSES like in Comment #5 / Comment #6


as there is (still) a card reader (3 slots) in this box I assume it's the cause for the change sdb is now seen as sde


fdisk -l /dev/sd? :

Disk /dev/sda: 200.0 GB, 200048565760 bytes
255 heads, 63 sectors/track, 24321 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000dcf1e

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        1044     8385898+  83  Linux
/dev/sda2            1045        3477    19543072+  bf  Solaris
/dev/sda3            3478       10773    58605120   8e  Linux LVM
/dev/sda4   *       10774       12018    10000462+  83  Linux

Disk /dev/sde: 40.0 GB, 40059321856 bytes
255 heads, 63 sectors/track, 4870 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000ebcc7

   Device Boot      Start         End      Blocks   Id  System
/dev/sde1               1         765     6144831    7  HPFS/NTFS
/dev/sde2             766        3377    20980890    7  HPFS/NTFS
/dev/sde3   *        3378        3403      204800    7  HPFS/NTFS
/dev/sde4            3403        4871    11788288    7  HPFS/NTFS



blkid:

/dev/loop0: TYPE="squashfs" 
/dev/sda1: UUID="da96c325-9584-444a-a6c4-c3aef107487d" TYPE="ext4" 
/dev/sda2: UUID="f00819db-02a7-467c-ba24-425a435713ee" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda3: UUID="UCqmkd-MMOR-MSul-cEDK-OStj-k9dW-j0MLsp" TYPE="lvm2pv" 
/dev/sda4: LABEL="f11" UUID="49a2e1f8-862c-4cba-8b54-4fb67525fe87" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda5: UUID="ac78402b-bc39-4f47-aa3c-ec546f3b45cb" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda6: UUID="f00819db-02a7-467c-ba24-425a435713ee" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda7: UUID="f00819db-02a7-467c-ba24-425a435713ee" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sde1: UUID="665899905899601B" LABEL="Lokaler DatentrM-dger" TYPE="ntfs" 
/dev/sde2: UUID="B458248D58245102" LABEL="VOLUME" TYPE="ntfs" 
/dev/sde3: UUID="08E4726AE47259C0" TYPE="ntfs" 
/dev/sde4: UUID="90F0704EF0703C92" TYPE="ntfs" 




the last lines from anaconda.log are:


 geometry: <parted.geometry.Geometry object at 0xb6a8058c>  PedPartition: <_ped.Partition object at 0xb6a87a4c> ;
15:28:24 DEBUG   : isys.py:mount()- going to mount /dev/sda1 on /tmp/getsize-4KZWhX with options ro
15:28:24 DEBUG   : PartitionDevice._setFormat: sda1 ;
15:28:24 DEBUG   : PartitionDevice._setFormat: sda1 ; current: None ; type: ext4 ;
15:28:24 DEBUG   : DiskDevice.addChild: kids: 1 ; name: sda ;
15:28:24 DEBUG   : PartitionDevice._setFormat: sda2 ;
15:28:24 DEBUG   : PartitionDevice._setFormat: sda2 ; current: None ; type: None ;
15:28:24 DEBUG   : PartitionDevice.probe: sda2 ; exists: True ;
15:28:24 DEBUG   : PartitionDevice.getFlag: path: /dev/sda2 ; flag: 1 ; part: parted.Partition instance --
  disk: <parted.disk.Disk object at 0xb77d9e8c>  fileSystem: <parted.filesystem.FileSystem object at 0xb6a8062c>
  number: 2  path: /dev/sda2  type: 0
  name: None  active: True  busy: False
  geometry: <parted.geometry.Geometry object at 0xb6a8044c>  PedPartition: <_ped.Partition object at 0xb6a8798c> ;
15:28:24 DEBUG   : PartitionDevice.flagAvailable: path: /dev/sda2 ; flag: 1 ; part: parted.Partition instance --
  disk: <parted.disk.Disk object at 0xb77d9e8c>  fileSystem: <parted.filesystem.FileSystem object at 0xb6a8062c>
  number: 2  path: /dev/sda2  type: 0
  name: None  active: True  busy: False
  geometry: <parted.geometry.Geometry object at 0xb6a8044c>  PedPartition: <_ped.Partition object at 0xb6a8798c> ;
15:28:24 DEBUG   : PartitionDevice.getFlag: path: /dev/sda2 ; flag: 10 ; part: parted.Partition instance --
  disk: <parted.disk.Disk object at 0xb77d9e8c>  fileSystem: <parted.filesystem.FileSystem object at 0xb6a8062c>
  number: 2  path: /dev/sda2  type: 0
  name: None  active: True  busy: False
  geometry: <parted.geometry.Geometry object at 0xb6a8044c>  PedPartition: <_ped.Partition object at 0xb6a8798c> ;
15:28:24 DEBUG   : PartitionDevice.flagAvailable: path: /dev/sda2 ; flag: 10 ; part: parted.Partition instance --
  disk: <parted.disk.Disk object at 0xb77d9e8c>  fileSystem: <parted.filesystem.FileSystem object at 0xb6a8062c>
  number: 2  path: /dev/sda2  type: 0
  name: None  active: True  busy: False
  geometry: <parted.geometry.Geometry object at 0xb6a8044c>  PedPartition: <_ped.Partition object at 0xb6a8798c> ;
15:28:24 DEBUG   : isys.py:mount()- going to mount /dev/sda2 on /tmp/getsize-Y7Ptcp with options ro



complete log are available !

Could you send the first 300k or so of sda2, so I can see how blkid treats it?

Thanks,
-Eric

(either by attaching, or via email is fine too)

file send to esandeen

Ronald's disk also appears to have old ext3 signatures too:

# blkid first_400K 
first_400K: UUID="f00819db-02a7-467c-ba24-425a435713ee" SEC_TYPE="ext2" TYPE="ext3" 
# /lib/udev/vol_id first_400K 
ID_FS_USAGE=filesystem
ID_FS_TYPE=ext3
...

so really no idea why it's trying to get mounted as btrfs.

I've pinged the guy who did the zfs identification for blkid, this is the 2nd time I've seen this.

So we have 3 or 4 bugs, I think!

1) btrfs oopses when trying to mount this zfs partition as btrfs
2) blkid doesn't recognize these zfs partitions
3) mkfs.zfs doesn't zero out old ext3 signatures
4) anaconda is mounting something volid & blkid think is ext3, as btrfs?

Josef can have this bug for 1), I'll look into 2), we can't fix 3), and I may clone this bug back to anaconda for 4).

thanks for support !


to 3)

I could do an shred -vz -n 3 /dev/sda, etc.. 
it's a test box.

but we'll loose the possibility to test against 1,2,4)

What should I do ?

I think we have enough info from the disk header you provided to fix up 2) and 4), ask Josef about 1) :)

If you need to be able to install f11 we can probably just wipe out the ext3 signatures on that partition so volid doesn't find it, or, wait for updated anaconda, or use an updates image with the fixed anaconda bits...

so the party line for btrfs not working on corrupted fs's (which is what zfs looks like to btrfs) is that we're not going to fix it until way later on, since we have alot of these BUG/BUG_ON's in place to catch stupid coding errors, so once we've gotten to the point where we're a bit more comfortable with stability we will start working on fixing "hey btrfs panics if you mount a corrupt image" bugs.

I wonder if we should ask anaconda to somehow disallow the loading of btrfs w/o the special incantation.

Otherwise btrfs looks like it may break installs for people who have never even touched btrfs....

Disallow loading the module?  Yes we can add that if we really need to, though it's a little annoying and we will probably forget to undo that change in the future until someone reminds us.  But, aren't we still going to see this problem if you boot with the special command line option and have a corrupted filesystem?  I guess that does significantly decrease the number of people who will run into the problem, but it doesn't really fix it.

Well, btrfs is experimental.  If it breaks you keep both pieces.

But if having it loaded in the kernel means that people not even *using* btrfs are panicing and failing to install, I think we need to not force this problem on them in the name of a bleeding-edge fs experiment in fedora...

remember, this guy didn't even have btrfs on his system, and it's been stated that we won't be fixing btrfs robustness in the face of corruption at this point... so we just need to have some way to avoid these oopses, I guess.

Ronald can you also dd off sda6 & send it my way?  thanks.

-Eric

For the record, I've modified anaconda so filesystem modules are only loaded on an as-needed basis.  So if you don't provide the special parameter and don't have any btrfs filesystems laying around, you should never get the module loaded and therefore shouldn't run into this problem.