On Mon, Feb 1, 2016 at 2:31 PM, Hendrik Friedel <hend...@friedels.name> wrote: > Hello, > > I am running CentOS from a btrfs root. > This worked fine until I added a device to that pool: > btrfs device add /dev/sda3 / > reboot > > This now causes the errors: > BTRFS: failed to read chunk tree on sdb3 > BTRFS: open_ctree failed > > Here I am stuck in a recovery prompt. > > btrfs fi show displays the file system correctly with 2.1GiB used for sdb3 > and 0.00GiB used on sda3 > > btrfs-tools version reports > btrfs-progs v4.3.1 > > Now, I read that in case of this issue, should add the second device of the > pool to the commandline argument of the kernel/the boot options/grub.cfg > > But I am not sure how to do this. > I can mount /boot/ and the /boot/grub2/grub.cfg contains: > insmod ext2 (but not btrfs!)
That's a bit weird. This is BIOS or UEFI system? On UEFI, the prebaked grubx64.efi includes btrfs, so insmod isn't strictly needed. But on BIOS it would be. I wonder if possibly this is malformed due to some confusion on GRUBs part when it finds a multiple device btrfs volume? But anyway, it might not be related since it sounds like the bootloader found the kernel and the initramfs, and what's happening is it's breaking in the initramfs. It might be as simple as manually mounting: btrfs dev scan btrfs fi show ## hopefully both devices are now associated with the volume mount /dev/sdXY /sysroot exit If it mounts, you can exit to continue the startup process. And then: dracut -f That'll rebuild the initramfs. > set root='hd0,msdos1' > search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 > --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1' > 4a470ac6-f013-4e7b-a4f3-3a58cc4debc3 > > after removing sda3 from the pool again, the system boots normally. That's unexpected. Both devices should now refer to each other, so either device missing should fail, it's effectively raid0 except on a chunk level. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
