Well I've just been through Hell, trying to resolve a problem that's not fixable apparently. I chose to set up /boot with ext3 and / with BTRFS because of all the nice features it has.

Things were fine for a couple months until this most recent dist-upgrade. The new grub has an incompatibility with BTRFS which nearly caused me to lose everything, as grub couldn't set up the boot system since it can't see the BTRFS partition.

I worked for days trying to get help in the linux-btrfs listserv, but they don't seem to understand Debian/Ubuntu, and they kept referring me to Debian and grub devs. I asked them how those devs will know any more about BTRFS than they do, but there was no reply.

They said the new grub (1.99~rc1-13) will fix it, but unfortunately the Debian package management system was jammed by BTRFS as well and I couldn't install/deinstall anything. I finally had to unpack the grub-pc .deb and manually install it, but guess what? It didn't fix the problem.

I've now had to completely rebuild my system without BTRFS. This has cost me days, which I cannot spare.

I realize it says 'experimental' on the BTRFS website, but it is in the stable kernel, and there is not a word anywhere about it being completely non-functional in Debian/Ubuntu.

So don't make the same mistake I did.

It's not btrfs responsibility to ensure debain and grub can use it. Grub has the responsibility to make sure it can understand BtrFS and, failing that, it's Debains responsibility to decide to add it to grub if they want their system to support it. But they don't claim to support it. Only that it's available if you want to play with it. Honestly, I don't see how a filesystem could 'break' the package tools on debain other than you not being able to mount all the partitions on recovery... OR you filled up the /var or other partition which would have caused the partition to lock up. This would also cause the package manager to refuse to install something if it didn't have the free space to do so. You don't get the full sapce on the partition availalbe to data on a BtrFS. They also recomend you using a partition larger than 1G. You can sometimes recover a little extraspace using a balance operation. This would give you the ability to reorganize data a little bit and make changes. When I first used BtrFs, I used it like I would any other filesystem and had a root partition of 1G, var of 500M and usr/ of the rest. I quickly found out that 1G was more like 500Mb and 600Mb after a tree balance and the var never got over 150Mb. So I consolidated the data onto the /usr partition with subvolumes (in the hopes that they will eventually have quota options). I also did a bunch of other stuff to make all the data for this install under a subvolume of the partition and made it the default subvolume. This makes it easier to take snapshots and store them outside of the normal mount point.

Like other things that go into the stable kernel, they are often still marked at "experimental". BtrFs is still marked as "experimental" in the kernel as of 2.6.39-rc5. It even has the label "Unstable disk format" even though it's not going to change unless an unforseable fix/feature causes them to change it.

By the way, BtrFs works fine with Lilo, even old versions of Lilo. But that's because Lilo boots a different way. You still need the ext3 /boot partition and an initrd. But that's beside the point.

Not a lot of sympathy here either. If experimental stuff breaks you get to keep all the pieces. Always been that way.
I run (non-prod) almost exclusively btrfs - have done for ages. Exclusively grub - haven't used lilo since last millenium I'm guessing. Haven't seen the issue, but I don't run much Debian based stuff. I have a Mint LMDE somewhere - might check that and see if it behaves similar.

I'm betting on the partition that was way too small and got filled up. That's the most logical reason for the package manager 'not working any more.'

O.K., so I checked my LMDE system - this is a rolling release based on Debian testing. Needed a truckload of updates including grub 1.99~rc1-13, so I kicked it off and went and fed the dog.

This system is a simple 2 partition setup (plus swap) - a ext3 /boot, and a (single) btrfs /. It doesn't update the MBR, but is chain-loaded from grub1 - which is itself chain-loaded from the Win7 loader - just to make things interesting.
Updated fine, and this is being posted from it. No problems at all.

No, the partition is not full.

lumak and syg00, you misinterpret my intention here as seeking help or "sympathy". No.

As I say, this is intended as a WARNING to others. Take it as you will.

Simple as that, an update to the installed kernel will cause automatically a run of update-grub, which fails because it can't find the /-partition, since it is formatted with BTRFS. Since update-grub reports an error to the package manager the package manager marks the package as unconfigured and will try to configure this package every time the package manager is invoked. This makes it difficult to install anything on that system. It is not impossible, but difficult.

@Quantumstate:
No backups?
This makes me assuming that you have installed an experimental file-system (and you clearly state that you in fact did know that) to a production machine. Why should someone do that? And why complaining about the time it consumed to re-install with a stable file-system?

If you want to avoid wasting time or getting a headache, don't use an experimental filesystem or anything else explicitly marked experimental.

What exactly do you want from a filesystem ? XFS and JFS are stable (non-experimental) high performance filesystems, if you want to try them.

I'll accept the warning as is. I thought about trying btrfs. Shame more on the update that didn't support that file system.

Still the source pages has plenty of warnings. Just not that one yet.

@TobiSGD

Ahhh yes, I forgot package managers try to help too much and screw things up. This is exactly why package managers shouldn't do anything more than blindly installing packages at the administrators request. Not saying that 'update-grub' was wrong for the package to do... But more of the fact that it forces the package manager to attempt it on each run afterwards. Tell the amdin the error and go away. The Admin will deal with it.

Then it (the thread title) should have been framed as a warning - not an absolute statement.

Lots of things might screw your system, btrfs amongst them, but as my experiment proves, there is no basis to say it will screw your (Debian based) system.
I have no issue with you sharing your (unfortunate) experience to warn others.

Additionally, BtrFs was not the problem. It was the pkgmgr, grub, and user error.

0 members found this post helpful.

lumak, it doesn't matter. The choice of BTRFS is the problem.

Furthermore, have a quick look at their patches; it's a forest. Reiser didn't have these problems when it got started.

Are you just trying to be argumentative?

0 members found this post helpful.