It seems to me from this that the cabled network hardware is not being properly initialised when booting Ubuntu 24. The cure is simply to actually power down the PC before launching Ubuntu 24
Java Jive wrote:
It seems to me from this that the cabled network hardware is not being
properly initialised when booting Ubuntu 24. The cure is simply to
actually power down the PC before launching Ubuntu 24
I had some older Dells (Precision and Dimension) which disabled the NIC
if it wasn't physically connected at the time it booted Windows, there
was a utility to re-enable it, probably doesn't exist for Linux (though
Dell were pretty good with their Linux support via Fedora last time I
kept up with it).
On 2025-11-15 15:04, Andy Burns wrote:
Java Jive wrote:
It seems to me from this that the cabled network hardware is not
being properly initialised when booting Ubuntu 24. The cure is
simply to actually power down the PC before launching Ubuntu 24
I had some older Dells (Precision and Dimension) which disabled the
NIC if it wasn't physically connected at the time it booted
Windows, there was a utility to re-enable it, probably doesn't
exist for Linux (though Dell were pretty good with their Linux
support via Fedora last time I kept up with it).
Interesting piece of info ... However, during the testing these were
in E-Dock stations - from which they are only undocked when I
travel, so weren't undocked during testing - so seemingly there
wouldn't be any reason for either OS to disable the netcard, as it
was permanently connected during the testing.
At Sat, 15 Nov 2025 15:17:26 +0000, Java Jive <java@evij.com.invalid>
wrote:
On 2025-11-15 15:04, Andy Burns wrote:
Java Jive wrote:
It seems to me from this that the cabled network hardware is not
being properly initialised when booting Ubuntu 24. The cure is
simply to actually power down the PC before launching Ubuntu 24
I had some older Dells (Precision and Dimension) which disabled the
NIC if it wasn't physically connected at the time it booted
Windows, there was a utility to re-enable it, probably doesn't
exist for Linux (though Dell were pretty good with their Linux
support via Fedora last time I kept up with it).
Interesting piece of info ... However, during the testing these were
in E-Dock stations - from which they are only undocked when I
travel, so weren't undocked during testing - so seemingly there
wouldn't be any reason for either OS to disable the netcard, as it
was permanently connected during the testing.
Weird problem. If you want to troubleshoot, you might get
it into failure mode, then run ethtool on the ethernet device
to see if auto-negotiation is happening properly, if the
Linux driver thinks link is detected, and so forth.
What chipset does your Ethernet use, and is it part
of the dock? It appears that Intel driver modules
have a "debug" option that can be set, not sure if
that helps...
In case it's helpful to anyone else ...
I have some Dell Precision M6800s & M6700s dual-booting via Grub between various versions of Windows and Ubuntu 24, all cabled to the LAN. If I choose to move between any version of Windows and Ubuntu by rebooting,
In case it's helpful to anyone else ...
I have some Dell Precision M6800s & M6700s dual-booting via Grub between various versions of Windows and Ubuntu 24, all cabled to the LAN. If I choose to move between any version of Windows and Ubuntu by rebooting, Ubuntu 24 cannot make a reliable cabled LAN connection, it keeps trying
to connect but never succeeds. However, if I choose to move between any version of Windows and Ubuntu by shutting down the PC in between, Ubuntu
24 'just works', no networking problem at all. Reboot from U24 and go
back into U24, the situation is unchanged - if it was working before
the reboot, it's working now, if it wasn't working before the reboot, it isn't working now. Reboot from U24 and go back into Windows, no network problems in Windows at all. Reboot from Windows and go back into any version of Windows, no network problems at all.
In summary, when rebooting ...
Ubuntu 24 -> Ubuntu 24 No change
Ubuntu 24 -> Windows No problem
Windows -> Ubuntu 24 U24 cannot make cabled LAN connection
Windows -> Windows No problem
It seems to me from this that the cabled network hardware is not being properly initialised when booting Ubuntu 24. The cure is simply to
actually power down the PC before launching Ubuntu 24
On 2025-11-15, Java Jive wrote:
In case it's helpful to anyone else ...
I have some Dell Precision M6800s & M6700s dual-booting via Grub between
various versions of Windows and Ubuntu 24, all cabled to the LAN. If I
choose to move between any version of Windows and Ubuntu by rebooting,
Win10, 11 have that "FastBoot" thing that mucks with hardware releases
on "reboot" (win basically goes into hibernate).
Not sure if / how that'd work *between* windows versions (e.g. you had
both 10,11 installed) though ...
On 2025-11-15 16:17, vallor wrote:
At Sat, 15 Nov 2025 15:17:26 +0000, Java Jive <java@evij.com.invalid>
wrote:
On 2025-11-15 15:04, Andy Burns wrote:
Java Jive wrote:
It seems to me from this that the cabled network hardware is not
being properly initialised when booting Ubuntu 24. The cure is
simply to actually power down the PC before launching Ubuntu 24
I had some older Dells (Precision and Dimension) which disabled the
NIC if it wasn't physically connected at the time it booted
Windows, there was a utility to re-enable it, probably doesn't
exist for Linux (though Dell were pretty good with their Linux
support via Fedora last time I kept up with it).
Interesting piece of info ... However, during the testing these were
in E-Dock stations - from which they are only undocked when I
travel, so weren't undocked during testing - so seemingly there
wouldn't be any reason for either OS to disable the netcard, as it
was permanently connected during the testing.
Weird problem. If you want to troubleshoot, you might get
it into failure mode, then run ethtool on the ethernet device
to see if auto-negotiation is happening properly, if the
Linux driver thinks link is detected, and so forth.
What chipset does your Ethernet use, and is it part
of the dock? It appears that Intel driver modules
have a "debug" option that can be set, not sure if
that helps...
Thanks for the suggestions, but now I know what causes it and the simple fix, probably I shall just try to remember always to shut down the PC
before going into Ubuntu.
Back now in Windows, the cabled net card is described as 'Intel Ethernet Connection I217-LM', and this doesn't change when docking and undocking
the PC. Similarly, another PC's net card, again regardless of whether
it is docked or not, is described as 'Intel 82579LM Gigabit Network Connection' (I haven't tested the Ubuntu 24 problem on that one, as it wasn't the PC I noticed the problem on). Given this, I think the dock
is merely an alternative connection between the PC's network interface
and the outside world, and doesn't have it's own separate network
interface in the dock itself.
Don't know what are the "networking problems". In each scenario, can
you connect to the internal web server in the cable modem, router, or whatever you have upstream of the problematic host? Check if you can do intranet connections before testing if you can get to the Internet.
It seems to me from this that the cabled network hardware is not being properly initialised when booting Ubuntu 24. The cure is simply to actually power down the PC before launching Ubuntu 24
In case it's helpful to anyone else ...
I have some Dell Precision M6800s & M6700s dual-booting via Grub between various versions of Windows and Ubuntu 24, all cabled to the LAN. If I choose to move between any version of Windows and Ubuntu by rebooting, Ubuntu 24 cannot make a reliable cabled LAN connection, it keeps trying
to connect but never succeeds. However, if I choose to move between any version of Windows and Ubuntu by shutting down the PC in between, Ubuntu
24 'just works', no networking problem at all. Reboot from U24 and go
back into U24, the situation is unchanged - if it was working before
the reboot, it's working now, if it wasn't working before the reboot, it isn't working now. Reboot from U24 and go back into Windows, no network problems in Windows at all. Reboot from Windows and go back into any version of Windows, no network problems at all.
In summary, when rebooting ...
Ubuntu 24 -> Ubuntu 24 No change
Ubuntu 24 -> Windows No problem
Windows -> Ubuntu 24 U24 cannot make cabled LAN connection
Windows -> Windows No problem
It seems to me from this that the cabled network hardware is not being properly initialised when booting Ubuntu 24. The cure is simply to actually power down the PC before launching Ubuntu 24
Win10, 11 have that "FastBoot" thing that mucks with hardware releases
on "reboot" (win basically goes into hibernate).
On 15/11/2025 14:39, Java Jive wrote:
It seems to me from this that the cabled network hardware is not being
properly initialised when booting Ubuntu 24. The cure is simply to
actually power down the PC before launching Ubuntu 24
You can try this trick to see if it connects without rebooting Ubuntu:
<https://i.postimg.cc/q7sgR5M3/2025-11-15-19-05-40.png>
This is all done in Ubuntu.
VanguardLH wrote:
Don't know what are the "networking problems". In each scenario, can
you connect to the internal web server in the cable modem, router, or
whatever you have upstream of the problematic host? Check if you can do
intranet connections before testing if you can get to the Internet.
I can't connect to anything in the problem scenario of rebooting from Windows into Ubuntu 24, I can connect to everything when there is no problem.
Dan Purgert <dan@djph.net> writes:
Win10, 11 have that "FastBoot" thing that mucks with hardware releases
on "reboot" (win basically goes into hibernate).
No. Reboot is always reboot, Windows would be completely useless without that. "FastBoot" aka fast startup happens when shutting down if not
disabled. And it's hibernate without hibernating apps so fairly useless.
Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
Dan Purgert <dan@djph.net> writes:
Win10, 11 have that "FastBoot" thing that mucks with hardware releases
on "reboot" (win basically goes into hibernate).
No. Reboot is always reboot, Windows would be completely useless without
that. "FastBoot" aka fast startup happens when shutting down if not
disabled. And it's hibernate without hibernating apps so fairly useless.
Actually Fast Starup is a full hibernate (all memory copied into the hyberfil.sys file).
Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
Dan Purgert <dan@djph.net> writes:
Win10, 11 have that "FastBoot" thing that mucks with hardware releases
on "reboot" (win basically goes into hibernate).
No. Reboot is always reboot, Windows would be completely useless without
that. "FastBoot" aka fast startup happens when shutting down if not
disabled. And it's hibernate without hibernating apps so fairly useless.
Actually Fast Starup is a full hibernate (all memory copied into the hyberfil.sys file). The computer then goes into sleep mode. When
brought out of sleep, the computer resumes from sleep. If, however, the computer ever lost power during sleep, the computer resumes using the hibernate file. Because a memory image is reinstated or resumed from a
Fast Startup mode, there is no re-initialization of hardware. This is
the same as a Windows restart which is a warm boot.
VanguardLH <V@nguard.LH> writes:
Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
Dan Purgert <dan@djph.net> writes:
Win10, 11 have that "FastBoot" thing that mucks with hardware releases >>>> on "reboot" (win basically goes into hibernate).
No. Reboot is always reboot, Windows would be completely useless without >>> that. "FastBoot" aka fast startup happens when shutting down if not
disabled. And it's hibernate without hibernating apps so fairly useless.
Actually Fast Starup is a full hibernate (all memory copied into the
hyberfil.sys file).
Source? For example here: https://learn.microsoft.com/en-us/windows-hardware/test/weg/delivering-a-great-startup-and-shutdown-experience
"Starting with Windows 8.x, the default shutdown and restart scenario
has been updated and named fast startup. Fast startup begins with the shutdown process and includes writing data to disk similar to the
hibernate process. A key difference is that all user sessions (Session
1) are logged off and the remaining information is written to the
hiberfile."
When user sessions are logged off, all user apps die and so aren't
written to the hiberfil.sys, which, as I stated, makes this "fast
startup" fairly useless.
VanguardLH <V@nguard.LH> writes:
Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
Dan Purgert <dan@djph.net> writes:
Win10, 11 have that "FastBoot" thing that mucks with hardware releases >>>> on "reboot" (win basically goes into hibernate).
No. Reboot is always reboot, Windows would be completely useless without >>> that. "FastBoot" aka fast startup happens when shutting down if not
disabled. And it's hibernate without hibernating apps so fairly useless.
Actually Fast Starup is a full hibernate (all memory copied into the
hyberfil.sys file).
Source? For example here: https://learn.microsoft.com/en-us/windows-hardware/test/weg/delivering-a-great-startup-and-shutdown-experience
"Starting with Windows 8.x, the default shutdown and restart scenario
has been updated and named fast startup. Fast startup begins with the shutdown process and includes writing data to disk similar to the
hibernate process. A key difference is that all user sessions (Session
1) are logged off and the remaining information is written to the
hiberfile."
When user sessions are logged off, all user apps die and so aren't
written to the hiberfil.sys, which, as I stated, makes this "fast
startup" fairly useless.
On 2025-11-16 03:18, VanguardLH wrote:
Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
Dan Purgert <dan@djph.net> writes:
Win10, 11 have that "FastBoot" thing that mucks with hardware releases >>>> on "reboot" (win basically goes into hibernate).
No. Reboot is always reboot, Windows would be completely useless without >>> that. "FastBoot" aka fast startup happens when shutting down if not
disabled. And it's hibernate without hibernating apps so fairly useless.
Actually Fast Starup is a full hibernate (all memory copied into the
hyberfil.sys file). The computer then goes into sleep mode. When
brought out of sleep, the computer resumes from sleep. If, however, the
computer ever lost power during sleep, the computer resumes using the
hibernate file. Because a memory image is reinstated or resumed from a
Fast Startup mode, there is no re-initialization of hardware. This is
the same as a Windows restart which is a warm boot.
No, hardware has to be reinitialized "somehow". Hardware has been
powered off, they have to be put back in the same status as they were
when the machine hibernated. The driver needs adequate entries to
restore status.
Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
VanguardLH <V@nguard.LH> writes:
Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
Dan Purgert <dan@djph.net> writes:Actually Fast Starup is a full hibernate (all memory copied into the
Win10, 11 have that "FastBoot" thing that mucks with hardware releases >>>> on "reboot" (win basically goes into hibernate).
No. Reboot is always reboot, Windows would be completely useless without >>> that. "FastBoot" aka fast startup happens when shutting down if not
disabled. And it's hibernate without hibernating apps so fairly useless. >>
hyberfil.sys file).
Source? For example here: https://learn.microsoft.com/en-us/windows-hardware/test/weg/delivering-a-great-startup-and-shutdown-experience
"Starting with Windows 8.x, the default shutdown and restart scenario
has been updated and named fast startup. Fast startup begins with the shutdown process and includes writing data to disk similar to the
hibernate process. A key difference is that all user sessions (Session
1) are logged off and the remaining information is written to the hiberfile."
When user sessions are logged off, all user apps die and so aren't
written to the hiberfil.sys, which, as I stated, makes this "fast
startup" fairly useless.
Depends on whether or not you chose to sleep (whether manually
instigated, or by idle timeout) or shutdown while Fast Startup (aka
FastBoot) was enabled.
On sleep, Fast Startup saves an image of memory into the hiberfil.sys
file. That's in case power is lost during sleep which means a reboot is needed, so the hiberfil.sys file is used to write back the memory image
on the boot. If power is not lost during sleep mode, well, you just
resume out of sleep mode.
Fast Startup may speed up booting, but it slows shutdown. When the
computer goes into sleep mode, you don't notice the writes to
hiberfil.sys. Users are more sensitive to how long it takes them to
resume using Windows, because they're waiting there staring at the
monitor. They are less sensitive to what happens going to sleep, or
during shutdown, because typically they leave, so they are not waiting. Faster startup, slower shutdown.
MikeS <mikes@is.invalid> wrote:
On 17/11/2025 12:26, VanguardLH wrote:
"Carlos E.R." <robin_listas@es.invalid> wrote:
On 2025-11-16 03:18, VanguardLH wrote:
Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
Dan Purgert <dan@djph.net> writes:Actually Fast Starup is a full hibernate (all memory copied into the >>>>> hyberfil.sys file). The computer then goes into sleep mode. When
Win10, 11 have that "FastBoot" thing that mucks with hardware releases >>>>>>> on "reboot" (win basically goes into hibernate).
No. Reboot is always reboot, Windows would be completely useless without >>>>>> that. "FastBoot" aka fast startup happens when shutting down if not >>>>>> disabled. And it's hibernate without hibernating apps so fairly useless. >>>>>
brought out of sleep, the computer resumes from sleep. If, however, the >>>>> computer ever lost power during sleep, the computer resumes using the >>>>> hibernate file. Because a memory image is reinstated or resumed from a >>>>> Fast Startup mode, there is no re-initialization of hardware. This is >>>>> the same as a Windows restart which is a warm boot.
No, hardware has to be reinitialized "somehow". Hardware has been
powered off, they have to be put back in the same status as they were
when the machine hibernated. The driver needs adequate entries to
restore status.
It is the lack of initialization of hardware on a FastBoot startup why
hardware that was hung, or in an inoperable state, remains so. FastBoot >>> copies a memory image of the kernel and drivers in their state at that
time, and restore those states on startup. Even if the hardware gets
the CPU reset on a cold boot, FastBoot is going to reinstate its memory
image of the kernel and drivers. The kernel and drivers are NOT loaded
on a FastBoot. They are resumed from a saved state. That the memory
image of states doesn't match hardware state is why FastBoot causes
problems. When rebooting to attempt troubleshooting, FastBoot can make
the boot-time menu disappear so fast the user has no chance of hitting a >>> key to get it recognized to go into troubleshooting mode, or make a
selection from a boot menu.
A little knowledge is a dangerous thing. Here is an accurate description:
https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/distinguishing-fast-startup-from-wake-from-hibernation
"2. Next, the power manager sends system power IRPs to device drivers to
tell them to prepare their devices to enter hibernation."
You've never encountered drivers that did not restore state correctly on resuming from hybrid hibernate?
"If the driver for a device configures the device differently depending
on whether a cold startup or a wake-from-hibernation occurred, this
driver should, after a fast startup, configure the device as though a
cold startup occurred."
Those wonderful "shoulds".
If there is a power outage during sleep, or during a Windows session,
how is all this graceful recovery information going to be captured on a computer that is instantly dead?
On 17/11/2025 10:14, Anssi Saari wrote:
VanguardLH <V@nguard.LH> writes:
Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
Dan Purgert <dan@djph.net> writes:Actually Fast Starup is a full hibernate (all memory copied into the
Win10, 11 have that "FastBoot" thing that mucks with hardware releases >>>>> on "reboot" (win basically goes into hibernate).
No. Reboot is always reboot, Windows would be completely useless without >>>> that. "FastBoot" aka fast startup happens when shutting down if not
disabled. And it's hibernate without hibernating apps so fairly useless. >>>
hyberfil.sys file).
Source? For example here:
https://learn.microsoft.com/en-us/windows-hardware/test/weg/delivering-a-great-startup-and-shutdown-experience
"Starting with Windows 8.x, the default shutdown and restart scenario
has been updated and named fast startup. Fast startup begins with the
shutdown process and includes writing data to disk similar to the
hibernate process. A key difference is that all user sessions (Session
1) are logged off and the remaining information is written to the
hiberfile."
When user sessions are logged off, all user apps die and so aren't
written to the hiberfil.sys, which, as I stated, makes this "fast
startup" fairly useless.
If you think hiberfil.sys is useless, why not disable it? Use this
command as an administrator:
powercfg.exe /hibernate off.
Restart the machine and see if it makes any difference.
Personally, I find fast startup useful on an old machine, but some
people prefer to start afresh while they make a cup of coffee!
Long ago, I had that situation, laptop that would not finally power down
and the battery ran out. I do not remember the cause.
It is the lack of initialization of hardware on a FastBoot startup why hardware that was hung, or in an inoperable state, remains so.
On Mon, 17 Nov 2025 19:24:39 +0100, Carlos E.R. wrote:
Long ago, I had that situation, laptop that would not finally power down
and the battery ran out. I do not remember the cause.
You were running Windows.
On Mon, 17 Nov 2025 06:26:20 -0600, VanguardLH wrote:
It is the lack of initialization of hardware on a FastBoot startup why
hardware that was hung, or in an inoperable state, remains so.
None of that is relevant to booting another OS, though. If Windows expects the hardware to be in a certain state, another OS will not and will reinitialize it from power up.
Unless that second OS is trying to do its own equivalent “fast boot”, which in its turn assumes that the hardware will be in the same start it
last left it. That is likely to lead to sadness.
Obviously after the developers were told about this the situation was corrected.
[Much more of the same, IMO also not fully correct, deleted.]
On 2025-11-15 15:39, Java Jive wrote:
In case it's helpful to anyone else ...
I have some Dell Precision M6800s & M6700s dual-booting via Grub
between various versions of Windows and Ubuntu 24, all cabled to the
LAN. If I choose to move between any version of Windows and Ubuntu by
rebooting, Ubuntu 24 cannot make a reliable cabled LAN connection, it
keeps trying to connect but never succeeds. However, if I choose to
move between any version of Windows and Ubuntu by shutting down the PC
in between, Ubuntu 24 'just works', no networking problem at all.
Reboot from U24 and go back into U24, the situation is unchanged -
if it was working before the reboot, it's working now, if it wasn't
working before the reboot, it isn't working now. Reboot from U24 and
go back into Windows, no network problems in Windows at all. Reboot
from Windows and go back into any version of Windows, no network
problems at all.
In summary, when rebooting ...
Ubuntu 24 -> Ubuntu 24 No change
Ubuntu 24 -> Windows No problem
Windows -> Ubuntu 24 U24 cannot make cabled LAN connection
Windows -> Windows No problem
It seems to me from this that the cabled network hardware is not being
properly initialised when booting Ubuntu 24. The cure is simply to
actually power down the PC before launching Ubuntu 24
[snip]
Open a bug with the Ubuntu people, somehow.
| Sysop: | Luis Silva |
|---|---|
| Location: | Lisbon |
| Users: | 766 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 66:47:35 |
| Calls: | 567 |
| Files: | 46,973 |
| Messages: | 13,571 |
