A new btrfs booting problem

[Teunis]

I've tried your version of 40_custom and it results in a 'press any key'.
Which in turn goes back to the Grub menu.

I am quitting for tonight, it is a quarter to ten and tomorrow I'm for a three week job flying to Lafayette LA.

Thanks for the support, it looks like a reinstall is going to be the way.

[GreyGeek]

Just a wild idea: was the boot flag set on the partition?

[Teunis]

The boot flag is set on the Win7 ntfs partition.

I'm going to reinstall using ext4, until at least the osprober is fixed btrfs is not suitable for a multi-boot system.

[oshunluvr]

... btrfs is not suitable for a multi-boot system.

Obviously, some of us do not agree with this conclusion and I've seen no evidence that this is true.

Re-reading this thread, it seems your issues appear to be with setting up grub properly and by extension os-prober. Neither of which are caused by any under lying file system. The nested grub menu failed because your 17.10 apparently does not have a grub.cfg menu yet. You would have to boot to it once, install grub (if it wasn't initially), and run grub-update for that to occur. Alternately, letting the new install install grub and using it's grub and grub menu would have worked just fine because os-prober would have located the EXT4 install.

@here, I'm booting 2 installs of KDEneon, 2 installs of Manjaro, Ubuntu, and Kubuntu 16.04 all from the same btrfs file system. Since they reside on the same file system;

• All 6 installs and their respective homes all are able to access all the available free space as needed and when space is freed, all 6 installs and homes have more space available.
• All 12 subvolumes (installs and homes) can be instantly snapshot-ed and backups created and stored with very few commands.
• I install and delete installs without reformatting or have to wipe a partition.
• I have added and replaced drives/partitions to/from my file system without rebooting and while still using an install on the file system - including moving the entire file system to a backup device and returning it to the original drive.
• I have not had to re-partition since this system was set up this way over 4 years ago.

My conclusion is btrfs is uniquely suited for multi-booting and using EXT4 or any other file system is too much work and a waste of both time and drive space. Yes, a few manual commands and edits are necessary because of the quirks of os-prober and the non-unique default subvolume names the installer uses, but solving those minor issues does not rise to the level of difficultly or possible danger of partitioning, re-partitioning, determining partition size, or other partition/format level drive manipulations that may be required to segregate, combine, or realign space on a drive.

For anyone else reading this thread who might be interested in attempting multi-booting using btrfs I have written extensively on this forum about how to do it properly including several How-To's.

[Teunis]

Yes oshunluvr, btrfs has many advantages for what otherwise would be a multi-partition set up.

But it sure has a learning curve in the case of a mix with ext4.
Yes 17.10 does have a grub.cfg menu, I'm not enough acquainted with grub to know what it's elementary function it has but by the time stamp I can see it was set up during the original install.

So you are suggesting running update-grub before a potential kernel update on 16.04 would avoid the problem I am encountering?
Ah well, I like a challenge so one more time a fresh install

[oshunluvr]

Yes oshunluvr, btrfs has many advantages for what otherwise would be a multi-partition set up.

But it sure has a learning curve in the case of a mix with ext4.
Yes 17.10 does have a grub.cfg menu, I'm not enough acquainted with grub to know what it's elementary function it has but by the time stamp I can see it was set up during the original install.

So you are suggesting running update-grub before a potential kernel update on 16.04 would avoid the problem I am encountering?
Ah well, I like a challenge so one more time a fresh install

Learning curve? Always That's part of what I love about Linux.

I suggest that if you re-install 17.10 to the new (since it appears you need to wipe the current one and start over) including grub, then boot into it, grub there should have found both it's own 17.10 install and the 16.04 install and both should be bootable. Then you would only need to make the 16.04 install the default selection for grub by setting the "set default" option in /etc/default/grub ("GRUB_DEFAULT=" followed by the menu number or the grub menu label) and running update-grub.

The downside to this method is now your boot files (grub) reside in 17.10. This means if/when you decide to delete the 17.10 install - and being such a short-lived support version, you will eventually - your grub and ability to boot will go with it. Prior to removing 17.10, you would need to boot into 16.04 (or any other install you have by then) and re-install grub to the drive. Not a difficult process, but one to be sure to do before deleting 17.10.

Alternately, you could again attempt to use 40_custom to make 16.04 your primary boot install. Here how I would do it;

1. Wipe and re-format the btrfs partition.
2. Install 17.10 to it along with grub.
3. Boot to 17.10 and make the 16.04 install the default in grub there.
4. Reboot to 16.04.
5. Edit 40_custom to include your 17.10 install and run update-grub.
6. View your new /boot/grub/grub,cfg to insure 17.10 is in it.
7. Reinstall grub, thus making the 16.04 grub version the one on the hard drive.
8. Reboot to both installs to test.

Done.

My solution here, since I often add new installs and delete old ones, was to make a dedicated grub partition that holds the grub file and grub.cfg. Then when I do a new install, I allow it to install grub to a second drive so it doesn't wipe my special grub off the main boot drive. Then I manually edit the grub,cfg to add the new install and remove any old ones. Since I boot this way, ALL my installs are in the custom menu. Here's what mine looks like:

### BEGIN Custom menu ###
menuentry 'KDE Neon' {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    configfile /@KDEneon/boot/grub/grub.cfg
}
menuentry 'KDE Neon - new' {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    configfile /@KDEneon_previous/boot/grub/grub.cfg
}
menuentry 'Kubuntu 16.04' {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    configfile /@Kubuntu_16_04/boot/grub/grub.cfg
}
menuentry 'Ubuntu 16.04' {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    configfile /@Ubuntu_16_04/boot/grub/grub.cfg
}
menuentry 'Manjaro free' {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    configfile /@Manjaro_free/boot/grub/grub.cfg
}
menuentry 'Manjaro nonfree' {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    configfile /@Manjaro_nonfree/boot/grub/grub.cfg
}
menuentry 'Memory test (memtest86+)' {
    insmod part_gpt
    insmod ext2
    search --no-floppy --fs-uuid --set=root 4bd4447b-48df-43d8-9781-d444d68ce462
    knetbsd /boot/memtest86+.elf
}
menuentry 'Memory test (memtest86+, serial console 115200)' {
    insmod part_gpt
    insmod ext2
    search --no-floppy --fs-uuid --set=root 4bd4447b-48df-43d8-9781-d444d68ce462
    linux16 /boot/memtest86+.bin console=ttyS0,115200n8
}
menuentry 'KDEneon ISO' {
    set isofile="/neon-useredition-20170608-2351-amd64.iso"
    loopback loop (hd0,2)$isofile
    linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
    initrd (loop)/casper/initrd.lz
}
### END Custom menu###

Note a couple things: All the installs are using the same UUID except the last 3. This means they all reside on the same btrfs file system. The last 3 are memtest which I put on the grub partition so I didn't have 6 or more duplicate copies of it installed everywhere (I can be a little OCD about that sort of thing) and a bootable ISO entry that I occasionally play with. Since I am using nested grub menus, I set the menu timeout to 3 seconds so if I reboot and walk away, grub only takes 6 seconds (3 secs. time 2 menus) to get to the boot process.

If you really want to dive into the multi-booting value of btrfs, the next step would be to re-name the 17.10 subvolumes and prepare for your next install. Really, it only requires editing fstab and grub.cfg to reflect the change in subvolume names.

[Qqmike]

These mild GRUB/fstab maneuvers are not unlike what we had to do with the GRUB Legacy in custom/special HDD setups. Like multi-booting. Like creating separate GRUB partitions. And so on. The was I always handle these things is to dummy them down. When you first do something, it looks obvious, it is fresh in your mind, and you can't imagine not understanding it or not being able to do it again successfully. Several months down the road, of course, most of us do NOT recall those exact steps (or the logic behind them), and it feels like you are having to do them for the very first time.

My Rx is simple and obvious:

Write the steps down on a piece of paper (Or, OK, if you must, in your phone/tablet/laptop/PC--memo), and file that paper under something like "Kubuntu set-up," or some such.
Step by step, including notes/logic/links where needed, and so on. Done in such a way that even if you don't understand or you forget the why's, it is clear enough that you can perform the monkey motions--step by step--to simply DO it successfully. This disarms a PITA to just another simple, quick and mundane task.

(Btw, for the newer UEFI-GRUB booting, I also keep such quick-and-dirty cheat sheets.)

[GreyGeek]

I second Oshunluver's recommendations!
EXT4 is so 20th century. LOL!