Created attachment 683291 [details] anaconda-tb Description of problem: F18 Release crashes during installation if one makes an lvm setup for the first disk and tries to use the remaining disks for a btrfs /home. Anaconda accepts the storage configuration but the installation crashes before starting the package installation. Version-Release number of selected component (if applicable): F18 Release How reproducible: always Steps to Reproduce: 0. Boot without kernel parameters, 1 big disk and several other small disks (1.2gb) 1. Go to manual partitioning 2. Create first a /boot as standard partition (to avoid effects of bz:892388) 3. Create a /. It cannot be set to use vda. 4. Change it to standard partition and then constrain it to vda 5. Do the same for swap, make sure that the first disk is consumed and all its partitions are constrained to vda. 6. Now, create a btrfs /home and constrain it to the remaining disks. 7. Finish Partitioning and Start Installation. It will crash in a moment. Actual results: Crash, ABRT makes it a DUP of 870586 (which is closed a long ago) and stops there. Expected results: No crash, or at least the rejection of the storage configuration. Take note of this usage for the next fedora version. Additional info: anaconda 18.37.11 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 786, in create raise DeviceCreateError(str(e), self.name) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/deviceaction.py", line 241, in execute self.device.create() File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 323, in processActions action.execute() File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 323, in doIt self.devicetree.processActions() File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 174, in turnOnFilesystems storage.doIt() File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 114, in doInstall turnOnFilesystems(storage) File "/usr/lib64/python2.7/threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 91, in run threading.Thread.run(self, *args, **kwargs) DeviceCreateError: ("mount failed: (32, 'mount: wrong fs type, bad option, bad superblock on /dev/vdb1,\\n missing codepage or helper program, or other error\\n In some cases useful info is found in syslog - try\\n dmesg | tail or so')", 'home') Local variables in innermost frame: self: non-existent 3000MB btrfs subvolume home (53) with non-existent btrfs filesystem mounted at /home e: mount failed: (32, 'mount: wrong fs type, bad option, bad superblock on /dev/vdb1,\n missing codepage or helper program, or other error\n In some cases useful info is found in syslog - try\n dmesg | tail or so')
Created attachment 683292 [details] anaconda.log
Created attachment 683293 [details] program.log
Created attachment 683294 [details] storage.log
Created attachment 683295 [details] packaging.log
From program.log 18:49:10,246 INFO program: Running... udevadm settle --timeout=300 18:49:10,280 INFO program: Running... udevadm settle --timeout=300 18:49:10,317 INFO program: Running... mkfs.btrfs --data=single --label=fedora /dev/vdb1 /dev/vdc1 /dev/vdd1 /dev/vde1 18:49:10,742 INFO program: 18:49:10,746 INFO program: WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL 18:49:10,746 INFO program: WARNING! - see http://btrfs.wiki.kernel.org before using 18:49:10,748 INFO program: 18:49:10,749 INFO program: SMALL VOLUME: forcing mixed metadata/data groups 18:49:10,750 INFO program: Created a data/metadata chunk of size 8388608 18:49:10,750 INFO program: adding device /dev/vdc1 id 2 18:49:10,751 INFO program: adding device /dev/vdd1 id 3 18:49:10,752 INFO program: adding device /dev/vde1 id 4 18:49:10,752 INFO program: fs created label fedora on /dev/vdb1 18:49:10,753 INFO program: nodesize 4096 leafsize 4096 sectorsize 4096 size 2.93GB 18:49:10,754 INFO program: Btrfs Btrfs v0.19 18:49:10,987 INFO program: Running... udevadm settle --timeout=300 18:49:11,007 INFO program: Running... udevadm settle --timeout=300 18:49:11,036 INFO program: Running... udevadm settle --timeout=300 18:49:11,070 INFO program: Running... udevadm settle --timeout=300 21:49:11,121 INFO program: Running... /bin/mount -n -t btrfs -o defaults /dev/vdb1 /tmp/btrfs-tmp.5205bBZQ 21:49:11,135 ERR program: mount: wrong fs type, bad option, bad superblock on /dev/vdb1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so
Created attachment 683322 [details] syslog file 21:49:10,371 INFO kernel:[ 435.624404] device label fedora devid 1 transid 3 /dev/vdb1 21:49:10,371 INFO kernel:[ 435.624720] device label fedora devid 1 transid 3 /dev/vdb1 21:49:10,385 INFO kernel:[ 435.638653] device label fedora devid 1 transid 3 /dev/vdb1 21:49:10,396 INFO kernel:[ 435.649839] device label fedora devid 2 transid 3 /dev/vdc1 21:49:10,404 INFO kernel:[ 435.657442] device label fedora devid 3 transid 3 /dev/vdd1 21:49:10,434 INFO kernel:[ 435.687677] device label fedora devid 4 transid 3 /dev/vde1 21:49:10,746 INFO kernel:[ 435.999309] device label fedora devid 1 transid 4 /dev/vdb1 21:49:10,918 INFO kernel:[ 436.171992] device label fedora devid 3 transid 4 /dev/vdd1 21:49:10,925 INFO kernel:[ 436.178937] device label fedora devid 3 transid 4 /dev/vdd1 21:49:10,928 INFO kernel:[ 436.181545] device label fedora devid 4 transid 4 /dev/vde1 21:49:10,929 INFO kernel:[ 436.182475] device label fedora devid 1 transid 4 /dev/vdc1 21:49:10,930 INFO kernel:[ 436.183409] device label fedora devid 4 transid 4 /dev/vde1 21:49:10,932 INFO kernel:[ 436.185171] device label fedora devid 1 transid 4 /dev/vdc1 21:49:10,971 INFO kernel:[ 436.224843] device label fedora devid 1 transid 4 /dev/vdb1 21:49:11,130 INFO kernel:[ 436.383110] device label fedora devid 1 transid 4 /dev/vdb1 21:49:11,133 INFO kernel:[ 436.386297] btrfs: disk space caching is enabled 21:49:11,133 WARNING kernel:[ 436.386697] btrfs: failed to read chunk tree on vde1 21:49:11,134 WARNING kernel:[ 436.387183] btrfs: open_ctree failed
I tried booting anaconda again, going to vt2, doing the mkfs.btrfs again and mounting it manually and i got the same error.
I installed to the first disk only (lvm stetup) and automatic partition. Now let's redo whatever anaconda was doing: # mkfs.btrfs --data=single --label=fedora /dev/vdb1 /dev/vdc1 /dev/vdd1 /dev/vde1 WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using SMALL VOLUME: forcing mixed metadata/data groups Created a data/metadata chunk of size 8388608 adding device /dev/vdc1 id 2 adding device /dev/vdd1 id 3 adding device /dev/vde1 id 4 fs created label fedora on /dev/vdb1 nodesize 4096 leafsize 4096 sectorsize 4096 size 2.93GB Btrfs Btrfs v0.19 Let's check wat it did: # btrfs fi show /dev/vdb1 Btrfs Btrfs v0.19 # btrfs fi show /dev/vdc1 Label: 'fedora' uuid: 6016d0ca-e70e-4106-a350-abc18dba0f30 Total devices 4 FS bytes used 28.00KB devid 4 size 750.00MB used 0.00 path /dev/vde1 devid 3 size 750.00MB used 0.00 path /dev/vdd1 devid 1 size 750.00MB used 12.00MB path /dev/vdc1 *** Some devices missing Btrfs Btrfs v0.19 # btrfs fi show /dev/vdd1 Label: 'fedora' uuid: 6016d0ca-e70e-4106-a350-abc18dba0f30 Total devices 4 FS bytes used 28.00KB devid 4 size 750.00MB used 0.00 path /dev/vde1 devid 3 size 750.00MB used 0.00 path /dev/vdd1 devid 1 size 750.00MB used 12.00MB path /dev/vdc1 *** Some devices missing Btrfs Btrfs v0.19 # btrfs fi show /dev/vde1 Label: 'fedora' uuid: 6016d0ca-e70e-4106-a350-abc18dba0f30 Total devices 4 FS bytes used 28.00KB devid 4 size 750.00MB used 0.00 path /dev/vde1 devid 3 size 750.00MB used 0.00 path /dev/vdd1 devid 1 size 750.00MB used 12.00MB path /dev/vdc1 *** Some devices missing Btrfs Btrfs v0.19 Is really nothing on vdb1? Is it a btrfs issue or an improper usage performed by anaconda (or the user and anaconda failing to reject the storage configuration)? # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/vdb1: LABEL="fedora" UUID="6016d0ca-e70e-4106-a350-abc18dba0f30" UUID_SUB="a712bd5c-7a58-40be-b0cc-4a18fa9c2a59" TYPE="btrfs" /dev/vdc1: LABEL="fedora" UUID="6016d0ca-e70e-4106-a350-abc18dba0f30" UUID_SUB="a712bd5c-7a58-40be-b0cc-4a18fa9c2a59" TYPE="btrfs" /dev/vdd1: LABEL="fedora" UUID="6016d0ca-e70e-4106-a350-abc18dba0f30" UUID_SUB="a5c2b20c-672f-4032-8b52-e30808940836" TYPE="btrfs" /dev/vde1: LABEL="fedora" UUID="6016d0ca-e70e-4106-a350-abc18dba0f30" UUID_SUB="6ab7e024-656d-44e5-8a6a-23272bdd3584" TYPE="btrfs" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" There is something in vdb1...
Let's wipe all btrfs devices: # dd if=/dev/zero of=/dev/vdb bs=40M dd: writing ‘/dev/vdb’: No space left on device 31+0 records in 30+0 records out 1258291200 bytes (1.3 GB) copied, 24.1144 s, 52.2 MB/s # dd if=/dev/zero of=/dev/vdc bs=40M dd: writing ‘/dev/vdc’: No space left on device 31+0 records in 30+0 records out 1258291200 bytes (1.3 GB) copied, 24.1911 s, 52.0 MB/s # dd if=/dev/zero of=/dev/vdd bs=40M dd: writing ‘/dev/vdd’: No space left on device 31+0 records in 30+0 records out 1258291200 bytes (1.3 GB) copied, 26.1067 s, 48.2 MB/s # dd if=/dev/zero of=/dev/vde bs=40M dd: writing ‘/dev/vde’: No space left on device 31+0 records in 30+0 records out 1258291200 bytes (1.3 GB) copied, 25.8176 s, 48.7 MB/s # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" Ok, they are gone. Now, create the btrfs device but with only vdb1 # mkfs.btrfs --data=single --label=fedora1 /dev/vdb1 WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using SMALL VOLUME: forcing mixed metadata/data groups Created a data/metadata chunk of size 8388608 fs created label fedora1 on /dev/vdb1 nodesize 4096 leafsize 4096 sectorsize 4096 size 750.00MB Btrfs Btrfs v0.19 # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/vdb1: LABEL="fedora1" UUID="bbbbf2c3-42e4-4fec-a682-d1dfa0ecd53e" UUID_SUB="9d062cb2-59b2-403c-b7f7-41996842a6a5" TYPE="btrfs" /dev/vdc1: LABEL="fedora1" UUID="bbbbf2c3-42e4-4fec-a682-d1dfa0ecd53e" UUID_SUB="9d062cb2-59b2-403c-b7f7-41996842a6a5" TYPE="btrfs" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" WOW!!! why vdc1 is part of a btrfs filesystem!!! (!) DANGER (!) # btrfs fi show /dev/vdb1 Btrfs Btrfs v0.19 # btrfs fi show /dev/vdc1 Label: 'fedora1' uuid: bbbbf2c3-42e4-4fec-a682-d1dfa0ecd53e Total devices 1 FS bytes used 28.00KB devid 1 size 750.00MB used 12.00MB path /dev/vdc1 Btrfs Btrfs v0.19 I did not specify vdc1 at all, in fact it might contain data... Now, clear the device again: # dd if=/dev/zero of=/dev/vdb bs=40M dd: writing ‘/dev/vdb’: No space left on device 31+0 records in 30+0 records out 1258291200 bytes (1.3 GB) copied, 24.0837 s, 52.2 MB/s # dd if=/dev/zero of=/dev/vdc bs=40M dd: writing ‘/dev/vdc’: No space left on device 31+0 records in 30+0 records out 1258291200 bytes (1.3 GB) copied, 23.876 s, 52.7 MB/s # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" # uname -r 3.6.10-4.fc18.x86_64 I have not yet performed a 'yum update', let's do it now. Done. # uname -r 3.7.2-201.fc18.x86_64 # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" (remove the --data=single) # mkfs.btrfs --label=fedora1 /dev/vdb1 WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using check_mounted(): Could not open /dev/vdb1 error checking /dev/vdb1 mount status Ok, let's create the partition table (using msdos disklabel) # fdisk -l Disk /dev/vda: 15.7 GB, 15728640000 bytes, 30720000 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000c5768 Device Boot Start End Blocks Id System /dev/vda1 * 2048 1026047 512000 83 Linux /dev/vda2 1026048 30719999 14846976 8e Linux LVM Disk /dev/vdb: 1258 MB, 1258291200 bytes, 2457600 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x6462c4de Device Boot Start End Blocks Id System /dev/vdb1 2048 2457599 1227776 83 Linux Disk /dev/vdc: 1258 MB, 1258291200 bytes, 2457600 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x6462c4de Device Boot Start End Blocks Id System /dev/vdc1 2048 2457599 1227776 83 Linux Disk /dev/vdd: 1258 MB, 1258291200 bytes, 2457600 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x21b52274 Device Boot Start End Blocks Id System /dev/vdd1 2048 2457599 1227776 83 Linux Disk /dev/vde: 1258 MB, 1258291200 bytes, 2457600 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x8c6412aa Device Boot Start End Blocks Id System /dev/vde1 2048 2457599 1227776 83 Linux Disk /dev/mapper/fedora-swap: 2113 MB, 2113929216 bytes, 4128768 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/fedora-root: 13.1 GB, 13086228480 bytes, 25559040 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes # mkfs.btrfs --label=fedora1 /dev/vdb1 WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using fs created label fedora1 on /dev/vdb1 nodesize 4096 leafsize 4096 sectorsize 4096 size 1.17GB Btrfs Btrfs v0.19 # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/vdb1: LABEL="fedora1" UUID="bc2c0e9e-b20c-4139-8f16-fbf79fddb3ca" UUID_SUB="08b4b98a-218c-4702-b3f3-a2deee34bf43" TYPE="btrfs" /dev/vdc1: LABEL="fedora1" UUID="bc2c0e9e-b20c-4139-8f16-fbf79fddb3ca" UUID_SUB="08b4b98a-218c-4702-b3f3-a2deee34bf43" TYPE="btrfs" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" It still takes vdc1 without authorization... Let's try the "last" device and what does mkfs.btrfs does in such case... # mkfs.btrfs --label=fedora2 /dev/vde1 WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using fs created label fedora2 on /dev/vde1 nodesize 4096 leafsize 4096 sectorsize 4096 size 1.17GB Btrfs Btrfs v0.19 # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/vdb1: LABEL="fedora1" UUID="bc2c0e9e-b20c-4139-8f16-fbf79fddb3ca" UUID_SUB="08b4b98a-218c-4702-b3f3-a2deee34bf43" TYPE="btrfs" /dev/vdc1: LABEL="fedora1" UUID="bc2c0e9e-b20c-4139-8f16-fbf79fddb3ca" UUID_SUB="08b4b98a-218c-4702-b3f3-a2deee34bf43" TYPE="btrfs" /dev/vde1: LABEL="fedora2" UUID="7fc4b2a4-2455-41bb-86ce-db91f9974027" UUID_SUB="a4fdb2d1-fc25-4f8e-b76e-b72fcfdf0a6c" TYPE="btrfs" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" It did what was expected. Now try to mount both "fedora1" and "fedora2" Command: # umount /mnt # mount /dev/vdb1 /mnt/ Messages: Jan 19 21:18:27 localhost kernel: [ 565.235134] device label fedora1 devid 1 transid 4 /dev/vdb1 Jan 19 21:18:27 localhost kernel: [ 565.240628] btrfs: disk space caching is enabled Command: # umount /mnt # mount /dev/vdc1 /mnt/ Messages: Jan 19 21:19:44 localhost kernel: [ 642.320863] device label fedora1 devid 1 transid 6 /dev/vdc1 Jan 19 21:19:44 localhost kernel: [ 642.323508] btrfs: disk space caching is enabled Command: # umount /mnt # mount /dev/vde1 /mnt/ Messages: Jan 19 21:20:37 localhost kernel: [ 695.746348] device label fedora2 devid 1 transid 4 /dev/vde1 Jan 19 21:20:37 localhost kernel: [ 695.749254] btrfs: disk space caching is enabled So, feodora1 is using both vdb1 and vdc1. # btrfs fi show /dev/vdb1 Btrfs Btrfs v0.19 # btrfs fi show /dev/vdc1 Label: 'fedora1' uuid: bc2c0e9e-b20c-4139-8f16-fbf79fddb3ca Total devices 1 FS bytes used 28.00KB devid 1 size 1.17GB used 155.88MB path /dev/vdc1 Btrfs Btrfs v0.19 # btrfs fi show /dev/vde1 Label: 'fedora2' uuid: 7fc4b2a4-2455-41bb-86ce-db91f9974027 Total devices 1 FS bytes used 28.00KB devid 1 size 1.17GB used 155.88MB path /dev/vde1 Btrfs Btrfs v0.19
Erase all btrfs stuff from disks again: # dd if=/dev/zero of=/dev/vdb1 bs=40M dd: writing ‘/dev/vdb1’: No space left on device 30+0 records in 29+0 records out 1257242624 bytes (1.3 GB) copied, 24.3492 s, 51.6 MB/s # dd if=/dev/zero of=/dev/vdc1 bs=40M dd: writing ‘/dev/vdc1’: No space left on device 30+0 records in 29+0 records out 1257242624 bytes (1.3 GB) copied, 23.9371 s, 52.5 MB/s # dd if=/dev/zero of=/dev/vde1 bs=40M dd: writing ‘/dev/vde1’: No space left on device 30+0 records in 29+0 records out 1257242624 bytes (1.3 GB) copied, 24.5898 s, 51.1 MB/s # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" Now, create an ext4 fs on vdc1 and mount it on /mnt/ext # mkfs.ext4 -L extfs /dev/vdc1 mke2fs 1.42.5 (29-Jul-2012) Filesystem label=extfs OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 76800 inodes, 306944 blocks 15347 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=314572800 10 block groups 32768 blocks per group, 32768 fragments per group 7680 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912 Allocating group tables: done Writing inode tables: done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/vdb1: LABEL="extfs" UUID="2e75a09a-58bc-46c3-b69d-15cbb8c004f9" TYPE="ext4" /dev/vdc1: LABEL="extfs" UUID="2e75a09a-58bc-46c3-b69d-15cbb8c004f9" TYPE="ext4" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" WOW! It is not btrfs specific at all!!! Both vdb1 and vdc1 are "extfs". Let's see which one mounts ok... # mount /dev/vdc1 /mnt/ext # mount /dev/vdb1 /mnt/ext2 # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 487M 0 487M 0% /dev tmpfs 498M 0 498M 0% /dev/shm tmpfs 498M 1.2M 497M 1% /run tmpfs 498M 0 498M 0% /sys/fs/cgroup /dev/mapper/fedora-root 12G 1.3G 11G 11% / tmpfs 498M 0 498M 0% /tmp /dev/vda1 485M 74M 386M 17% /boot /dev/vdc1 1.2G 34M 1.1G 4% /mnt/ext /dev/vdb1 1.2G 34M 1.1G 4% /mnt/ext2 (!) (?) What does this suppose to mean? # cp /boot/vmlinuz-3.6.10-4.fc18.x86_64 /mnt/ext # ls -l /mnt/ext total 4768 drwx------. 2 root root 16384 Jan 19 21:32 lost+found -rwxr-xr-x. 1 root root 4862486 Jan 19 21:35 vmlinuz-3.6.10-4.fc18.x86_64 # ls -l /mnt/ext2/ total 16 drwx------. 2 root root 16384 Jan 19 21:32 lost+found # df -k Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 498600 0 498600 0% /dev tmpfs 509824 0 509824 0% /dev/shm tmpfs 509824 1132 508692 1% /run tmpfs 509824 0 509824 0% /sys/fs/cgroup /dev/mapper/fedora-root 12578736 1275504 10664256 11% / tmpfs 509824 0 509824 0% /tmp /dev/vda1 495844 75534 394710 17% /boot /dev/vdc1 1208448 39336 1107724 4% /mnt/ext /dev/vdb1 1208448 34568 1112492 4% /mnt/ext2 It appears that there are two different filesystems both with the same UUID and LABEL.... # mount proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel) devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=498600k,nr_inodes=124650,mode=755) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,seclabel,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) /dev/mapper/fedora-root on / type ext4 (rw,relatime,seclabel,data=ordered) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) debugfs on /sys/kernel/debug type debugfs (rw,relatime) configfs on /sys/kernel/config type configfs (rw,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel) mqueue on /dev/mqueue type mqueue (rw,relatime,seclabel) tmpfs on /tmp type tmpfs (rw,seclabel) /dev/vda1 on /boot type ext4 (rw,relatime,seclabel,data=ordered) /dev/vdc1 on /mnt/ext type ext4 (rw,relatime,seclabel,data=ordered) /dev/vdb1 on /mnt/ext2 type ext4 (rw,relatime,seclabel,data=ordered) In the messages: Jan 19 21:34:15 localhost kernel: [ 1513.267306] EXT4-fs (vdc1): mounted filesystem with ordered data mode. Opts: (null) Jan 19 21:34:19 localhost kernel: [ 1517.858626] EXT4-fs (vdb1): recovery complete Jan 19 21:34:19 localhost kernel: [ 1517.858641] EXT4-fs (vdb1): mounted filesystem with ordered data mode. Opts: (null) It appears that effectively there are two filesystems. # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/vdb1: LABEL="extfs" UUID="2e75a09a-58bc-46c3-b69d-15cbb8c004f9" TYPE="ext4" /dev/vdc1: LABEL="extfs" UUID="2e75a09a-58bc-46c3-b69d-15cbb8c004f9" TYPE="ext4" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" [root@localhost ~]# df -k Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 498600 0 498600 0% /dev tmpfs 509824 0 509824 0% /dev/shm tmpfs 509824 1152 508672 1% /run tmpfs 509824 0 509824 0% /sys/fs/cgroup /dev/mapper/fedora-root 12578736 1276624 10663136 11% / tmpfs 509824 0 509824 0% /tmp /dev/vda1 495844 75534 394710 17% /boot /dev/vdc1 1208448 39336 1107724 4% /mnt/ext So, vdc1 is mounted and has an ext4, now retry to see if it ovewrites it. # mkfs.btrfs --label=fedora1 /dev/vdb1 WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using fs created label fedora1 on /dev/vdb1 nodesize 4096 leafsize 4096 sectorsize 4096 size 1.17GB Btrfs Btrfs v0.19 # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/vdb1: LABEL="fedora1" UUID="62e993b3-49e4-456d-8e52-4c90ff3865c4" UUID_SUB="1df7385f-afed-402c-b1bb-c3736ef79fa2" TYPE="btrfs" /dev/vdc1: LABEL="extfs" UUID="2e75a09a-58bc-46c3-b69d-15cbb8c004f9" TYPE="ext4" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" So, vdc1 survived, but was it because it was mounted? # umount /mnt/ext [root@localhost ~]# mkfs.btrfs --label=fedora1 /dev/vdb1 WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using fs created label fedora1 on /dev/vdb1 nodesize 4096 leafsize 4096 sectorsize 4096 size 1.17GB Btrfs Btrfs v0.19 # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/vdb1: LABEL="fedora1" UUID="6982f993-eb39-478f-bbd7-26e26365d4c6" UUID_SUB="3c4c1a58-b300-4206-a074-e774f8cae866" TYPE="btrfs" /dev/vdc1: LABEL="fedora1" UUID="6982f993-eb39-478f-bbd7-26e26365d4c6" UUID_SUB="3c4c1a58-b300-4206-a074-e774f8cae866" TYPE="btrfs" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" Yes, if the filesystem is mounted, it appears "protected". If the filesystem is not mounted, it can be wiped. Messages: Jan 19 21:44:39 localhost kernel: [ 2137.114401] device label fedora1 devid 1 transid 3 /dev/vdb1 Jan 19 21:44:39 localhost kernel: [ 2137.281862] device label fedora1 devid 1 transid 4 /dev/vdb1 Jan 19 21:46:31 localhost kernel: [ 2249.467321] EXT4-fs error (device vdc1): ext4_mb_generate_buddy:742: group 1, 32768 clusters in bitmap, 32692 in gd Jan 19 21:46:37 localhost kernel: [ 2255.167820] device label fedora1 devid 1 transid 3 /dev/vdb1 Jan 19 21:46:37 localhost kernel: [ 2255.170335] device label fedora1 devid 1 transid 4 /dev/vdb1 Jan 19 21:46:37 localhost kernel: [ 2255.333893] device label fedora1 devid 1 transid 4 /dev/vdb1 There is something very wrong going on.... Wipe everything. # dd if=/dev/zero of=/dev/vdb1 bs=40M dd: writing ‘/dev/vdb1’: No space left on device 30+0 records in 29+0 records out 1257242624 bytes (1.3 GB) copied, 24.0822 s, 52.2 MB/s # dd if=/dev/zero of=/dev/vdc1 bs=40M dd: writing ‘/dev/vdc1’: No space left on device 30+0 records in 29+0 records out 1257242624 bytes (1.3 GB) copied, 24.0534 s, 52.3 MB/s # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" Do a sanitary reboot. # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" Test reiserfs too: # mkreiserfs -l reiser1 /dev/vdd1 mkreiserfs 3.6.21 (2009 www.namesys.com) A pair of credits: Oleg Drokin was the debugger for V3 during most of the time that V4 was under development, and was quite skilled and fast at it. He wrote the large write optimization of V3. Vladimir Saveliev started as the most junior programmer on the team, and became the lead programmer. He is now an experienced highly productive programmer. He wrote the extent handling code for Reiser4, plus parts of the balancing code and file write and file read. Guessing about desired format.. Kernel 3.7.2-201.fc18.x86_64 is running. Format 3.6 with standard journal Count of blocks on the device: 306944 Number of blocks consumed by mkreiserfs formatting process: 8221 Blocksize: 4096 Hash function used to sort names: "r5" Journal Size 8193 blocks (first block 18) Journal Max transaction length 1024 inode generation number: 0 UUID: 7f8a5ccd-b008-4612-82f9-a5d80e9df4cf LABEL: reiser1 ATTENTION: YOU SHOULD REBOOT AFTER FDISK! ALL DATA WILL BE LOST ON '/dev/vdd1'! Continue (y/n):y Initializing journal - 0%....20%....40%....60%....80%....100% Syncing..ok ReiserFS is successfully created on /dev/vdd1. [root@localhost ~]# blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/vdd1: LABEL="reiser1" UUID="7f8a5ccd-b008-4612-82f9-a5d80e9df4cf" TYPE="reiserfs" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" # dd if=/dev/zero of=/dev/vdd1 bs=40M dd: writing ‘/dev/vdd1’: No space left on device 30+0 records in 29+0 records out 1257242624 bytes (1.3 GB) copied, 23.9643 s, 52.5 MB/s # dd if=/dev/zero of=/dev/vdd1 bs=40M dd: writing ‘/dev/vdd1’: No space left on device 30+0 records in 29+0 records out 1257242624 bytes (1.3 GB) copied, 23.9643 s, 52.5 MB/s # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" # mkreiserfs -l reiser2 /dev/vdb1 mkreiserfs 3.6.21 (2009 www.namesys.com) A pair of credits: Many persons came to www.namesys.com/support.html, and got a question answered for $25, or just gave us a small donation there. Vitaly Fertman wrote fsck for V3 and maintains the reiserfsprogs package now. He wrote librepair, userspace plugins repair code, fsck for V4, and worked on developing libreiser4 and userspace plugins with Umka. Guessing about desired format.. Kernel 3.7.2-201.fc18.x86_64 is running. Format 3.6 with standard journal Count of blocks on the device: 306944 Number of blocks consumed by mkreiserfs formatting process: 8221 Blocksize: 4096 Hash function used to sort names: "r5" Journal Size 8193 blocks (first block 18) Journal Max transaction length 1024 inode generation number: 0 UUID: 03165d80-ef51-404f-b904-e7ecec73267d LABEL: reiser2 ATTENTION: YOU SHOULD REBOOT AFTER FDISK! ALL DATA WILL BE LOST ON '/dev/vdb1'! Continue (y/n):y Initializing journal - 0%....20%....40%....60%....80%....100% Syncing..ok ReiserFS is successfully created on /dev/vdb1. # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/vdb1: LABEL="reiser2" UUID="03165d80-ef51-404f-b904-e7ecec73267d" TYPE="reiserfs" /dev/vdc1: LABEL="reiser2" UUID="03165d80-ef51-404f-b904-e7ecec73267d" TYPE="reiserfs" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" # mount /dev/vdb1 /mnt/reiser-vdb1 # mount /dev/vdc1 /mnt/reiser-vdc1 # cp /boot/vmlinuz-3.6.10-4.fc18.x86_64 /mnt/reiser-vdb1/ # ls -l /mnt/reiser-vdb1 total 4757 -rwxr-xr-x. 1 root root 4862486 Jan 19 22:00 vmlinuz-3.6.10-4.fc18.x86_64 # ls -l /mnt/reiser-vdc1 total 0 # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 487M 0 487M 0% /dev tmpfs 498M 0 498M 0% /dev/shm tmpfs 498M 1.1M 497M 1% /run tmpfs 498M 0 498M 0% /sys/fs/cgroup /dev/mapper/fedora-root 12G 1.3G 11G 11% / tmpfs 498M 0 498M 0% /tmp /dev/vda1 485M 74M 386M 17% /boot /dev/vdb1 1.2G 37M 1.2G 4% /mnt/reiser-vdb1 /dev/vdc1 1.2G 33M 1.2G 3% /mnt/reiser-vdc1 Messages: Jan 19 22:00:00 localhost kernel: [ 348.441560] REISERFS (device vdb1): found reiserfs format "3.6" with standard journal Jan 19 22:00:00 localhost kernel: [ 348.441568] REISERFS (device vdb1): using ordered data mode Jan 19 22:00:00 localhost kernel: [ 348.441569] reiserfs: using flush barriers Jan 19 22:00:00 localhost kernel: [ 348.441798] REISERFS (device vdb1): journal params: device vdb1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Jan 19 22:00:00 localhost kernel: [ 348.442264] REISERFS (device vdb1): checking transaction log (vdb1) Jan 19 22:00:00 localhost kernel: [ 348.571095] REISERFS (device vdb1): Using r5 hash to sort names Jan 19 22:00:00 localhost kernel: [ 348.571297] REISERFS (device vdb1): Created .reiserfs_priv - reserved for xattr storage. Jan 19 22:00:10 localhost kernel: [ 358.209862] REISERFS (device vdc1): found reiserfs format "3.6" with standard journal Jan 19 22:00:10 localhost kernel: [ 358.209889] REISERFS (device vdc1): using ordered data mode Jan 19 22:00:10 localhost kernel: [ 358.209894] reiserfs: using flush barriers Jan 19 22:00:10 localhost kernel: [ 358.211211] REISERFS (device vdc1): journal params: device vdc1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Jan 19 22:00:10 localhost kernel: [ 358.213088] REISERFS (device vdc1): checking transaction log (vdc1) Jan 19 22:00:10 localhost kernel: [ 358.462171] REISERFS (device vdc1): replayed 1 transactions in 0 seconds Jan 19 22:00:10 localhost kernel: [ 358.470521] REISERFS (device vdc1): Using r5 hash to sort names So, it is an AWFULL bug that affects vdb and vdc in particular. Maybe Anaconda just hit it. But which component is the guilty one? It affects btfs, ext4, reiserfs... (i thested only those)
So, in the DESCRIPTION, we have: # fs.btrfs --data=single --label=fedora /dev/vdb1 /dev/vdc1 /dev/vdd1 /dev/vde1 Which leads to Comment #8 The btfs file-system cannot be mounted by vdb1, thus Anaconda will crash. And from Comment #10 Onwards: # mkfs.ext4 -L extfs /dev/vdc1 # mkfs.btrfs --label=fedora1 /dev/vdb1 # mkreiserfs -l reiser2 /dev/vdb1 In these cases, if vdc1 is NOT MOUNTED (at least with mkfs.btrfs), it will be wiped. Both vdb1 and vdc1 will have a file-system with the same LABEL and UUID.
Created attachment 683401 [details] output of 'strace mkfs.ext4 -L extfs /dev/vdc1' ( # dd if=/dev/zero of=/dev/vdb1 bs=40M dd: writing ‘/dev/vdb1’: No space left on device 30+0 records in 29+0 records out 1257242624 bytes (1.3 GB) copied, 24.0066 s, 52.4 MB/s # dd if=/dev/zero of=/dev/vdc1 bs=40M dd: writing ‘/dev/vdc1’: No space left on device 30+0 records in 29+0 records out 1257242624 bytes (1.3 GB) copied, 24.0345 s, 52.3 MB/s # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" # init 6 Do a sanitary reboot. # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" Let's do an strace to # strace mkfs.ext4 -L extfs /dev/vdc1 # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/vdb1: LABEL="extfs" UUID="17d55155-e14e-4ad4-8d61-ab09a60e1df3" TYPE="ext4" /dev/vdc1: LABEL="extfs" UUID="17d55155-e14e-4ad4-8d61-ab09a60e1df3" TYPE="ext4" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" $ grep -i vdc1 strace-mkfs.exr4-vc1.out # strace mkfs.ext4 -L extfs /dev/vdc1 execve("/usr/sbin/mkfs.ext4", ["mkfs.ext4", "-L", "extfs", "/dev/vdc1"], [/* 25 vars */]) = 0 stat("/dev/vdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 33), ...}) = 0 stat("/dev/vdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 33), ...}) = 0 stat("/dev/vdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 33), ...}) = 0 stat("/dev/vdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 33), ...}) = 0 stat("/dev/vdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 33), ...}) = 0 open("/dev/vdc1", O_RDONLY|O_EXCL) = 3 open("/dev/vdc1", O_RDONLY) = 3 open("/dev/vdc1", O_RDONLY) = 3 open("/dev/vdc1", O_RDONLY) = 3 stat("/dev/vdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 33), ...}) = 0 open("/dev/vdc1", O_RDONLY) = 3 open("/dev/vdc1", O_RDONLY|O_EXCL) = 3 stat("/dev/vdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 33), ...}) = 0 open("/dev/vdc1", O_RDWR|O_EXCL) = 3 stat("/dev/vdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(252, 33), ...}) = 0 $ grep -i vdb1 strace-mkfs.exr4-vc1.out But the strace does not mention vdb1 at all....
# blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/vdb1: LABEL="extfs" UUID="17d55155-e14e-4ad4-8d61-ab09a60e1df3" TYPE="ext4" /dev/vdc1: LABEL="extfs" UUID="17d55155-e14e-4ad4-8d61-ab09a60e1df3" TYPE="ext4" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" # mount /dev/vdb1 /mnt/ext-vdb1 # mount /dev/vdc1 /mnt/ext-vdc1 # df -k Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 498600 0 498600 0% /dev tmpfs 509824 0 509824 0% /dev/shm tmpfs 509824 1120 508704 1% /run tmpfs 509824 0 509824 0% /sys/fs/cgroup /dev/mapper/fedora-root 12578736 1277972 10661788 11% / tmpfs 509824 0 509824 0% /tmp /dev/vda1 495844 75534 394710 17% /boot /dev/vdb1 1208448 34568 1112492 4% /mnt/ext-vdb1 /dev/vdc1 1208448 34568 1112492 4% /mnt/ext-vdc1 # tar cf /mnt/ext-vdb1/usr-bkp-1.tar /usr/ tar: Removing leading `/' from member names tar: Removing leading `/' from hard link targets # tar cf /mnt/ext-vdc1/usrbin-bkp-2.tar /usr/bin/ tar: Removing leading `/' from member names tar: Removing leading `/' from hard link targets # ls -l /mnt/ext-vdb1 total 837960 drwx------. 2 root root 16384 Jan 19 22:31 lost+found -rw-r--r--. 1 root root 858050560 Jan 19 22:48 usr-bkp-1.tar # ls -l /mnt/ext-vdc1/ ls: cannot access /mnt/ext-vdc1/usr-bkp-1.tar: Input/output error total 42248 drwx------. 2 root root 16384 Jan 19 22:31 lost+found -rw-r--r--. 1 root root 43243520 Jan 19 23:34 usrbin-bkp-2.tar -?????????? ? ? ? ? ? usr-bkp-1.tar Messages: Jan 19 23:35:04 localhost kernel: [ 3978.179714] EXT4-fs error (device vdc1): ext4_mb_generate_buddy:742: group 1, 1971 clusters in bitmap, 32692 in gd Jan 19 23:35:04 localhost kernel: [ 3978.189646] JBD2: Spotted dirty metadata buffer (dev = vdc1, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Jan 19 23:35:04 localhost kernel: [ 3978.362623] JBD2: Spotted dirty metadata buffer (dev = vdc1, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Jan 19 23:35:16 localhost kernel: [ 3990.866887] EXT4-fs error (device vdc1): ext4_lookup:1383: inode #2: comm ls: deleted inode referenced: 12
I set the guest a hostname to avoid confusion in the future. Also i power-cycled the guest. # hostnamectl Static hostname: fntstx3localdomain Pretty hostname: fntstx3.localdomain Icon name: n/a Machine ID: 6edd621a3d9752943a01ca74f153f539 Boot ID: dd1550ec6f9c477ab55d71f0745176c7 Virtualization: kvm Operating System: Fedora 18 (Spherical Cow) CPE OS Name: cpe:/o:fedoraproject:fedora:18 Kernel: Linux 3.7.2-201.fc18.x86_64 Architecture: x86_64 # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" Now, another test: # sleep 2 && dd if=/dev/zero of=/dev/vdb1 bs=40M dd: writing ‘/dev/vdb1’: No space left on device 30+0 records in 29+0 records out 1257242624 bytes (1.3 GB) copied, 23.8133 s, 52.8 MB/s I switched to vt2 and monitored a iostat, only vdb1 has any activity. (OK) # sleep 2 && dd if=/dev/zero of=/dev/vdc1 bs=40M dd: writing ‘/dev/vdc1’: No space left on device 30+0 records in 29+0 records out 1257242624 bytes (1.3 GB) copied, 24.5227 s, 51.3 MB/s I switched to vt2 and monitored a iostat, only vdc1 has any activity. (OK) # sleep 2 && mkfs.ext4 -L extfs /dev/vdc1 I switched to vt2 and monitored a iostat, only vdc1 seems to have any activity. (It appears to be OK but is BAD!) # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/vdb1: LABEL="extfs" UUID="bebbf26a-790b-424b-abcc-97fdd4b54082" TYPE="ext4" /dev/vdc1: LABEL="extfs" UUID="bebbf26a-790b-424b-abcc-97fdd4b54082" TYPE="ext4" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" # badblocks -w /dev/vdb1 # blkid -c /dev/null /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/vda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" Humm, collateral-io to vdc1 if one targets vdb1 (at least in this case) I power off the guest and changed all disks from VIRTIO to SATA. # blkid -c /dev/null /dev/sda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/sda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" # mkfs.ext4 -L extfs /dev/sdc1 mke2fs 1.42.5 (29-Jul-2012) Filesystem label=extfs OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 76800 inodes, 306944 blocks 15347 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=314572800 10 block groups 32768 blocks per group, 32768 fragments per group 7680 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912 Allocating group tables: done Writing inode tables: done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done # blkid -c /dev/null /dev/sdc1: LABEL="extfs" UUID="7416c985-d79e-405b-9cdc-ce0deb9e4171" TYPE="ext4" /dev/sdb1: LABEL="extfs" UUID="7416c985-d79e-405b-9cdc-ce0deb9e4171" TYPE="ext4" /dev/sda1: UUID="56abde15-029d-484c-a118-c39539bdd864" TYPE="ext4" /dev/sda2: UUID="3UJcny-2SH4-HHmK-9Xao-l75U-vya7-fHP092" TYPE="LVM2_member" /dev/sr0: UUID="2013-01-09-19-59-42-00" LABEL="Fedora 18 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/mapper/fedora-swap: UUID="ae8a77ff-134e-4e43-98ef-f691fa5896bb" TYPE="swap" /dev/mapper/fedora-root: UUID="886601fd-6cc8-41bc-a3b5-b78f9cfb7873" TYPE="ext4" No effect, changing VIRTIO to SATA did not improve things, sdb1 was affected.
Ok, i solved it. For some reason, virt-manager was using the same disk image for two devices, a thing i believed to not to be possible. It normally prints a warning if one tries to but i never saw one when i created the guest, maybe there is a bug in virt-manager that bypasses such message. So, i am obviously closing it at a NOTABUG.