An early xmas present: 6.1 kernel

[treebeard]

If you care for a stroll on the bleeding edge, A 6.1 kernel for the Pinephone has landed.

Download the deb, do a "sudo dpkg -i linux-image-6.1-sunxi64_6.1+sunxi64-1_arm64.deb", then reboot and you should be good. Do "uname -a" to check. The install doesn't overwrite anything related to the 5.15 kernel but will add a stanza to /boot/extlinux/extlinux.conf for the 6.1 kernel as the default entry. If you want/need to switch back to 5.15, changing the default selection should do it.

I'm hoping this might fix, or at least reduce, the "fail to wake" problems and perhaps take care of the spontaneous reboots as well. In any case, it sounds like 6.1 will be the kernel released in bookworm.

I've only been running it a couple hours but have gone through my usual post-upgrade checklist with no new issues. I haven't tested any bluetooth stuff.

[zetabeta]

sort of good news. i have been wondering why mobian is stuck at 5.15 kernel.

[Zebulon Walton]

If you care for a stroll on the bleeding edge, A 6.1 kernel for the Pinephone has landed.

Interesting, will have to give it a try. I'm doing an image backup of the eMMC while writing this and keeping my emergency SD card handy...

---

...OK, I'm up and running on the 6.1 kernel. Haven't noted any changes but what was working appears to still be working. Audio on calls works but no volume control. Bluetooth audio not working. We'll see how it goes. A possible issue is that there is now only 34MB free space on my /boot partition, though once satisfied 6.1 is working OK I can always delete the older kernel.

[Zebulon Walton]

Turns out the small /boot partition is going to be a real problem. I figured since I had a current image backup and the new kernel, might as well run updates. One of the updates was for the 5.15 kernel, so initramfs bombed out creating the initrd.img files due to lack of space. Tried removing the 5.15 kernel but apt wanted to also uninstall the pinephone-support package, so I didn't do that.

So I removed the 6.1 kernel, ran dpkg-reconfigure for the 5.15 kernel to rebuild initrd.img, and all is OK for now running on 5.15.

Since I'm using full disk encryption I believe it would require deleting the current eMMC installation and installing everything from scratch to make /boot larger - a major pain in the rear.

[wibble]

You should be able to resize the encrypted partition(s) but you'll need to boot from SD to do it as you can't do it while the partition is mounted. I'm assuming it's using LUKS rather than native filesystem encryption. Its a multi-step process as the partition management tools don't yet handle it natively, but it can be done, and there are plenty of tutorials around.

[Zebulon Walton]

You should be able to resize the encrypted partition(s) but you'll need to boot from SD to do it as you can't do it while the partition is mounted. I'm assuming it's using LUKS rather than native filesystem encryption. Its a multi-step process as the partition management tools don't yet handle it natively, but it can be done, and there are plenty of tutorials around.

I'll look into that. (It is LUKS encryption.) I have a current image backup so it won't hurt to do some experimentation.

Another way might be to delete the main partition and expand the boot partition to a desired size like maybe 500MB. Then create a new main partition with LUKS encryption and copy the entire backed-up filesystem to it.

[treebeard]

You should be able to resize the encrypted partition(s) but you'll need to boot from SD to do it as you can't do it while the partition is mounted. I'm assuming it's using LUKS rather than native filesystem encryption. Its a multi-step process as the partition management tools don't yet handle it natively, but it can be done, and there are plenty of tutorials around.

I'll look into that. (It is LUKS encryption.) I have a current image backup so it won't hurt to do some experimentation.

Another way might be to delete the main partition and expand the boot partition to a desired size like maybe 500MB. Then create a new main partition with LUKS encryption and copy the entire backed-up filesystem to it.

I'm using FDE as well, but my /boot is about 480MB.  I think I used the 20210815 image.  Perhaps the developers expanded that at some point but you're using an older image?

If you do try to enlarge /boot, be aware that the UUIDs for the /boot & / file systems and the LUKS container must stay the same.  Those UUIDs are in /etc/fstab and /etc/crypttab and get embedded inside the initrds so it gets complicated if they change.  My notes say that the partition UUIDs are not relevant. When creating a filesystem you can use the "-U" switch to set the UUID and cryptsetup has "--uuid" for that.

[Zebulon Walton]

If you do try to enlarge /boot, be aware that the UUIDs for the /boot & / file systems and the LUKS container must stay the same.  Those UUIDs are in /etc/fstab and /etc/crypttab and get embedded inside the initrds so it gets complicated if they change.  My notes say that the partition UUIDs are not relevant. When creating a filesystem you can use the "-U" switch to set the UUID and cryptsetup has "--uuid" for that.

I figured that would be the case, I've documented the needed UUID info. I'll also use the same label "root") for good measure though I don't think that's used. Thanks for confirming the partition UUIDs aren't needed.It looked that way to me but I wasn't certain. The boot partition UUID won't change since I'll be enlarging that partition and filesystem rather than deleting and re-creating it. As far as I can tell LVM is not being used so that's one less thing to worry about.

Now I just have to find the time to do it...

[Zebulon Walton]

Well - it almost worked.

The first gotcha was that I created the new ext4 filesystem using the old UUID but did not do that for the LUKS encrypted partition. (With full disk encryption it's the UUID of the LUKS encrypted partition that is looked for at boot time.) Once that was fixed using cryptsetup the phone booted up and everything seemed to be there. The boot partition is now 512MB, which should be plenty.

BUT - now the phone "thinks" the battery is at 0% charge so the modem and wifi will not come online. The last kind of problem I expected. I have two batteries and that's the case with both. Also the phone does boot up and otherwise run on the battery.

Spot-checking applications they seem to launch OK, except megapixels which bombs out saying it "could not find a /dev/media* node matching sun6i-csi". Checking. there are no /dev/media* files at all. Maybe a similar problem for the battery (device node missing)? Additionally when using the volume control it says the output device is "dummy output". So it does look like there is a device node problem going on here. Not sure why this would be since /dev entries have been created dynamically at boot time on Linux systems for a long time now. Expected entries for the eMMC and many other devices are there.

I had copied the backed-up Mobian system to the new filesystem using "cp -a" (the archive flag) to copy everything from the root of the drive while preserving permissions, so there should not be anything missing. Everything was done from a desktop Linux system with the phone connected via USB to access the eMMC.

Not sure what's going on here. If I can't figure it out will have to restore my image backup. In the meantime it's back to my emergency SD card.

[Zebulon Walton]

Current status: Fixed it. Hooking up the serial-to-USB diag cable while booting up yielded a bunch of module errors. I had forgotten that I'd run updates AFTER making my image backup, and the whole space problem was caused by a 5.15 kernel update coming in - so the modules on the backed-up root filesystem were now out of sync with the running kernel in /boot! D'oh!!

So, I replaced the entire contents of /boot with the /boot files from my image backup and now the phone works as it should. (Well, as it was working before anyway.)

Then I went ahead and installed the 6.1 kernel with plenty of space left on /boot for future kernel updates. Was it worth the aggravation? Are there any current advantages to running 6.1 at this time? Beats me, time will tell. But it's likely that at some point the small /boot partition would be a problem.

At least now I know it is possible to expand /boot when using full disk encryption with this method. It was just a bit less trouble than pulling teeth but knowing the "gotchas" now it would not take as long to do it again. Still, if you don't have a highly customized installation it might be faster and easier to just reinstall from scratch.

Steps are basically the following, done from a desktop Linux system or booted from an SD card:

1. Make image backup of eMMC. Make sure you can mount the root filesystem in the image.

2. Record UUIDs of the existing root LUKS partition and ext4 filesystem.

3. Delete root partition from eMMC

4. Expand /boot partition on the eMMC to desired size (I used Gparted and set the size to 512MB which is a bit of overkill. Might want to be more conservative with space on a 16GB eMMC.)

5. Create LUKS partition on remaining eMMC space using cryptsetup. Set UUID to be the same as the old LUKS partition.

6. Open the LUKS partition with cryptsetup and create an ext4 filesystem. Set UUID to be the same as the old filesystem and mount it. (I think it was the same as the UUID of the LUKS partition. At least that's the way it is now.)

7. From a root shell, "cp -a /old/root/filesystem /new/root/filesystem

8. Umount and close the new root filesystem on the eMMC and reboot.

Test the phone - if it works immediately make an image backup of the new setup!