No network devices available after Updating Debian


#1

Today I installed the latest copy of UNIX Demain (4-14). I was able to add my network WIFI.
Then I did the
apt-get update command

and I added all the updates and rebooted but now I cannot connect to the network.
The icon says “No network devices available”
When I run nmtui, I can see my network connection under “Edit” but I cannot activate it. The list of networks to activate is empty.


Connecting USB serial device
#2

This really looks like this:

https://bugs.96boards.org/show_bug.cgi?id=744

If so, yes, this is a known problem (and I am not sure how to fix it :wink: , but there is a workaround in the bug report as well.


#3

I thought that on kernel/modules update, old kernel/modules were NOT automatically removed (e.g. on my debian laptop I can boot on old kernel version if not manually removed). So in this condition kernel should be able find the corresponding (old) modules. Is it different with Dragonboard ?


#4

@Loic, the kernel package is upgraded, it’s not a new kernel package. The binary kernel package installed in the image is “linux-image-4.14.0-qcomlt-arm64”, and that’s the one that gets bump’d when we build a new kernel.

the problem is that we pushed a new kernel , so the binary package is upgraded in the rootfs, so the modules are upgraded too. but we will be booting with the original Image file… not the new one. that’s because the Image file is embedded in the boot image along with the bootloader, even though the Image file is also there in the rootfs…

there is no ‘trivial’ solution…

  • we could create a new kernel binary package for each build, and the kernel would never be upgraded at all
  • we could use uboot instead of LK, and have uboot fetch the image file from rootfs
  • we could maybe get LK to fetch from rootfs (not sure…)
  • we could recreate the boot image when installing a kernel and reflashing it into ‘boot’ partition (but what if the user didn’t use boot partition, but ‘fastboot boot’ command?)

#5

Is there any ETA on when this will be fixed? I might be able to do the fix suggested in the bug report but I need more detailed instructions.
Is loading an older version of Debian an option,


#6

Is there any ETA on when this will be fixed? I might be able to do the fix suggested in the bug report but I need more detailed instructions.
Is loading an older version of Debian an option,

Fixing up the damage is a little tricky (because there is no network)
however if you can reinstall it should be OK to reinstall 18.01. You can
avoid the problem happening by marking the kernel package so apt doesn’t
try to upgrade it.

If you run: sudo apt-mark hold linux-image-4.14.0-qcomlt-arm64
before the upgrade then it should prevent any problems.

To be doubly sure you might also like to sudo apt install abootimg
before you upgrade too (you can use abootimg to repair networking on
a broken system by copying the new kernel to the boot partition).

Daniel.


#7

@danielt, the workaround does not require network access to the board, since you can download the ‘latest’ boot image from snapshots.linaro.org and reboot with this image.

but you are right, that another workaround would be to regenerate the boot after from the board after the upgrade.

in fact something like

abootimg -u /dev/disk/by-partlabel/boot -k <Image.gz+dtb>

would work

@dstrower, I don’t have an ETA for a proper fix, at this point.


#8

This really looks like this:

https://bugs.96boards.org/show_bug.cgi?id=744

If so, yes, this is a known problem (and I am not sure how to fix it
:wink: , but there is a workaround in the bug report as well.

I think it is to do with how we have versioned the kernel package.

The normal debian kernel has a version number that gets bumped when
modules become incompatible.

linux-image-4.16.0-2-amd64 (4.16.12-1)
linux-image-4.16.0-1-amd64 (4.16.5-1)

The distro tools automatically prevent linux-image-4.16.0-1 from being
removed during an upgrade (assuming it met the properties requires to
be protected, such as being the running kernel). In our case all the
unique numbers are exclusively in the version number so the distro
scripts don’t protect our kernels in the same way.

linux-image-4.14.0-qcomlt-arm64 (4.14.15-00139-g5511441d1b48-20)


#9

@danielt, the workaround does not require network access to the board, since you can download the ‘latest’ boot image from snapshots.linaro.org and reboot with this image.

Agree. Using fastboot to workaround does not require to fix networking
access… but it does require people to know how long ago they did the
upgrade that broke the system (and some folks don’t reset their boards
very often).


#10

@danielt
I did your suggestion of reloading the UNIX and then doing the command:
sudo apt-mark hold linux-image-4.14.0-qcomlt-arm64
before the upgrade.
This worked. My Dragonboard is running now.

Thank you.


#11

Thanks @dstrower for posting this question, I had the exact same issue. Thanks @danielt for the suggested fix.


#12

@ndec, I think It’s important to fix/workaround this issue quickly, apt-upgrade is commonly used which will lead to many new issues opened on the forum for various reasons (WiFi, BT, camera, video encoder) because of missing modules.


#13

after a bit of discussion, we decided to add @danielt workaround in our image by default. so the kernel package will be held by default and the kernel will never be upgraded… which hopefully will not lead to too many issues…

‘power users’ who wants to use the latest kernel, will have to un-hold the package, but they will know that they have to worry about the boot image. for users that don’t want to worry about that, then apt-get upgrade should be less error prone…

it’s far from being perfect, but hopefully it’s a bit better…

the change has just been submitted here https://review.linaro.org/#/c/25914/, once it’s merged the new images will have it.