[SOLVED] eth0 missing after upgrading sarpi-firmware/hack of 17 feb 2021

Pigi_102 · 03-16-2021, 03:02 PM

Also this test hasn't been successful

Only eth0, with exact mac address in udev rule:

Code:

root@casa:~# cat /etc/udev/rules.d/70-persistent-net.rules 

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="dc:a6:32:95:7c:c4", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

root@casa:~# reboot

Code:

root@casa:~# ifconfig eth0
eth0: error fetching interface information: Device not found

Just to be sure:

Code:

root@casa:~# last | grep reboot
reboot   system boot  5.4.65-v7l-sarpi Tue Mar 16 20:58 - 21:00  (00:02)    
reboot   system boot  5.4.65-v7l-sarpi Tue Mar 16 20:55 - 20:57  (00:02)

Holy crap ! It's driving me crazy.

Pigi

mralk3 · 03-16-2021, 03:39 PM

Have you had any power outages that affected your internet connection? It doesn't work with Raspbian AND Slackware AND doesn't show up in dmesg. Seems like your ethernet port is dead. Do you have a network port / network cable testing tool? Is the ethernet port on your modem still functional?

You do not provide enough information. So we are essentially guessing at helping you.

Pigi_102 · 03-16-2021, 03:39 PM

I finally found the problem !!!!!
By reading on
Raspberry device tree I finally fpung that all the device in the dtc is handled by bcm2711-rpi-4-b.dtb in the /boot

I've compared this file with one from previous ( old ) installation and noticed that:

Code:

root@casa:/boot# md5sum bcm2711-rpi-4-b.dtb
9490c333629da513b498887bdfb594bc  bcm2711-rpi-4-b.dtb.notworking
root@casa:/boot# md5sum bcm2711-rpi-4-b.dtb.old
915076abebc8a1c1d6b3c97a230b599f  bcm2711-rpi-4-b.dtb.old

In effect they looks a bit different also in size:

Code:

root@casa:/boot# ls -l bcm2711-rpi-4-b.dtb*
-rw-r--r-- 1 root root 47484 Mar 16 21:19 bcm2711-rpi-4-b.dtb.old
-rw-r--r-- 1 root root 49090 Mar 16 21:19 bcm2711-rpi-4-b.dtb

But the strangest thing is that:

Code:

root@casa:/boot# file bcm2711-rpi-4-b.dtb*
bcm2711-rpi-4-b.dtb.old:   Device Tree Blob version 17, size=47484, boot CPU=0, string block size=3960, DT structure block size=43452
bcm2711-rpi-4-b.dtb:       Device Tree Blob version 17, size=49090, boot CPU=0, string block size=4026, DT structure block size=44992

so same version different dimension.

I took the ".old" and copied on the existing one, rebooted and voila':

Code:

root@casa:/boot# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP mode DEFAULT group default qlen 1000
    link/ether dc:a6:32:95:7c:c4 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:e0:4c:6b:65:7d brd ff:ff:ff:ff:ff:ff
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN mode DEFAULT group default qlen 1000
    link/ether 9c:eb:e8:0d:0b:a5 brd ff:ff:ff:ff:ff:ff
5: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000
    link/ether dc:a6:32:95:7c:c5 brd ff:ff:ff:ff:ff:ff
6: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 100
    link/ether 1e:d5:d1:ec:d9:d6 brd ff:ff:ff:ff:ff:ff
7: tap1: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN mode DEFAULT group default qlen 100
    link/ether 1e:5c:4e:a6:30:57 brd ff:ff:ff:ff:ff:ff
8: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 1e:5c:4e:a6:30:57 brd ff:ff:ff:ff:ff:ff
9: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:e3:69:47:49 brd ff:ff:ff:ff:ff:ff
11: vetheba24aa@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default 
    link/ether b6:20:93:ca:2c:71 brd ff:ff:ff:ff:ff:ff link-netnsid 2
13: veth086ae3c@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default 
    link/ether f2:e4:4f:53:f7:5f brd ff:ff:ff:ff:ff:ff link-netnsid 0
15: veth2843de8@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default 
    link/ether 1a:d2:ac:92:c3:77 brd ff:ff:ff:ff:ff:ff link-netnsid 1
17: vethbd17c8d@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default 
    link/ether e2:fe:c0:fb:6a:cb brd ff:ff:ff:ff:ff:ff link-netnsid 3

and finally:

Code:

root@casa:/boot# dmesg | grep bcmge
[    1.007683] bcmgenet fd580000.ethernet: failed to get enet clock
[    1.007766] bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
[    1.007849] bcmgenet fd580000.ethernet: failed to get enet-wol clock
[    1.007935] bcmgenet fd580000.ethernet: failed to get enet-eee clock
[    1.008027] bcmgenet: Skipping UMAC reset
[    1.022750] libphy: bcmgenet MII bus: probed
[   16.945208] bcmgenet: Skipping UMAC reset
[   16.947297] bcmgenet fd580000.ethernet: configuring instance for external RGMII
[   16.947594] bcmgenet fd580000.ethernet eth0: Link is Down
[   80.393292] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

So definitely not an udev issue but a firmware/dtb problem.

You were right, Exaga, it could ( probably) be a consequence of the :

Quote:

Originally Posted by Exaga

Hi Pigi.
First of all you're dealing with SARPi batch 17Feb21 pkgs that were built during the "NVRAM-gate" fiasco where the brcmfmac43455 NVRAM files were updated due to new firmware being released. The issue was touched on in this post: https://www.linuxquestions.org/quest...ml#post6222303

Probably my board firmware is not aligned with the new dtb or maybe the dtb was in same way bad at least for my environment.

Should check more in depth which is the combination that stop my eth to appear, but for the moment I'm happy.

thanks all, and sorry for the noise.

Pigi

Exaga · 03-16-2021, 04:37 PM

Quote:

Originally Posted by Pigi_102

So definitely not an udev issue but a firmware/dtb problem.

"Stunning! Like a young Burt Reynolds."

Can I suggest, before the next time you ask for assistance, you might think about the problem and explain it in a way that doesn't waste so much of your time and effort? It's not a language barrier, it's just an organised approach - and thought process - which helps you, and helps others to help you. Keeping your Slackware [ARM] system fully up to date is high on the list of priorities, as it should be with any OS and/or frequently updated software.

Quote:

Originally Posted by mralk3

You do not provide enough information. So we are essentially guessing at helping you.

Food for thought. Perhaps this can be improved upon for future reference. Not the first time we've been here, so...

Quote:

Originally Posted by Exaga

So, updating Slackware ARM current with all the latest official pkgs - if it hasn't already been done [WHY NOT?!?!

] - and installing the latest SARPi shizzle pgks, should fix this problem.

Quote:

Originally Posted by Pigi_102

Code:

root@casa:~# last | grep reboot
reboot   system boot  5.4.65-v7l-sarpi Tue Mar 16 20:58 - 21:00  (00:02)    
reboot   system boot  5.4.65-v7l-sarpi Tue Mar 16 20:55 - 20:57  (00:02)

Linux kernel 5.4.65 release was circa September 2020? Is that the kernel version you were using?

Pigi_102 · 03-16-2021, 05:02 PM

Sorry, Exaga, just to learn for the next time:

Quote:

Originally Posted by Exaga

Can I suggest, before the next time you ask for assistance, you might think about the problem and explain it in a way that doesn't waste so much of your time and effort? It's not a language barrier, it's just an organised approach - and thought process - which helps you, and helps others to help you. Keeping your Slackware [ARM] system fully up to date is high on the list of priorities, as it should be with any OS and/or frequently updated software.

This was my first message:

Quote:

Originally Posted by Pigi_102

Hello all,
trying to fix a problem with wifi not working on my RPi4, as access point, on 21 February this year I've upgraded the two packages:

Code:

sarpi4-hacks-4.0-armv7l-1_slackcurrent_17Feb21_sp1
sarpi4-boot-firmware-armv7l-1_slackcurrent_17Feb21_sp1

I haven't rebooted as it was only firmware so modprobe -r and modprobe was all I needed to get stuff working again.

Today I lost power on rpi for the first time since, but after the power comes back and rpi rebooted, I was not able to reach her from remote.
No dhcp nor other services.
I've then connected a monitor and keyboard and started to debug.
It was an easy one.... eth0 was missing

Can you help shine some light on this ?
What should I check ?

I haven't talk about wlan, and haven't talk about udev.
Basically, in my intention, I meant:"I've upgraded this packages, it's only firmware, didn't rebooted soon, after reboot there is no more eth0"

If this is was not clear then, can you show me the right way to ask help for this problem ?

I don't want to look or be polemic, only I don't understand your feeling and want to learn on how to ask a question.

Pigi

Pigi_102 · 03-16-2021, 05:04 PM

Quote:

Originally Posted by Exaga

Linux kernel 5.4.65 release was circa September 2020? Is that the kernel version you were using?

Sorry, I missed your question.
Yes, is that one.
That was the last ( positive ) upgrade to current I did.

Pigi

Exaga · 03-16-2021, 05:09 PM

Quote:

Originally Posted by Pigi_102

Sorry, I missed your question.
Yes, is that one.
That was the last ( positive ) upgrade to current I did.

This link should help you...

https://www.latlmes.com/tech/why-kee...so-important-1

mralk3 · 03-16-2021, 05:31 PM

I see that Exaga has already done all the reaming, so I will just say: I am glad you figured it all out!

Exaga · 03-16-2021, 05:39 PM

Quote:

Originally Posted by Pigi_102

Sorry, Exaga, just to learn for the next time:

If this is was not clear then, can you show me the right way to ask help for this problem ?

I don't want to look or be polemic, only I don't understand your feeling and want to learn on how to ask a question.

No need to apologise.

Everybody works differently, but there has to be some organised thought processing going on, so that all involved are reading from the same page, in order to advise and offer help in return that's going to enable you to be productive and ultimately successful. You do have a responsibility to be accurate and concise with the information you give out when asking for help with any problem(s). Nobody is blessed with clairvoyance or owns a working crystal ball.

This could have all been very easy and taken 5-10 minutes to solve. It's taken 2 days and you've fixed the problem yourself by updating all your system pkgs - which is what should have been done before you even asked for help. Trying to fix an out-of-date system is often a lost cause.

Pigi_102 · 03-16-2021, 05:47 PM

Just for clarity, Exaga, I fixed by using an old dtb, from an old package.
When I tried to upgrade with sarpi4 hack and firmware from 6 March I ended with a not even booting system, but that was (almost) expected.
Probably some of the firmware and dtb are strictly tied with ( at least ) kernel release.

Pigi

Exaga · 03-16-2021, 06:06 PM

Quote:

Originally Posted by Pigi_102

Just for clarity, Exaga, I fixed by using an old dtb, from an old package.
When I tried to upgrade with sarpi4 hack and firmware from 6 March I ended with a not even booting system, but that was (almost) expected.
Probably some of the firmware and dtb are strictly tied with ( at least ) kernel release.

OK noted.

I think whatever you're doing is unconventional and not conducive towards maintaining a fully up-to-date Slackware ARM system. If you chop and change the pkgs you have installed, there could be missing elements, libraries, devices, udev rules, or whatever, and all sorts of chaos ensuing as a result. Then when people try to guess what's going (or gone) wrong, from the information you're giving them, it only exacerbates any confusion that arises.

Raspberry Pi kernels and firmwares are released at the same time for a reason. Using a 6 month old kernel and modern firmware (and vice versa) has a potential of giving you more problems than a toilet full of snakes. Then as people try to advise, you're not giving them the full picture of the mess that exists on your system to begin with. I think this was a major factor with the problem here.

It is, however, a valuable lesson for next time. If, next time, you haven't got a fully updated Slackware ARM system then I just won't waste any of your time by offering help or advice, until you have updated it.