Fraoch
Posts: 90
Joined: Thu Mar 07, 2013 11:53 pm
Location: Cambridge, Ontario, Canada

Re: Buster bug report thread

Thu Aug 08, 2019 11:34 pm

Fraoch wrote:
Thu Aug 08, 2019 1:48 pm
Can anyone confirm that webkitgtk is broken on Buster on the Pi1?

Whenever I try to run Midori or Web on the Pi1B I get a segmentation fault.

https://www.raspberrypi.org/forums/view ... 6#p1511486

These browsers work fine on the Pi2, the 3B+ and the 4.

An alternative, lightweight browser is needed on the 1 because Chromium is so slow as to be unusable on the 1. The only browser that runs on the 1 is Dillo, and Midori or Web are much better without being overly resource-intensive.
Fixed with an update to webkit, thanks!
Pencoed-made Model 1B, Samsung memory
2B 1.1
3B+
4B 2GB

itsmedoofer
Posts: 347
Joined: Wed Sep 25, 2013 8:43 am

Re: Buster bug report thread

Fri Aug 09, 2019 1:16 pm

plugwash wrote:
Tue Aug 06, 2019 1:28 pm
scottme wrote:
Thu Aug 01, 2019 2:52 pm
Is there a problem with the package python3-ws4py on the Buster repository?
Yes, it's broken :/, specifically it's not compatible with python 3.7. There was a patch, but it seems it never got uploaded for some reason. https://bugs.debian.org/cgi-bin/bugrepo ... bug=903529

It seems Debian removed the package from buster, but I didn't remove it in raspbian. I'm not sure why I didn't pick up the breakage and remove it.
If you need it this works...

Code: Select all

sudo pip3 install ws4py

User avatar
RichardRussell
Posts: 572
Joined: Thu Jun 21, 2012 10:48 am

Re: Buster bug report thread

Sat Aug 10, 2019 9:31 am

Is there a forecast for when this V3D driver fix will be incorporated in Buster? Is it possible that it may be available sooner as a separate install of mesa? Currently this issue causes BBC BASIC not to work correctly, and other applications are almost certainly affected.

billw
Posts: 399
Joined: Tue Sep 18, 2012 8:23 pm

Re: Buster bug report thread

Sat Aug 10, 2019 9:27 pm

I installed audacious and it plays audio fine on HDMI speakers.
Then I plugged in a USB sound card and selected it from the panel volume applet.
Now when audacious is launched it gives an error:

ALSA error: snd_pcm_hw_params_set_channels failed: invalid argument.

But if I launch VLC, it will play the mp3s through the USB sound card OK.

billw
Posts: 399
Joined: Tue Sep 18, 2012 8:23 pm

Re: Buster bug report thread

Sat Aug 10, 2019 9:52 pm

PeterO wrote:
Wed Jul 31, 2019 6:25 am
I just installed "xmag" to look at an icon , and the rubber band leaves a trail behind.
Same trails with xzoom and xfce4-screenshooter.

Appears to be a problem with XOR drawing.

MarkJ62
Posts: 28
Joined: Mon Dec 17, 2012 11:55 am
Location: Sydney, Australia
Contact: Website

Re: Buster bug report thread

Mon Aug 12, 2019 12:28 pm

Apt seems to keep downloading Packages.xz even when using a caching proxy (Squid).

I have a Bramble of 12 Pi3B+ and 10 Pi3B’s. I have one Pi3B+ with a PiDrive running Squid. When I do updates (sudo apt update) on each Pi it downloads the two Inrelease files, packages.gz and packages.xz. The two inrelease files and the packages.gz get cached when the first one runs, however it will always download the 13Mb packages.xz file. It seems apt 1.8.2 resets the connection and forces a re-download of packages.xz on each and every Pi. Squid logs the connection reset forcing a cache miss. It’s also quite slow at downloading, probably because everyone else has to download it every time.

Apt 1.4.9 under Stretch did not reset the connection and was able to cache it for subsequent requests.

Milliways
Posts: 426
Joined: Fri Apr 25, 2014 12:18 am
Location: Sydney, Australia

Lack of error reporting for missing root partition

Tue Aug 13, 2019 4:21 am

I used a script I wrote to copy an updated Raspbian to another SD Card.

This uses rsync, and I have successfully used it in the past.
I just ran it and the SD Card did not boot - I got 4 Raspberries then nothing.

The card did not boot on a Pi3B+ either.

The fix was trivial when I eventually realised what I had done wrong, the SD Card had a new PARTUUID and I had copied a cmdline.txt with a different PARTUUID.

The lack of any error reporting seems to be a bug.

On previous Raspbian there was a error message when the root partition was missing/faulty.

Code: Select all

Unable to mount root fs on unknown-block(179,2)

plugwash
Forum Moderator
Forum Moderator
Posts: 3435
Joined: Wed Dec 28, 2011 11:45 pm

Re: Buster bug report thread

Tue Aug 13, 2019 3:10 pm

I'm not 100% sure but it's possible that you just didn't wait long enough.

The problem is some storage devices can take quite a while to wake up. So the kernel has to wait quite a while before it can be reasonablly sure that the root filesystem isn't going to show up.

mob-i-l
Posts: 255
Joined: Sat Dec 29, 2012 2:45 am
Location: Lund, Skåne/Scania, Sweden
Contact: Website Facebook Google+ Twitter YouTube

Re: Buster bug report thread

Tue Aug 13, 2019 10:31 pm

Many videos in Chromium are not working. The entire browsing window becomes black when you play a video, but you can hear the sound. I have the most updated Raspbian Buster upgraded with dist-upgrade, and have rebooted. I use two monitors with Raspberry Pi 4 Model B 4GB RAM with 64 MB GPU memory. The videos in Chromium used to work with earlier versions of Buster except that they didn't always work on Twitter. Now the videos doesn't work in e.g. YouTube and IMDB.

Here is an example of a video that does work: https://www.youtube.com/watch?v=gDeAB31eNdk

Here is an example of a video that doesn't work (browser window becomes black): https://www.youtube.com/watch?v=2Wl0cCVSpyQ

Sometimes the video shows but is one color and striped.

I have tried with h264ify both enabled and disabled, but no difference.

On Raspberry Pi 4 do you need h264ify or does it improve anything?
Last edited by mob-i-l on Tue Aug 20, 2019 1:42 pm, edited 3 times in total.
Have Pi0&1A&1B&1B+&2B&3B&4B w/ Raspbian. Started w/ BASIC on ABC80&ZX81 then Forth, Z80… https://scratch.mit.edu/users/mobluse/ https://github.com/mobluse/ https://twitter.com/mobluse/ https://YouTube.com/MOBiL4u/

User avatar
RichardRussell
Posts: 572
Joined: Thu Jun 21, 2012 10:48 am

Re: Buster bug report thread

Wed Aug 14, 2019 1:06 pm

RichardRussell wrote:
Sat Aug 10, 2019 9:31 am
Is there a forecast for when this V3D driver fix will be incorporated in Buster?
If it would be helpful to report this at the official github repo, which category does mesa/V3D belong in: linux, firmware or userland?

dhylands
Posts: 3
Joined: Sun Feb 14, 2016 8:12 pm

Re: Buster bug report thread

Thu Aug 15, 2019 6:02 pm

Raspberry Pi 4 doesn't recognize my Aeotec Z-Stick

I just ran into a rather weird problem which seems isolated to the Raspberry Pi 4.

I'm using a vanilla 2019-07-10-raspbian-buster-lite.zip image. The only change
I did was to touch /boot/SSH after writing the sdcard.

Problem: When I plug my Z-Stick into any of the USB ports on my Raspberry Pi4
it doesn't enumerate.

Before plugging in the z-stick, dmesg shows:

Code: Select all

pi@raspberrypi:~ $ dmesg | tail -20
[    5.575858] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    5.575885] brcmfmac: power management disabled
[    5.881836] bcmgenet fd580000.genet: configuring instance for external RGMII (no delay)
[    5.882052] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    6.951793] bcmgenet fd580000.genet eth0: Link is Down
[   11.111817] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   11.111851] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   11.841265] Bluetooth: Core ver 2.22
[   11.841341] NET: Registered protocol family 31
[   11.841351] Bluetooth: HCI device and connection manager initialized
[   11.841371] Bluetooth: HCI socket layer initialized
[   11.841386] Bluetooth: L2CAP socket layer initialized
[   11.841432] Bluetooth: SCO socket layer initialized
[   11.854011] Bluetooth: HCI UART driver ver 2.3
[   11.854026] Bluetooth: HCI UART protocol H4 registered
[   11.854110] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   11.854336] Bluetooth: HCI UART protocol Broadcom registered
[   12.057443] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   12.057450] Bluetooth: BNEP filters: protocol multicast
[   12.057462] Bluetooth: BNEP socket layer initialized
After plugging in the z-stick, dmesg reports the exact same thing.

If I plug a unpowerd hub into the Rpi4 and then plug the z-stick into the hub, then
it enumerates fine.

Code: Select all

pi@raspberrypi:~ $ dmesg | tail -20
[   11.841432] Bluetooth: SCO socket layer initialized
[   11.854011] Bluetooth: HCI UART driver ver 2.3
[   11.854026] Bluetooth: HCI UART protocol H4 registered
[   11.854110] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   11.854336] Bluetooth: HCI UART protocol Broadcom registered
[   12.057443] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   12.057450] Bluetooth: BNEP filters: protocol multicast
[   12.057462] Bluetooth: BNEP socket layer initialized
[  123.791547] usb 1-1.1: new high-speed USB device number 3 using xhci_hcd
[  123.931902] usb 1-1.1: New USB device found, idVendor=1a40, idProduct=0201, bcdDevice= 1.00
[  123.931917] usb 1-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[  123.931930] usb 1-1.1: Product: USB 2.0 Hub [MTT]
[  123.940208] hub 1-1.1:1.0: USB hub found
[  123.940863] hub 1-1.1:1.0: 7 ports detected
[  126.841544] usb 1-1.1.6: new full-speed USB device number 4 using xhci_hcd
[  126.978069] usb 1-1.1.6: New USB device found, idVendor=0658, idProduct=0200, bcdDevice= 0.00
[  126.978085] usb 1-1.1.6: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  127.045705] cdc_acm 1-1.1.6:1.0: ttyACM0: USB ACM device
[  127.047724] usbcore: registered new interface driver cdc_acm
[  127.047734] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
If I boot my 3B+ using the exact same sdcard and plug the Z-stick in directly
to the 3B+ then it enumerates fine (might be because there is an internal hub?)

Code: Select all

pi@raspberrypi:~ $ dmesg | tail -20
[    8.082388] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   13.539751] Bluetooth: Core ver 2.22
[   13.539855] NET: Registered protocol family 31
[   13.539862] Bluetooth: HCI device and connection manager initialized
[   13.539894] Bluetooth: HCI socket layer initialized
[   13.539907] Bluetooth: L2CAP socket layer initialized
[   13.539951] Bluetooth: SCO socket layer initialized
[   13.557558] Bluetooth: HCI UART driver ver 2.3
[   13.557573] Bluetooth: HCI UART protocol H4 registered
[   13.557705] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   13.557937] Bluetooth: HCI UART protocol Broadcom registered
[   13.855213] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   13.855223] Bluetooth: BNEP filters: protocol multicast
[   13.855235] Bluetooth: BNEP socket layer initialized
[  148.945122] usb 1-1.3: new full-speed USB device number 5 using dwc_otg
[  149.076819] usb 1-1.3: New USB device found, idVendor=0658, idProduct=0200, bcdDevice= 0.00
[  149.076832] usb 1-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  149.133077] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
[  149.133890] usbcore: registered new interface driver cdc_acm
[  149.133898] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
I tried adding dwc_otg.speed=1 to /boot/cmdline.txt but this didn't change the behaviour.
I also tried doing a sudo apt update followed by sudo apt upgrade and that also
didn't change the behaviour.

The Z-stick also enumerates fine on all of my regular computers/laptops (Linux, Windows, Mac OS).

lsusb -v (when plugged in via the hub) reports:

Code: Select all

pi@raspberrypi:~ $ sudo lsusb -s 001:004 -v

Bus 001 Device 004: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x0658 Sigma Designs, Inc.
  idProduct          0x0200 Aeotec Z-Stick Gen5 (ZW090) - UZB
  bcdDevice            0.00
  iManufacturer           0 
  iProduct                0 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0043
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x00
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              32
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0000
  (Bus Powered)
Last edited by dhylands on Thu Aug 15, 2019 6:08 pm, edited 1 time in total.

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

Re: Buster bug report thread

Thu Aug 15, 2019 6:05 pm

dhylands wrote:
Thu Aug 15, 2019 6:02 pm
Raspberry Pi 4 doesn't recognize my Aeotec Z-Stick
There is a hardware design flaw with the Aeotec Z-Stick. Read the whole thread for more details and a possible workaround involving using some specific USB hubs.

dhylands
Posts: 3
Joined: Sun Feb 14, 2016 8:12 pm

Re: Buster bug report thread

Thu Aug 15, 2019 8:30 pm

trejan wrote:
Thu Aug 15, 2019 6:05 pm
dhylands wrote:
Thu Aug 15, 2019 6:02 pm
Raspberry Pi 4 doesn't recognize my Aeotec Z-Stick
There is a hardware design flaw with the Aeotec Z-Stick. Read the whole thread for more details and a possible workaround involving using some specific USB hubs.
I discovered that using a hub makes it work (in my initial report).

However, I would have expected it to work when plugged directly into one of the USB 2.0 hubs on the Pi4. So I'm not totally convinced that this is a only problem with the Aeotec.

I measured a 1.5k ohm resistor between VBUS (5v) and D+ and it's supposed to be between 3.3v and D+, so the Z-Stick isn't quite following the spec.

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

Re: Buster bug report thread

Thu Aug 15, 2019 8:34 pm

dhylands wrote:
Thu Aug 15, 2019 8:30 pm
However, I would have expected it to work when plugged directly into one of the USB 2.0 hubs on the Pi4. So
The USB 2.0 ports are actually USB 3.0 ports on the controller but without the extra data lines connected to the socket. As the Z-Stick doesn't have those extra data lines anyway, there is no difference between plugging it into a USB 2.0 or 3.0 port on the RPi 4.

wpballa1
Posts: 52
Joined: Sat Jun 27, 2015 12:49 am

Re: Buster bug report thread

Sun Aug 18, 2019 8:05 pm

I used HPLIP to set up a wireless HP laser printer on Stretch with no issues, but the installation does not complete on Buster. It claims to successfully install the required plug-in, but then claims continually that I need to install said plug-in. I have installed it both through the toolbox and manually to no avail. The key question is whether this is a Buster issue or an HPLIP issue so I know where to report it. My stretch system still works fine with the printer but I think HPLIP does not go above version 9.8 of Debian yet which may be the issue.

This has been confirmed to be an HPLIP issue that will be fixed in the next release, date unknown.
Last edited by wpballa1 on Mon Aug 19, 2019 3:52 pm, edited 1 time in total.

jetaudio
Posts: 1
Joined: Mon Aug 19, 2019 6:03 am

Re: Buster bug report thread

Mon Aug 19, 2019 6:05 am

I cannot see the camera preview after start_preview() using picamera library when connect my display through composite. Please help :(

nbgh007
Posts: 8
Joined: Tue Aug 20, 2019 7:45 am

Re: Buster bug report thread

Tue Aug 20, 2019 8:20 am

USB Hot-Plug failed in Buster (OK in Stretch as of July 16).

Raspbian Buster installed on 3b+ and 4b with NOOBS. 100% clean on reformatted microsd card, no customization, only update/dist-upgrade.
Raspberry PI (3b+ or 4b) and Surface Pro are connected to a USB switch to which are connected a mouse/keyboard set and a USB-Ethernet adapter. The switch has its own power supply - with and without did not change the general behavioral problem.
Sequence A: 1. Boot SP; 2. Switch to and boot RPI; 3. Switch back to SP; 4. Switch back to RPI, and nothing... no mouse/keyboard and frozen GUI. Sequence B: 1. Boot RPI; 2. Unplug connection to USB switch; 3. Wait 15 secs; 4. Reconnect to switch, and nothing... no mouse/keyboard and frozen GUI.

Raspbian Stretch (version of July 16) installed on 3b+ with NOOBS. 100% clean on reformatted microsd card, no customization. (Saved microsd card for just in case... :-)
No such problem...

I originally blamed and communicated with the USB switch manufacturer to find out after more tests last night that it was in fact raspbian buster...

jdonald
Posts: 309
Joined: Fri Nov 03, 2017 4:36 pm

Re: Buster bug report thread

Tue Aug 20, 2019 3:06 pm

The raspberrypi-kernel-headers package is installing the wrong version headers.
jamesh wrote:
Wed Jun 26, 2019 2:31 pm
For Raspbian issue: TBD
This isn't really a kernel issue so can't file on raspberrypi/linux. Where would should it go for a better chance of getting addressed?

plugwash
Forum Moderator
Forum Moderator
Posts: 3435
Joined: Wed Dec 28, 2011 11:45 pm

Re: Buster bug report thread

Tue Aug 20, 2019 4:22 pm


ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5789
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Buster bug report thread

Tue Aug 20, 2019 4:37 pm

plugwash wrote:
Tue Aug 20, 2019 4:22 pm
I would think https://github.com/rpi-distro/repo
Yup, that's it. Please provide more information though. The current kernel and headers packages are for 4.19.66. If you have an older kernel and install the headers package without upgrading the kernel package at the same time, then they won't match.

jdonald
Posts: 309
Joined: Fri Nov 03, 2017 4:36 pm

Re: Buster bug report thread

Wed Aug 21, 2019 2:02 am

I see now. I've corrected myself in the other thread.

What happened earlier was that I installed raspberrypi-kernel-headers followed by an rpi-update and didn't find any connection from 4.19.57 to 4.19.58 to 4.19.66.

Running apt update followed by a do-over gets headers and the kernel in sync to 4.19.66, so no Raspbian bug here.

nbgh007
Posts: 8
Joined: Tue Aug 20, 2019 7:45 am

Buster fails to (re)boot with powered USB Switch/Hub

Wed Aug 21, 2019 9:04 am

Buster fails to (re)boot with powered USB Switch/Hub (OK in Stretch as of July 16).
Similar bug report: USB Hot-Plug failed in Buster (OK in Stretch as of July 16).

Config:
Surface Pro (on PC1) / Raspberry PI 4b (on PC2).
Both connected to a powered USB Switch/Hub and a powered 4K HDMI Switch.
A mouse/keyboard set and a USB-to-Ethernet adapter is connected to the USB Switch.
A FHD TV screen is connected to the HDMI switch.

Initial Steps of each Sequence:
1. NOOBS 3.2.0 loaded on a newly formatted microsd card (Surface Pro / Windows 10).
2. Surface Pro shutdown, and both Switches switched to PC2.

Sequence 1 / Steps:
3. Power on RPI. Nothing... no boot
4. Switch USB Switch to PC1 (down) and back (to PC2). Boot started!

Sequence 2 / Steps:
3. Unplug USB Switch from power.
4. Power on RPI. Boot...

Sequence 3 / Steps:
3. Power on RPI. Nothing...! no boot
4. Switch USB Switch to PC1 (down) and back (to PC2). Boot started!
5. Install raspbian & (simple) config.
6. Reboot. Nothing...! no reboot
7. Switch USB Switch to PC1 (down) and back (to PC2). Reboot started!
8. Unplug USB Switch from power.
9. Reboot. No problem.
10. sudo apt-get update & dist-update.
11. no change to behavior

Notes:
1. This used to be a problem years ago...
2. Stretch as of June 16 (and April 8) is clean.
3. Stretch as of yesterday show the same problem...!
4. I wonder if that has to do with the idea to power RPI from USB...

User avatar
rpdom
Posts: 14759
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: Buster bug report thread

Wed Aug 21, 2019 10:00 am

What make/model is this "USB Switch/Hub"?

nbgh007
Posts: 8
Joined: Tue Aug 20, 2019 7:45 am

Buster fails to (re)boot with powered USB Switch/Hub

Wed Aug 21, 2019 2:55 pm

Ugreen:
https://www.amazon.de/UGREEN-Umschalter ... way&sr=8-3

It works perfect under similar scenarios (eg, unplug/plug-back the connection to the Switch) with Surface Pro (W10) et Dell Dimension (Mint 19.1), and between Surface Pro (W10) and Rapberry PI 3b+ (Raspbian version: Stretch prior to July 16).

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

Re: Buster fails to (re)boot with powered USB Switch/Hub

Wed Aug 21, 2019 2:59 pm

I've got the same switch. It backfeeds power to the Pi and the new Pi 4 doesn't like that. It is a problem with the switch as it shouldn't do that. The OS doesn't affect it. There is another thread on here with the same complaint from other people with this switch.

Return to “Raspbian”