Trying to Boot 18.04 Once to Recover Vaults Data?

[PhysicistSarah]

I upgraded to 19.04 a few weeks ago and now I'm trying to downgrade to 18.04 temporarily.

I made backups of my system using btrfs backups to an external drive and then placed my old 18.04 @ and @home directories back on the original drive. They're both labelled appropriately (Not that I forgot to rename them from their backup names) and they're both read-write using

btrfs property

.

I can't get grub to boot it though. I even tried to boot from the grub command line using typical methods, but got stuck when the system mostly booted but I got an additional terminal saying that init wasn't found and I didn't know what to do from there.

I also tried our solution from: https://www.kubuntuforums.net/showth...ght=sarah+grub
but no dice.

I just need to get the system to boot once to recover the encrypted data, so I'm ok if you tell me to just do something at the grub command line to get it to boot. General solutions are fine too though.

Thanks

This is the screen when I choose default options in grub:


EDIT 1: There is also this error:

 kubuntu@kubuntu:/mnt/sdc$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0    7:0    0   1.7G  1 loop /rofs
sda      8:0    0 931.5G  0 disk 
└─sda1   8:1    0 931.5G  0 part 
sdb      8:16   0  22.4G  0 disk 
sdc      8:32   0 465.8G  0 disk 
├─sdc1   8:33   0   512M  0 part /mnt/sdc/@/boot/efi
└─sdc2   8:34   0 465.3G  0 part /mnt/sdc
sdd      8:48   0 931.5G  0 disk 
sde      8:64   1  14.9G  0 disk /cdrom
├─sde1   8:65   1   1.8G  0 part 
└─sde2   8:66   1   3.7M  0 part 
sdf      8:80   1   1.9G  0 disk 
└─sdf1   8:81   1   1.9G  0 part 
sr0     11:0    1  1024M  0 rom  
sr1     11:1    1     7M  0 rom  
kubuntu@kubuntu:/mnt/sdc$ sudo grub-install --boot-directory=@/boot/ --efi-directory=@/boot/efi/
Installing for x86_64-efi platform.
Installation finished. No error reported.
kubuntu@kubuntu:/mnt/sdc$ sudo update-grub
/usr/sbin/grub-probe: error: failed to get canonical path of `/cow'.

EDIT 2:

I found out that the UUID of the hard drive had changed since I did the install of 19.04, so I changed this in /sdc2/@/etc/fstab. Strangely, at boot time in grub, it still shows the old UUID in the error prompt. I figured that maybe it was going off an old fstab, so I deleted the boot entries using efibootmgr and then did the grub-install process using --boot-directory and --efidirectory parameters.

Grub-install went fine with no errors, but it still produced the same error at boot time. Still not sure what is up with it. Can't manually boot either.

Here are some pictures of what's happening:
(Manual Boot)


(Results of manual boot)


blkif & fstab:

# <file system> <mount point> <type> <options> <dump> <pass>

#Lesser Ark
UUID=8b2f117e-ed70-4405-9524-cac9c249da01    /            btrfs    defaults,noatime,nodiratime,compress=lzo,ssd,subvol=@        0    1
#UUID=423F-051C                               /boot/efi    vfat     umask=0077               0    1
UUID=8b2f117e-ed70-4405-9524-cac9c249da01    /home        btrfs    defaults,noatime,nodiratime,compress=zstd,ssd,subvol=@home    0    2
#UUID=45f9fe6b-ae81-47c7-bbd7-f9ca4ac66060    none         swap     sw                       0    0
#UUID=423F-051C    /boot/efi    vfat    defaults    0    1

#ELYSIUM
UUID=0f834b1e-78a4-4b8b-9528-3b6c3f5ae37b /media/sarah/ELYSIUM btrfs defaults,noauto,space_cache,compress=zstd,autodefrag,subvol=EternalFields    0    0

#SENTINEL
UUID=38e88d7b-d527-4784-8060-cfa456c27b13 /media/sarah/SENTINEL btrfs defaults,noauto,space_cache,compress=zstd 0 0

#Convergent Refuge
UUID=bae62e15-46d2-4aa4-84de-5f8bdd93c3e2 /media/sarah/ConvergentRefuge btrfs defaults,noatime,space_cache,compress=zstd 0 0

kubuntu@kubuntu:/mnt$ sudo blkid
/dev/sda1: LABEL="Convergent Refuge" UUID="bae62e15-46d2-4aa4-84de-5f8bdd93c3e2" UUID_SUB="55c809a3-a971-4736-94ef-a11e7f1a6172" TYPE="btrfs" PARTLABEL="Convergent Refuge" PARTUUID="9c3a4912-6cd5-4155-a78f-6356f1acb874"
/dev/sdc1: LABEL_FATBOOT="L_ARK_EFI" LABEL="L_ARK_EFI" UUID="423F-051C" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="78554a15-d0ad-4253-870d-2e13f9d5c1d8"
/dev/sdc2: UUID="8b2f117e-ed70-4405-9524-cac9c249da01" UUID_SUB="684c8b61-6133-4e74-a756-314c6c8c5054" TYPE="btrfs" PARTLABEL="Lesser Ark" PARTUUID="611080a8-55e8-4523-9128-bb5cc31c7750"
/dev/sdd: LABEL="SENTINEL" UUID="38e88d7b-d527-4784-8060-cfa456c27b13" UUID_SUB="719dea99-2f2d-4f58-acc1-fd959ca84c14" TYPE="btrfs"
/dev/loop0: TYPE="squashfs"
/dev/sdb: PTUUID="5f43f34d-52f6-4eeb-acd7-8dcc866c752d" PTTYPE="gpt"
/dev/sde1: UUID="2019-04-16-19-25-03-00" LABEL="Kubuntu 19.04 amd64" TYPE="iso9660" PTUUID="5ed9fb2f" PTTYPE="dos" PARTUUID="5ed9fb2f-01"
/dev/sde2: SEC_TYPE="msdos" UUID="039E-EF17" TYPE="vfat" PARTUUID="5ed9fb2f-02"
/dev/sdf1: SEC_TYPE="msdos" UUID="8B27-5FEE" TYPE="vfat"
/dev/sr1: UUID="2007-02-13-02-23-10-" LABEL="U3 System" TYPE="iso9660"

[jlittle]

...it still shows the old UUID in the error prompt...

I'm not sure I understand your problems generally, but I can point out that the UUID is used by grub* and is coded into /boot/grub/grub.cfg. So if you're editing /etc/fstab to fix the UUID there I suspect you need to fix it in grub.cfg too.

* I think it's the Debian use of grub that involves UUIDs. I dislike them a lot, and my use of grub doesn't have UUIDs (nor does my /etc/fstab files). Labels are simple and less error prone.

(A bit late now, but unless you're very restricted in space, leaving the old install intact by renaming @ and maybe @home, then installing without formatting the btrfs, would have made backing out of 19.04 just another rename.)

Sent from my Vodafone Smart ultra 6 using Tapatalk

[Worzel]

Found this which references the time at which the update-grub command is issued. The whole discussion may (or not) be of help.

https://www.linuxquestions.org/quest...ll-4175616085/

I lost about ten years of backup thru Vaults but my memory is going at a faster rate so ...

Jim

[PhysicistSarah]

I found the grub.cf file in sdc/@/boot/efi/EFI/ubuntu

It reads:

 search.fs_uuid 8b2f117e-ed70-4405-9524-cac9c249da01 root hd2,gpt2 
set prefix=($root)'/@/boot/grub'
configfile $prefix/grub.cfg

The UUID appears to be correct. Although I could only find it when I mounted the SDC1 partition. Not sure if this helps.

[jlittle]

I found the grub.cf file in sdc/@/boot/efi/EFI/ubuntu

That file is not used, as far as I've been able to tell. In any case it just invokes the one in @/boot/grub/grub.cfg,which is hundreds of lines long.

[PhysicistSarah]

Yep, I found the proper grub.cfg file. I don't know why I didn't see it before.

Anyway, it booted just fine after I used gedit's find and replace tool for the old UUID's with the new ones. I booted to the old OS and got the encrypted data and restored my new OS.

I don't know why update.grub wasn't working though. That probably would have done the same thing I was doing, but it was broken for some reason.

Thanks for the recommendation though!