[20:41] <alram> Hi! :-)
[20:42] <alram> a bit of a bummer happened today, I installed a bunch of regular apt update packages that were waiting and after that, my xubuntu 21.04 on the rpi4b booted into ... the rainbow screen of death
[20:42] <alram> https://paste.ubuntu.com/p/SXnzTTsNtS/
[20:43] <alram> i rsynced the boot partition and the files under /boot/ with 'rsync -rva' from another working ubuntu setup that runs from an external ssd as well that is pretty much from the identical source tree 
[20:44] <alram> since the rainbow screen hits like within 1 second or so after the FAT partition and the boot stuff is found, I'm kinda presuming it has something to do with the bootloader 
[20:45] <alram> the drive itself seems to work just fine and all that jazz 
[20:47] <alram> as I updated those packages, I had was prompted to restart a couple of services, I think it's the lightdm that's mostly a source of woes, I usually just reboot if I'm inside Xfce because a lightdm restart always just locks things up one way or another 
[20:47] <alram> (as in it's not reloading some desktop elements properly etc, that's why I often just reboot regardless of the 5.11 kerneltree)
[20:49] <alram> To clarify; the kernel/Linux info I posted from dmesg into that pastebin link is what I got from the last time I started up the OS successfully; it doesn't even make it far enough in the boot process now to start logging anything 
[20:52] <alram> kinda strange, since usually if absolutely nothing else has worked, at least copying the bootloader from some other working build HAS worked, I mean, the setups are more or less identical (both are running the Xubuntu flavor, 64bit, RPi4B's, what have you not ...)
[20:53] <alram> I was wondering whether or not it could've been an issue with the EEPROM stuff, that's when those things usually occur 
[20:55] <alram> I'm thinking about that especially since I successfully booted from my backup drive to RPiOS and ran the EEPROM update and it got reverted after one attempted boot. Now, since Ubuntu uses u-boot, I'm wondering where I should start poking to see if I can get things to work or not
[20:56] <alram> or should I just nuke the whole thing from orbit and pave a new build on top, and then rsync what can be rsynced, or something... 
[20:57] <alram> I do have all the files backed up and stuff like that, I just had an insane amount of packages installed and whatnot since I used that for a lot of development purposes 
[21:00] <alram> ... I also have no idea where to start the diagnostics from, since it doesn't get to a point where dmesg would actually start logging something 
[21:02] <alram> I would almost be willing to make a bet that it has something to do with an EEPROM version mismatch, since those are the only incidents when I've seen the boot sequence hit a crash boom bang like that  
[21:03] <alram>   (  ^ == EEPROM = EEPROM firmware in this case )
[21:07] <alram> Also btw (and this might be somewhat important to any devs that might be around here somewhere...): I noticed that the 'ubuntu-advantage-tools' wouldn't either install properly or uninstall properly on my other RPi4B Ubuntu 21.04; there was an update to that apt package and it first failed to install, then I couldn't get it out with apt, aptitude _or_ dpkg, so ... 
[21:09] <alram> ( ^ that might actually be of developer interest; I noticed that the same package was installed with regular apt-updates on both my Ubuntu pi's, the other one where the installation+uninstallation failed is still working with multiple reboots and all just to be sure. ) 
[21:11] <alram> ( And of that Pi4B not booting up -- I _have_ checked the cmdline.txt so that it points to the right part-UUID; however I should probably, out of diagnostic curiosity, point that to an invalid location and see what happens. I hit the rainbow right after the FAT boot partition is found, so maybe that could help in narrowing it down..) 
[21:13] <alram> But anyway, please refer to the Ubuntu pastebin url (https://paste.ubuntu.com/p/SXnzTTsNtS/); the kernel details are from the very last successful boot attempt before I hit the rainbow.
[21:15] <alram> I'd assume that something being "half-installed" means that they're pending restart? If it isn't the EEPROM mismatch causing the issue, then it's got to be something related to the very first things that bootloader start to load up... hmm! 
[21:18] <alram> Other than that, I've got to applaud everyone who has contributed to the development of the ARM-side of the OS, a lot of stuff has been improving lately and I'm very happy to see actual progress i.e. on browser and video playback performance and such. Very nice!