vincent-
Posts: 1
Joined: Sat Jul 25, 2020 6:21 am

Re: STICKY: Buster bug report thread

Sun Jul 26, 2020 6:47 am

The update of raspberrypi-kernel has broken the installation of v4l2loopback-dkms

---------------------------------------------------

v4l2loopback-dkms-0.12.1-1 (current version in Buster) fails to install because the kernel module fails to build for kernels >= 5.1. This has been fixed upstream, and in fact the v4l2loopback-dkms-0.12.5-1 from Bullseye installs just fine.

The problem was introduced by raspberrypi-kernel-1.20200717-1 which started to ship 5.4 kernels instead of 4.19.

I have reported this on GitHub, but I'm not sure if I did it in the right place.

tombsar
Posts: 46
Joined: Wed May 13, 2020 12:40 am

Re: STICKY: Buster bug report thread

Sun Jul 26, 2020 12:54 pm

Everything worked fine last week, and I check for upgrades every couple of days, so I know it was something that changed very recently that introduced the regression. I see from my apt logs that I got two kernel updates (4.19.118 and 5.4.51) within that timeframe, which seem like obvious candidates for the cause.
beta-tester wrote:
Sun Jul 26, 2020 6:30 am
to up- or downgrade to a specific kernel, use ifs commit hash value:

Code: Select all

sudo rpi-update  e1050e94821a70b2e4c72b318d6c6c968552e9a2  # hash of commit  "kernel: Bump to 4.19.118"
sudo reboot
Thanks for this.

Downgrading to kernel 4.19.115 (87fea11838d706311dc3708d67c334967505a292) returned the system to a working state.

Upgrading to kernel 4.19.118 (e1050e94821a70b2e4c72b318d6c6c968552e9a2) it was still working.

Upgrading to kernel 5.4.51 (6ed953db15f863e1c8962a447307628c48946bf6) it is broken.

So I'm pretty confident this is a kernel issue.

If I may vent my frustration a little, I deliberately stayed away from any beta and/or testing versions of the OS because I wanted a stable development system, so it is rather disappointing that such a regression made it through testing; I can't be the only person to have noticed this problem(?).

Is this likely to get fixed, or is the answer that I should wait until the full kms driver is released? I understand fkms is not being as actively maintained as it used to be.

beta-tester
Posts: 1412
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: STICKY: Buster bug report thread

Sun Jul 26, 2020 1:24 pm

in the initial post on this thread is a list where to report issues officially...
Once bugs are confirmed, you should use the github repo to make an official report.

For Linux kernel issues: https://github.com/raspberrypi/linux/issues
For Firmware issues: https://github.com/raspberrypi/firmware/issues
For Userland issues (demo apps etc) : https://github.com/raspberrypi/userland/issues
For Raspbian issue: TBD
For Desktop issues: TBD
... there is the best chance to get a fix.
(but the developers have their priorities that may not fit with ours :? )
tombsar wrote:
Sun Jul 26, 2020 12:54 pm
Upgrading to kernel 4.19.118 (e1050e94821a70b2e4c72b318d6c6c968552e9a2) it was still working.
Upgrading to kernel 5.4.51 (6ed953db15f863e1c8962a447307628c48946bf6) it is broken.
if you wanna make the developer happy, you can try to find the exact two commits of transition from last working commit to first broken/not-working commit...
in between of 4.19.118 and 5.4.5 there are still some other commits.
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

beta-tester
Posts: 1412
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: STICKY: Buster bug report thread

Wed Aug 12, 2020 7:00 pm

is there a repository on github that contains all the source code of modification/customization that were made to debian packages for Raspberry Pi OS?
i don't mean the repositories for linux kernel, firmware or userland.

for example i am looking for the modifications/customizations on the packages firefox-esr and chromium made for Raspbarry Pi OS.
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

trejan
Posts: 3064
Joined: Tue Jul 02, 2019 2:28 pm

Re: STICKY: Buster bug report thread

Wed Aug 12, 2020 7:10 pm

beta-tester wrote:
Wed Aug 12, 2020 7:00 pm
is there a repository on github that contains all the source code of modification/customization that were made to debian packages for Raspberry Pi OS?
The RPT modified Chromium is at https://github.com/RPi-Distro/chromium-browser but I've no idea where the firefox one is. They've said that not all of the RPT Git repos are public and that the official method to get source is to enable the source repo in /etc/apt/sources.list and retrieve the source packages using "apt source packagenamehere"

beta-tester
Posts: 1412
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: STICKY: Buster bug report thread

Wed Aug 12, 2020 7:24 pm

trejan wrote:
Wed Aug 12, 2020 7:10 pm
beta-tester wrote:
Wed Aug 12, 2020 7:00 pm
is there a repository on github that contains all the source code of modification/customization that were made to debian packages for Raspberry Pi OS?
The RPT modified Chromium is at https://github.com/RPi-Distro/chromium-browser but I've no idea where the firefox one is. They've said that not all of the RPT Git repos are public and that the official method to get source is to enable the source repo in /etc/apt/sources.list and retrieve the source packages using "apt source packagenamehere"
thank you...
i expected that there must be more modified packages available... :?
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

trejan
Posts: 3064
Joined: Tue Jul 02, 2019 2:28 pm

Re: STICKY: Buster bug report thread

Wed Aug 12, 2020 7:25 pm

beta-tester wrote:
Wed Aug 12, 2020 7:24 pm
i expected that there must be more modified packages available... :?
You'll have to use "apt source" to get those.

fruitoftheloom
Posts: 25237
Joined: Tue Mar 25, 2014 12:40 pm
Location: Delightful Dorset

Re: STICKY: Buster bug report thread

Wed Aug 12, 2020 7:29 pm

beta-tester wrote:
Wed Aug 12, 2020 7:00 pm
is there a repository on github that contains all the source code of modification/customization that were made to debian packages for Raspberry Pi OS?
i don't mean the repositories for linux kernel, firmware or userland.

for example i am looking for the modifications/customizations on the packages firefox-esr and chromium made for Raspbarry Pi OS.


AFAIAA

chromium-browser is where all the development has been undertaken.

firefox-esr is just a standard Debian Package.
The information is out there....you just have to let it in.

My other Linux machine is a ChromeBox

max11
Posts: 63
Joined: Tue May 14, 2019 12:48 pm

Re: STICKY: Buster bug report thread

Thu Sep 10, 2020 12:42 am

I finally installed Raspian Buster after being a happy user with Stretch.

Version is buster, kernel: Linux 5.4.51-v7+ Kodi Leia 18.7

My Problem is the DVB-C/T2 Astrometa Stick, which is as far as i can see, running fine (after solving the wellknown problems with the frontends)

Driver is 'dvb-demod-mn88473-01.fw'
Tvheadend shows the two adapters DVB-T2 and DVB-C.

If i try to scan nothing happens. Scan hangs and fails.

Connecting the adapter to the board this is shown in dmesg:

pi@raspberrypi:~ $ dmesg
[ 358.997308] usb 1-1.2.3: new high-speed USB device number 9 using dwc_otg
[ 359.237320] usb 1-1.2.3: New USB device found, idVendor=15f4, idProduct=0131, bcdDevice= 1.00
[ 359.237341] usb 1-1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 359.237350] usb 1-1.2.3: Product: dvbt2
[ 359.237360] usb 1-1.2.3: Manufacturer: astrometadvbt2
[ 359.245008] usb 1-1.2.3: dvb_usb_v2: found a 'Astrometa DVB-T2' in warm state
[ 359.324391] usb 1-1.2.3: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[ 359.324438] dvbdev: DVB: registering new adapter (Astrometa DVB-T2)
[ 359.354343] i2c i2c-3: Added multiplexed i2c bus 4
[ 359.354361] rtl2832 3-0010: Realtek RTL2832 successfully attached
[ 359.374115] mn88473 3-0018: Panasonic MN88473 successfully identified
[ 359.374197] usb 1-1.2.3: DVB: registering adapter 5 frontend 0 (Realtek RTL2832 (DVB-T))...
[ 359.374405] usb 1-1.2.3: DVB: registering adapter 5 frontend 1 (Panasonic MN88473)...
[ 359.374642] r820t 4-003a: creating new instance
[ 359.381499] r820t 4-003a: Rafael Micro r820t successfully identified
[ 359.381557] r820t 4-003a: attaching existing instance
[ 359.386376] r820t 4-003a: Rafael Micro r820t successfully identified
[ 359.409249] Registered IR keymap rc-empty
[ 359.409422] rc rc0: Astrometa DVB-T2 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2.3/rc/rc0
[ 359.409671] rc rc0: lirc_dev: driver dvb_usb_rtl28xxu registered at minor = 0, raw IR receiver, no transmitter
[ 359.409887] input: Astrometa DVB-T2 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2.3/rc/rc0/input12
[ 359.410297] usb 1-1.2.3: dvb_usb_v2: schedule remote query interval to 200 msecs
[ 359.418328] usb 1-1.2.3: dvb_usb_v2: 'Astrometa DVB-T2' successfully initialized and connected
pi@raspberrypi:~ $


With Raspbian Linux 9 (stretch) (kernel: Linux 4.19.66-v/+) and Kodi 18.2 (newer versions aren't available) everything is working fine..

Edit: Don't ask me why, but after disconnecting and reconnecting several times as well as rebooting and restarting Tvheadend several times now all of a sudden the system is recocognized.. scan is working ....

Edit2: It seems to have been a lucky failure, that i was able to scan.... :-( Maybe it worked as i took a backup from a working system (with a Terratec-adapter) and TVheadend didn't realize it in the first moment as both were on the same cable/same networks/same muxes/same services ....

After a reboot TVheadend is not finding anything ... scan pending ... and then fail ...
So let me resume:

The astrometa adapter is working fine with Raspbian stretch
It is recognized under Buster ... it is enabled ....but doesn't work with Buster, only with Stretch.

This seems to be a bug,
Any ideas?

My adapter is not any more scanned

mlp6868
Posts: 39
Joined: Sun Sep 27, 2020 11:48 pm

Re: STICKY: Buster bug report thread

Mon Sep 28, 2020 12:34 am

I'm in the process of tracking down an issue with the "initial partition resize" that has been with us for a long time (longer than stretch). The resize operation that kicks in on first boot seems to get the block count wrong by one (one too large). The SD boots fine, so the Pi's kernel appears to be ok with that.

But every once in a while, I want to boot the SD on a Linux system, say, to fix something, or get files off or so. I get an error (taken from dmesg here):

Code: Select all

[1381708.267473] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[1381708.800548] EXT4-fs (sdb2): bad geometry: block count 15563776 exceeds size of device (15563775 blocks)
On the linux system, I resize the file system again to the actual partition size, and all is fine. I can then mount the /dev/sdb2 partition on the Linux system alright.

I had seen this many times, but always on systems that had been in use for a long time, had maybe been shut down hard along the way (e.g. the power failed), and I was never quite sure if there is something in the history of the file system that causes this.

Today I burned a new image (2020-08-20-raspios-buster lite) on a 64G SD. Directly after the image was on, the #2 partition mounted fine. I then booted a Pi with it, and it went through the resizing operation. Right after the initial boot I shut down again and tried to mount again on the Linux system, got the above error. It's reproducible.

On the Linux system, I did (of course you'd need to adapt to your device name and partition/file system sizes)

Code: Select all

fsck -f /dev/seb2
    .... asks some questions and issues warning but completes alright...
resize2fs /dev/sdb2 15563775
fsck /dev/sdb2
effectively shrinking the file system size by one block to match reality. After that, I could mount the partition on the linux system, it still boots the Pi.

What I would like to find out:
- is this a known issue? (I couldn't find anything about this anywhere)
- I didn't immediately see an appropriate place to report this. Suggestions?

If this is not a known issue, I will dissect the code that's at work there at first boot and figure out where it goes wrong. First things first...

Thanks for any advice.

- mlp

User avatar
jojopi
Posts: 3406
Joined: Tue Oct 11, 2011 8:38 pm

Re: STICKY: Buster bug report thread

Mon Sep 28, 2020 10:12 am

mlp6868 wrote:
Mon Sep 28, 2020 12:34 am
The resize operation that kicks in on first boot seems to get the block count wrong by one (one too large). The SD boots fine, so the Pi's kernel appears to be ok with that.

But every once in a while, I want to boot the SD on a Linux system, say, to fix something, or get files off or so. I get an error (taken from dmesg here):
[1381708.267473] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[1381708.800548] EXT4-fs (sdb2): bad geometry: block count 15563776 exceeds size of device (15563775 blocks)
Is it possible that something on your other Linux system is changing the size of partition2, after the Pi has completed resize2fs?

I know that sounds very broken, but the Pi kernel will not boot if its root filesystem does not fit in the partition. It gives the same error as your other system.

After resizing on the Pi, fdisk should report that the End sector for p2 is the last sector of the disk. That is one less than the reported number of sectors, because LBA counts from zero.

Code: Select all

Disk /dev/mmcblk0: 14.9 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes           ^^^^^^^^
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x97709164

Device         Boot  Start      End  Sectors  Size Id Type
/dev/mmcblk0p1        8192   532479   524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      532480 31116287 30583808 14.6G 83 Linux
                           ^^^^^^^^
If something decreases that further, then you will indeed need to resize2fs again before the card is usable.

mlp6868
Posts: 39
Joined: Sun Sep 27, 2020 11:48 pm

Re: STICKY: Buster bug report thread

Mon Sep 28, 2020 3:04 pm

jojopi, thanks for the reply.

First off, I'm highly confident that my findings are correct. I reproduced the error on a variety of Linux systems/flavors before, Ubuntu, Gentoo (my main distro), Arch, Debian.

Today I started over, and dd'ed the image again to the SD card.

I then booted a pi with it, triggering the resize, shut that pi down again.

Instead of going to my Linux system now, I write-locked the SD card carrier so nothing can tamper with partition and file system sizes, and mounted it, with a USB-SD card adapter, on yet another Pi that runs off its own system, of course. That Pi's dmesg shows

Code: Select all

[4543471.372901] sd 0:0:0:0: Attached scsi generic sg0 type 0
[4543471.636359] sd 0:0:0:0: [sda] 125042687 512-byte logical blocks: (64.0 GB/59.6 GiB)
[4543471.636643] sd 0:0:0:0: [sda] Write Protect is off
[4543471.636665] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[4543471.640468] sd 0:0:0:0: [sda] No Caching mode page found
[4543471.640482] sd 0:0:0:0: [sda] Assuming drive cache: write through
[4543471.652115]  sda: sda1 sda2
[4543471.652353] sda: p2 size 124510208 extends beyond EOD, enabling native capacity
[4543471.658930]  sda: sda1 sda2
[4543471.659143] sda: p2 size 124510208 extends beyond EOD, truncated
[4543471.662392] sd 0:0:0:0: [sda] Attached SCSI removable disk


and fdisk shows (look at the 125042687 numbers):

Code: Select all

Disk /dev/sda: 59.6 GiB, 64021855744 bytes, 125042687 sectors
Disk model: Storage Device  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x22c25c49

Device     Boot  Start       End   Sectors  Size Id Type
/dev/sda1         8192    532479    524288  256M  c W95 FAT32 (LBA)
/dev/sda2       532480 125042687 124510208 59.4G 83 Linux
You called it - that /dev/sda2 partition end should be 125042686, one less.

On attempting to mount, I get

Code: Select all

# mount /dev/sda2 /mnt/usbdisk/
mount: /mnt/usbdisk: wrong fs type, bad option, bad superblock on /dev/sda2, missing codepage or helper program, or other error.


and then dmesg adds

Code: Select all

[4544276.337947] EXT4-fs (sda2): bad geometry: block count 15563776 exceeds size of device (15563775 blocks)
I went through the same fix as on my Linux desktop before,

Code: Select all

# resize2fs /dev/sda2 15563775
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/sda2 to 15563775 (4k) blocks.
The filesystem on /dev/sda2 is now 15563775 (4k) blocks long.

# fsck  /dev/sda2
fsck from util-linux 2.33.1
e2fsck 1.44.5 (15-Dec-2018)
rootfs: clean, 44518/3800000 files, 549411/15563775 blocks
# mount /dev/sda2 /mnt/usbdisk/
# ls /mnt/usbdisk/
bin  boot  dev	etc  home  lib	lost+found  media  mnt	opt  proc  root  run  sbin  srv  sys  tmp  usr	var
#
Maybe you could try to reproduce this. Before anyone asks - the SHA256sums of the buster image and original zip taken straight off the web site (checksum is correct...):

Code: Select all

# sha256sum 2020-08-20-raspios-buster-armhf-lite.*
09ac98ea433e8cb19d09ead1a0bd439cafb1c3e4cb699af04b4e4da1f6ca3f02  2020-08-20-raspios-buster-armhf-lite.img
4522df4a29f9aac4b0166fbfee9f599dab55a997c855702bfe35329c13334668  2020-08-20-raspios-buster-armhf-lite.zip
Hope it helps -

- mlp

User avatar
jojopi
Posts: 3406
Joined: Tue Oct 11, 2011 8:38 pm

Re: STICKY: Buster bug report thread

Mon Sep 28, 2020 4:00 pm

mlp6868 wrote:
Mon Sep 28, 2020 3:04 pm
[4543471.636359] sd 0:0:0:0: [sda] 125042687 512-byte logical blocks: (64.0 GB/59.6 GiB)
I cannot reproduce the issue. However, two differences are that I do not have any 64GB (SDXC) cards, and all the SDHC cards that I have report a size that is at least a multiple of 4096 bytes, whereas yours is an odd multiple of 512. (One sector less than a multiple of 128MiB.) I could see that making a difference.

Is it possible that this is an artifact of your USB bridge, and the card is actually 512 bytes bigger when accessed natively in the Pi's slot?

mlp6868
Posts: 39
Joined: Sun Sep 27, 2020 11:48 pm

Re: STICKY: Buster bug report thread

Mon Sep 28, 2020 8:56 pm

I see the same on a Mac with its built-in SD card reader, so it's unlikely to be an issue with the adapter.

But I will try to find a 32G card that I can sacrifice and re-try. I'll see if I can get to it tonight.

Thanks. - mlp

ejolson
Posts: 6349
Joined: Tue Mar 18, 2014 11:47 am

Re: STICKY: Buster bug report thread

Tue Sep 29, 2020 5:20 pm

CONFIG_CRYPTO_ADIANTUM is not set to yes in the kernel for the Buster version of Raspberry Pi OS.

More information is in the post

viewtopic.php?p=1734777#p1734777

User avatar
Milliways
Posts: 619
Joined: Fri Apr 25, 2014 12:18 am
Location: Sydney, Australia

Re: STICKY: Buster bug report thread - unable to set locale en_AU.UTF-8

Wed Sep 30, 2020 2:41 am

I did a fresh installation of Raspberry Pi OS (32-bit) with desktop using the Raspberry Pi Installer.

I successfully setup, the booted following the prompts to set password,

Set Timezone Sydney
Set Keyboard US International
Set WiFi Country AU

I attempted to select locale en_AU.UTF-8

There was an error running option I1 Change Locale

The language etc in locale is set to en_US.UTF-8

running

Code: Select all

sudo locale-gen 
seemed to complete, but locale remains stubbornly set to en_US

Code: Select all

localectl set-locale en_AU.UTF-8
seems to work, but nothing changes

I have "SOLVED" the problem by manually editing /etc/default/locale

/etc/default/locale

Code: Select all

LC_ALL=
LANGUAGE=en_AU.UTF-8
LANG=en_AU.UTF-8
There appears to be some problem in the current images, as I have successfully performed these steps on Stretch (and earlier) and Raspbian Lite Raspberry Pi reference 2019-07-10
Last edited by Milliways on Thu Oct 01, 2020 1:21 am, edited 1 time in total.

njheb
Posts: 8
Joined: Sun Apr 08, 2018 2:24 pm
Location: uk

Re: STICKY: Buster bug report thread

Wed Sep 30, 2020 2:16 pm

I agree there seems to be a problem with piwiz setting locale during setup. I should have posted here rather than where i did initially.

viewtopic.php?f=28&t=286940&p=1735083#p1735083

User avatar
DougieLawson
Posts: 40547
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: STICKY: Buster bug report thread

Wed Sep 30, 2020 6:48 pm

njheb wrote:
Wed Sep 30, 2020 2:16 pm
I agree there seems to be a problem with piwiz setting locale during setup. I should have posted here rather than where i did initially.

viewtopic.php?f=28&t=286940&p=1735083#p1735083
Post an issue at https://github.com/raspberrypi-ui/piwiz and the piwiz developer will look at it.
Any language using left-hand whitespace for syntax is ridiculous

Any DMs sent on Twitter will be answered next month.
Fake doctors - are all on my foes list.

Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

njheb
Posts: 8
Joined: Sun Apr 08, 2018 2:24 pm
Location: uk

Re: STICKY: Buster bug report thread

Wed Sep 30, 2020 7:06 pm

Rather embarrassingly the problem seems to be one of misinterpretation on my part. On rerunning piwiz without selecting the "Use English Language" checkbox on the "set country page" everything is fine.

User avatar
Milliways
Posts: 619
Joined: Fri Apr 25, 2014 12:18 am
Location: Sydney, Australia

Re: STICKY: Buster bug report thread

Thu Oct 01, 2020 12:06 am

DougieLawson wrote:
Wed Sep 30, 2020 6:48 pm
njheb wrote:
Wed Sep 30, 2020 2:16 pm
I agree there seems to be a problem with piwiz setting locale during setup. I should have posted here rather than where i did initially.

viewtopic.php?f=28&t=286940&p=1735083#p1735083
Post an issue at https://github.com/raspberrypi-ui/piwiz and the piwiz developer will look at it.
I doubt this is a piwiz issue, as raspi-config and setting locale via the traditional commands also fail - unless it upsets something else.
I also suspect it is not a recent issue; after having Unicode problems over ssh I restored from a January backup which had similar problems (locale was set to en-AU - without UTF-8)

User avatar
jojopi
Posts: 3406
Joined: Tue Oct 11, 2011 8:38 pm

Re: STICKY: Buster bug report thread

Thu Oct 01, 2020 1:14 am

Milliways wrote:
Thu Oct 01, 2020 12:06 am
I also suspect it is not a recent issue; after having Unicode problems over ssh I restored from a January backup which had similar problems (locale was set to en-AU - without UTF-8)
The locale without UTF-8 was requested by your SSH client. I do not know how to explain that any better than I did in the original thread.

User avatar
Milliways
Posts: 619
Joined: Fri Apr 25, 2014 12:18 am
Location: Sydney, Australia

Re: STICKY: Buster bug report thread

Thu Oct 01, 2020 1:20 am

jojopi wrote:
Thu Oct 01, 2020 1:14 am
Milliways wrote:
Thu Oct 01, 2020 12:06 am
I also suspect it is not a recent issue; after having Unicode problems over ssh I restored from a January backup which had similar problems (locale was set to en-AU - without UTF-8)
The locale without UTF-8 was requested by your SSH client. I do not know how to explain that any better than I did in the original thread.
I accept that the client requested a locale which was not available.
The issue is that Buster WILL NOT install the requested locale en-AU.UTF-8 and all attempts produce an error.

User avatar
jojopi
Posts: 3406
Joined: Tue Oct 11, 2011 8:38 pm

Re: STICKY: Buster bug report thread

Thu Oct 01, 2020 4:46 pm

Milliways wrote:
Thu Oct 01, 2020 1:20 am
The issue is that Buster WILL NOT install the requested locale en-AU.UTF-8 and all attempts produce an error.
There may be issues, but that is still not a reproducible bug. It works fine to generate en_AU.UTF-8, and to set it as the system default locale, and the locale is functional. You say you fixed it by editing /etc/default/locale, so presumably it was the middle step that was causing difficulty?

The system default locale is just the default. It will not have any effect until the next login, and even then it does not affect users and processes that have their own preferences.
Milliways wrote:
Wed Sep 30, 2020 2:41 am
There was an error running option I1 Change Locale
Unfortunately when raspi-config displays that message, it will obscure any actual error text. If you run sudo dpkg-reconfigure locales directly, errors should be left on the screen at the end.

Does it ask zero, one, or two questions before failing? The only crash I have been able to find is by unchecking all of the boxes in the first question.

User avatar
karrika
Posts: 1312
Joined: Mon Oct 19, 2015 6:21 am
Location: Finland

Re: STICKY: Buster bug report thread

Tue Oct 06, 2020 5:40 am

I decided to update my PiZero (original one that came with the MagPi). It has a 320 by 240 LCD module and it was running Buster from May 2020.

After the update the headphone audio stopped working for PiZero (except omxplayer). The strange thing is that omxplayer works with the correct local audio. But mplayer does not.

The normal ways using raspi-config or adding hdmi_ignore_edid_audio=1 to config.txt did not help.
The alsamixer still claims that the audio card is HEADPHONES. The PiZero is using the gpiopins and they get activated in /etc/rc.local:
gpio_alt -p 12 -f 0
gpio_alt -p 13 -f 0
amixer set PCM 100%

In dmesg I also got a new set of warnings:

[ 17.127131] spi-bcm2835 20204000.spi: chipselect 1 already in use
[ 17.127167] spi_master spi0: spi_device register error /soc/spi@7e204000/rpi-display-ts@1
[ 17.127198] spi_master spi0: Failed to create SPI device for /soc/spi@7e204000/rpi-display-ts@1
[ 17.127282] spi-bcm2835 20204000.spi: chipselect 0 already in use
[ 17.127307] spi_master spi0: spi_device register error /soc/spi@7e204000/rpi-display@0
[ 17.127334] spi_master spi0: Failed to create SPI device for /soc/spi@7e204000/rpi-display@0

And the third weird thing is that the sccreen copied by fbcp flickers the cursor all the time and clicking on menus or objects does not work.

This sounds like an awful lot of things to go bad at once.

User avatar
karrika
Posts: 1312
Joined: Mon Oct 19, 2015 6:21 am
Location: Finland

Re: STICKY: Buster bug report thread

Thu Oct 08, 2020 5:50 am

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.

Return to “Raspberry Pi OS”