And now I was able to reproduce on a second machine. The main
difference between the affected and the unaffected systems is
initramfs. On the affected systems, I don't use one.
In this test of with or without initramfs script. I guess the kernel
remain same at 3.17-rc3 and above
On the working
systems, the rootfs is mounted via initramfs before. I'll test, if an
initramfs will solve the issue. Seems likely, cause if I put the disk
of an affected system into a working system and mount it there,
everything works.
Of course, with the initramfs it works. Content of the init-script:
#!/bin/sh
mount -t devtmpfs devtmpfs /dev
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t tmpfs tmpfs /run
sleep 3 # wait for kernel msgs to quiet
echo "loading initrd"
btrfs dev scan
sleep 5
mount -o ro,subvol=rootfs,inode_cache,autodefrag /dev/sda1 /newroot
this will work since the device path that we provide here
is already the device path which probably will be the final
device path after bootup.
Thanks
if [[ -x /newroot/sbin/init ]]; then
umount /sys /proc
exec switch_root /newroot /sbin/init
fi
#rescue shell
exec sh
--
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
