REVISITING - More BTRFS fun Multibooting to subvolumes - FIXING GRUB

[steve7233]

Can VB handle BTRFS? If so then I can learn it via a VM then delete the VM and do it inm the host. Now why didn't I think of this sooner? Now that I think of it. Didn't some one suggest that in another thread?

[vinnywright]

LOL yup just what I thought .

he meant ,,,to literally just rename them ,,,,,rite click in dolphin>rename>and type in a new name for @ and @home like hear

vinny@vinny-Bonobo-Extreme:/media/vinny/ff5d66d4-35b6-4c9c-a64e-8dfbe2aa1e31$ ls
@  @17.04  @17.04snap  @home  @home17.04  @home17.04snap  ubiquity-apt-clone  var

the @17.04 and @home17.04 where named @ and @home ,when installed ,,,then I just renamed them as you see ,,,the CURENT @ and @home are a neon-LTS install ,,,,,,the @home17.04snap is a snapshot of @home17.04

VINNY

[GreyGeek]

It's called "paying your dues"!
Keep up the good work ... that's really how one learns.

[steve7233]

what exactly dose this mean?

befor you could not boot ? ,,,,,, after you could not boot ? ,,,,, is this what you did to "rename the subvolumes" ? ,,,,,,why did you create new subvolumes ?

I hope you did not think creating new subvolumes was the same as renaming the subvolumes the got installed as @ and @home ,,,,,,IF you deleted those 2 ,,,,,you are hosed .

+ you do not just delete a subvolume ,,,,you use the btrfs command "btrfs subvolume delete -c <path to the subvolume>"

VINNY

I read oshunluvr's several threads on mulltibooting and have been trying to figure all that out. Basicly he says to rename @ and @home then edit fstab and grub.cfg. I think I goofed in my method of renaming the subvolumes. I thought If I kept it simple I would avoid hosing my system. Unfortunatly it looks like I made a hosing mistake anyway. I thought I could clone @ and @home. I created @Kubuntu1404 and @homeKubuntu1404 then btrfs deleted the @ and @home. I rebooted after the file edits. All seemed fine. listing the sub volumes showed the orginal volumes were now marked as deleted and checking the mounts showed that @Kubuntu1404 and @homeKubuntu1404 were mounted and @ and @home were not.

Based on that, I thought I understood and then deleted the deleted ones. I rebooted and ... emergency mode I don't mind -to much-, having to reinstall as I have learned that occasionaly all Linux true Linux users hose themselves every now and then. . I just want to know what I did wrong and how to do it the correct way. Now I will go run the 16.04 install so I can try again hopfully with out borking my system this time. I look at it this way, So I made a silly mistake. Now I can help others to avoid the mistake and look like I know what I am doing to a Linux newbie. I just hope I have internet after the install.

I am learning how to fix a no internet machine with all these reinstalls!

[vinnywright]

Yes, btrfs subvolume delete. Was I supposed to run some other subvolume command after the btrfs delete? Maybe something to move meta data or something?

you did not answer the rest of the questions ,,,,that are more important ATM

VINNY

[steve7233]

what exactly dose this mean?

befor you could not boot ? ,,,,,, after you could not boot ? ,,,,, is this what you did to "rename the subvolumes" ? ,,,,,,why did you create new subvolumes ?

I hope you did not think creating new subvolumes was the same as renaming the subvolumes the got installed as @ and @home ,,,,,,IF you deleted those 2 ,,,,,you are hosed .

+ you do not just delete a subvolume ,,,,you use the btrfs command "btrfs subvolume delete -c <path to the subvolume>"

VINNY

Yes, btrfs subvolume delete. Was I supposed to run some other subvolume command after the btrfs delete? Maybe something to move meta data or something?

[vinnywright]

I can't boot Kubuntu. It gose in to rescue mode. I created a new subvolume for @ and @ home.

what exactly dose this mean?

befor you could not boot ? ,,,,,, after you could not boot ? ,,,,, is this what you did to "rename the subvolumes" ? ,,,,,,why did you create new subvolumes ?

Fstab.cgfg and grub.cfg are edited. I checked with Kubuntu live DVD. I deleted @ and @home. Before I rebooted I listed the subvo!umes @ and @home were deleted and in their place was the word deleted.

I hope you did not think creating new subvolumes was the same as renaming the subvolumes the got installed as @ and @home ,,,,,,IF you deleted those 2 ,,,,,you are hosed .

+ you do not just delete a subvolume ,,,,you use the btrfs command "btrfs subvolume delete -c <path to the subvolume>"

VINNY

[steve7233]

It won't boot now! Goes to emergency mode. I did a lot of google searches. Nothing worked. I read Ubuntu stuff on BTRFS multiboot, reloading and reinstalling GRUB2 to a BTRFS system. I tried boot-repair, but it had an install problem. I have a snapshots foldure but if I use those it might not boot if it is the same problem. I will goto the store and when I get back I will install Kubuntu 17.04. I will check this thread first incase some one thinks they can help fix Grub2. I tried purgeing and reinstalling Grub2 using chroot but get something like 'failed to get conical path to device.'.

[steve7233]

I can't boot Kubuntu. It gose in to rescue mode. I created a new subvolume for @ and @ home. Fstab.cgfg and grub.cfg are edited. I checked with Kubuntu live DVD. I deleted @ and @home. Before I rebooted I listed the subvo!umes @ and @home were deleted and in their place was the word deleted.

[oshunluvr]

If you are adventurous enough to have followed my previous post here on how to do multiple installs to a single BTRFS file system, you might be running into trouble booting to all your installs. I did mention there to edit 40_custom in the original post, but several people have missed that part, so here's a re-visit to just that piece of the process in greater detail:

The issue:
os-prober - the tool that GRUB uses to detect installs - does not look inside subvolumes to detect other installs. I doubt it ever will. My untested belief is, if you mounted each install first, then run os-prober, it might find them. Even if it did, it would be useless to you because they grub.cfg would have the mounts in it's menu - which wouldn't exist on the next reboot.

This write-up assumes the following:
You have installed several version of *buntus or a few select other distros that install to btrfs using subvolumes, Manjaro for example.
You have followed my previous post's instructions to rename the subvolumes to unique names.
You have installed grub with each install.
When you reboot after each install, you only see the latest distro in your grub menu.

Rest assured, as long as you don't select "Format this partition" during installation AND you have previously renamed the subvolumes from @ and @home to something else, they will still be there after the second (and beyond) installs to the same btrfs volume.

So here's the Catch 22: If you allow grub to be installed with each new installation, you will only be able to boot to the new install each time. If you don't allow grub to be install each time, you will only be able to boot to the installation that was last installed with grub. Is that clear?

Example:
First you install Kubuntu LTS.
You rename @ to @Kubuntu and @home to @Kubuntu_home and do the necessary edits to grub.cfg and fstab.
You boot to Kubuntu and run update-grub - and all is good.

Second install WITH grub installation:
You install Lubuntu 17.04 to the same btrfs file system and you install grub to the same boot device.
Upon reboot - you can only select Lubuntu

Second install WITHOUT grub installation (launch the installer with the -b switch to install without boot loader):
You install Lubuntu the same btrfs file system and grub is not installed.
Upon reboot - you can only select Kubuntu and Lubuntu doesn't have grub within it at all.

Either way, you're stuck, but there are several solutions - This is Linux after all

Solution 1:
Install grub every time to the same boot device (i.e. you're on a single disk system):

Install your primary OS (I'm assuming Kubuntu for this example), then install all the others you want - all of them with grub.

This ensures all the installations have all the necessary grub files to boot.

Follow the same renaming routine after each install - renaming @ and @home to something unique and editing fstab and grub.cfg as required (see the linked older post if you don't understand this).

After each install, reboot to the new install and edit /etc/grub.d/40_custom and add this to it:

menuentry 'Kubuntu' {
    insmod part_gpt 
    insmod btrfs
    search --no-floppy --fs-uuid --set=root <YOUR BTRFS UUID HERE>
    configfile /@Kubuntu/boot/grub/grub.cfg
}

Now make 40_custom executable and run update-grub.

This allows grub to switch another menu. Now when you reboot, Kubuntu is also available in the menu.
When you re-boot to Kubuntu, edit 40_custom in Kubuntu again, but now add each new installation to it.

For example, you have Kubuntu, Lubuntu and Manjaro all installed to the same btrfs filesystem using unique subvolumes, but you prefer to boot to Kubuntu on a daily basis.

Your 40_custom file under Kubuntu might look like:

menuentry 'Lubuntu 17.04' {
   insmod part_gpt
   insmod btrfs
   search --no-floppy --fs-uuid --set=root <YOUR BTRFS UUID HERE>
   configfile /@Lubuntu/boot/grub/grub.cfg
}
menuentry 'Manjaro' {
   insmod part_gpt
   insmod btrfs
   search --no-floppy --fs-uuid --set=root <YOUR BTRFS UUID HERE>
   configfile /@Manjaro/boot/grub/grub.cfg
}

As you install other distros, simply edit 40_custom under it and add your Kubuntu install, reboot to Kubuntu and add the new distro to 40_custom there as described above and you'll be able to boot to all of your installs.

Solution 2:
Install grub every time to a different boot device (you have more than one boot-able disk):

This is basically the same technique as above except when installing your primary boot distro, you install grub to your primary boot drive (usually sda).

When you install all the other distros, install grub to your second drive (usually sdb). This ensures all the necessary grub files are there with each distro but they're not "taking over" as the boot distro.

With this method, you need only edit 40_custom within your bootable installation (Kubuntu in the above example) and you needn't bother with 40_custom in any of the other installs.

GRUB NOTE: When you use grub this way - multiple menus - here are a couple tips:

• In each installation, make the grub menu visible (edit /etc/default/grub or /etc/grub.d/00_header depending on the distro).
• You can return to the previous menu from a secondary one with the ESC key.

CAVEAT: In both above solutions you are relying on a single distro to boot all the others. This is fine until you decide you no longer want the distro you're booting to. Don't forget, if you delete the boot-able install, you delete the grub files needed to boot along with it.

It's a simple matter to make any other of the distros the main boot-able install. Just copy your full 40_custom file over the the installation of choice, boot to it, run update-grub and then run grub-install. Verify you boot to the chosen distro by default, then delete the distro you no longer need.

Solution 3:
Make a bootable grub partition (another multi-disk solution):

This is my method but it's not the easiest to initially set up. I have more than one drive on my system, so I created and mounted a 128MB EXT2 partition on one of them (actually two of them so I have a boot-able backup drive). I copied /boot/grub from one install to this partition. Then ran grub-install with the --root-directory option pointing at the grub partition. Whenever I install a distro, I tell it to boot from sdc, but my boot drive is sda (sdb as backup) so my grub is never messed with.

Now regardless of deleting installs, I can always boot. I manually edit the grub.cfg on this bootable partition and add and subtract installs as I do them - using the same menuentry as you would in 40_custom. Here's the tail (the part after the header info) of my grub.cfg from that partition:

[FONT=monospace][COLOR=#000000]### BEGIN Custom menu ### [/COLOR]
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 fcc94981-05e4-4846-92e7-87bf9885178d 
   configfile /@KDEneon_new/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###

[/FONT]

You can see by the UUID that all my installs reside on the same UUID. I also moved MEMTEST to the grub partition so it's not installed 10 times and the last stanza allowed me to boot from an ISO without burning it to a USB or DVD first.

[#]btrfs[/#] [#]grub[/#] [#]multiboot[/#]