REVISITING - More BTRFS fun Multibooting to subvolumes - FIXING GRUB

[steve7233]

Finally!!!

steve7233@steve7233-HP-dv6-US:~$ mount |grep btrfs
/dev/sda5 on / type btrfs (rw,relatime,space_cache,subvolid=277,subvol=/@kubuntu1704)
/dev/sda5 on /home type btrfs (rw,relatime,space_cache,subvolid=278,subvol=/@kubuntu1704_home)
steve7233@steve7233-HP-dv6-US:~$

I updated grub and rebooted. All is well! By the way I noticed a reboot bug during the last reboot. It seemed to hang about the end of the process. I had to power reset then startx a few times then it corrected itself -No Kwin -. I rebooted again then everything worked. I waited until I was sure it booted properly then run grub-update and rebooted. Now for a break.

[steve7233]

grub.cfg had a couple of typos that everyone kept overlooking. Uppercase K when lower was used in the sub volume name.

[steve7233]

Ahh, I Forgot the last part in the name. I'll fix that and reboot. I was watchingSeason 3 of Dark Matter on Netflix on the big monitor and must have got side tracked by the action.
I can see the head lines now: "Dark Matter causes Kubuntu 17.04 boot error!"

[vinnywright]

@Vinney apparently you missed the part where I said that kate failed to save the changes even thought kate said it was saving them.

no I did not miss it ,,,,I was just telling how I new from your info what was what .

did you do the edits from a live system (the installation media) or the running system ?

VINNY

[steve7233]

@Vinney apparently you missed the part where I said that kate failed to save the changes even thought kate said it was saving them.

[vinnywright]

from your "mount" output it dose not appear that you did rename the subvolumes ,,,,if you had their would be no @ to mount .

your grub config looks good for the FIRST boot ,,,,,,but since you booted from the "advanced options " at the boot screen you were in a different part of the grub menu than that that you edited.

the grub should be good,,,,,you got the "You need to boot the kernel first." because you did not rename the subvolumes and grub was looking for the renamed names (@Kubuntu1704) and could not find it .

make sure the /etc/fstab is edited as well ,,,,,,,I do not thik it is @now ,,,,,,,or you would not have been able to boot on the advanced options either as the system would be trying to mount @Kubuntu1704 ,,,and their is none .

VINNY

[steve7233]

Yes I edited fstab. They changes appear not have taken effect. I specifically selected save from the file menu. Is there a bug in Kate or something? When I edited grub I clicked on the close button in the title bar and selected save. Maybe the menu is bugged, but closing via the title bar button and selecting save works.

[steve7233]

I'm not clear on what you mean by "It doesn't seem to be loading the new volumes. Why not?" because you don't say why you believe that to be the case. Assuming the above is from your grub.cfg, it looks normal to me.

What's the output of "mount" once you've booted?
Did you edit @Kubuntu1704/etc/fstab to show the new subvolume names?

If you managed to get it to boot and you've edited the correct fstab and the mounts are correct - then run "sudo update-grub" and it will "fix" grub.cfg for you and you should be good to go.

steve7233@steve7233-HP-dv6-US:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1964336k,nr_inodes=491084,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=397444k,mode=755)
/dev/sda5 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=13020)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/sda5 on /home type btrfs (rw,relatime,space_cache,subvolid=258,subvol=/@home)
tmpfs on /run/user/119 type tmpfs (rw,nosuid,nodev,relatime,size=397440k,mode=700,uid=119,gid=127)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=397440k,mode=700,uid=1000,gid=1000)

[oshunluvr]

I'm not clear on what you mean by "It doesn't seem to be loading the new volumes. Why not?" because you don't say why you believe that to be the case. Assuming the above is from your grub.cfg, it looks normal to me.

What's the output of "mount" once you've booted?
Did you edit @Kubuntu1704/etc/fstab to show the new subvolume names?

If you managed to get it to boot and you've edited the correct fstab and the mounts are correct - then run "sudo update-grub" and it will "fix" grub.cfg for you and you should be good to go.

[steve7233]

Slight boot problem. 'You need to boot the kernel first.' After that it went to the boot menu. I selected advanced options and the top kernel. Kubuntu booted properly after that.
Snippit from grub.cfg

menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-27a9a212-d177-4665-b6bc-bf304e8c1f3e' {
	recordfail
	load_video
	gfxmode $linux_gfx_mode
	insmod gzio
	if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
	insmod part_msdos
	insmod btrfs
	set root='hd0,msdos5'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5  27a9a212-d177-4665-b6bc-bf304e8c1f3e
	else
	  search --no-floppy --fs-uuid --set=root 27a9a212-d177-4665-b6bc-bf304e8c1f3e
	fi
       linux	/@Kubuntu1704/boot/vmlinuz-4.10.0-35-generic root=UUID=27a9a212-d177-4665-b6bc-bf304e8c1f3e ro rootflags=subvol=@Kubuntu1704  quiet splash $vt_handoff
	initrd	/@Kubuntu1704/boot/initrd.img-4.10.0-35-generic
}

It doesn't seem to be loading the new volumes. Why not?

[steve7233]

3) Enter the new root subvolume and edit /etc/fstab and change the mount options from @ and @home to your new names.

[/FONT]

I would have had it if I had realized I was editing the wrong sub volume! Then I deleted it, when I deleted @. ... OK you can stop laughing now. I used to have a card that said "to error is human, but to really screw up is to use a computer." You would think with all my years of using computers I would notice that. It's always the simple things that we forget and then have to laugh about later when we realize. Thanks for helping me clear it up.

[oshunluvr]

Yeah, I guess I need to add a note there or something. Rename simply means "RENAME", as in the Linux command "mv <oldname> <newname>". I didn't anticipate this causing confusion to anyone and you're not the first who thought is was something special other than just renaming. I should also add a note about reading the btrfs command list - there's no rename command specially for btrfs. Here's my subvolumes on my main btrfs file system:

drwxr-xr-x 1 root root 286 Aug 23 11:32 @KDEneon
drwxr-xr-x 1 root root 286 Aug 23 11:32 @KDEneon_170925-145522
drwxr-xr-x 1 root root 288 Jun  7 09:36 @KDEneon_backup1
drwxr-xr-x 1 root root 288 Jun 23 15:29 @KDEneon_backup2
drwxr-xr-x 1 root root 302 Jun 30 07:58 @KDEneon_backup3
drwxr-xr-x 1 root root  48 Sep  6 16:46 @KDEneon_home
drwxr-xr-x 1 root root  48 Sep  6 16:46 @KDEneon_home_170925-145537
drwxr-xr-x 1 root root  38 Apr  1 09:30 @KDEneon_home_backup1
drwxr-xr-x 1 root root  38 Apr  1 09:30 @KDEneon_home_backup2
drwxr-xr-x 1 root root  38 Apr  1 09:30 @KDEneon_home_backup3
drwxr-xr-x 1 root root  48 Sep  6 16:46 @KDEneon_home_save1
drwxr-xr-x 1 root root 196 Jun 13 16:49 @KDEneon_new
drwxr-xr-x 1 root root  12 Jun 13 16:41 @KDEneon_new_home
drwxr-xr-x 1 root root 286 Aug 23 11:32 @KDEneon_save1
drwxr-xr-x 1 root root 286 Sep 22 13:49 @KDEneon_save2
drwxr-xr-x 1 root root 262 Dec 13  2016 @Kubuntu_16_04
drwxr-xr-x 1 root root  32 Dec 22  2016 @Kubuntu_16_04_home
drwxr-xr-x 1 root root 282 Jun 27 09:31 @Manjaro_free
drwxr-xr-x 1 root root  12 Jun 11 08:11 @Manjaro_free_home
drwxr-xr-x 1 root root 216 Jun 10 11:55 @Manjaro_nonfree
drwxr-xr-x 1 root root  12 Jun 10 11:49 @Manjaro_nonfree_home
drwxr-xr-x 1 root root 234 Jun 13 17:21 @Ubuntu_16_04
drwxr-xr-x 1 root root  12 Jun 13 16:14 @Ubuntu_16_04_home

Six of these are subvolumes I can boot to, the rest are homes or snapshots.

As far as "cloning" a subvolume, you're mixing tasks. There's really no need to ever "clone" (as in make-a-full-copy-of) a subvolume because taking a snapshot does it better and faster and without error. To expand a bit:

You can take a "snapshot" of a subvolume which is effectively a full copy of a subvolume. The only rules are the snapshot must be on the same btrfs file system. So if your subvolume @ is on a file system on sda2, the the snapshot of it must also be on sda2. You can copy a subvolume snapshot from one file system to another (a different partition or drive) IF the snapshot is read-only - Then you can use the btrfs send|receive commands to transmit a read-only snapshot from one btrfs file system to another. In my list above, the subvolumes ending in ".backup." are read-only backups that have been transmitted to another file system (my backup btrfs drive) without yet deleting them.

So, steve7233, back to your issue: Assuming you now have a working copy of 17.04 installed to a btrfs file system using the default @ and @home subvolumes. For the list below, I will use /dev/sda2 as the partition that your btrfs file system resides on and assume you will use @Kubuntu1704 as your new subvolume name. Obviously, use the correct partition device name and whatever new subvolume names you want when you actually do this:

1) Mount the parent btrfs file system somewhere.

sudo mkdir /mnt/parent
sudo mount /dev/sda2 /mnt/parent
cd /mnt/parent

You are now in the parent file system. To verify all is well, a simple directory listing will work:

ls

the result should be

@ @home

2) Snapshot (regular, not read-only) both subvolumes using your desired new subvolume names.

sudo btrfs subvolume snapshot @ @Kubuntu1704
sudo btrfs subvolume snapshot @home @Kubuntu1704_home

Now a directory listing (ls command) results in:

@ @home @Kubuntu1704 @Kubuntu1704_home

You now have two copies of your install and your home. At this point, note a few things: Your snapshots have not taken any additional space on your drive. The snapshot will not change as you make changes to the source subvolume and the source subvolume will not change if you change something in the snapshot. A snapshot is an exact subvolume copy frozen at the time it was made. So if you delete a file in @home it will still be in @Kubuntu1704_home and vice-versa. As you make changes to either the source or the snapshot subvolume, the snapshot subvolume will begin to consume space on the drive.

3) Enter the new root subvolume and edit /etc/fstab and change the mount options from @ and @home to your new names.

kate @Kubuntu1704/etc/fstab

Find the two lines that are similar to:

UUID=8f0c1661-4e84-4512-b875-23bcfd5be1d8 / btrfs rw...subvol=@ 0 1
UUID=8f0c1661-4e84-4512-b875-23bcfd5be1d8 /home btrfs rw...subvol=@home 0 2


Edit the subvol=@ to subvol=@Kubuntu1704 and @home to @Kubuntu1704_home and save.

MAKE ABSOLUTELY SURE there are no typos in these edits and have a bootable device handy as a backup.

4) Enter /boot/grub/grub.cfg and manually edit the boot menuentry to reflect the new root subvolume name.

sudo chmod u+w /boot/grub/grub.cfg
kate /boot/grub/grub.cfg

In this file, find this line (usually about line 133) :

### BEGIN /etc/grub.d/10_linux ###

Then look about 25 lines lower for a line beginning with:

linux /@/boot/vmlinuz...

and ending with:

....rootflags=subvol=@

Change@ in both places to @Kubuntu1704 and also one line lower you'll see /@/boot/initrd... Change that to @Kubuntu1704 also, and save the file.

If you've done everything correctly, at this point you should be able to reboot and you'll be using the snapshot subvolume instead of the previous @ and @home. To verify this, simply list your mounts and look at what mount options are in place:

mount |grep btrfs

The output should be similar to:

/dev/sda2 on / type btrfs (rw...subvol=/@Kubuntu1704)
/dev/sda2 on /home type btrfs (rw...subvol=/@Kubuntu1704_home

I shortened the output to just show the last bit where the subvolume is indicated.

Assuming all is as expected, run update-grub so all your grub menuentries are pointing to the new subvolumes:

sudo update-grub

At this point, you can keep @ and @home or install over them or delete them and @Kubuntu1704 and @Kubuntu1704_home will not be touched.

[steve7233]

I have 17.04 installed now. Before I can try multi booting I first need to figure out what I did wrong and what I should have done.

[steve7233]

COW will give VB fits unless you turn it off for the folder in which your plan on placing your virtual HDs. Or, my approach, was to create static virtual HDs preset to a fixed size, usually 40-60Gb, depending on what I planned to do with the virtual OS. That way the dynamic change of HD size is avoided and BTRFS is happy.

I always use fixed disks anyway since they work better in VB, plus you don't risk running out of host disk space.

[GreyGeek]

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?

COW will give VB fits unless you turn it off for the folder in which your plan on placing your virtual HDs. Or, my approach, was to create static virtual HDs preset to a fixed size, usually 40-60Gb, depending on what I planned to do with the virtual OS. That way the dynamic change of HD size is avoided and BTRFS is happy.