Boot up from cold boot no network

Fri Sep 23 16:12:25 MST 2022

The onboard nic is a 82579LM Gigabit Network Connection (Lewisville)
        vendor: Intel Corporation

The driver is e1000e. When this nic began acting up a few months ago, I 
started using the usb adapter.  When it started acting up, I removed it 
and went back to the onboard nic.

ip link showed

: 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 so ip 
neighbor showed nothing.  ip address: 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

tcpdump did nothing.

Joseph Sinclair asked if I upgraded or downgraded the kernel. I hadn't 
upgraded the kernel unless it did that when I upgraded to Kubuntu 22.04.

I ran journalctl -xe after it booted up without the network and with 
it.  I wouldn't know what to look for.  If anyone else wants to have a 
look, I've put version on google drive.

without network 
https://drive.google.com/file/d/1tPf-2wzsAdN9YL1fbIt0gbJu082YCqUU/view?usp=sharing

with network 
https://drive.google.com/file/d/1_dc12Loro0D4dCe8_kodqIj3GKTQOspf/view?usp=sharing

On 9/23/22 14:00, Michael Butash via PLUG-discuss wrote:
> I've used a lot of usb-based devices, and still do technically with a 
> thunderbolt dock for like the past 5 years, and not really run into 
> this on either ubuntu or arch.  I've run into some weirdness before 
> though with wired or wireless nics. Basic linux network 101 applies... 
> test it like a network engineer, layer 1-7.
>
> use "ip link" to see the state of of the physical nic, or verify layer 1
> use "ip neighbor" to verify you see mac forwarding ala arp table, or 
> layer 2/3
> use "ip address" to verify exactly that, verifying dhcp or static 
> configs take place for layer 3
> use "iftop" or "tcpdump" to see what traffic is sending, and if any is 
> coming back assuming your nic has link for layer 2-7
>
> Aside from that probably a kernel/firmware thing.  Use journalctl -xe 
> or -b options to show you boot and logs (as root) of what happens 
> around the events with your nic.  It could be some firmware bug, 
> realtek's used to be terrible cursed names, but really haven't a 
> problem for me in the past 5-10 years I'd say, and you're hard pressed 
> to find a usb nic that *isn't* a realtek.
>
> You can probably rmmod and insmod the realtek driver too as long as 
> something isn't using it.  If it's busted, it should not be used, but 
> stranger things happen, especially if firmware is hung in a funky way, 
> which is usually what would always happen with them.
>
> -mb
>
>
> On Fri, Sep 23, 2022 at 12:04 PM T Zack Crawford via PLUG-discuss 
> <plug-discuss at lists.phxlinux.org> wrote:
>
>     I am very interested in the answer because my desktop does the
>     same thing if I tell it to hibernate, boot into my windows dual
>     boot, and reboot back into linux. I can regain network access
>     again by hibernating again and booting back into linux directly
>     (no windows). Pretty annoying because it takes a solid 2-5 minutes
>     to shut down when hibernating. At least it still does the job,
>     just with delay.
>
>     This only happens if I try hibernating and then boot into windows
>     (not full shutdown, not hibernate and boot directly to linux). It
>     has always happened since I enabled hibernation (arch wiki
>     instructions). Having Systemd restart NetworkManager does nothing.
>     Setting up a new network configuration with networkmanager does
>     not solve it. This is with my motherboard ethernet and my wireless
>     USB adapter. I spent some good energy trying to figure it out, but
>     never did.
>
>
>     Did you update kernels today? What if you downgrade?
>
>     Put the solution as a boot script. Or at least bash profile
>     instead of run commands (otherwise it will run every time you
>     spawn a terminal shell)
>
>     Sep 23, 2022 11:14:35 Jim via PLUG-discuss
>     <plug-discuss at lists.phxlinux.org>:
>
>     > A few months ago my Dell Optiplex 7010 running Ubuntu 20.04
>     started booting up without the network.  I'd reboot the machine
>     and  the network was there.  If I shut down the machine and turned
>     it on again, no network.  I thought something was wrong with the
>     built in ethernet adapter, so I bought a usb adapter, disabled the
>     built in one and the problem went away until today.  Now it's
>     happening with the usb ethernet adapter.  Rebooting the machine
>     fixes the problem gets the network up and running.  If I start
>     with a cold boot and reboot at the grub screen, I get the
>     network.  I have 3 SSDs and 2 HDDs.  I have the same video card
>     that I had before this problem first showed itself.  It's a
>     GeForce GT 710.
>     >
>     > I looked online and found something telling of other people who
>     have had this problem.  They disconnected video cards and went
>     back to the built in video (display port), and removed hard drives
>     that had been added later and this fixed the problem.  The
>     ultimate solution was to replace the power supply.  I disconnected
>     one SSD and the 2 HDDs.  I don't have anything that can use a
>     display port, so I left the video card in place.  All I had
>     connected were  2 SSDs.  One it boots from and my home directory
>     is on the other.  The problem still showed itself when I booted
>     the machine, so I shut down and plugged in everything again.  This
>     thing has a 240 watt power supply.  Do power supplies go band in
>     such a way they don't produce the amount of power they used to?
>     >
>     > Any ideas what it might be?  Is there a command that would tell
>     the system to set up the network again?  If there is, I could put
>     it in the .bashrc until I get this fixed.
>     >
>     > Thanks
>     >
>     > ---------------------------------------------------
>     > PLUG-discuss mailing list: PLUG-discuss at lists.phxlinux.org
>     > To subscribe, unsubscribe, or to change your mail settings:
>     > https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>     ---------------------------------------------------
>     PLUG-discuss mailing list: PLUG-discuss at lists.phxlinux.org
>     To subscribe, unsubscribe, or to change your mail settings:
>     https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list:PLUG-discuss at lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20220923/b0d1e7ab/attachment.htm>