STICKY: Buster bug report thread

[ke4roh]

ENVIRONMENT:
Running a fresh install of Buster desktop on a Pi 3 B v. 1.2. This problem does not appear on Stretch.

SYMPTOMS:
The wi-fi works fine for a few minutes, then becomes disabled. Once it is "disabled," ifconfig does not list the wlan0 interface at all, unless I try to bring it up again, and then it doesn't connect. When I mouse over the wi-fi control in LXDE, it shows "no wireless interfaces found."

THINGS THAT DON'T HELP:
My country is set correctly in wpa_supplicant.conf.
Restarting wpa_supplicant doesn't work.
Upgrading wpa-supplicant to 2.9 (probably not https://bugs.launchpad.net/raspbian/+bug/1834749 or https://bugs.debian.org/cgi-bin/bugrepo ... bug=911297 then)
Changing the Pi, the power supply, or the SD card

WORKAROUND:
Reboot for another 2 to 20 minutes of connectivity.

[TheSplund]

Pi (1) Model B 256M + Pi NOIR camera + Buster
I recently posted that I was having trouble with an early Pi, a NOIR v1, and Buster (viewtopic.php?f=28&t=289636) and I seem to have proved that, out of the box, the latest iteration of the OS (ie Buster) will not work with with configuration - it won't even work if you tweak the memory balance and/or boot into the CLI instead of the Desktop. Jessie and Stretch work fine.
This doesn't align with the current statement of "we’ve always tried to maintain software backwards-compatibility with older hardware, and so the standard Raspbian image for all models of Raspberry Pi is now based on Buster"

[DougieLawson]

Pi (1) Model B 256M + Pi NOIR camera + Buster
I recently posted that I was having trouble with an early Pi, a NOIR v1, and Buster (viewtopic.php?f=28&t=289636) and I seem to have proved that, out of the box, the latest iteration of the OS (ie Buster) will not work with with configuration - it won't even work if you tweak the memory balance and/or boot into the CLI instead of the Desktop. Jessie and Stretch work fine.
This doesn't align with the current statement of "we’ve always tried to maintain software backwards-compatibility with older hardware, and so the standard Raspbian image for all models of Raspberry Pi is now based on Buster"

My camera on a RPi1B works perfectly. Your problem is bound to be a setup problem, a hardware failure, a Chinese fake camera or a problem with wiring the camera to the RPi.

What do you get from vcgencmd get_camera command

You should get something like

Code: Select all

pi@odyssey:~ $ vcgencmd get_camera
supported=1 detected=1
pi@odyssey:~ $

What in /boot/config.txt (and be careful to pick the right config if you're using NOOBS).

Code: Select all

dtparam=audio=on
dtoverlay=gpio-ir,gpio_pin=23

gpu_mem=128
start_x=1
disable_camera_led=1

hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=81
dtparam=spi=on
dtparam=i2c_arm=on
disable_splash=1

[Dixonge]

The latest updates to buster forced two packages that broke the sound.

Code: Select all

sudo apt purge pulseaudio pulseaudio-utils

restores normal operation to headphone audio settings. And sounds work again.

THANK YOU! Driving me crazy. So. Many. Fixes. Starting to regret this freakin' Pi 4 purchase

[fruitoftheloom]

The latest updates to buster forced two packages that broke the sound.

Code: Select all

sudo apt purge pulseaudio pulseaudio-utils

restores normal operation to headphone audio settings. And sounds work again.

THANK YOU! Driving me crazy. So. Many. Fixes. Starting to regret this freakin' Pi 4 purchase

PulseAudio is not a standard included package in Raspbian Stretch, Buster or Raspberry Pi Operating Systems, therefore not a bug but software you have installed:

https://www.raspberrypi.org/blog/raspbian-stretch/

[TheSplund]

Pi (1) Model B 256M + Pi NOIR camera + Buster
I recently posted that I was having trouble with an early Pi, a NOIR v1, and Buster (viewtopic.php?f=28&t=289636) and I seem to have proved that, out of the box, the latest iteration of the OS (ie Buster) will not work with with configuration - it won't even work if you tweak the memory balance and/or boot into the CLI instead of the Desktop. Jessie and Stretch work fine.
This doesn't align with the current statement of "we’ve always tried to maintain software backwards-compatibility with older hardware, and so the standard Raspbian image for all models of Raspberry Pi is now based on Buster"

My camera on a RPi1B works perfectly. Your problem is bound to be a setup problem, a hardware failure, a Chinese fake camera or a problem with wiring the camera to the RPi.

What do you get from vcgencmd get_camera command

You should get something like

Code: Select all

pi@odyssey:~ $ vcgencmd get_camera
supported=1 detected=1
pi@odyssey:~ $

What in /boot/config.txt (and be careful to pick the right config if you're using NOOBS).

Code: Select all

dtparam=audio=on
dtoverlay=gpio-ir,gpio_pin=23

gpu_mem=128
start_x=1
disable_camera_led=1

hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=81
dtparam=spi=on
dtparam=i2c_arm=on
disable_splash=1

Hello again Dougie - IIRC your Pi has 512MB whereas mine only has 256MB. Like both my Pi1 & Pi3, I bought my NOIR from cpc.farnell.com so it ought to be very legit. My camera is working 100% with Jessie, Stretch, MotionEyeOS - all in fact tested working within the last 48 hours.
At present I've got that Pi1 ModelB (256MB) running MotionEyeOS outside, in the dark, so I can only tell you that running that command over SSH gives me 'supported=1 detected=1'.
Obviously(?) any config created by that OS will be different from Buster but I recall that I only had a simple set of choices in NOOBS (as you would expect given its homonymic(?) title)- those being somethng like 'Desktop', 'Lite', 'Desktop with software' (or Debian/other OS etc) - and, if my memory serves me correctly, even the GPU/CPU split is not an obvious option in NOOBS, and a 'noob' wouldn't have the knowledge to add anything to the config (and isn't told to by any supporting documentation that I've seen), but I will check once daylight has returned and I drop a fresh Buster build into it with NOOBS (rather than 'Imager1.4' which is so much less painfull!).
As I posted yesterday in my original thread (before I discovered this Buster bug report one) I tried your suggestion of 128MB for the GPU and also booting to the CLI (and both options too) but nothing got it working (but I was up and running in Stretch in around 15 mins or so).

[rpdom]

Hello again Dougie - IIRC your Pi has 512MB whereas mine only has 256MB.

I think Dougie has a 256MB Pi 1B. I certainly do have a couple, so I might get around to testing this at some pint with one of the cameras I currently use with a Zero.

[TheSplund]

Hello again Dougie - IIRC your Pi has 512MB whereas mine only has 256MB.

I think Dougie has a 256MB Pi 1B. I certainly do have a couple, so I might get around to testing this at some pint with one of the cameras I currently use with a Zero.

Are you sure? A quote from Dougie yesterday morning "My old 512MB 1B with a the camera has 128MB for GPU memory. I run it headless with motion driving the camera." (viewtopic.php?f=28&t=289636&p=1751140#p1751140

[rpdom]

Hello again Dougie - IIRC your Pi has 512MB whereas mine only has 256MB.

I think Dougie has a 256MB Pi 1B. I certainly do have a couple, so I might get around to testing this at some pint with one of the cameras I currently use with a Zero.

Are you sure? A quote from Dougie yesterday morning "My old 512MB 1B with a the camera has 128MB for GPU memory. I run it headless with motion driving the camera." (viewtopic.php?f=28&t=289636&p=1751140#p1751140

Maybe he has more than one 1B? I have a few.

[DougieLawson]

Maybe he has more than one 1B? I have a few.

I have five RPi1B's they're all 512MB model B rev2.

The one with the camera has 128MB for GPU, 384MB for Linux and it works perfectly.

[TheSplund]

So NOOBS install done (pics here https://photos.app.goo.gl/t1S57GkunqJwibPt9); I went through setup options and chose to skip updates (as this didn't seem to achieve anything before); and rebooted - all good so far.
vcgencmd get_camera returns supported=0 detected=0 as camera obviously not yet enabled
the 'unhashed' lines in /boot/config.txt are:
dtparam=audio=on
[pi4]
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
(there's nothing after this)

So above the [pi4] I entered this:
dtparam=audio=on
dtoverlay=gpio-ir,gpio_pin=23

gpu_mem=128
start_x=1
disable_camera_led=1
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=81 ----note text the underscore was missing in the formatted comment above but I spotted it
dtparam=spi=on
dtparam=i2c_arm=on
disable_splash=1

and having double-checked my spelling I saved and rebooted.
15 mins later it's still rebooting - note that I see the '"Welcome to the Raspberry Pi Desktop' as before (shown in one of those pics)
20 mins...
35 mins...
60mins - you get the picture. No change since the Welcome screen
All LEDs glowing with the LNK LED intermittant. I cannot SSH into it.
So basically it's the same as yesterday and the day before

Holding 'Shift' whilst rebooting allowed me to edit the config and so I hashed out the new lines and rebooted - clearly something else has now been affected as it's slow booting again (updating or unloding packages perhaps? I have no clue TBH) but it gets to a Desktop now though it is quite sluggish in comparison to the initital boot. Oddly the GPU still had 128MB so I changed that to 64 and rebooted. Update to follow...

[TheSplund]

Maybe he has more than one 1B? I have a few.

I have five RPi1B's they're all 512MB model B rev2.

The one with the camera has 128MB for GPU, 384MB for Linux and it works perfectly.

ok, so my genuine 'supported by Buster as it's an early Pi' that only has 256MB has now rebooted without the camera enabled and just 64M for the GPU - any more seems to heavily affect the CPU I guess.
So back to my bug report: I would propose that this iteration of the OS* does not fully support all Pi models if a NOIR camera is enabled, and certainly not 'out of the box', so who does this bug report go to now? Do we have any Pi representatives, ie those described as a 'Raspberry Pi Engineer & Forum Moderator', here?

*and to reiterate Stretch did

[rpdom]

ok, so my genuine 'supported by Buster as it's an early Pi' that only has 256MB has now rebooted without the camera enabled and just 64M for the GPU - any more seems to heavily affect the CPU I guess.
So back to my bug report: I would propose that this iteration of the OS* does not fully support all Pi models if a NOIR camera is enabled, and certainly not 'out of the box', so who does this bug report go to now? Do we have any Pi representatives, ie those described as a 'Raspberry Pi Engineer & Forum Moderator', here?

I suspect it can work and when I get around to testing on my Pi 1B 256MB I will confirm that. I don't have a NOIR camera, just the standard one, but as the only significant difference between the two is the IR filter I believe that will be a true test.

[underpressure]

Got this kernel panic on a Pi Zero W after being up for a few days.

Code: Select all

Nov  2 05:42:47 zerow-2 kernel: [473512.478499] 8<--- cut here ---
Nov  2 05:42:47 zerow-2 kernel: [473512.479538] Unable to handle kernel paging request at virtual address 9a3c71a4
Nov  2 05:42:47 zerow-2 kernel: [473512.480536] pgd = 86981be8
Nov  2 05:42:47 zerow-2 kernel: [473512.481517] [9a3c71a4] *pgd=00000000
Nov  2 05:42:47 zerow-2 kernel: [473512.482516] Internal error: Oops: 5 [#1] ARM
Nov  2 05:42:47 zerow-2 kernel: [473512.483509] Modules linked in: aes_arm aes_generic cmac bnep hci_uart btbcm bluetooth ecdh_generic ecc libaes 8021q garp stp llc spidev brcmfmac brcmutil sha256_generic libsha256 cfg80211 raspberrypi_hwmon rfkill i2c_bcm2835 spi_bcm2835 bcm2835_codec(C) bcm2835_v4l2(C) v4l2_mem2mem bcm2835_isp(C) bcm2835_mmal_vchiq(C) videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common snd_bcm2835(C) snd_pcm videodev snd_timer snd mc vc_sm_cma(C) fixed uio_pdrv_genirq uio i2c_dev ip_tables x_tables ipv6
Nov  2 05:42:47 zerow-2 kernel: [473512.491510] CPU: 0 PID: 23991 Comm: dhcpcd-run-hook Tainted: G         C        5.4.72+ #1356
Nov  2 05:42:47 zerow-2 kernel: [473512.494071] Hardware name: BCM2835
Nov  2 05:42:47 zerow-2 kernel: [473512.495391] PC is at unlink_anon_vmas+0x19c/0x208
Nov  2 05:42:47 zerow-2 kernel: [473512.496695] LR is at 0xd8572720
Nov  2 05:42:47 zerow-2 kernel: [473512.497949] pc : [<c0198c98>]    lr : [<d8572720>]    psr: 20000013
Nov  2 05:42:47 zerow-2 kernel: [473512.499228] sp : d4e81e68  ip : defb9c20  fp : d4e81e9c
Nov  2 05:42:47 zerow-2 kernel: [473512.500516] r10: 00000122  r9 : d863033c  r8 : d8630334
Nov  2 05:42:47 zerow-2 kernel: [473512.501818] r7 : c0bcf344  r6 : 00000100  r5 : 00000122  r4 : d7a3f9c0
Nov  2 05:42:47 zerow-2 kernel: [473512.503157] r3 : e5847000  r2 : c07c6a00  r1 : d97f7e60  r0 : 000e11d0
Nov  2 05:42:47 zerow-2 kernel: [473512.504477] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Nov  2 05:42:47 zerow-2 kernel: [473512.505806] Control: 00c5387d  Table: 14c40008  DAC: 00000055
Nov  2 05:42:47 zerow-2 kernel: [473512.507155] Process dhcpcd-run-hook (pid: 23991, stack limit = 0xc7a4a11d)
Nov  2 05:42:47 zerow-2 kernel: [473512.508539] Stack: (0xd4e81e68 to 0xd4e82000)
Nov  2 05:42:47 zerow-2 kernel: [473512.509897] 1e60:                   d8630e40 d8630300 d4e81e9c d8630300 d86308a0 d8630e40
Nov  2 05:42:47 zerow-2 kernel: [473512.512551] 1e80: b6db5000 d4e81ed8 00002000 00000000 d4e81ed4 d4e81ea0 c018aabc c0198b08
Nov  2 05:42:47 zerow-2 kernel: [473512.515192] 1ea0: b6c00000 c018be6c 00000000 d8630480 d9439c40 ffffe000 d9439c7c 00000000
Nov  2 05:42:47 zerow-2 kernel: [473512.517835] 1ec0: ffffe000 00000000 d4e81f34 d4e81ed8 c0192f00 c018aa70 d9439c40 00010000
Nov  2 05:42:47 zerow-2 kernel: [473512.520530] 1ee0: ffffffff d9439c7d 00000001 c7068000 c7068000 00000008 00000008 dab18d48
Nov  2 05:42:47 zerow-2 kernel: [473512.523358] 1f00: dab18d6c dab18d90 dab18db4 da7bbc40 dab18dd8 dab17224 dab233c8 c0aa7028
Nov  2 05:42:47 zerow-2 kernel: [473512.526325] 1f20: d9439c40 00000000 d4e81f4c d4e81f38 c00202d0 c0192e18 d95de3c0 d9439c40
Nov  2 05:42:47 zerow-2 kernel: [473512.529395] 1f40: d4e81f74 d4e81f50 c00270f8 c002028c c0aac220 d4e81fb0 c07b3038 c0aa7028
Nov  2 05:42:47 zerow-2 kernel: [473512.532557] 1f60: 00000010 000000f8 d4e81f94 d4e81f78 c00278bc c0026ddc 00000004 00023154
Nov  2 05:42:47 zerow-2 kernel: [473512.535783] 1f80: 000117ac 000000f8 d4e81fa4 d4e81f98 c002794c c002787c 00000000 d4e81fa8
Nov  2 05:42:47 zerow-2 kernel: [473512.539081] 1fa0: c0009000 c0027938 00000004 00023154 00000000 00dda8a8 00000000 00036010
Nov  2 05:42:47 zerow-2 kernel: [473512.542423] 1fc0: 00000004 00023154 000117ac 000000f8 00000000 00000000 b6f47000 00000000
Nov  2 05:42:47 zerow-2 kernel: [473512.545785] 1fe0: 00035ee0 be889688 0001f864 b6e54944 60000010 00000000 00000000 00000000
Nov  2 05:42:47 zerow-2 kernel: [473512.549118] Backtrace:
Nov  2 05:42:47 zerow-2 kernel: [473512.550762] [<c0198afc>] (unlink_anon_vmas) from [<c018aabc>] (free_pgtables+0x58/0xc8)
Nov  2 05:42:47 zerow-2 kernel: [473512.554011]  r10:00000000 r9:00002000 r8:d4e81ed8 r7:b6db5000 r6:d8630e40 r5:d86308a0
Nov  2 05:42:47 zerow-2 kernel: [473512.557236]  r4:d8630300
Nov  2 05:42:47 zerow-2 kernel: [473512.558810] [<c018aa64>] (free_pgtables) from [<c0192f00>] (exit_mmap+0xf4/0x1a0)
Nov  2 05:42:47 zerow-2 kernel: [473512.561918]  r10:00000000 r9:ffffe000 r8:00000000 r7:d9439c7c r6:ffffe000 r5:d9439c40
Nov  2 05:42:47 zerow-2 kernel: [473512.565001]  r4:d8630480
Nov  2 05:42:47 zerow-2 kernel: [473512.566500] [<c0192e0c>] (exit_mmap) from [<c00202d0>] (mmput+0x50/0xd4)
Nov  2 05:42:47 zerow-2 kernel: [473512.568022]  r5:00000000 r4:d9439c40
Nov  2 05:42:47 zerow-2 kernel: [473512.569512] [<c0020280>] (mmput) from [<c00270f8>] (do_exit+0x328/0xa54)
Nov  2 05:42:47 zerow-2 kernel: [473512.571011]  r5:d9439c40 r4:d95de3c0
Nov  2 05:42:47 zerow-2 kernel: [473512.572470] [<c0026dd0>] (do_exit) from [<c00278bc>] (do_group_exit+0x4c/0xbc)
Nov  2 05:42:47 zerow-2 kernel: [473512.573948]  r7:000000f8
Nov  2 05:42:47 zerow-2 kernel: [473512.575374] [<c0027870>] (do_group_exit) from [<c002794c>] (__wake_up_parent+0x0/0x30)
Nov  2 05:42:47 zerow-2 kernel: [473512.578189]  r7:000000f8 r6:000117ac r5:00023154 r4:00000004
Nov  2 05:42:47 zerow-2 kernel: [473512.579621] [<c002792c>] (sys_exit_group) from [<c0009000>] (ret_fast_syscall+0x0/0x28)
Nov  2 05:42:47 zerow-2 kernel: [473512.582467] Exception stack(0xd4e81fa8 to 0xd4e81ff0)
Nov  2 05:42:47 zerow-2 kernel: [473512.583897] 1fa0:                   00000004 00023154 00000000 00dda8a8 00000000 00036010
Nov  2 05:42:47 zerow-2 kernel: [473512.586683] 1fc0: 00000004 00023154 000117ac 000000f8 00000000 00000000 b6f47000 00000000
Nov  2 05:42:47 zerow-2 kernel: [473512.589568] 1fe0: 00035ee0 be889688 0001f864 b6e54944
Nov  2 05:42:47 zerow-2 kernel: [473512.591022] Code: ebffff6a eaffffe4 e24bd028 e89daff0 (e59f305c)
Nov  2 05:42:47 zerow-2 kernel: [473512.592641] ---[ end trace c291995996fda875 ]---
Nov  2 05:42:47 zerow-2 kernel: [473512.594121] Fixing recursive fault but reboot is needed!

Code: Select all

$ uname -a
Linux zerow-2 5.4.72+ #1356 Thu Oct 22 13:56:00 BST 2020 armv6l GNU/Linux

[DougieLawson]

Got this kernel panic on a Pi Zero W after being up for a few days.

Code: Select all

$ uname -a
Linux zerow-2 5.4.72+ #1356 Thu Oct 22 13:56:00 BST 2020 armv6l GNU/Linux

Your kernel is out of date. Run sudo apt update; sudo apt dist-upgrade -y; sudo reboot to get 5.4.73.

[TheSplund]

ok, so my genuine 'supported by Buster as it's an early Pi' that only has 256MB has now rebooted without the camera enabled and just 64M for the GPU - any more seems to heavily affect the CPU I guess.
So back to my bug report: I would propose that this iteration of the OS* does not fully support all Pi models if a NOIR camera is enabled, and certainly not 'out of the box', so who does this bug report go to now? Do we have any Pi representatives, ie those described as a 'Raspberry Pi Engineer & Forum Moderator', here?

I suspect it can work and when I get around to testing on my Pi 1B 256MB I will confirm that. I don't have a NOIR camera, just the standard one, but as the only significant difference between the two is the IR filter I believe that will be a true test.

Thanks, though I can now report that I get a result (ie a responsive GUI with a camera) if I pick one/several(?) of the intermediate GPU allocations (72-104 so far) and keep the boot/config.txt file simple (ie what the Prefs pane sets, which is just starting the camera and allocating the GPU mem) - it's beginning to look like the extremes (64 & 128) that dont play ball. Anyway, I had some feedback from one of the engineers and I'm going to move on to actually using this Pi rather without the Desktop
UPDATE: Eureka! I've sussed it. By default, when NOOBS prepares the SSD and you subsequently enable the camera, the GPU memory is actually set to 128M and not 64M as the Performance pane was actually showing (if you don't check this before you reboot then you'd not know it had been changed) - I feel a slight fool, in part, as everytime I've booted and thought that 64M wasn't working was after I'd freshly built the OS.

[NimbUx]

Pi 4B with Raspbian "Buster"not booted from SD memory card - so, the OS is treating mmc as
removable-plug &play devices. Upon inserting a SD card into the slot - one that has the usual partitioning scheme, viz one primary FAT plus one secondary ext4 (inside the so-called extended container partition), we observe the following :
- the FAT primary gets auto-mounted, under /media/ - this is expected;
- the Linux ext4 is not mounted by the p&p daemon

There is no error on the file systems, and the Linux part can still be mounted manually and accessed subsequently without errors - yet this leads to the question : does P&P automount only primary partitions, or only FAT ones (I confess I haven't tested the whole lot of possible variations of partitionning schemes) ? Is that a (questionable) design decision ? or rather should it be considered - and reported - as a quirk / bug (you name it) ?

[karrika]

Audacity does not recognize the output device on a Pi 400. I have tried HDMI and Bluetooth headphones. All other software works with both HDMI and Bluetooth headphones. I have a faint memory that this worked on a Pi4B in 2020 May version.

If I add an USB PnP Sound device. It just works. Through the USB sound dongle.

This is a real problem for the Pi 400 as it relies on HDMI for sound.

[gordon77]

It's a pity that the built in UK keyboard is still not recognised on a Pi400, even if you don't choose US keyboard at install.
it still mixes US,UK and GB settings in the preferences

[gordon77]

Audacity does not recognize the output device on a Pi 400. I have tried HDMI and Bluetooth headphones. All other software works with both HDMI and Bluetooth headphones. I have a faint memory that this worked on a Pi4B in 2020 May version.

If I add an USB PnP Sound device. It just works. Through the USB sound dongle.

This is a real problem for the Pi 400 as it relies on HDMI for sound.

I've just tried the latest PiOS and Audacity now plays through the HDMI on a Pi400 !!

[karrika]

Audacity does not recognize the output device on a Pi 400. I have tried HDMI and Bluetooth headphones. All other software works with both HDMI and Bluetooth headphones. I have a faint memory that this worked on a Pi4B in 2020 May version.

If I add an USB PnP Sound device. It just works. Through the USB sound dongle.

This is a real problem for the Pi 400 as it relies on HDMI for sound.

I've just tried the latest PiOS and Audacity now plays through the HDMI on a Pi400 !!

Yes, I can confirm this as well. The update this week solved it. Good work guys!

[Rudolf]

Did the December update and am quite happy - but: I am unable to use the Pi-Hole in the network. When I add the DNS IP of the Pi-Hole into the new network settings, it gets painfully slow on the net and is no longer usable. Any hints what could go wrong there?

*update* I did some testing:
A(Router default) - if I use the DNS service provided by router default on the RaspberryPi4 I get a ping time to www.google.com of about 3ms
B(Pi-Hole) - if I change the DNS Server entry in the "Wireless & Wired Network Setting" to the Pi-Hole IP I get a ping time of about 14ms
C(Crosscheck) - if I use the macOS and Win10 machines in the house changing the DNS IP back and forth does not alter the 3ms ping time

Anybody out there knowing exactly what the Network Settings at Pi Desktop change and why only the Pi changes behavior when switching?

*2020-12-08 Update* Ok, I will answer myself now.
The way I found working was to <sudo nano /etc/resolv.conf.head> and add nameserver w.x.y.z (the Pi-Hole IP number) to it, reboot and it now works as seen by nslookup. Warning: this does not show up in <Wireless & Wired Network Setting> !
Remark, the internet feels snappy again now ...

[Fuchks]

udev rules for symlinks to serial-to-USB devices ttyUSB will symlink to gpiochip on freshly installed and updated Buster (Raspberry Pi OS Lite).
This issue arises on a Pi2B Rev 1.1 HW 1a01041 with 2x FTDI FT232 adapters, other users reported same problem on Pi3B.

used udev rule (example)

Code: Select all

SUBSYSTEMS=="usb", ATTRS{serial}=="12345678", SYMLINK+="MyUSBDevice"

Discussions on that issue:
viewtopic.php?t=283585
https://www.indilib.org/forum/ekos/7878 ... pping.html

Issue for Pi Kernel

Edit: SOLUTION AT END

Disabling stock /etc/udev/rules.d/99-com.rules solves the issue partly (not everytime) - or excluding the following lines:

Code: Select all

#SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"
#SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
#       chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
#       chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio;\
#       chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\
#'"

Code: Select all

sudo udevadm test $(udevadm info -q path -n /dev/ttyUSBx)

will solve the issue everytime for usb device x

My workaround as i do not need this gpio stuff:

Exclude the following lines from the stock /etc/udev/rules.d/99-com.rules:

Code: Select all

#SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"
#SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
#       chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
#       chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio;\
#       chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\
#'"

Add the line to /etc/rc.local:

Code: Select all

sudo udevadm control --reload-rules && sudo udevadm trigger

Let me know if this works reliable on your system too

Solution from XECDesign: https://github.com/raspberrypi/linux/is ... -755231352

Udev rule has to look like:

Code: Select all

SUBSYSTEM=="tty", ATTRS{serial}=="12345678", SYMLINK+="MyUSBDevice"

[SJMarty]

Testing a fresh install of the December 2, 2020 release of Raspberry Pi OS (with desktop and recommended software) on a Pi 4/8 GB. During the initial setup wizard, I change the default password to something new. After completing the wizard and rebooting, when enabling SSH, I receive the message that the default password has not been changed. The password change performed during the initial setup does not "take" and the password has to be changed manually.

I saw this same issue mentioned a couple of times in the announcement post comments but not in this thread.

[linuxham100]

The current version of Raspberry PI OS, wifi doesn't work. I don't know the root cause, but a new install used to work just fine, and now doesn't.