This could be a follow-up of this thread:
http://www.linuxquestions.org/questi...le-4175552433/

Test made with an ISO built from Slackware64-current as of Thu Mar 3 20:05:41 UTC 2016.

When trying to use a partition that already contains a file system as target, if btrfs is chosen to format it this fails with an error message from mkfs.btrfs like e.g.
"/dev/sda2 appears to contain an existing file system (ext4)
use the -f option to force overwrite".

Easy fix:
sed -i "s/mkfs.btrfs/mkfs.btrfs -f/" /usr/lib/setup/SeTpartitions

With the fix applied blkid confirms that the partition contains a btrfs file system.

I assume that if the user wants to format to btrfs another partition (for /home, for instance) the -f option is still needed.

However lilo fails when / contains a btrfs file system, but that's a known issue and not the point here.

When I installed 14.2-beta to btrfs I had to precreate a btrfs partition using mkfs.btrfs prior to launching the installer. When I tried using the installer, formatting to btrfs only ended up with an existing ext4 or jfs file system being left as-is from a previous format, even after destroying the table with gdisk, all it would format under is ext4, even with the table cleared. Not certain if related...

The latest kernels allows for better accessibility of the /dev mountpoint for devtmpfs with Grub, so the legacy detection method proposed in a patch from Debian I submitted for usage with gpt partitions and btrfs as /(root) is unnecessary, for now hopefully.

Formatting with btrfs as /(root) with a separate /boot partition with a standard msdos partition table with fdisk does work, gpt does not however, even with a bios boot partition. If you use gpt and btrfs as /(root), you will need syslinux or grub.

Probably. A quick look to the logs of the installer (Alt+F4) would have told you.

PS I don't quite get you. If by 'the table has been cleared" you mean "no partition left" how could the installer work? It needs at least one partition of type Linux[1] as target for installation.

As written in my previous post that's a known issue. But without a separate partition for /boot it's easy to install grub just after installation and before rebooting: just insure that the root partition be still mounted as /mnt or mount it again, bind mount /dev, /sys and /proc, chroot /mnt and install grub, then reboot.

[1]It could use a partition of type "Microsft basic data" (at least to put an ext4 file system in it, I must admit that I didn't check if it's also possible to equip this type of partition with another Linux file system) but doesn't work that way as is.

When I recreated the table and used an 8300 type Linux partition, a freshly made one, selecting btrfs only used ext4. If I didn't destroy the table and only recreated a partition it would not reformat but would leave the existing ext4, jfs, or other existing partition as-is.

I kinda thought that would have been picked up without being said directly.

Would that had been crystal clear in my small mind I wouldn't have requested you to elaborate, sorry if that bothered you.

Now I made some more tests and here are my findings.

Even if you really wipe out the GUID partition table and blank out the master boot record with gdisk (typing x to switch to the expert menu then z for zap), you do not destroy the file system: for instance blkid still reports the type "ext4". When I recreate a partition table with gdisk (still using the whole device), blkid still reports ext4. and when running setup at the TARGET step, so does mkfs.btrfs.

So, I didn't find a way to reuse a device with a wiped then recreated partition table that has contained a file system to put a btrfs file system in it unless using the -f option of mkfs.btrfs.

It could probably be done zeroing the whole device's content with dd, but I guess that most users would not want to do that.

1 members found this post helpful.

I'm a bit surprised that option -f isn't used either by default, or via an optional dialog output that tries to run mkfs.btrfs, for example, fails, returns with information of an existing file system, then asks a yes/no if you want to destroy the file system and rebuilt it with the -f option.

Has this always been the behavior of mkfs.btrfs, because I don't remember it being this problematic.

Fixed in Current since Thu Mar 10 23:43:47 UTC 2016.

I mark this thread as [SOLVED]