[SOLVED] Pi4 won't boot after update + no usb ports

[skynet01]

Hey guys, a little stumped. My Pi4 been running fine for about 3 weeks without any issues, I have an SSD drive connected (it gets mounted after boot and OS runs from it, used Toms guide https://www.tomshardware.com/news/boot- ... 39782.html:to USB3 and a small USB Hub to get Aeotec USB Zwave working. I am also using about 10 GPIO pins for basic reed window sensors (i am running home assistant on this Pi)

Today I decided to do an update, I have a "if it aint broke, let's brake it" mythology apparently.
I just ran a `sudo apt upgrade` got the following list of packages to upgrade:

Code: Select all

base-files/stable 10.3+rpi1+deb10u1 armhf [upgradable from: 10.3+rpi1]
bzip2/stable 1.0.6-9.2~deb10u1 armhf [upgradable from: 1.0.6-9.1]
console-setup-linux/stable 1.193~deb10u1 all [upgradable from: 1.191]
console-setup/stable 1.193~deb10u1 all [upgradable from: 1.191]
dirmngr/stable 2.2.12-1+rpi1+deb10u1 armhf [upgradable from: 2.2.12-1+rpi1]
docker-ce-cli/buster 5:19.03.2~3-0~raspbian-buster armhf [upgradable from: 5:19.03.1~3-0~raspbian-buster]
docker-ce/buster 5:19.03.2~3-0~raspbian-buster armhf [upgradable from: 5:19.03.1~3-0~raspbian-buster]
e2fsprogs/stable 1.44.5-1+deb10u1 armhf [upgradable from: 1.44.5-1]
gnupg-l10n/stable 2.2.12-1+rpi1+deb10u1 all [upgradable from: 2.2.12-1+rpi1]
gnupg-utils/stable 2.2.12-1+rpi1+deb10u1 armhf [upgradable from: 2.2.12-1+rpi1]
gnupg/stable 2.2.12-1+rpi1+deb10u1 all [upgradable from: 2.2.12-1+rpi1]
gpg-agent/stable 2.2.12-1+rpi1+deb10u1 armhf [upgradable from: 2.2.12-1+rpi1]
gpg-wks-client/stable 2.2.12-1+rpi1+deb10u1 armhf [upgradable from: 2.2.12-1+rpi1]
gpg-wks-server/stable 2.2.12-1+rpi1+deb10u1 armhf [upgradable from: 2.2.12-1+rpi1]
gpg/stable 2.2.12-1+rpi1+deb10u1 armhf [upgradable from: 2.2.12-1+rpi1]
gpgconf/stable 2.2.12-1+rpi1+deb10u1 armhf [upgradable from: 2.2.12-1+rpi1]
gpgsm/stable 2.2.12-1+rpi1+deb10u1 armhf [upgradable from: 2.2.12-1+rpi1]
gpgv/stable 2.2.12-1+rpi1+deb10u1 armhf [upgradable from: 2.2.12-1+rpi1]
keyboard-configuration/stable 1.193~deb10u1 all [upgradable from: 1.191]
libbabeltrace1/stable 1.5.6-2+deb10u1 armhf [upgradable from: 1.5.6-2]
libbz2-1.0/stable 1.0.6-9.2~deb10u1 armhf [upgradable from: 1.0.6-9.1]
libcom-err2/stable 1.44.5-1+deb10u1 armhf [upgradable from: 1.44.5-1]
libcryptsetup12/stable 2:2.1.0-5+deb10u2 armhf [upgradable from: 2:2.1.0-5]
libext2fs2/stable 1.44.5-1+deb10u1 armhf [upgradable from: 1.44.5-1]
libglib2.0-0/stable 2.58.3-2+deb10u1 armhf [upgradable from: 2.58.3-2]
libglib2.0-bin/stable 2.58.3-2+deb10u1 armhf [upgradable from: 2.58.3-2]
libglib2.0-data/stable 2.58.3-2+deb10u1 all [upgradable from: 2.58.3-2]
libldap-2.4-2/stable 2.4.47+dfsg-3+rpi1+deb10u1 armhf [upgradable from: 2.4.47+dfsg-3+rpi1]
libldap-common/stable 2.4.47+dfsg-3+rpi1+deb10u1 all [upgradable from: 2.4.47+dfsg-3+rpi1]
libncurses6/stable 6.1+20181013-2+deb10u1 armhf [upgradable from: 6.1+20181013-2]
libncursesw5/stable 6.1+20181013-2+deb10u1 armhf [upgradable from: 6.1+20181013-2]
libncursesw6/stable 6.1+20181013-2+deb10u1 armhf [upgradable from: 6.1+20181013-2]
libnss3/stable 2:3.42.1-1+deb10u1 armhf [upgradable from: 2:3.42.1-1]
libpam-systemd/stable 241-7~deb10u1+rpi1 armhf [upgradable from: 241-5+rpi1]
libss2/stable 1.44.5-1+deb10u1 armhf [upgradable from: 1.44.5-1]
libsystemd0/stable 241-7~deb10u1+rpi1 armhf [upgradable from: 241-5+rpi1]
libtinfo5/stable 6.1+20181013-2+deb10u1 armhf [upgradable from: 6.1+20181013-2]
libtinfo6/stable 6.1+20181013-2+deb10u1 armhf [upgradable from: 6.1+20181013-2]
libudev1/stable 241-7~deb10u1+rpi1 armhf [upgradable from: 241-5+rpi1]
libwbclient0/stable 2:4.9.5+dfsg-5+deb10u1+rpi1 armhf [upgradable from: 2:4.9.5+dfsg-5]
ncurses-base/stable 6.1+20181013-2+deb10u1 all [upgradable from: 6.1+20181013-2]
ncurses-bin/stable 6.1+20181013-2+deb10u1 armhf [upgradable from: 6.1+20181013-2]
ncurses-term/stable 6.1+20181013-2+deb10u1 all [upgradable from: 6.1+20181013-2]
systemd-sysv/stable 241-7~deb10u1+rpi1 armhf [upgradable from: 241-5+rpi1]
systemd/stable 241-7~deb10u1+rpi1 armhf [upgradable from: 241-5+rpi1]
udev/stable 241-7~deb10u1+rpi1 armhf [upgradable from: 241-5+rpi1]
unzip/stable 6.0-23+deb10u1 armhf [upgradable from: 6.0-23]
usb.ids/stable 2019.07.27-0+deb10u1 all [upgradable from: 2019.04.23-1]

Update went fine without any errors,
After the reboot the Pi4 won't boot. When it powers on, red light stays on, green light blinks for 1-2 seconds and then turns off. Whats strange is that none of the USB devices power on either, usually their light would come up right away.

I removed the sd card and i did get the correct number of blinking lights coming up (4 green blinks) so the bootloader seems ok.
I then reflashed my sd card (with balenaEtcher) with a fresh copy Raspbian Lite, still same deal. Also disconnected all devices from the board except for network cable.

Any ideas on what's happening / what other things i can do to trouble shoot this.

[skynet01]

Alright, it turned out that its somehow connected with my gpio's once i disconnected them the booting went ok.

Has anyone heard of something like this happening? The sensors are passive and dont have any power going to them, they all share common ground. Since they are reed sensors, this would be equivalent to grounding some GPIO pins when the windows are closed. Currently I am using:

gpio15
gpio14
gpio8
gpio7
gpio6
gpio5
gpio4
gpio3
gpio2
gpio1
gpio0

Thank you for the help!

[trejan]

GPIO0 and GPIO1 are used for the HAT configuration EEPROM. The firmware will try to read the EEPROM at startup to load in any configuration. Those two pins being connected to ground via your sensors is causing that to fail.

GPIO pins ID_SC and ID_SD (GPIO0 and GPIO1) are reserved for use solely for board detection / identification. The only allowed connections to the ID_ pins are an ID EEPROM plus 3.9K pull up resistors. Do not connect anything else to these pins!

[skynet01]

yeppppp.. you are correct! Thank you so much, I saw them marked green on diagram so I assumed they would be safe to go. Disconnected those and it boots fine. Also makes sense why they work after the boot and not during.