problem using incremental backup to external hd

[oldgeek]

A normal Kubuntu installer written to a USB doesn't use grub, IIUC. My reaction is that if you get to grub you haven't pressed the right key at the right time.

Here are my steps. I plug in the USB with Kubuntu, then turn on the machine. When the first screen pops up, I hit F12 to get to the Bios. I select the USB listed as the boot device, then hit Enter. I almost immediately get a Grub screen, which freezes the computer up and I can't do anything but shut it off. The Grub, I assume, is from the live USB. I have a UEFI bootloader on the internal HD, but not on the USB. Never needed it before, This used to work just fine, as I always do a clean install of new OSs. I feel more comfortable using the USB than writing scripts I don't understand. What am I doing wrong?

[Snowhog]

When you say you get a Grub screen, do you mean you are presented with a Grub Menu, or something else?

[oldgeek]

Grub menu. What one usually sees first.

[oldgeek]

OK, sorry to waste people's time, but the error was mine. I'm not familiar with the Bios menu, and there is a selection to boot from from UEFI. I did that, and got into the live USB. So I tried to do the relink method using the jlittle's suggestions (post 4) but couldn't get past this line: sudo btrfs create @home_new. Instead, I got an error message saying there was no token create. What happened?

[oldgeek]

Update: After fiddling around a little, I finally got everything to work, including the reflink procedure in post #4. However, after finishing, I was unable to umount /mnt/top, a message said it was busy. It kept being busy for quite awhile afterwards, and then I accidentally closed Konsole before finishing everything. I could not boot past the login screen after that, until I did the rollback procedure and got it up and working again. So I presume I'm where I was before the problem with incremental backups started. What I need to know is why I couldn't unmount /mnt/top after following the procedure for reflink? I am also unable to delete the @old subvolume created when I did the rollback..again, it says it can't destroy it because it's not empty. Why is my filesystem so hyperactive?

[jlittle]

Yesterday I said I'd do a custom.cfg that would let you do an iso boot to get around USB problems. I didn't get to it till quite late, and I always try to test code that I post, and it didn't work. I wasted a lot of time I should have been sleeping. Today, I've worked out what was wrong. I'd struck a bug in the version of grub I was running, that I knew all about in April 2020, but had completely forgotten. I'd made notes back then, but it just didn't occur to me to check them. Anyway, I see that oldgeek has got past the booting of the USB, but it will be good to have this on KFN so that I can suggest it to others, so here it is. Put the following in a file called /boot/grub/custom.cfg:

menuentry "ubuntu iso" {
    search --set=root --label "main"
    set isofile="jammy-desktop-amd64.iso"
    set isopath="/@/boot/$isofile"
    loopback loop ($root)$isopath
    linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isopath noprompt noeject
    initrd (loop)/casper/initrd
}

This assumes the iso has been copied into /boot on a system with @ as the root subvolume. (It's better IMO to put isos in a subvolume created for the purpose, but anywhere that you don't want to manipulate will do.) You'd want to edit the iso file name, and the search line to match the label of the btrfs partition, or change "--label" to "--fs-uuid" and give the UUID as shown by sudo blkid.