Closed pseudofunizer closed 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'!
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!
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!
Kernel has been updated in v28, thanks!
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
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 theconfig.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:
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!