Impossible to boot 18.04.2 from btrfs

[BertN45]

Try to install Xubuntu 18.04.2 on btrfs, it failed to boot because grub could not find the kernel.
The partition did have two directories @ and @home, the @ one contained all the root files, while the @home one contained the 'user' directory.

[Sebastien Bacher (seb128)]

Thank you for your bug report. You did select custom partitioning in the installer right? Could you describe what partitions you add/their fs type and if you picked to format or not? What grub error do you get exactly?

[BertN45 (lammert-nijhof)]

The boot loader is stored on sda since 2014 and used by all systems on sdc and sdd. Up to now all 18.04.2 systems use Linux 4.15, since the 4.18 HWE upgrade failed on the compilation of the ZFS-SPL module (another bug report).
I remember that after trying to repair the system by running update-grub from another system on sdd5, the btrfs sdc5 boot entry has not been detected anymore by the Linux 4.15 update-grub.

The sdc5 has been used before by an ext4 partition with Xubuntu 18.10 and I restored that partition.
Tomorrow I could try to reconstruct the problem in a Virtual Machine and I could send you that vdi or vdmk file with the boot error. Else I retry the install.

I have 3 disks and a SSD and they are:
- sda of 500GB (3.5") has 2 ZFS partitions one for virtual machines and one for data.
- sdb of 320GB (2.5") has 2 ZFS partitions one for virtual machines and one for data.
- sdc of 1 TB (3.5") has 5 partitions, one fresh install of btrfs for the system (Xubuntu 18.04.2 on sdc5), one swap (sdc6), one zfs for virtual machines and one zfs for data and the last 500GB is zfs used for archives.
- sdd of 128GB (SSD) has an extended partition with 3 ext4 system partitions (Xubuntu or Ubuntu Mate, one 18.10 and two 18.04.2) and one ZFS Log partition for data. The SSD has three primary partitions, two for ZFS Cache and one for ZFS Log for virtual machines. All HDD ZFS partitions are lz4 compressed.

I have that many system partitions since the main one uses Virtualbox and the two others contain VMware and QEMU/KVM. I keep the sdc5 partition to be independent of the SSD, if needed. I lost one SSD in the past.

I also use btrfs with Peppermint 9 (Linux 4.15) on a Pentium 4 HT with two 40GB IDE HDDs. I installed it on one disk with a root and home physical partition and balanced both partitions over the two HDDs. Afterwards I compressed both btrfs volumes using LZO. That 15 year old PC booted in an amazing 45 seconds instead of a couple of minutes, Partly caused by striping and partly by the compression. That did give me the idea to replace all ext4 system partitions by btrfs LZO compressed partitions to gain say 33% in boot time :)
The first try-out failed.

[Sebastien Bacher (seb128)]

Thanks for the details, it's not clear from the description though what you tried to do exactly to get the error? Was that using the xubuntu installer (and if so what did you do in the partioning step?) or did you end up in that situation by using update-grub manually from one of your existing installations?

[BertN45 (lammert-nijhof)]

I tried to reconstruct the issue using Virtual Machines. I took an Ubuntu 18.04.2 VM with Linux 4.15 and added a second disk. I booted that VM from the ISO with Xubuntu 18.04.2 and installed Xubuntu on that second disk and it rebooted after install without any problem.
So I have to retry it on the real hardware.

However I rebooted Ubuntu from the first ext4 disk and that showed a part of the problem. The command 'update-grub' does not detect the btrfs system see my annex.

The ext file manager shows the btrfs disk with the @ and @home folders a second window of the file manager shows the @ root (sub-)volume. However the terminal with the update-grub shows, that update-grub does not detect the btrfs system.

I try it again on the real HW now, with its many many partitions and many disks. I use my gsm for the photos.

[BertN45 (lammert-nijhof)]

I tried to reconstruct the issue using Virtual Machines. I took an Ubuntu 18.04.2 VM with Linux 4.15 and added a second disk. I booted that VM from the ISO with Xubuntu 18.04.2 and installed Xubuntu on that second disk and it rebooted after install without any problem.
So I have to retry it on the real hardware.

However I rebooted Ubuntu from the first ext4 disk and that showed a part of the problem. The command 'update-grub' does not detect the btrfs system see my annex.

The ext file manager shows the btrfs disk with the @ and @home folders a second window of the file manager shows the @ root (sub-)volume. However the terminal with the update-grub shows, that update-grub does not detect the btrfs system.

I try it again on the real HW now, with its many many partitions and many disks. I use my gsm for the photos.

[BertN45 (lammert-nijhof)]

OK I installed again from CD on the real hardware on partition sdc5. I had the same old problem, but than I detected, that I told the BIOS some time ago to boot from the SSD. I did forget it completely and normally I have no problem, since I install the boot loader on all disks after running update-grub.
I did set the BIOS back to sda and now the btrfs system boots as expected.

The only remaining problem is that update-grub from an ext4 disk does not detect the btrfs system. Basically the reason that I could not correct the problem directly. What do we do next, adapt this bug or cancel it and write a new one.

[BertN45 (lammert-nijhof)]

WRAP UP

First my mistake:
I found a work-around. My 2008 HP dc5850 allows me to boot from the first disk of the internal SATA-2 controller or from a SATA-3 PCIe card, I have added for the SSD. I did boot in the BIOS from the SSD, but did forget all about it and assumed during the installation of Xubuntu with btrfs, that I was still booting from sda. That is where everything started to go wrong, since grub (SSD) still expected the previous ext4 system on that newly installed partition.

Second the remaining bug in update-grub.
I booted in the main system again and did run update-grub. Update-grub did not detect the btrfs system and left it out from the list of bootable system. So in my mind there was no way I could boot that just installed system and that resulted in this bug-report.

I'm lucky with the separate SATA-3 controller, because I can boot both systems, but I have to select the btrfs system from the BIOS after any update of one my three ext4 systems. During 'normal' operation I have to select the boot entry for my main system manually. So it is important, that update-grub is corrected for those people with a BIOS without drive choice.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Waynkee (spitfire328)]

After installing Ubuntu 19.10 after a few days the software would not come on when I turned the computer on. Have tryed all that I know to fix it, still not working, after reinstalling 3 times.