TheRemote / Ubuntu-Server-raspi4-unofficial

Ubuntu Server 18.04.4 Raspberry Pi 4 Image + Build Script (unofficial)
https://jamesachambers.com/raspberry-pi-4-ubuntu-server-desktop-18-04-3-image-unofficial/
Apache License 2.0
535 stars 93 forks source link

Kernel update to 4.19.105? / Chaos+a found fix for it after running "flash-kernel" inside the Ubuntu #115

Closed pseudofunizer closed 4 years ago

pseudofunizer commented 4 years ago

I began probing for a way to update the kernel v.4.19.105 as it's now listed as a mandatory and urgent update, at least according to LWN.net's article from a few days ago.

https://lwn.net/Articles/812876/ "All users of the 4.19 kernel series must upgrade."

I bit the bullet even though I had no clear idea what would happen when I did so, and nonetheless installed the flash-kernel apt package that I had troubles with in the past and had hence uninstalled it completely.

I had been searching for possible solutions for the error messages it gave earlier on when it attempted to ram itself through, and the reason for that was that it wasn't able to find the bcm packages, so I copied them from another directory location to where they were needed according to instructions I found from Raspberry Foundation's forums.

Well, sure enough, beginning from the boot sequence, everything was screwed up. After nearly losing my mind, I found out that flash-kernel had added an outdated / unwanted line into the config.txt file, that's on the MicroSD jump-boot card:

dtoverlay=vc4-kms-v3d

I removed that line and everything was working again. However, there seems to be some kind of a mess-up with the whole paremeter, namely that it causes Ubuntu distros to go haywire, and removing it disables the 3D acceleration altogether (!) -- according to Raspberry Pi's official forums: https://www.raspberrypi.org/forums/viewtopic.php?t=247893

At least in my case it did the trick and everything was back to ~normal with the next boot.

Now, the issue is that although everything's working again, I'm still stuck with the 4.19.97-v8-27 version of the kernel, things should run on a 4.19.105 kernel now, but I'm wondering how on earth I'll get there or if it's even advisable?

The rpi-update util can be installed on other OS's/distros than just Raspbian, at least according to the utility's GitHub page. (See: https://github.com/Hexxeh/rpi-update / Installing)

However, it's also said under the "Notes" section:

This is only intended for use with Raspbian. If you are using a different distribution then check with the maintainers if using rpi-update is safe.

I figured I'd do just that, so... Any last words of advice before I start probing that realm to see what happens? :-) Thanks a lot, and I hope @TheRemote keeps up the good work. Cheers!

pseudofunizer commented 4 years ago

Installed rpi-update as instructed on the "Installing under other OSes" section of the git page ( https://github.com/Hexxeh/rpi-update ). Ran it with no problems and everything seems to be working except that the kernel version I'm being shown is still the same-old 4.19.97-v8-27 and not 4.19.105, although the rpi-update now says that my firmware is up to date ? Which is odd. It would imply that rpi-update either has updated some kernel modules within the Ubuntu Server build, but it's not showing the correct version numbering for some reason, OR it's actually being fooled by its own version check function that it's done any successful updates to begin with...

Anyway, all help on this issue is kindly appreciated. Otherwise all's well -- for now. Keep on truckin'!

pseudofunizer commented 4 years ago

OK, a small status update - and this time some more good news (or rather, so far so good :D )

After running rpi-update on the Ubuntu Server, I re-enabled that line for the graphics overlay from /boot/firmware/config.txt :

dtoverlay=vc4-kms-v3d

... And now everything's working a-OK. I noticed that the hardware acceleration for graphics had indeed been tossed aside when that option wasn't in use, causing hardware-accelerated video (such as Youtube videos) to become an issue. That's now fixed and the video playback seems to be smoother than ever!

In fact, as for the video playback, my Firefox full version is looking way better and no audio glitching either on this Xubuntu build, whereas, in comparison, my up-to-date Raspbian with the 4.19.105 kernel was still coughing up during regular YT video playback on its Raspbian-specific Chromium build ( ":D" ).

To summarize at this point: after re-introducing the dtoverlay switch to config.txt, everything seems to be working great. Video playback is smooth, no screen tearing, 3D acceleration working as well. The only thing that is still a question mark is why my kernel, according to inxi, still seems to be at 4.19.97-v8-27 ... Oh well!

TheRemote commented 4 years ago

Hey again pseudo,

Thanks as always for the incredibly detailed and helpful information you always post!

Here is how I switch the kernel when I run the updater:

echo "Updating kernel and modules ..."
export KERNEL_VERSION="$(ls updates/rootfs/lib/modules)"
sudo depmod "${KERNEL_VERSION}"

# Create kernel and component symlinks
sudo rm -rf /boot/initrd.img
sudo rm -rf /boot/vmlinux
sudo rm -rf /boot/System.map
sudo rm -rf /boot/Module.symvers
sudo rm -rf /boot/config
sudo ln -s /boot/initrd.img-"${KERNEL_VERSION}" /boot/initrd.img
sudo ln -s /boot/vmlinux-"${KERNEL_VERSION}" /boot/vmlinux
sudo ln -s /boot/System.map-"${KERNEL_VERSION}" /boot/System.map
sudo ln -s /boot/Module.symvers-"${KERNEL_VERSION}" /boot/Module.symvers
sudo ln -s /boot/config-"${KERNEL_VERSION}" /boot/config

# Create kernel header symlink
sudo rm -rf /lib/modules/"${KERNEL_VERSION}"/build 
sudo rm -rf /lib/modules/"${KERNEL_VERSION}"/source
sudo ln -s /usr/src/"${KERNEL_VERSION}"/ /lib/modules/"${KERNEL_VERSION}"/build
sudo ln -s /usr/src/"${KERNEL_VERSION}"/ /lib/modules/"${KERNEL_VERSION}"/source

# Call update-initramfs to finish kernel setup
sha1sum=$(sha1sum /boot/vmlinux-"${KERNEL_VERSION}")
echo "$sha1sum  /boot/vmlinux-${KERNEL_VERSION}" | sudo tee /var/lib/initramfs-tools/"${KERNEL_VERSION}" >/dev/null;
sudo update-initramfs -k "${KERNEL_VERSION}" -u

I think the key parts for you is to use sudo depmod "${KERNEL_VERSION}" and sudo update-initramfs -k "${KERNEL_VERSION}" -u if rpi-update has taken care of everything else!

TheRemote commented 4 years ago

Kernel has been updated in v28, thanks!

pseudofunizer commented 4 years ago

Thanks so much, James! The update went without much further problems; although I did had to revert my cmdline.txt and config.txt from the backups I created just before the update, JIC (and, as instructed).

(As a side note: I could perhaps help you in writing an automated backup / revert-to-script for the Updater.sh in regards of the config.txt and the cmdline.txt? I've noticed over time that those two files are so essential to the entire update process that it's very easy for things to go awry when they are not the way they were before the update. In fact, a majority of people's Updater-related problems can likely be traced back to changes in those two files...)

A curious observation: ever since expanding my system to a jump-booted SSD, I've noticed that all updates want to stick themselves into the last known partition of the /dev/sda drive. In this case, I've made a swap partition for testing purposes, and for some reason, a majority of these kernel-related updates (regardless of your updater script, btw) want to stick themselves into the swap partition; being /dev/sda3 in this case, whereas it should've been /dev/sda2. That's not at all a problem with the Updater script, but rather somewhere deeper inside Linux's update handling and so forth.

SO, an oddity - but at least for now all the sysinfo details (inxi and such) at least show that I'm running Kernel v. 4.19.105-v8-28, everything seems to be in working order and so forth ... So far, so good! :)

@TheRemote If you take in any donations for the hard and unrewarding work that you do? Please do let me know if there's some monetary way to at least buy you a couple of virtual drinks/beer/coffees for your respectable effort in bringing at least one proper distro in working order for the RPi4B. Hats off to you, Captain, and keep up the good work. o7