[Bug 1383948] Re: Ubiquity Installer doesn't recognize existing btrfs partitions

Fri Oct 31 14:05:16 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/31/2014 12:00 AM, Damiön la Bagh wrote:
> The 1st 15 mintues of this presentation by the SUN engineers who 
> wrote ZFS explains the design philosophy behind partitionless 
> systems (BTRFS/ZFS). If you can find 15 minutes I highly recommend 
> watching.

Again, there is nothing inherently "partitionless" about btrfs or zfs.
You can go without partitions with any filesystem, and no filesystem
gets any benefit from not having a partition table.

> (other filesystems) The whole point when choosing BTRFS on a setup 
> is to not use any other file systems. BTRFS/ZFS were designed to 
> replace all other partitions+filesystems+LVM+RAID schemes (see the 
> video)

No, the idea is to replace lvm and raid layers for dividing up and
adding redundancy to storage spaces.  In other words, you used to
partition a disk into different pieces for different parts of the
filesystem, like / and /home, even when they each used the same
filesystem type, and you don't want or need to do this with btrfs.

A single btrfs partition per disk is not the same thing as not having
any partition table at all; do not confuse the two.

> (coding in small spaces) The first 64Kib only needs to point to 
> /@/boot how much code do you really need for a pointer? note: @ 
> refers to the root subvolume that Ubuntu creates automatically on
> an btrfs install.

There is no "only points to".  That 64k has to have all of the code
needed for the grub core, the disk driver, and the btrfs filesystem
code, which has to be capable of understanding any btrfs filesystem and
locating any file on it.  That's a LOT of code for such a complex
filesystem.

> (UEFI FAT) They didn't need to change MBR they just needed to
> change it to a pointer to a place in an existing filesystem (like
> the way btrfs works)

I think you are confused here again.  There are no "pointers".  In
btrfs, they simply leave the first 64k of the disk untouched so that a
boot loader can put itself in the place the pc bios normally loads it
from.  Blindly loading the first sector of a disk was one of the major
design flaws of the pc bios and the reason uefi switched to having an
actual filesystem on the disk that the firmware understands and can
locate and load files ( that identify which architecture they are for so
the correct one can be loaded ) from.  The MBR -> GPT switch is really
just an added bonus that you may as well take advantage of at the same
time you switch to UEFI, but it is actually possible to just use MBR and
define an EFI system partition with that.

> I checked both my desktop and laptop BTRFS boot drives and they
> both show 0x000: EB 63 90  in the very first sector. So I am
> guessing the EB 63 90 represents BTRFS's boot pointer area.

Again, there is no pointer.  The first 440 bytes of the mbr/boot sector
are executable 16 bit 8086 code.  The first instruction of which is
usually a jump instruction.  EB 63 90 decodes to JMP 0165.  You are
looking at the first instruction of grub.  The grub code goes on to read
the rest of itself from that first 64k, then on to opening the
filesystem, loading modules, the config file, etc.

> (wipe btrfs boot sector) I'll try your experiment in a VM tomorrow
>  (am on nightshift now and want to have my mind clear and focused 
> when I'm wiping sectors) This did spark me to do some more
> research. Apparently there is a utility to remove ZFS/BTRFS from a
> physical disk that is prefered over dd and doesn't have to destroy
> all of your data. wipefs. 
> https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#How_to_clean_up_old_superblock_.3F

wipefs
> 
is for removing signatures of any kind of filesystem, partition
table, raid, etc.  This will remove the actual btrfs superblock ( at
offset 64k ), not the grub boot sector, so you don't want to do that.
 The idea is to leave your filesystem intact, and just remove the grub
boot sector.

> Thank you from the bottom of my heart! Your software has helped me
>  and my colleagues in numerous ways over the years. Thank you for 
> making something so robust and easy to use.  I've made donations to
>  the gParted project in the past, I'd like to make another
> donation, is there a page for parted separately or are gParted and
> parted developed together?

Well, I'm not the one guy who wrote parted; just the current
maintainer.  I have done quite a bit of work improving it ( and some
on gparted ) these last two years.  parted itself does not have any
sort of donation setup, but it is a GNU project so you could donate to
GNU.  gparted is a separate project that uses the libparted library.
There is a bit of cross pollination though as I have contributed
plenty of patches to gparted, and Mike Fleetwood, who is one of the
major gparted developers, recently contributed a patch to fix a bug in
parted.

> (parted feature req) where is the best place to add feature
> requests for parted? I've been secretly hoping that parted would
> one day shdisplay LVM volume groups and logical volumes, and would
> display BTRFS/ZFS subvolumes in a similar fashion to how MSDOS
> extended partitions are currently shown.

I've had a similar thought but decided it simply isn't workable within
the current framework.  The whole system assumes it is dealing with
contiguous slices of a single drive.  Dealing with non contiguous
slices that can span multiple drives gets real hairy real fast, and
you can't really represent it in a sensible way.  For instance, you
may have two btrfs subvolumes.  The first subvolume may occupy bytes
1-a, then b-c.  In between a and b may be used by a second subvolume.
 In fact, parts of the a-b range may be *shared* between the two
subvolumes, so how do you show that?  What if you have a dozen
snapshots?  90% of their space is shared, but each one has 5% unique
to itself.  It really just gets impossible to visualize.

There was a btrfs-gui tool posted a few years back to the mailing list
that let you visualize just the chunk map: a-b space on disk one is
linear, b-c on disk one and d-e on disk two are a mirror, and so on.
Even that granularity was somewhat complicated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUU5cbAAoJEI5FoCIzSKrwlAQIAJCbv7w63P52ecqASEjSY/SL
lDDMw7Xwr+nepJxpLbG11Q01bAk6hZR1KhTYySwXPHs+PoXzWRZD2CJ3SkAAXXdg
AuG8I5DD+KPyhZE2sSYZdOhfuEzinonSik2MXiQgelQxDNvo1YvzG/Iabdsmd8Y0
jsVQbeb4is7uPOvdrJpC/oVt0xBf6bNQ5OWcNC2FojPHhu1MM8es7/d3xORy7gPh
u5nIX5JnMSI4NyQtnN9ZX2w6LyrN1YbugeFASznqg9zdhnn0JtOP94bPTZhygTmn
0ZtMDaVqwlQCViMZJ3q7I/btRmHuBk7COy0PcWmCEz1sWA2diKVOrA08G5kU6p0=
=Yw2M
-----END PGP SIGNATURE-----

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to parted in Ubuntu.
https://bugs.launchpad.net/bugs/1383948

Title:
  Ubiquity Installer doesn't recognize existing btrfs partitions

Status in “parted” package in Ubuntu:
  In Progress

Bug description:
  Steps to reproduce the bug:
  On a machine with an existing raw btrfs partition (no partition table, just raw btrfs to disk as btrfs is intended to be used)
  (created with sudo mkfs.btrfs /dev/sdc)
  From the 14.04.1 LTS live USB
  open a terminal
  scan for btrfs partitions using:
    sudo btrfs device scan
  then view the partition and data usage with
    sudo btrfs filesystem show
  The device is shown
  Label: none  uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxx
  	Total devices 1 FS bytes used 37.71GiB
  	devid    2 size 223.57GiB used 40.03GiB path /dev/sdc
  Start the Ubuntu Ubiquity Installer by clicking on the icon in the launcher
  Choose Download Updates and install Fluendo then
  Next
  Then choose Do Something Else, Choose partitions manually
  Scroll down to /dev/sdc
  The Ubiquity Partition manager doesn't recognize the btrfs disk/volume and just says free-space (see screenshot with proof)

  What should happen:
  At the partition screen it should recgonize my existing btrfs volume and let me reinstall without formating the btrfs volume

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1383948/+subscriptions