DietPi v6.9 and Device "NULL" does not exist

[slim0287]

With DietPi v6.9, when I switch to super user (sudo su), the header claims 'Device "NULL" does not exist.' v6.8 did not do this. Other than this odd report in the header, I can't detect any issues. A mild bug but I figured I'd report it.

Required Information:

• DietPi version | 6.9
• Distro version | 9.4
• Kernel version | 4.14.34-v7+
• SBC device | RPi2
• Power supply used | Eh, not sure. It came with the CanaKit.
• SDcard used | SanDisk Extreme 16GB microSHDC UHS-1

Steps to reproduce:

1. Upgrade from v6.8 to v6.9
2. Execute "sudo su"

Expected behaviour:

I've never seen the 'Device "NULL" does not exist.' message before when switching to super user.

Actual behaviour:

'Device "NULL" does not exist.' is reported when I switch to super user.

[MichaIng]

@slim0287
Thanks for your report. This shows up if no active network device could be found and should actually only occur if the system has no internet access as well.

Can you verify that you have network access, even that the error occurs?

Can you paste the output of:
ip a
ip r
ip l

With v6.9 we changed the network device estimation from net-tools ifconfig/route/netstat to ip, to allow non-root permissions and as ip is the modern way to do that.

Indeed where the previous method "fails" silently, ip r show eth0 shows the error you see. We will handle it with version v6.10 better.

€: Ah, forgot the sudo su. Hmm the error does not show up before that? Strange, as the banner and ip output should work the same. I will try to replicate.

[slim0287]

@MichaIng
Yes, the error only shows up with sudo su. I definitely have network access. I use this Pi as my DNS server (Pihole) plus I can ping network addresses from it, such as www.google.com.

Here's the output you asked for:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:27:eb:bb:a4:05 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:e0:4c:68:76:27 brd ff:ff:ff:ff:ff:ff
    inet 192.168.32.99/24 brd 192.168.32.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:4cff:fe68:7627/64 scope link 
       valid_lft forever preferred_lft forever
$ ip r
default via 192.168.32.9 dev eth1 
192.168.32.0/24 dev eth1 proto kernel scope link src 192.168.32.99 
$ ip l
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: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:bb:a4:05 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:68:76:27 brd ff:ff:ff:ff:ff:ff
$ 

Slim

[MichaIng]

@slim0287
Found a related issue, although in your case there are still some questions:

• You have two interfaces: eth0, which is down and eth1, which is up.
• Our obtain_network_device script goes through the ip l result list, which contains both, and saves the first found device in the list to further check with ip r.
• In your case, the first found device is down, thus does not show up on ip r, thus no "active" device is found.

This is indeed a bug we need to fix. Instead of first checking ip l we could directly scan ip r for eth[0-9] and wlan[0-9] to directly find the active device or integrate ip r loop into ip l loop and just break, after an active device was found.

But the other questions:

• It seems you have two Ethernet devices on your RPi2, the internal one an an external card/stick? Could be verified by ls -al /sys/class/net/, but ip l should always show exactly the same available devices. In case do you need both? DietPi is known to not handle two devices in parallel greatly, at least they cannot be configured via dietpi-config to be both active, thus just via manual setup.
• As the error does not show up without sudo su, I am not quite sure how this can be related, but it might be that eth0 is somehow just available/visible for root user. Could you rerun the ip l/r/a commands outside of sudo su?
• Up to v6.8 we used ifconfig to scan for available devices. On the one hand, ifconfig can be just run with root permissions, thus we ran it with sudo within our scripts, which would have made eth0 available then. But unlike ip l, ifconfig only shows active devices, thus the error cannot occur there.

Quick solution
Could you run sed -i 's/ip l/ip r/g' /DietPi/dietpi/obtain_network_details and retest?
This should restore the exact behaviour of pre 6.9.

@Fourdee
As ip l also lists inactive but available network devices, we could scan this indeed first via loop, save first eth/wlan index found, but go on with loop and replace the index, on first active device found (match ip r). If no active device was found, then we at least can show the first available device, skip IP estimation and instead show "inactive", "unplugged" or something like that within banner and other scripts that use the save file. Finally we could also add the full list of all available devices and their state/IP within banner, although this can lead to some additional lines and in case other scripts rework to handle this.

• [x] 🈯️ This case more generally shows, that we need to review https://github.com/Fourdee/DietPi/pull/1839 to check if ip l vs ifconfig leads to the same issue within other scripts. €: Done, no ip l used within PR above, ifconfig eth[0-9] replaced by ip a s eth[0-9] which would both fail with the same error.

[slim0287]

@MichaIng
I have two network interfaces because I set the Pi to use the USB port as an ethernet interface. I did this because I've found speeds of ethernet through USB are a lot faster than ethernet through the Pi's native ethernet port, using speedtest_cli. So, although there are two interfaces, I only use the interface through USB.

So, in response to your three questions:

• ls -al /sys/class/net does show the two eth interfaces I described above and I did put the USB interface in through a manual set up. Are you suggesting I should delete the interface associated with the native ethernet port?

• In thelp l/r/a output I gave you previously, that was outside of sudo su. Here is the output inside of sudo su:

root@atlantis:~# ip l
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: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:bb:a4:05 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:68:76:27 brd ff:ff:ff:ff:ff:ff
root@atlantis:~# ip r
default via 192.168.32.9 dev eth1 
192.168.32.0/24 dev eth1 proto kernel scope link src 192.168.32.99 
root@atlantis:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:27:eb:bb:a4:05 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:e0:4c:68:76:27 brd ff:ff:ff:ff:ff:ff
    inet 192.168.32.99/24 brd 192.168.32.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:4cff:fe68:7627/64 scope link 
       valid_lft forever preferred_lft forever
root@atlantis:~# 

I tried your "quick solution" but there is no such file:

$ sed -i 's/ip l/ip r/g' /DietPi/dietpi/obtain_network_details
sed: can't read /DietPi/dietpi/obtain_network_details: No such file or directory

Ok, I think I answered your questions and perhaps provided some critical information regarding how my interfaces are set up. Thanks for the help!

[MichaIng]

@slim0287
Thanks for response. Hmm as ip outputs are the same, I am still confused why the error does not show up outside of sudo su. But anyway, the issue is clear.
Sorry about the wrong fix, forgot the script is in sub directory. Use:
sed -i 's/ip l/ip r/g' /DietPi/dietpi/func/obtain_network_details

Jep, RPi2 ethernet is just 100Mbit, where external could be Gbit. Makes sense to use external one, if you need the network speed.

About disabling internal device: I think in this case you could/need to completely disable the related kernel module. I will check later how to achieve this. Would be cool to have this as an option within dietpi-config: Generally allow to disable internal network device for SBCs where applicable due to non Gbit. Of course an additional device should be found then.

[stuie382]

For me, moving the /etc/network/interfaces into the /etc/network/interfaces.d directory then rebooting did the trick

[slim0287]

I went ahead and did:
sed -i 's/ip l/ip r/g' /DietPi/dietpi/func/obtain_network_details

That did the trick for removing the device null upon sudo su. I have not tried stuie382's suggestion of moving the /etc/network/interfaces file into the /etc/network/interfaces.d directory.

Admittedly, I probably no longer need the speed that comes from using the external interface given I use this Pi primarily for Pi-hole and also as an Samba server for music for my Sonos. However somewhere along my screwing around with Pis I found the external interface as faster so I've been using it when I have a wired connection. I'm not ambitious enough to disable related kernels modules for disabling the internal device, and given everything is working well in my application there doesn't seem to be a need.

At this point, it seems you understand the issue and perhaps will address it in 6.10. Nothing's broken here, so I'll sight tight until the next release.

[MichaIng]

@slim0287
Jep, this will be fixed for v6.10, thanks again for testing and reporting back.
With the fix, there is indeed no need to disable any kernel module, but it would make things more consistent and clean, if e.g. one could choose the one (or several) network devices that are wanted to be active and thus disable the other ones. But low priority indeed, most importantly we have a solution as above.

@stuie382
There should be no difference, if the file is placed at /etc/network/interfaces or within /etc/network/interfaces.d. Settings within /etc/network/interfaces.d in case overwrite the ones within /etc/network/interfaces, but if the latter is not available at all, nothing should change. Furthermore doing this will break DietPi-Config and other scripts, as well as some Debian core functions which expect the file to be present. Maybe in your case the reboot itself was the solution?

[stuie382]

@Michalng I had performed several reboots prior to moving the file and it would refuse to boot successfully due to the null device error.

[MichaIng]

@stuie382
Hmm it refused to boot successfully? In TO case this was just a cosmetic error that does not affect boot or network access. Our IP estimation script just scanned the wrong interface. Although I am currently not sure, if some other scripts, parsing this info, might lead to further issues. Will check this later. The banner of course is just cosmetic.

In your case the main issue seems to be a different then. If the above solution (without moving interface file) does not work for you, I suggest to open a separate issue, at best with dietpi-bugreport upload, so we can investigate separately.

[MichaIng]

@slim0287
I fixed the issue for v6.10 and made some general code rework of the script when already touching: https://github.com/Fourdee/DietPi/pull/1853

You can test, if you like, by simply replacing the current script:
wget https://raw.githubusercontent.com/Fourdee/DietPi/obtain_network_details/dietpi/func/obtain_network_details -O /DietPi/dietpi/func/obtain_network_details

[slim0287]

@MichaIng
Unfortunately the result of the command you provided was not too good:

$ sudo wget https://raw.githubusercontent.com/Fourdee/DietPi/obtain_network_details/dietpi/func/obtain_network_details -O /DietPi/dietpi/func/obtain_network_details
--2018-06-16 16:35:20--  https://raw.githubusercontent.com/Fourdee/DietPi/obtain_network_details/dietpi/func/obtain_network_details
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.24.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.24.133|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2018-06-16 16:35:20 ERROR 404: Not Found.

$ ls -al
total 216
drwxr-xr-x 2 root root   360 Jun 13 14:10 .
drwxr-xr-x 5 root root   960 Jun 10 06:41 ..
-rwxr-xr-x 1 root root     0 Jun 16 16:35 obtain_network_details
$ 

I deleted some of the directory listing just to simplify this post, but you see I ended up with a zero byte obtain_network_details file. I put the v6.9 file back in place with:

sudo wget https://github.com/Fourdee/DietPi/blob/master/dietpi/func/obtain_network_details -O /DietPi/dietpi/func/obtain_network_details

After I do this, I no longer have the Device "NULL" does not exist. issue. Admittedly, I'm a little confused because github lists the obtain_network_details I grabbed as last modified 26 days ago.

Whatever the case may be, everything appears to be working for me.

[MichaIng]

@slim0287
Ah sorry, we just merged the PR into testing branch, thus the branch within you link is not available any more and nothing got downloaded/replaced. Use now:
sudo wget https://raw.githubusercontent.com/Fourdee/DietPi/testing/dietpi/func/obtain_network_details -O /DietPi/dietpi/func/obtain_network_details
Sorry, I am always too fast to clean up branches, after PR was merged 😉.

[slim0287]

@MichaIng
Thanks, that worked. obtain_network_details now is a much smaller file and theDevice "NULL" does not exist doesn't exist.😉

[MichaIng]

@slim0287
Great to hear 😃. Jep I made some code tuning besides and reduced script size and execution time by about one third.

Okay I will close this issue now. Feel free to reopen if required.