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: 1385
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: 1385
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: 2343
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: 1385
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: 2343
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: 23914
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.
Rather than negativity think outside the box !
RPi 4B 4GB (SSD Boot) RaspiOS64 ARM64
Asus ChromeBox 3 Celeron is my other computer...

max11
Posts: 50
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: 6
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: 3299
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: 6
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: 3299
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: 6
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

Return to “Raspberry Pi OS”