I believe you have a choice.
Keep what you have or downgrade.
To downgrade the packages during the update, I run this:
$ sudo pacman -Syyuu
You will have to answer Y to each package. I think there is a --no-confirm or something like that, if you prefer not to be bothered.
updated, first time KMS work, what is behind the scenes?
Sounds like you updated on one branch at one time and switched to lower branch and did an update.
I had plasma-git packages rolled back.
As for dracut, I figured it was a long shot. Unless maybe there were plans to move to it.
The kernels depends on mkinitcpio, because they have a .preset file and hook, that generates initramfs on each kernel update. So far I have not seen Arch plan to move to dracut any time soon.
I am still messing with the hooks to get it working for me. But now I know to make sure it co-exists nicely with initcpio rather than try to replace it. Thanks for the info.
First, thanks for this new kernel. It seems rpi team change the way of thinking about kernel because now they really follow 5.10 branch and are really very reactive about changes.
I hope this paves the way for a new era of even better 64-bit compatibility. I’m thinking about camera here.
All neon crypto modules has been enabled in both new kernels.
I don’t know if you can see it on screen but the “cryptsetup benchmark” has its performance increased by roughly 12%.
FYI:
There was some activity in the RPi firmware git today but there are no changes that involves our 2 raspberrypi-bootloader packages (*.dat, *.elf and bootcode.bin). So no reason to make the packages this week.
I pushed the latest llinux-rpi4-mainline to the unstable branch when the mirrors sync.
Today was my going to town day. I had the kernel compiled before I went to town but the bluetooth was not working so I had to stop what I was doing to go to town. When I got back home I found out that the cause of the bluetooth not working was because of today’s update of the 2 bootloader packages so I am holding them back for now.
Because of my limited time today I did not get around to removing the config.txt and cmdline.txt from the kernel; so saving that for another day…
There was no movement with the -rc kernel git today regarding a kernel bump.
linux-rpi4-mainline-5.10.14-1-aarch64.pkg.tar.zst
linux-rpi4-mainline-headers-5.10.14-1-aarch64.pkg.tar.zstUpdated without issue, thank you!
I am pretty sure linux-rpi4 will move to kernel 5.10. Mainline will track 5.11 and rc will move to tracking 5.12. Please correct me if I am mistaken.
My question, is there anything significant for the RPi4 in 5.11? I do not recall much that is significant in 5.11, but I am sure you follow more closely that I do.
Correct. RPi folks have already moved to kernel 5.10 as their default kernel. Kernel 5.11 will most likely loose it’s -rc status this weekend so beginning next week I will start moving 5.10 ==> linux-rpi4 and 5.11 ==> linux-rpi4-mainline.
Not that I have seen that peeks my interest.
firmware-raspberrypi-6-1.8 has issues with my directly attached USB SSD. The SSD has worked fine and with UASP support until this firmware version. I reinstalled 6.1.4 and my SSD once again works fine. Some sort of USB timeout/reset type issue, or so it appeared. Sorry, the error occurs during mounting of my btrfs root filesystem and I did not think to take a picture. If that would be helpful, I can reset and take a pic.
Interestingly, if I take that same SSD and with the 6-1-8 firmware installed, but this time place a USB hub in between, the SSD works fine. So only when directly attached does this issue occur. The hub is powered, but I doubt it is a power issue. I have been using this SSD for months without issue.
The only change was a fix to keep the wifi from dis-connecting with the pi4 wifi firmware. Probably by moving the ssd away from the pi4 board and connecting to a hub stopped some interference. Try putting a usb extension between the pi board and the ssd to put some distance between the two.
I don’t have a usb 3.0 extension cable but I do have a little longer cable to try.
This error occured with dtoverlay=disable-wifi, I don’t use wifi in the office.
But since nothing related changed, I’ll mess around with positioning and maybe other kernel versions. I’ll try to figure something out… maybe it is the cold… brr dangy.
The firmware-raspberrypi package has pi related firmware for rpi things like it’s wifi, bluetooth. I would assume your ssd has it’s firmware loaded onboard it.
Go figure, now I can not make it fail. So ignore this mess, sorry for the false alarm.
My guess is interference from somewhere. Even your monitor can cause interference.
One big Please. On every occasion where the config,txt file is overwritten, (kernel rc update, or even first boot) hdmi_drive=2 is preconfigured. I’m using DVI monitor and, normally, booting to black screen. So, I must change it on another system. If you just comment that line both tv users or dvi users can boot and further changes are easy. Thanx.