Skip to content

Installing Arch Linux onto a GPT partitioned, btrfs root SSD on a legacy BIOS system

January 20, 2011

Update 10-14-2011: I should add a note that as Arch Linux is rolling release and constantly changing, these instructions are likely out of date. I do not know for sure, as I have not had a need to re-install my machine. As a silver-lining to this though, I can attest that this setup has been quite stable and reliable–even despite a few mistakes with my battery meter…

Update 4-2-2011: I just got through following my own guide to setup my desktop with a btrfs root, and noticed a few things here that needed updating or were wrong, or missing, and such. This should be more accurate now.

I was recently gifted with a 40GB Intel X25-V SSD (one of those things I really wanted, but wouldn’t buy for myself) and after sitting on it for a month, pouring over blogs and wiki articles about SSD’s, trying to determine how I wanted to set it up, I finally got around to it over the past few days. My two main sources of info are the very informative Arch Linux wiki page on SSD optimizations, along with a blog post on GPT booting. I also referenced this wiki page, but ended up doing some things differently. I decided I wanted to partition it with GPT, and use btrfs as the main filesystem, despite it’s “unstable” status. I wanted GPT because it’s more “modern” than the legacy MBR scheme, but mostly I went with it because it was the default mode for gdisk, which also aligned my partitions to that magic multiple of 1MB. (I realize fdisk can do this, but didn’t want to deal with wacky sector math :P) I wanted btrfs because it too was more “modern.” What really grabbed me, and ultimately made me switch to using it in place of ext4, was the subvolume feature. Instead of separate partitions for major directories, I could use subvolumes with disk quotas. This would allow me to just let btrfs consume the whole disk, and let the filesystem and SSD handle the rest (mostly because I have no clue how the SSD wear protection routines handles multiple partitions, I decided to take them out of the equation :P) This setup does present a few problems, namely that GPT partitions need a protective MBR workaround to boot from legacy BIOS based computers–which describes every computer I own. Legacy Grub (the Arch Linux default) doesn’t support booting from GPT in this manner, and on top of that, only syslinux supports booting from a btrfs filesystem. Even then, it cannot handle subvolumes very well. Luckily, my setup didn’t need the more interesting uses of subvolumes/snapshots.


If you’re doing this from the Arch Linux install disk like me, don’t forget to setup up your network (partial-configure-network) and uncomment a mirror in /etc/pacman.d/mirrorlist. You may also want to set the clock and proper timezone to be sure the dates are accurate.

Preparing the Disk

Make sure gptfdisk and btrfs-progs are installed (note, gptfdisk used to be called gdisk)

# pacman -Sy gptfdisk btrfs-progs-unstable

Now we’ll run gdisk and partition the drive

# gdisk /dev/sda
GPT fdisk (gdisk) version 0.6.14

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries.

Command (? for help):

Now, create a new empty GPT partition table using ‘o’

Command (? for help): o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y

Now add partitions with ‘n’, entering the necessary info when prompted. For my setup I did a 1 MiB “BIOS boot” partition at the beginning, followed by another consuming the rest of the disk. This is necessary for GRUB2 to boot a GPT disk on a legacy BIOS system, and I left it here just in case GRUB2 supports btrfs sometime soon and (for whatever reason) I decide to switch. If you do decide to use GRUB2, you’ll need a separate /boot partition with a non-btrfs filesystem also.

Command (? for help): n
Partition number (1-128, default 1): 1
First sector (34-78165360, default = 34) or {+-}size{KMGTP}: 34
Information: Moved requested sector from 34 to 2048 in
order to align on 2048-sector boundaries.
Use 'l' on the experts' menu to adjust alignment
Last sector (2048-78165360, default = 78165360) or {+-}size{KMGTP}: +1M 
Current type is 'Linux/Windows data'
Hex code or GUID (L to show codes, Enter = 0700): ef02
Changed type of partition to 'BIOS boot partition'
Command (? for help): n
Partition number (2-128, default 2): 2
First sector (4096-78165360, default = 4096) or {+-}size{KMGTP}: 4096
Last sector (4096-78165360, default = 78165360) or {+-}size{KMGTP}: 78165360
Information: Moved requested sector from 78165360 to 78165326 in
order to align on 2048-sector boundaries.
Use 'l' on the experts' menu to adjust alignment
Current type is 'Linux/Windows data'
Hex code or GUID (L to show codes, Enter = 0700): 0700
Changed type of partition to 'Linux/Windows data'

Now, the other thing we need to do is set the “legacy BIOS bootable” flag on our root partition, which we can do in gdisk by first entering expert mode with ‘x’, then edit attributes with ‘a’

Command (? for help): x
Expert command (? for help): a Partition number (1-2): 2
Known attributes are:
0 - system partition
1 - hide from EFI
2 - legacy BIOS bootable
60 - read-only
62 - hidden
63 - do not automount

Attribute value is 0000000000000000. Set fields are:
  No Fields Set

Toggle which attribute field (0-63, 64 to exit): 2
Have enabled the 'legacy BIOS bootable' attribute.
Attribute value is 0000000000000004. Set fields are:
2 (legacy BIOS bootable)

Toggle which attribute field (0-63, 64 or <Enter> to exit):

Then write the partition table with ‘w’ and exit. If you’re like me and didn’t realize the legacy BIOS boot flag was necessary, you can apply the attribute using sgdisk (part of gptfdisk).

# sgdisk -A N:set:2 /dev/sdX

where N is your partition number (2 in my case) and X is your disk. See sgdisk man page for more info.


You can now go ahead and format your disk in the usual manner

# mkfs.btrfs -L ArchSSD /dev/sda2

Normally, this is where you’d mount this to /mnt and go about the usual manual Arch Linux installation, but there is a better option. We can make a subvolume called ‘__active’ to function as our actual root directory. This allows us to snapshot our entire ‘/’ for backup purposes. Aside: The mkinitcpio-btrfs hook (available in the AUR) looks for a subvolume called ‘__active’ for some of it’s more advanced features, such as rollback support.  Naming your subvolume this way allows you to use these features if you wish. To do so, first mount this filesystem to a temporary directory, then use the btrfs command to make a new subvolume and mount that to /mnt. The mount options I use are good defaults for a SSD: discard enables TRIM support (if your drive supports it) and ssd enables optimized operations for SSD (btrfs can autodetect this, but I ere on the thorough side :P)

# mkdir /broot && mount -o defaults,noatime,discard,ssd /dev/sda2 /broot
# btrfs subvolume create /broot/__active
# mount -o subvol=__active /dev/sda2 /mnt

Remember how I said syslinux doesn’t handle subvolumes well? Turns out syslinux cannot read in a subvolume to find /boot, so we need to make our /boot at the very root of the filesystem, and that means we need to bind it under our ‘__active’ subvolume, so that it appears in the expected place once the system is booted.

# mkdir /broot/boot /mnt/boot && mount --bind /broot/boot /mnt/boot

At this point, go ahead and add subvolumes for any directories you’d traditionally put on a separate partition. For me this was /home, /usr, and /var.

# btrfs subvolume create /broot/__active/home
# btrfs subvolume create /broot/__active/usr
# btrfs subvolume create /broot/__active/var

Due to the fact these are subvolumes under ‘__active’, as long as ‘__active’ is mounted there is no need to mount these subvolumes. This is because the people behind btrfs have designed subvolumes to be navigable as simple sub-directories (as long as you have btrfs-progs installed). The default permissions of the subvolumes is 0700, but the system should/pacman installs the filesystem with 0755, so you may want to change these now so it doens’t complain later.

# chmod -R 0755 /broot/__active


The next part is your typical manual Arch Linux installation (which will be familiar to those who have ever made their system unbootable and had to rollback an upgrade).

Installing the base system

The first step is to setup our /mnt as a working root directory in order to allow us to chroot into it. This involves making a /proc and /sys filesystem, as well as binding /dev.

# mkdir /mnt/proc /mnt/dev /mnt/sys
# mount -o bind /dev /mnt/dev
# mount -t sysfs none /mnt/sys
# mount -t proc none /mnt/proc

With our chroot setup, we can now install the base packages, along with our bootloader and our filesystem utils.

# mkdir -p /mnt/var/lib/pacman
# pacman -r /mnt -Sy base syslinux btrfs-progs-unstable --ignore grub

The -r option tells pacman to use a different root directory when performing operations. Note: For whatever reason, the ignore directive was not working for me, but grub can be uninstalled later. I realized this was a feature that had been removed, but now with pacman 3.5, it’s back and working as expected :]

Installing the bootloader

Installing syslinux is simple, as follows:

# mkdir /mnt/boot/syslinux (newer versions of the syslinux package include this directory)
# chroot /mnt extlinux -i /boot/syslinux

The next step is copying the boot code into the MBR. Notice we use a special GPT mbr in this case.

# cat /mnt/usr/lib/syslinux/gptmbr.bin > /dev/sda

The last thing to do for the bootloader is to write the configuration file. Mine is a simple barebones config, but it is possible to do fancier ones with syslinux if you desire.

# nano /mnt/syslinux/extlinux.conf


LABEL arch
    KERNEL /boot/vmlinuz26
    INITRD /boot/kernel26.img
    APPEND root=/dev/sda2 rootflags=subvol=__active ro elevator=noop

This is pretty much a standard “no-frills” boot configuration. The only interesting things to note are the rootflags argument, telling it to mount the subvolume ‘__active’ as root, and the elevator argument is to switch the disk I/O scheduler, a small tweak for SSD performace. If you have other non-SSD drives then check out the SSD page on the Arch Linux wiki for more info about setting only certain drives.


Almost done, now we just need to configure some of the base system to allow us to boot into our new system. First we need to write our /etc/fstab. For this part, I followed the wiki guide and had an entry to mount the filesystem’s root to /var/lib/(btrfs label) in order to be able to bind the /boot under our ‘/’ root. Just like before, we also mount our ‘__active’ subvolume as our filesystem ‘/’. The only other unique thing I do is to mount a new tmpfs to /tmp, in order to reduce some writes to the SSD. My final  fstab follows:

devpts                   /dev/pts          devpts   defaults                                      0 0
shm                      /dev/shm          tmpfs    nodev,nosuid                                  0 0
/dev/sda2                /                 btrfs    defaults,noatime,discard,ssd,subvol=__active  0 0
/dev/sda2                /var/lib/ArchSSD  btrfs    defaults,noatime,discard,ssd                  0 0
/var/lib/ArchSSD/boot    /boot             none     rw,bind                                       0 0
none                     /tmp              tmpfs    nodev,nosuid,noatime,noexec,mode=1777         0 0

Notice I have no swap partition, (swap on an SSD would kill it if it got used often) and for the moment I have no plans to add one; this laptop has 2 GB of ram, and I’ve barely scratched that with the normal day-to-day activities. I’ve contemplated setting up Compcache and/or using a sacrificial SD card, but as I run a majority of lightweight software, I doubt this will be necessary anytime soon. Lastly, edit your rc.conf (filling in timezone data in the very least), set your root password, and perhaps perform any special edits to mkinitcpio.conf or modprobe.conf. After that you’re ready to reboot and try out that new SSD.

# cd /
# umount /mnt/{dev,proc,sys,boot}
# umount /mnt
# reboot

Other Configurations

I have also moved my browser caches into a tmpfs. The method I did this is not too different from the “Speed-up Firefox with tmpfs” page on the Arch wiki. Although, I usually use Chromium which places it’s cache in ~/.cache/chromium (the XDG standard location). As I could not find a setting to change this, I changed the directory :P I decided to put the whole ~/.cache into the tmpfs, and I did this by simply changing XDG_CACHE_HOME. To do so, just place something like this in your .bash_profile (or your other login shell’s profile)

export XDG_CACHE_HOME=/dev/shm/username/.cache
if [ ! -f $XDG_CACHE_HOME ];
    mkdir -p -m 0700 $XDG_CACHE_HOME

The one problem with this, of course, is that this directory will be cleared once the computer is shutdown; ~/.cache is intended for non-persistent data, but if you have thumbnail caches and such you like to keep between shutdowns, you may want to either setup a syncing script similar to the one on the wiki page, or limit it to just the chromium subdirectory. Logout then log back in for the changes to take effect. Note, the directory pointed to by XDG_CACHE_HOME will probably be regenerated as needed by any [good] xdg compliant program, but just in case it isn’t, and also to make sure it has proper permissions (as it is in a globally accessible directory), we make it ourselves with the proper permissions.

The Result

Just a qualitative result, but I definitely notice an increase in boot speed and when starting X. Even though this particular drive has relatively “low” read/write speeds compared to other SSD (and my drive isn’t even hitting that limit, as I only have SATA I on this laptop). When starting X, all my autostart applications not only startup faster, but seem to start more concurrently, where as before they seemed to startup one after the other. This could just be the smaller delay between loading each program–I imagine the advantages I’m seeing are mostly due to the superior random read speeds of SSD vs HDD, coupled with the simpler noop I/O scheduler. This Intel SSD also has very low power consumption, and I will have to do some number crunching to see how much this drive actually uses compared to my old HDD with some similar tasks. Lastly, with no longer needing to worry about a head crashing on a platter, I carry this laptop like a book and move it around as I please :]


Special Thanks to my partner for spoiling me rotten ;]


From → Howto

  1. RippleAdder permalink

    Btrfs isn’t really considered experimental anymore you should have flew to the sun with wings of was using nilfs.

    • Well, maybe not experimental, but not yet stable/complete either. (the tools are still called btrfs-progs-unstable in [core])

      Hahaha, well perhaps the spare harddrive I have now could be the Icarus drive ;] This SSD I wanted something somewhat stable :P

  2. RippleAdder permalink

    wings of wax

  3. Hendy permalink

    This was great. I have a follow up question. I was looking at this arch forum POST, and wondering about how you go about mounting the /home /usr and /var subvolumes you created. Do you need to explicitly do so? In the forum post, the poster has both a root and home subvolume and mounts them explicitly in fstab.

    It looks like you created:
    |– /home
    |– /usr
    |– /var

    And then you only mount / (with subvol=__active) explicitly. Is this using btrf subvols home, usr, and var? Or is everything going into __active and the other subvols are unused.

    Using ‘sudo btrfs subvolume list /’ doesn’t show any information about the sizes of the subvols. Anyway, what are your thoughts on this? Should I explicitly mount the vols created at the proper mountpoints and copy everything over?

    • Hendy permalink

      That tree didn’t show up so hot — it’s supposed to have home, var, and usr shown under the top-level tree, __active.

  4. Hendy permalink

    Oh, also just re-read your bit, which says (I think) that subvolumes of subvolumes are automatically mounted with the higher level subvolume? Is that the case? Can you handle them individually if you want? For example, this post talks about being able to mount var, home or whatever with different mount options. So… in the method you used, can you control them explicitly or are they just bundled with __active? Thanks!

    • Glad this could help you out :] I lost a whole weekend (and almost a laptop out the window) getting this all to work together the way I wanted to.

      I’m not a btrfs expert, but my impression is that the subvolumes are not automatically mounted exactly, but might as well be; they just exist “under” the parent subvolume, and btrfs does what is can to abstract away the details and make it appear as a normal directory under the parent subvolume.

      There’s a page I read when setting all this up that explained this, but I have not been able to find it since then.

      That being said, I’m pretty sure you can just mount them individually if you want different mount options and such. I can’t say for sure, but I think when navigating the filesystem tree, the system uses the newest applicable entry in /etc/mtab.

      For example, I usually mount my /home with ‘nosuid’ and if I had an on disk /tmp, I’d mount that with ‘noexec’ also. I was considering doing that on this setup too, but I decided to get it working first and go back and play later (which, I realized I have completely forgotten to do :x)

      And actually, just found a link about this here

      Hope that helps :]

      • Hendy permalink

        Thanks for the reply and the link. That’s interesting. So… it does seem, then, like subvolumes under a top level subvolumes don’t have any control over them, right? I’m thinking that one only chooses the options for the top level subvolume?

        Or do you mount /dev/mapper/root to / (with subvol=__active) and then map / to /home (with subvol=home)? I can’t see from the link or my understanding whether or not you can actually access the home subvol or not. You can for sure snapshot it like a subvol; I’ve done that!

        Also, your /tmp line in fstab was giving me access issues with yaourt. If you remove the “noexec” option, that works. It couldn’t run ./configure. I guess I could set yaourt to use some other location, but I just wanted to pass that along.

        I’m getting errors with the .bash_profile line about the XDG_CACHE export not being a valid option or something like that. I’ll try to debug that and post back, as I like the idea.

        • My impression is that a subvolume under another acts like a subdirectory in every way it can, meaning it inherits mount options, etc., but that doesn’t prevent you from explicitly mounting it with different options. For example, if I did mount my /home subvolume in the way I mentioned, I would probably change my fstab to this:

          /dev/sda2 / btrfs defaults,noatime,discard,ssd,subvol=__active 0 0
          /dev/sda2 /home btrfs defaults,noatime,discard,ssd,nosuid,subvolid=xxx 0 0

          (note we need to use subvolid with this one, apparently btrfs can only mount root subvolumes by name)

          so when my system uses /home, it will use the latter options because I mouted that to /home last. Essentially, I think it shadows what was in /home before, which in this case was the subvolume itself, as seen from being mounted from “__active”

          I think a better way to explain it might be that mounting __active to root tells the system to use it as a single filesystem (with btrfs exposing the subvolumes under __active as normal directories under it), but the second mount tells it to treat it like two filesystems: __active being assigned to the root, and a subvolume being assigned to /home; when you navigate to /home, the system uses the second filesystem, which was the subvolume mounted with the latter options.

          Huh, I don’t use yaourt, so I never caught this. The noexec option is a paranoid security enhancement I do on my systems (from following this page And in checking that page I found the warning that some things execute from /tmp and this breaks them :P I haven’t run into anything that broke yet, but I’ll probably take that part out from the tutorial.

          You’re using XDG_CACHE_HOME, correct?

  5. Hendy permalink

    | (note we need to use subvolid with this one,
    | apparently btrfs can only mount root subvolumes
    | by name)

    Bingo! That’s it and makes total sense. I tried mounting my home subvol to /mnt once and it didn’t find it. The note about IDs now rings a bell for sure.

    Re. the XDG_CACHE_HOME… I’m trying, but I don’t think it’s working. I’m getting some kind of error about it when I first log in. Also, if i set it from a bash session, it only seems to work for that particular session. For example, I use rxvt-unicode and when I set it and then open a new tab and do “echo $XDG_CACHE_HOME”, it returns “/home/jwhendy/.cache”. But from the session I exported it from, it’s /dev/shm/jwhendy/.cache.

    The only way I can get it to work so far is if I run the export command from a terminal and then start chromium from that same terminal.

    How is this working for you?

    • Oh! I think I remember now, there shouldn’t be spaces around the ‘=’ in .bash_profile. I must have mistyped it writing it up here.

      Fixed now, and I actually rearranged that section–I didn’t quite like how I originally set it up.

  6. KJ4OHH permalink

    After booting syslinux, I get the following error:

    ERROR: Unable to determine the file system type of /dev/sda:
    Either it contains no filesystem, an unknown filesystem,
    or more than one valid file system signature was found.

    Try adding
    to the kernel command line.

    Then it drops me to an emergency shell.

    • I’ll have to double check my configuration, but it looks like I may have mistyped the example syslinux configuration file. For the root option you want to specify the partition the root filesystem is on, which in this case is /dev/sda2

    • Hendy permalink

      I realize you may specifically have followed this post for btrfs everywhere… but just wanted to chime in and say that I have a separate boot partition and did not use the fstab options to have /boot at /var/lib/something.

      I did encryption + btrfs and thus actually had to have a separate boot partition… anyway, just a thought.

  7. Hendy permalink

    How has your system been working? I’m having issues and may be dealingn with the whole btrfs out of space issue. I’ve balanced a couple times in a row, but am getting all kinds of out of space errors as of today. Would you see what you think about THIS? Just thought you might have a suggestion.

    • My system has been working really well actually. It’s not my main laptop so it doesn’t get the rigorous testing it should.

      I purposefully avoid building packages on that laptop for that reason… I just lucked out that I can copy my built packages from my main laptop. However, it sounds like you may have just run out of space. Just like one of the posters said, for various reasons btrfs disk space gets calculated incorrectly so ‘df’ doesn’t report it properly.

      I’m sorry you ended up reinstalling before I got to this :[ I’ve run into “out of space” issues on other laptops often enough to know how annoying they are (downfall of finding /var was small…). I’m going to get back to looking into disk quotas for btrfs when I get a chance, so hopefully if this ever happens again, the “damage” can be minimized.

      I’d post the link to the disk space calculations on the btrfs wiki, but it seems down at the moment. Easy to find, just search for “run out of disk space” on the wiki when it is back up.

  8. Hendy permalink

    Well, that’s the funny thing… df, du, and whatever the btrfs deal was (list subvolume?) seemed to agree. There were only about 20-30G out of ~75G used. Still don’t know what happened. I just reinstalled with ext4. It’s fine. Btrfs sounded neat, but I really wasn’t using the snapshot features anyway. I’ve got hourly, daily, weekly, and monthly rsync scripts that kind of do that anyway. It was a fun learning experience and if it matures, I’m sure I’ll wander back!

    Your blog was incredibly helpful on this!

  9. Alexander permalink

    Thank you for this guide!

    I tried install gentoo with btrfs ( __active with all partitions (/boot, /, …) ). But there is problem – I can’t install grub2:

    # grub-mkconfig -o ‘/boot/grub/grub.cfg’
    /sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).

    my installation log:

    # gdisk /dev/sda
    o y
    n 1 34 +1M ef02
    n 2 4096 +2G fd00
    n 3 0700
    x a 3 2
    w y

    # gdisk /dev/sdb
    o y
    n 1 34 +1M ef02
    n 2 4096 +2G fd00
    n 3 0700
    x a 3 2
    w y

    # mdadm –create /dev/md2 –level=1 –raid-devices=2 /dev/sda2 /dev/sdb2
    # mkswap -f /dev/md2

    # mkfs.btrfs -L Gentoo -m raid1 -d raid1 /dev/sda3 /dev/sdb3

    # mkdir /broot && mount -o defaults,noatime,discard,ssd /dev/sda3 /broot
    # btrfs subvolume create /broot/__active
    # mount -o subvol=__active /dev/sda3 /mnt/gentoo
    # mkdir /broot/boot /mnt/gentoo/boot && mount –bind /broot/boot /mnt/gentoo/boot
    # btrfs subvolume create /broot/__active/home
    # btrfs subvolume create /broot/__active/usr
    # btrfs subvolume create /broot/__active/var
    # chmod -R 0755 /broot/__active
    # mkdir /mnt/gentoo/proc /mnt/gentoo/dev /mnt/gentoo/sys
    # mount -o bind /dev /mnt/gentoo/dev
    # mount -t sysfs none /mnt/gentoo/sys
    # mount -t proc none /mnt/gentoo/proc

    # chroot /mnt/gentoo /bin/bash
    % env-update && source /etc/profile

    % grub-mkconfig -o ‘/boot/grub/grub.cfg’
    /sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).

    • Alexander permalink

      little edit: without `discard` and `ssd`

      • Hey Alexander,

        I have not used GRUB2 at all really, but it looks like you have /boot in the btrfs filesystem, correct? If I remember reading correctly, GRUB2 can’t boot from a btrfs root drive, so you’ll need to add another separate partition formatted to something like ext3/4. Now since there’s a whole separate partition for boot, you can simply mount it instead of having to bind it.

        # mke2fs -L GentooBoot /dev/sdaX (X being whatever number the boot is)
        # mount /dev/sdaX /mnt/gentoo/boot

        # chroot /mnt/gentoo /bin/bash
        % grub-mkconfig -o ‘/boot/grub/grub.cfg’

        Let me know how that works out :]

        • Alexander permalink

          Yes, I tried install / and /boot on Btrfs (Btrfs on 2 disks in btrfs-raid1 mode). My aim was create / and /boot on Btrfs and install any bootloader.

          I dont know difference between grub/grub2 and extlinux, they all works nice.. but not with btrfs…

          Grub2 show me error because I use / on Btrfs (and moving /boot to ext4, for example, will not help here). May be here is solution (for grub2):

          Grub Legacy should work well with Btrfs on / (and Grub2 too if follow ^^ guide) but I’m not sure about multi-device Btrfs…

          I tried and syslinux too but after reboot I see: “warning: only support single device btrfs”

          So.. I think I must use software raid1 + LVM + ext4 now for /boot and / because no way for now use Btrfs for /boot and/or / on multiple devices…

          • I’m sorry, I got a little mixed up. Grub-legacy can boot a btrfs / but needs a non-btrfs /boot. GRUB2, as I understand it, needs to be patched in order to mount a btrfs /.

            However, grub-legacy cannot boot from GPT drives, only GRUB2 and syslinux can

            I don’t have any experience on RAID setups and very little with GRUB2, so this is about as helpful as I can be, sorry :/

  10. Anonymous permalink

    A few things you may want to include in this article..

    I have found this to work better than copying the boot record using cat:

    dd bs=440 conv=notrunc count=1 if=/usr/lib/syslinux/gptmbr.bin of=/dev/sda

    Also, I went through this setup unknowing that you CANNOT install using the compress flag (or compress=lzo for better performance) on root of the drive, due to the fact that syslinux does not support btrfs compressed boot images. However if you would like to install archlinux while compressed, then you would just need to mount the subvolume __active with the compress flag.


    # btrfs subvolume create /broot/__active
    # mount -o subvol=__active /dev/sda2 /mnt

    Becomes this:
    # btrfs subvolume create /broot/__active
    # mount -o compress=lzo,subvol=__active /dev/sda2 /mnt

    • Anonymous permalink

      Also, another thing that would be good to warn is that syslinux doesn’t support multi-drive boot sectors, raid 0 is a no go :(

  11. Anonymous permalink

    Blah.. A few more things I forgot to mention.

    1) syslinux doesn’t support multi-drive boot sectors (raid0,1,etc).
    2) If you instead use archlinux’s syslinux.cfg (which is preferred) then you will need to copy menu.c32, reboot.c32, hdt.c32 (for hardware detection tool), chain.c32 (for windows bootloader chaining), and from /mnt/usr/lib/syslinux.

  12. Hi,
    i enjoyed to much this article and i followed it setup my archlinux desktop.

    The only thing that, in my opinion, could be improved is the layout of the btrfs filesystem.
    One of the reason to use btrfs filesystem is it’s ability to take snapshot, almost infinite snapshots, so if you put your /home directory on separate subvolume but outside of the root (yours __active) subvolume will be easier to manage the snapshots and the rollback of the system.

    • That’s true, I hadn’t thought about doing it that way. I did it the way I did was the ability to one-shot snapshot the whole system, and the fact my fstab only had one of the funky subvolume mounting. But just a matter of preference. However, as I haven’t actually been using the snapshot abilities at all, but invested in versioning my home directory… your approach would probably be simpler and more versatile.

      • Thank you for reply.
        With your approach you can’t be able to take a snapshot of the whole system because the snapshot are not recursive, this means that every sub-subvolume will be an empty directory inside the snapshot.
        If you want to take a snaphot of the whole system you have just to use one single subvolume in the root of the btrfs filesystems.

        Snapshots are very cool and useful, i’ve a cronojob that take a snapshot of my /home every 5-15 minutes so if i made some stupid thing like deleting an important file i can restore it very quick and easily.

  13. Chad permalink

    So this post still seems almost current. One thing I don’t understand. How do you make sure /boot is bound to __active/boot? I They don’t seem to correlate even after I run “mkdir /broot/boot /mnt/boot && mount –bind /broot/boot /mnt/boot”. I can make changes to one but the changes don’t occur in the other. In fact, __active/boot doesn’t seem to hold any files(the kernel, initramfs or syslinux folder…)

    • Actually, __active/boot should be empty. During the setup I just use boot directly. I had to do it this way because (at the time, maybe still true) Syslinux couldn’t boot from subvolumes. Thus boot is just a plain directory on the root btrfs filetree.

      It’s been a while, so I hope I still have this right:
      __active is a just a subvolume under the root filesystem, and I put the major directories as additional subvolumes under it. There’s no reason to do it this way or another, but doing this gave me “future” options (aka, snapshots the __active directory, place quotas on the major directories one would usually make separate partitions, etc.) Like I said above, I couldn’t do this with boot because of limitations in Syslinux

      On system startup __active is mounted as my system / and as such the folder would be empty, and in order to access it (during setup or after booting–say to upgrade kernel and/or bootloader), I need bind the boot in the root btrfs filesystem to my root filesystem.

      Hope that clears up the confusion.

      • Chad permalink

        Hey, thanks for clarifying. Are you still using this setup?

        I tried it out, got it working. Now I’m wondering if grub2 would be better and whether to ditch /var and /sys subvolumes. I think this would allow full encryption and rollback, which would be very awesome. I talked to someone in the syslinux irc. They said that syslinux has limited btrfs subvolume support (mostly the installation might fail to detect syslinux being installed in btrfs vs ext*) Anyway. Kinda fun playing around with this. I have a pretty fast box now even with gnome. I’ll be setting up openbox once all the kinks are worked out. Thank you for the informative artical.

  14. This is so thought provoking. I felt inspired by reading
    it! I think this place will become my new favorite site!

  15. It’s funny how many different websites the internet has about this topic. I don’t know if I will need to come back here, but it is nice to know I stumbled upon the one that has a
    lot of useful information if this ever comes up for me another time.

  16. What you said made a bunch of sense. But, what about this?
    suppose you typed a catchier title? I mean, I don’t wish to tell you how to run your website, but suppose you added something that makes people desire more? I mean Installing Arch Linux onto a GPT partitioned, btrfs root SSD on a legacy BIOS system | Mathletic is a little boring. You could peek at Yahoo’s home
    page and watch how they write article titles to get viewers interested.

    You might add a video or a picture or two to grab people excited about everything’ve written. Just my opinion, it could bring your blog a little bit more interesting.

  17. Sure, you can run your remodel 3/4 bath environmental and temperature controls with far better efficiency.
    Sound Cabinet StructureThough refacing kitchen cabinets may make
    your old cabinets either. There are many areas of Illinois at varying
    price ranges. It is possible to do based on your home’s floor plan, which means you require to take into account when deciding which kitchen area design and style components?

Trackbacks & Pingbacks

  1. Installing an SSD (Fedora 16) | Sudesh Jethoe's blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s