How many "5.4 broke..." threads before it is reverted?

[bjtheone]

I think some basic telemetry in the rpi-update script would be fine. Getting an idea how many testers there are and how often they update would be a start.

While I would be very upset about any telemetry being added to the mainline, even if I was notified about it, I would not have any issues with it being added to a test build. It is fairly easy to test the basic stuff and the mainstream apps. It is almost always going to be the corner cases that bite you, so getting it out in front of a wider audience is key to beta testing. Even a reporting script that captured everything the beta tester has installed would likely be useful.

Having enough info to know what beta testers ran, plus some hardware and software config info is key to getting any idea of test coverage. That would allow RPT to focus on areas they deemed important, and areas that did not get much coverage.

[trejan]

I think some basic telemetry in the rpi-update script would be fine. Getting an idea how many testers there are and how often they update would be a start.

How about an additional prompt for rpi-update when it first runs? Have a Y/N/? option with the ? showing you what gets sent. If you say no then it won't ask again. If you say yes then it'll automatically do it each time you run rpi-update. There would also be an option to disable/enable it at a later date.

How many people will actually select Y to this is something that needs to be considered though. If the majority of people will select N then there is no point.

[bls]

I ran rpi-update on both RaspiOS32 & RaspiOS64 to get kernel 5.4 on fresh installs, and do not recognize any the "issues" reported.

Yea, that's the thing that's missing in this thread. The issues were primarily with the 8GB models (the few exceptions were heavily overclocked). My 4B2 and 4B4 have no problems with the new kernel, bootloader or VL805 firmware.

Since my daily driver OS has had several tweaks done to it, I also tried starting from a fresh install of the default/recommended RaspiOS32 on another card, and that worked fine as well. I never encountered the CPU1 not starting error, or any corruption problems with video playback in Chromium browser or VLC (windowed and full-screen). It's working fine on my systems.

On support forums small problems seem like big issues because more people come to complain than to talk about how well everything works. That's the nature of forums, and it's the same with any system or software.

I suspect the number of people having trouble is relatively small compared to the userbase, which doesn't warrant a reversion. The silent release of a major update was a surprise, and it sucks for those who are having trouble, but it's working fine for me and probably most others as well.

EDIT
Just a note to say that most people won't automatically get the new bootloader and VL805 firmware. For that you need to edit /etc/default/rpi-eeprom-update and change FIRMWARE_RELEASE_STATUS="critical" to FIRMWARE_RELEASE_STATUS= "stable" before updating.

Code: Select all

pi@raspberrypi:~ $ uname -a && sudo rpi-eeprom-update && nproc

Linux raspberrypi 5.4.51-v7l+ #1326 SMP Fri Jul 17 10:51:18 BST 2020 armv7l GNU/Linux

BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Thu 16 Jul 2020 03:15:46 PM UTC (1594912546)
 LATEST: Thu 16 Jul 2020 03:15:46 PM UTC (1594912546)
 FW DIR: /lib/firmware/raspberrypi/bootloader/stable
VL805: up-to-date
CURRENT: 000138a1
 LATEST: 000138a1

4

Like @HawaiianPi, I upgraded my Pi48G and have not experienced any issues. Since we know that many people like to futz with the system with the likes of over-clocking, sometimes installing random software, etc., it seems to me one thing that might be helpful is to gather information about the systems that are failing. While it may be too late to do anything programmatically for this time, it might be useful if people with failing systems could report what system mods they've made, such as: any and all changes to config.txt, installed software, etc. Also good to know if the starting point for the system install was Lite or Full.

For the future, a tool that automagically gathered all the relevant info could certainly be useful in zeroing in on common root causes.

My $.02

[W. H. Heydt]

For the future, a tool that automagically gathered all the relevant info could certainly be useful in zeroing in on common root causes.

While the idea of being able to automatically gather data on how systems are running (or not running), it is just such data gathering that people object to when MS and other large corporations do it. Adding such to Linux is unlikely to win friends and would be likely widely condemned.

[dickon]

Debian proffers popcon by default, IIRC. That's a logger for installed packages.

[trejan]

While the idea of being able to automatically gather data on how systems are running (or not running), it is just such data gathering that people object to when MS and other large corporations do it. Adding such to Linux is unlikely to win friends and would be likely widely condemned.

I think you're making a mountain out of a mole hill. Does the mere existence of telemetry in something cause you to recoil in disgust? There are lots of open source projects that have telemetry with some of the big ones like Firefox being opt-out and Ubuntu being opt-in. If the Pi version is opt-in and clearly shows what is being sent then what is the problem?

[bls]

For the future, a tool that automagically gathered all the relevant info could certainly be useful in zeroing in on common root causes.

While the idea of being able to automatically gather data on how systems are running (or not running), it is just such data gathering that people object to when MS and other large corporations do it. Adding such to Linux is unlikely to win friends and would be likely widely condemned.

While I did use the phrase “automagically”, I didn’t suggest that it be done automatically, as MSFT does. I was thinking that it could be a script that generates a lovely well-formatted text file of some sort that people could voluntarily attach to their postings here. The automagic part would be that the tool (script?) is readily available and easily creates the formatted output. Users could easily review it before submission, of course, and submitting it would be voluntary.

If such a tool existed and worked, it could potentially lead to problems accompanied by the data getting resolved more quickly. Faster responses would probably inspire others to use it (the big carrot!)

MSFT on the other hand, deals with a HUGE number of systems, and dealing with 1 Billion users requires tools of a completely different scale. I know the people that built the MSFT reporting system. It’s all anonymized, and with such a huge amount of data they are able to identify some really interesting trends, like “ This model of memory SIMMs has high error rates in kernel mode, crashing the system”, or “Vendor X’s consumer desktop system has problems among Y% of the users, while their business offerings have close to 0% issues”

Clearly RasPiOS doesn’t need that now. Focusing only on the data that folks in these forums typically ask for (what version, network configuration, installed apps, etc) could cut down response times (no longer need to ask for configuration details or modifications if data submitted with the question), and enable RPF developers to build useful search across such data, if they wanted.

I wasn’t thinking of ANYTHING privacy-invasive, just thinking about how some actual data about problem systems would be useful, and how that could be brought into use. It was just a brainstorm without much thought (other than the above), and I don’t think that your leap to “would be widely condemned” was very helpful.

Asking questions to help us all get to a shared understanding would have been much more appropriate.

[trejan]

I was thinking that it could be a script that generates a lovely well-formatted text file of some sort that people could voluntarily attach to their postings here. The automagic part would be that the tool (script?) is readily available and easily creates the formatted output. Users could easily review it before submission, of course, and submitting it would be voluntary.

This already exists as raspinfo and is installed by default. It is fairly basic still so would need to be expanded with whatever extra information is needed.

[bls]

I was thinking that it could be a script that generates a lovely well-formatted text file of some sort that people could voluntarily attach to their postings here. The automagic part would be that the tool (script?) is readily available and easily creates the formatted output. Users could easily review it before submission, of course, and submitting it would be voluntary.

This already exists as raspinfo and is installed by default. It is fairly basic still so would need to be expanded with whatever extra information is needed.

I wasn't aware of this, because I always install Lite, and it's not there by default. Looks like a great starting point! Some of the typical information that we (mostly you guys, not me ) ask for could include dhcpcd.conf, wpa_supplicant.conf (with SSIDs and passwords edited out, of course), etc. For "system-type" errors, I'm big on checking the system logs, but those would require too much scrubbing and raise too many flags.

I guess my test on it would be that the volunteer responders here start asking for the raspinfo output in a growing number of queries. Seems like some set of networking queries always have a go-around or 3 to get a full config understanding, for instance. Target one or two types of queries, make raspinfo useful for those queries, and then actually use it and promote it in these forums.

[HawaiianPi]

Like @HawaiianPi, I upgraded my Pi48G and have not experienced any issues.

When did you upgrade, because they released a fix already (this morning).

[bls]

Like @HawaiianPi, I upgraded my Pi48G and have not experienced any issues.

When did you upgrade, because they released a fix already (this morning).

I upgraded yesterday morning, and it ran fine. I updated again this morning, and it's still not exhibiting any issues.

[HawaiianPi]

I upgraded yesterday morning, and it ran fine. I updated again this morning, and it's still not exhibiting any issues.

Did you try playing any full-screen videos yesterday with either Chromium browser or VLC? That was a confirmed issue with 8GB models and kernel 5.4.51 #1326 (some kind of DMA problem). Kernel 5.4.51 #1327 fixed it (as long as you leave the compositor enabled).

[bls]

I upgraded yesterday morning, and it ran fine. I updated again this morning, and it's still not exhibiting any issues.

Did you try playing any full-screen videos yesterday with either Chromium browser or VLC? That was a confirmed issue with 8GB models and kernel 5.4.51 #1326 (some kind of DMA problem). Kernel 5.4.51 #1327 fixed it (as long as you leave the compositor enabled).

I had not tried it, but just did. Youtube video played fine in a window (even a large window), but failed in full screen. It does switch back to in a window and keep playing, though! This is on Lite with icewm. I haven't touched config.txt

Edit: Not surprisingly, and for completeness, it plays correctly in a TigerVNC session running full screen.

[hydra3333]

I was thinking that it could be a script that generates a lovely well-formatted text file of some sort that people could voluntarily attach to their postings here. The automagic part would be that the tool (script?) is readily available and easily creates the formatted output. Users could easily review it before submission, of course, and submitting it would be voluntary.

This already exists as raspinfo and is installed by default. It is fairly basic still so would need to be expanded with whatever extra information is needed.

Thanks.

I just tried and it was not found. I had to first

Code: Select all

sudo apt install -y raspinfo

[hippy]

I suspect the number of people having trouble is relatively small compared to the userbase, which doesn't warrant a reversion. The silent release of a major update was a surprise, and it sucks for those who are having trouble, but it's working fine for me and probably most others as well.

That's an important thing to consider. Before expending energy and effort on fixing something it always pays to determine how much of a problem one has, whether problems are very serious and widespread or rather minor and limited.

I am not convinced the issues are so serious, that the release was so fundamentally flawed, that it really shouldn't have been released, must be reverted. That seems to be blowing the problem out of all proportion as happened with the USB-C, PoE HAT and 1V8 LAN issues.

But then, having not experienced any problems so far, I am not sure of the scale of the problem or that anyone is. Does anyone have a collated list of what doesn't work or has been adversely impacted ?

[hippy]

I would guess holding 'raspberrypi-kernel', 'raspberrypi-bootloader' and 'raspberrypi-kernel-headers' would be enough but someone more experienced in this area might like to advise on that.

I make a daily dump of the installed packages and also the libraspberrypi-bin, libraspberrypi-dev, libraspberrypi-doc, libraspberrypi0 and rpi-eeprom were updated with the kernel. Can someone tell if this ones safe to update or should also be put on hold? Thank you.

From today's upgrade to fix related issue I now believe all 7 of those need holding. I don't believe 'rpi-eeprom' needs holding but it probably does no harm to hold it as well.

As the opportunity presented itself I thought I would test holding and it appears to work as desired -

Code: Select all

pi@Pi3B:~/apps/demo $ uname -a
Linux Pi3B 5.4.51-v7+ #1326 SMP Fri Jul 17 10:45:25 BST 2020 armv7l GNU/Linux

Code: Select all

pi@Pi3B:~/apps/demo $ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0
  raspberrypi-bootloader raspberrypi-kernel raspberrypi-kernel-headers
7 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 137 MB of archives.
After this operation, 67.6 kB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.

Code: Select all

pi@Pi3B:~/apps/demo $ sudo apt-mark hold libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0
libraspberrypi-bin set on hold.
libraspberrypi-dev set on hold.
libraspberrypi-doc set on hold.
libraspberrypi0 set on hold.
pi@Pi3B:~/apps/demo $ sudo apt-mark hold raspberrypi-bootloader raspberrypi-kernel raspberrypi-kernel-headers
raspberrypi-bootloader set on hold.
raspberrypi-kernel set on hold.
raspberrypi-kernel-headers set on hold.
pi@Pi3B:~/apps/demo $ 

Code: Select all

pi@Pi3B:~/apps/demo $ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0
  raspberrypi-bootloader raspberrypi-kernel raspberrypi-kernel-headers
0 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.

Doing unholds, another upgrade, then a reboot, has me on the latest -

Code: Select all

pi@Pi3B:~/apps/demo $ uname -a
Linux Pi3B 5.4.51-v7+ #1327 SMP Thu Jul 23 10:58:46 BST 2020 armv7l GNU/Linux

Note that only the # number increments and the date changes, not the "5.4.51" part.

[phi6ndepa]

i have finally gotten the final parts to hook my raspberry pi 4 B 4Gb , RPi4B4

and i am about to run through the directions to boot from USD/SSD

i am following the post viewtopic.php?f=63&t=277413&start=150#p1690538

and have changed critical to stable in the eeprom update

and run
sudo rpi-eeprom-update -f /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-06-15.bin

rebooted, etc and run
sudo rpi-eeprom-update

(new people, like me, that post has it all written out exactly the way you need it. and maybe answers to this post will update it a bit)

SO ! it seems there was a decent amount of eeprom "stable" updates in the time between then and now: my output read as follows:

sudo rpi-eeprom-update
BCM2711 detected
Dedicated VL805 EEPROM detected
*** UPDATE AVAILABLE ***
BOOTLOADER: update available
CURRENT: Mon 15 Jun 2020 01:36:19 PM UTC (1592228179)
LATEST: Thu 16 Jul 2020 03:15:46 PM UTC (1594912546)
FW DIR: /lib/firmware/raspberrypi/bootloader/stable
VL805: up-to-date
CURRENT: 000138a1
LATEST: 000138a1

SO ! i'm gong to run
sudo rpi-eeprom-update -f /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-07-16.bin

and hope it works out ok; but i'd like some advice on 2 things

1) should i run an earlier one like 2020-07-13 which i saw a firmware date mentioned, here ? i don't know what other ones were in between june 15th and now.

AND

2) what other things can i update manually and how (what text commands and procedure ala the linked post) ? i noticed hippy and sismeiro mentioning things called
'raspberrypi-kernel', 'raspberrypi-bootloader' and 'raspberrypi-kernel-headers' as well as libraspberrypi-bin, libraspberrypi-dev, libraspberrypi-doc, libraspberrypi0 and rpi-eeprom
so i was wondering what other files i'd have to manually open and change to stable and run commands on.
interestingly the upgrade and update (full update afterwards only installed a superfluous file called 'rpi-eeprom-images' and said i could run 'sudo apt autoremove' to remove it, but i left it anyway) did not install the latest eeprom, even thouh i had previously changed critical to stable (even before the update and upgrade because i had tried it before unsucessfully beforehand. my wifi wouldn't find and connect to the regular band of the router, and i had to switch to the 5G one to get and keep a stable connection that is constantly detected and connected to)

sorry for the text block, i try to be concise as possible, or thorough. or both.

[phi6ndepa]

i don't know why but i get this

vcgencmd bootloader_config
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0

while they get

vcgencmd bootloader_config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41


i hope i can just copy and paste if i can open the file with 'sudo nano' somehow, so i guess i'll try the path as /etc/default/ with, 'sudo nano /etc/default/bootloader_config' AND that file doesn't exist, so i can maybe find this on https://www.raspberrypi.org/documentati ... _config.md

but, i'm stuck. please help

[trejan]

i don't know why but i get this

vcgencmd bootloader_config
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0

while they get

vcgencmd bootloader_config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41

You need to give rpi-eeprom-update the -d option to tell it you want the default configuration or configuration from the file if one is specified. If you don't use the -d option then it will extract the old config and reuse it which is why you're missing options.

-d Use the default bootloader config, or if a file is specified using the -f
flag use the config in that file. This option only applies when a
bootloader EEPROM update is needed; if the bootloader EEPROM is up-to-date
then its config will not be changed.

[phi6ndepa]

thank you; that worked, it was on the rpi documetation link too and i figured to just add it. i was going to apologize for everything and say i hope it helped anyone trying to do the same.

i'm going to carry on with the rest of the raspberry pi dot org link and note any differences to the thread post. i have a usb 3.0 uasp to 2.5'' sata ssd adapter (neeyer brand powered adapter) and a kingston 240GB A400 internal ssd; so i think that's all trouble free and supported hopefully.

thanks

[ejolson]

i don't know why but i get this

vcgencmd bootloader_config
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0

while they get

vcgencmd bootloader_config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41

You need to give rpi-eeprom-update the -d option to tell it you want the default configuration or configuration from the file if one is specified. If you don't use the -d option then it will extract the old config and reuse it which is why you're missing options.

-d Use the default bootloader config, or if a file is specified using the -f
flag use the config in that file. This option only applies when a
bootloader EEPROM update is needed; if the bootloader EEPROM is up-to-date
then its config will not be changed.

Adding the lines with the settings you want using nano should work just fine and only requires one update.

[phi6ndepa]

thanks, i got the right text; but what filepath/command line input would i put to edit it ? i haven't seen the way yet.

[ejolson]

thanks, i got the right text; but what filepath/command line input would i put to edit it ? i haven't seen the way yet.

My recommendation would be to start another thread entitled "editing eeprom options" in troubleshooting or general topics. I'll look for your question there as will others who know better. For this thread such questions are so far off topic that many who might have advice to offer will miss the question.

[phi6ndepa]

you are right. thanks.

i noticed the top of that raspberry pi dot org link had the commands under the hashed out ones. stress and coffee and tired, just missed it. it doesn't seem absolutely necessary for what i'm doing, but if i ever need to, i would make a thread or search.

thanks anyway though.