On Apr 24, 2014, at 5:07 PM, Marc MERLIN <marc@xxxxxxxxxxx> wrote: > > > In 3.14 the device shows up before btrfs is loaded: > sd 2:0:0:0: [sda] Cache data unavailable > sd 2:0:0:0: [sda] Assuming drive cache: write through > sd 2:0:0:0: [sda] Attached SCSI disk > (...) > Btrfs loaded Same for me though, and I can boot. [ 0.693215] ata1.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133 [ 0.693799] ata1.00: 167772160 sectors, multi 128: LBA48 NCQ (depth 31/32) [ 0.694153] ata1.00: configured for UDMA/133 [ 0.695475] scsi 0:0:0:0: Direct-Access ATA VBOX HARDDISK 1.0 PQ: 0 ANSI: 5 [ 0.699386] sd 0:0:0:0: [sda] 167772160 512-byte logical blocks: (85.8 GB/80.0 GiB) [ 0.699443] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 0.700604] sd 0:0:0:0: [sda] Write Protect is off [ 0.701151] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 0.701187] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 0.707841] sda: sda1 sda2 sda3 [ 0.709846] sd 0:0:0:0: [sda] Attached SCSI disk (…) [ 2.380090] bio: create slab <bio-1> at 1 [ 2.384645] Btrfs loaded So I don't think the order is it. The biggest difference I'm seeing between the 3.13.11 and 3.14.1 dmesg's provided: 3.13.11: [ 1.861740] bio: create slab <bio-1> at 1 [ 1.863389] Btrfs loaded 3.14.1: [ 3.949312] bio: create slab <bio-1> at 1 [ 3.950942] Btrfs loaded It's happening much later, and it's right at this point VFS complains: [ 4.182603] VFS: Cannot open root device "sda2" or unknown-block(8,2): error -38 The 8,2 message is consistent with the kernel not knowing what file system sda2 is. Seems like it's saying "I see sda2, I know you want to use it as root, but I don't know what's there - *poof*" and it panics. If rootwait alone doesn't work, I wonder if root=uuid=2ba08fbc-4b95-46cc-b638-299f16462620 instead of root=/dev/sda2 will work along with rootwait. It should then wait for that fs uuid to become available, rather than waiting for sda2 to become available. I vaguely recall there recently being btrfs boot problems with the module compiled in… Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
