Fixed with an update to webkit, thanks!Fraoch wrote: ↑Thu Aug 08, 2019 1:48 pmCan 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.
Re: Buster bug report thread
Pencoed-made Model 1B, Samsung memory
2B 1.1
3B+
4B 2GB
2B 1.1
3B+
4B 2GB
-
- Posts: 456
- Joined: Wed Sep 25, 2013 8:43 am
- Location: Canterbury, Kent, UK
- Contact: AOL
Re: Buster bug report thread
If you need it this works...plugwash wrote: ↑Tue Aug 06, 2019 1:28 pmYes, 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.
Code: Select all
sudo pip3 install ws4py
- RichardRussell
- Posts: 698
- Joined: Thu Jun 21, 2012 10:48 am
Re: Buster bug report thread
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.
Re: Buster bug report thread
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.
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.
Re: Buster bug report thread
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.
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.
Lack of error reporting for missing root partition
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.
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)
Re: Buster bug report thread
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.
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.
-
- Posts: 337
- Joined: Sat Dec 29, 2012 2:45 am
- Location: Lund, Skåne/Scania, Sweden
- Contact: Website Facebook Twitter YouTube
Re: Buster bug report thread
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?
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/ rasPiOS. 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/
- RichardRussell
- Posts: 698
- Joined: Thu Jun 21, 2012 10:48 am
Re: Buster bug report thread
If it would be helpful to report this at the official github repo, which category does mesa/V3D belong in: linux, firmware or userland?RichardRussell wrote: ↑Sat Aug 10, 2019 9:31 amIs there a forecast for when this V3D driver fix will be incorporated in Buster?
Re: Buster bug report thread
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:
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.
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?)
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:
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
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
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 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.
Re: Buster bug report thread
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.
Re: Buster bug report thread
I discovered that using a hub makes it work (in my initial report).trejan wrote: ↑Thu Aug 15, 2019 6:05 pmThere 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.
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.
Re: Buster bug report thread
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.
Re: Buster bug report thread
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.
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.
Re: Buster bug report thread
I cannot see the camera preview after start_preview() using picamera library when connect my display through composite. Please help 

Re: Buster bug report thread
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...
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...
Re: Buster bug report thread
The raspberrypi-kernel-headers package is installing the wrong version headers.
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?
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 6275
- 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
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.
Re: Buster bug report thread
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.
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.
Buster fails to (re)boot with powered USB Switch/Hub
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...
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...
Buster fails to (re)boot with powered USB Switch/Hub
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).
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).
Re: Buster fails to (re)boot with powered USB Switch/Hub
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.nbgh007 wrote: ↑Wed Aug 21, 2019 2:55 pmUgreen:
https://www.amazon.de/UGREEN-Umschalter ... way&sr=8-3