Release upgrade from 20.04 to 22.04 possible without issues?

[dieter-erich]

Hi, I have a 20.04 Ubuntu Mate installation under Win7 that works just fine. Nevertheless, I am considering upgrading to 22.04. Is this possible without issue by just using 'release upgrade'? The laptop is old (sic Win7) and does not have Bitlocker! Thanks, best, Dieter

[hakuna-m]

Honestly, I have never tried an upgrade from 20.04 to 22.04. But we changed some patches for 22.04 because package lupin-support has been dropped since 22.04

So probably it is a good idea to install the new patches and remove package lupin-support as workaround for possible issues.

We need 3 changed patches:

1) grub-install -> /usr/local/sbin which does not install GRUB in MBR or EFI partition 2) grub-mkimage-lupin -> /usr/local/sbin which creates wubildr on Windows partition 3) 10_lupin -> /etc/grub.d which creates the Grub menu entries for Wubi

As you see the 3 patches avoid to install GRUB in MBR or EFI partition and an empty GRUB menu. Here is a possible way to change the patches in 20.04 to that one which are used in 22.04:

# create temporary directory and use it
cd $(mktemp -d)
# download patches
wget https://raw.githubusercontent.com/hakuna-m/wubiuefi/master/data/custom-installation/patch/grub-install
wget https://raw.githubusercontent.com/hakuna-m/wubiuefi/master/data/custom-installation/patch/grub-mkimage-lupin
wget https://raw.githubusercontent.com/hakuna-m/wubiuefi/master/data/custom-installation/patch/10_lupin
# make it executable
sudo chmod +x grub-install
sudo chmod +x grub-mkimage-lupin
sudo chmod +x 10_lupin
# change owner
sudo chown root:root grub-install
sudo chown root:root grub-mkimage-lupin
sudo chown root:root 10_lupin
# copy patches to /usr/local/sbin
sudo mv grub-install /usr/local/sbin/grub-install
sudo mv grub-mkimage-lupin /usr/local/sbin/grub-mkimage-lupin
# remove unused patch
sudo rm /usr/local/sbin/grub-install-efi
# remove unused package
sudo apt-get remove lupin-support
# add grub entries for Wubi
sudo mv 10_lupin /etc/grub.d/10_lupin
sudo update-grub

As you know it is also a good idea to make a backup of /ubuntu/disks/root.disk before fixing and upgrading.

[dieter-erich]

Thank you! I'll try sometimes in the next days and report!------------------------------------------------------------------------Dieter Blaas,Max Perutz LaboratoriesMedical University of Vienna,Inst. Med. Biochem., Vienna Biocenter (VBC),Dr. Bohr Gasse 9/3,A-1030 Vienna, Austria,Tel: 0043 1 4277 61630,Mobile: 0043 699 1942 1659e-mail: @. -------- Ursprüngliche Nachricht --------Von: hakuna matata @.> Datum: 18.07.23 21:04 (GMT+01:00) An: hakuna-m/wubiuefi @.> Cc: dieter-erich @.>, Author @.***> Betreff: Re: [hakuna-m/wubiuefi] Release upgrade from 20.04 to 22.04 possible without issues? (Issue #337) Honestly, I have never tried an upgrade from 20.04 to 22.04. But we changed some patches for 22.04 because package lupin-support has been dropped since 22.04 So probably it is a good idea to install the new patches and remove package lupin-support as workaround for possible issues. We need 3 changed patches:

grub-install -> /usr/local/sbin which does not install GRUB in MBR or EFI partition grub-mkimage-lupin -> /usr/local/sbin which creates wubildr on Windows partition 10_lupin -> /etc/grub.d which creates the Grub menu entries for Wubi

As you see the 3 patches avoid to install GRUB in MBR or EFI partition and an empty GRUB menu. Here is a possible way to change the patches in 20.04 to that one which are used in 22.04:

create temporary directory and use it

cd $(mktemp -d)

download patches

wget https://raw.githubusercontent.com/hakuna-m/wubiuefi/master/data/custom-installation/patch/grub-install wget https://raw.githubusercontent.com/hakuna-m/wubiuefi/master/data/custom-installation/patch/grub-mkimage-lupin wget https://raw.githubusercontent.com/hakuna-m/wubiuefi/master/data/custom-installation/patch/10_lupin

make it executable

sudo chmod +x grub-install sudo chmod +x grub-mkimage-lupin sudo chmod +x 10_lupin

change owner

sudo chown root:root grub-install sudo chown root:root grub-mkimage-lupin sudo chown root:root 10_lupin

copy patches to /usr/local/sbin

sudo mv grub-install /usr/local/sbin/grub-install sudo mv grub-mkimage-lupin /usr/local/sbin/grub-mkimage-lupin

remove unused patch

sudo rm /usr/local/sbin/grub-install-efi

remove unused package

sudo apt-get remove lupin-support

add grub entries for Wubi

sudo mv 10_lupin /etc/grub.d/10_lupin sudo update-grub

As you know it is also a good idea to make a backup of /ubuntu/disks/root.disk before fixing and upgrading.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[shaddybaddah]

I accidentally did this quite some time ago. Everything works ok, except I have to manually change the Grub linux kernel entry so that the command line contains rw instead of ro.

Otherwise I run into two problems, which after an early and brief investigation, I misdiagnosed.

Before I describe those, note, lupin-support remains as a remnant from the 20 LTS install, so grub and mkimage etc all work ok.

The first problem, which differs from 20 LTS is, for some reason, if root.disk journal needs fsck repair, it doesn't occur. And instead, I'm dropped into busybox-initramfs.

Feb 27 22:19:34 a-ubu22l kernel: EXT4-fs (loop0): INFO: recovery required on readonly filesystem
Feb 27 22:19:34 a-ubu22l kernel: EXT4-fs (loop0): INFO: write access unavailable, cannot proceed (try mounting with noload)
<busybox complains about non-existent root mount>

(I am certain that the noload option will not help, but happy to be corrected) I was leaning to this being an e2fsprogs change, but I came back and edited this, because as I'll mention below, I suspect there is something else happening with a default r/w mode for loop devices??? Though... looking on 20 LTS, this is how it deals with the problem:

Feb 27 22:22:16 g-ubu20l kernel: EXT4-fs (loop0): INFO: recovery required on readonly filesystem
Feb 27 22:22:16 g-ubu20l kernel: EXT4-fs (loop0): write access will be enabled during recovery
Feb 27 22:22:16 g-ubu20l kernel: EXT4-fs (loop0): recovery complete
Feb 27 22:22:16 g-ubu20l kernel: EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)

I can get the filesystem cleaned by just doing the fsck manually:

(initramfs) losetup /dev/loop0 /host/ubuntu/disks/root.disk
<output (that isn't logged in journal) like: [   S.MS] loop0: detected capacity change from 0 to XX>
(initramfs) fsck /dev/loop0
<fsck output, free inodes, blocks, etc>

Of course, if I have specified rw as described, I encounter no such issue:

Feb 28 00:24:42 a-ubu22l kernel: EXT4-fs (loop0): recovery complete
Feb 28 00:24:42 a-ubu22l kernel: EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.

On to the mode for loop device r/w defaults... I am investigating as I type, but it wouldn't seem to make sense to me that this changed on kernels for 22 LTS but not 20 LTS. The second problem lends itself to this being the case though, because, if I clean the root filesystem, and ctrl-alt-del, rinse and repeat, I now get past the fsck, but I am dropped into single user mode as root cannot be remounted rw.

And I see this in the journal that systemd-remount-fs.service failed. And systemctl status systemd-remount-fs indicates that (typing this in from the screen):

mount: /: cannot remount /host/ubuntu/disks/root.disk read-write, is write-protected.

This is confusing to me. /host is definitely writable. That leaves me thinking of two options... when /dev/loop0 was setup, it was against root.disk on a ro mounted /host... which I didn't think possible at all. But if it was possible, that means that the backing file for /dev/loop0 and not the device is in read-only mode.

The other is that /dev/loop0 device is in read-only mode... but that also doesn't make sense to me, because it is obviously capable of being in a read-write mode, as evidenced by the success if I specify rw on the linux command line.

Note: I can't remount manually either.

In any case, for posterity, here's the 20 LTS output, which is good:

Feb 27 23:12:04 g-ubu20l systemd[1]: Starting Remount Root and Kernel File Systems...
..
Feb 27 23:12:04 g-ubu20l systemd[1]: Finished Remount Root and Kernel File Systems.

$ systemctl status systemd-remount-fs
● systemd-remount-fs.service - Remount Root and Kernel File Systems
     Loaded: loaded (/lib/systemd/system/systemd-remount-fs.service; enabled-runtime; vendor preset: enabled)
     Active: active (exited) since Tue 2024-02-27 23:12:04 AEDT; 1h 58min ago
       Docs: man:systemd-remount-fs.service(8)
             https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
    Process: 325 ExecStart=/lib/systemd/systemd-remount-fs (code=exited, status=0/SUCCESS)
   Main PID: 325 (code=exited, status=0/SUCCESS)

Feb 27 23:12:04 g-ubu20l systemd[1]: Finished Remount Root and Kernel File Systems.

Anyway, I thought documenting this might be helpful. Main thing is, either remember to edit your linux command line manually each time, or do it in /boot/grub/grub.cfg everytime it gets re-written, say on a kernel upgrade.

[shaddybaddah]

Sorry, I just realised that I was a little bit terse in my opening.

I accidentally did this quite some time ago. Everything works ok, except I have to manually change the Grub linux kernel entry so that the command line contains rw instead of ro.

I mean of course, the upgrade from 20 LTS to 22 LTS. Also, I realise that I also have a faulty memory.

Otherwise I run into two problems, which after an early and brief investigation, I misdiagnosed.

I didn't misdiagnose.. I forgot. I believe the issue stems from this change to initramfs-tools which I observed before. On 20 LTS

/usr/share/initramfs-tools/scripts/local:273:           loopdev=`losetup -f`; losetup ${loopdev} "/host/${LOOP#/}"; mount ${roflag} -t ${FSTYPE} ${LOOPFLAGS} ${loopdev} "${rootmnt?}"

against 22 LTS:

/usr/share/initramfs-tools/scripts/local:263:           mount ${roflag} -o loop -t ${FSTYPE} ${LOOPFLAGS} "/host/${LOOP#/}" "${rootmnt?}"

I now remember... I think the 22 LTS change was made with good intentions. It's concise and accordingly, seems optimal against 20 LTS. But, without having tested myself, I suspect that using mount with the loop option induces it to setup the loop device as if this had been issues:

$ losetup -r /dev/loop0 /host/ubuntu/disks/root.disk

I remember now why I didn't pursue this... I imagined if I raised this against Ubuntu's initramfs-tools package, I wouldn't get much help because 22 LTS isn't supposed to have lupin support... and if I'm right, there is no other context in which this code would have remained in 22 LTS. So I would be alerting them to remnant code that might be disappeared. I will test my own fix for this and report.

[shaddybaddah]

Sorry, yep, reverting that line temporarily, fixed it. So I guess there's two options for wubiuefi... a package to divert script/local to a fixed version, or... and i'll have a look into this myself, an attempt to appeal to authority to get upstream to revert this.

I really have to understand why they made this change... and what it could have been tested against in 22 LTS. It surely couldn't have been a completely theoretical change.

[shaddybaddah]

https://github.com/hakuna-m/wubiuefi/blob/1da9c1ccd10a6ec193857c953274eabdd64d5f6b/data/custom-installation/patch/loop-remount#L20

Oops. I see that the 20 LTS was patched by wubiuefi. Egg on face moment.

[shaddybaddah]

Hi. Just for closure here. I now believe I understand why my 20.04 to 22.04 in-place upgrade failed. It's because of https://github.com/hakuna-m/wubiuefi/issues/169. My installation initially began with 18.04, and I believe I must have encountered the same (minor and easily solvable) issue after upgrade to 20.04. And I plowed on anyway to 22.04.

Because the /etc/initramfs-tools/hooks/loop-remount file from 18.04 that remained there, doesn't actually modify /usr/share/initramfs-tools/scripts/local in-place.

So the gotchya should be for the upgrade from 18.04 to 20.04 (along side overcoming being trapped in a grub-pc error dialog on LTS upgrade via graphical means (must kill the postinstall process)).

Sorry for the noise.