Advice Request Help with installing Linux

Share practical recommendations that address the author's needs.
Antimalware18

Antimalware18

Level 13
Verified
Top Poster
Well-known
Forum Veteran
Hello everyone

I may have posted on this before so if this is repeat i am sorry, it however does come with more imformation? ive been trying to install any flavor on linux on my spare laptop
as im slowly trying to move away fromt he windows ecosystem as Linux gaming and just usage in general progresses.

However, on my laptop a Asus Vivobook 17 everytime i try to install any flavor of linux it always fails, today it failed again WITHOUT wiping the drive like i told it to (thank god) but i do have a log from this one. I have used AI the past day or so to try and help me before asking for help and its been quite...in decisive. it seems to believe my VMD controller being active and On in the bios is whats causing it. the AI is not to sure. so, anyone willing to give this log a read through and tell me potentially why this keeps failing time and time again? thank you and all help is greatly appriciated. this has been bothering me for awhile

EDIT: its also important to mention that i cant go full force with this and just disable VMD if its the issue, that apparently could trigger bitlocker to want my key next time. i however do not have access to that key and wont. ever. So, before i do any more wipes to this drive. i really need to know what is going wrong with the installs, why, and how to fix it lol also in the bios the only option i can change is the VMD, i can turn it on/off, there is no option to disable RST or change it to UHCI or sata controls.
 

Attachments

Antimalware18 said:
Hello everyone I may have posted on this before so if this is repeat i am sorry, it however does come with more imformation? ive been trying to install any flavor on linux on my spare laptop as im slowly trying to move away fromt he windows ecosystem as Linux gaming and just usage in general progres […]
Click to expand...


Hi Antimalware18 — VMD is a plausible cause, but only if the installer cannot properly access the internal SSD. I would not disable it merely because an AI guessed it, especially without your BitLocker recovery key.

The decisive check is from the live Linux session:

Code: 
lsblk -e7 -o NAME,MODEL,SIZE,TYPE,FSTYPE,MOUNTPOINTS
lspci -nnk | grep -A3 -Ei 'VMD|RAID|SATA|NVMe'

  • If the internal NVMe drive is absent, or the installer explicitly reports an RST/VMD conflict, then VMD is probably involved.
  • If the drive and its partitions appear normally and the installer lets you select it, VMD is not the usual “drive hidden by RST” problem. It could still be a driver bug, but disabling VMD should not be the first experiment.

Ubuntu’s documentation makes the same distinction: leave RST/VMD alone when the installer can access the disks; change it only when the required disk is inaccessible, while recognizing that Windows might subsequently fail to start (Ubuntu documentation).

Please protect the existing installation first​


Changing VMD can alter the storage path seen by Windows. That may produce either an inaccessible-boot-device error or a BitLocker recovery prompt. Microsoft also lists firmware and boot-configuration changes as potential BitLocker recovery triggers and recommends suspending BitLocker before planned changes (Microsoft).

Since you cannot obtain the recovery key:

  1. Do not change VMD yet.
  2. Back up anything important from Windows now.
  3. Do not assume a failed installer left everything untouched; it may have changed EFI files or boot entries even without formatting the main Windows partition.
  4. If you intend to preserve Windows, the safest option is a separate SSD or external USB SSD with the present firmware settings unchanged.
  5. If you genuinely intend to erase Windows completely, BitLocker does not prevent Linux from deleting the partition table—but once you start, treat the existing Windows installation and its data as unrecoverable.

Also, the alternative controller mode is AHCI, not UHCI; UHCI refers to an old USB controller interface. If ASUS only provides a VMD toggle, that is normal on some models.

What the failure message would tell us​


Failure pointMore likely explanation
Internal SSD absent / explicit RST warningVMD/RST configuration
SquashFS, decompression or read errorsBad ISO, USB stick/port, or RAM
NVMe timeouts or I/O errorsSSD, firmware or storage-driver issue
Partition creation/formatting errorDisk state, failing SSD, or installer issue
GRUB/EFI/NVRAM failure near the endUEFI boot mode, EFI partition, or firmware issue

I cannot determine which applies because the actual log is not present in the post excerpt. Please attach the log as a text file, or paste the section beginning slightly before the first error rather than only the final “installation failed” message. Also include:

  • The exact VivoBook model, such as F1702ZA, not merely “VivoBook 17”
  • Distribution and ISO version
  • How the USB was created
  • Whether all attempts used the same USB stick
  • Whether the internal SSD appears in lsblk
  • The exact stage at which installation fails

Meanwhile, verify the ISO’s SHA-256 checksum and try a different USB stick and port. When several unrelated distributions fail, the common components—USB media, RAM, SSD and firmware settings—deserve attention before repeatedly wiping anything.

Sources
 
I thought I'd ask what my Gemini Plus thought, as I had 3 successful installs of Mint Cinnamon on two HP computers (laptop and a EliteDesk) and a Surface 5 laptop. I submitted your post and log file. You can compare notes with the Bots reply. In my case, #3 was an issue, disabling Secure Boot (fast start up was already disabled), and FWIW, I used BalenaEtcher.

Looking closely at the log provided, the root cause of the installation failure is clear.
The installer crashed during the configuring apt stage:
Plaintext

Oct 29 11:05:14 ubuntu subiquity_log.3256[14677]: Running command ['udevadm', 'settle'] with allowed return codes [0] (capture=False)
Oct 29 11:07:14 ubuntu subiquity_log.3256[14677]: TIMED subp(['udevadm', 'settle']): 120.052
...
curtin.util.ProcessExecutionError: Unexpected error while running command.
Command: ['udevadm', 'settle']
Exit code: 1

Key Issues Identified in the Log​

  1. udevadm settle Timeout (Primary Failure):
    • The subiquity/curtin installer executed udevadm settle after mounting the target filesystem to configure apt.
    • udevadm settle waits for the system kernel's device event queue to handle all pending hardware events.
    • It hit a 120-second hard timeout and returned Exit Code 1, triggering a fatal crash in the Ubuntu subiquity-desktop-bootstrap installer engine.
  2. Why udevadm settle Times Out:
    • Stuck Hardware Queue: A device driver or kernel module is failing to respond or hanging while trying to initialize hardware (common with proprietary Wi-Fi cards, Nvidia GPUs, USB controllers, or storage controllers).
    • Virtualization or Fast Boot / RST Conflicts: If the storage controller is set to Intel RST/RAID instead of AHCI in the BIOS, or if Windows Fast Startup / BitLocker is holding a hardware lock on the drive, the kernel gets stuck waiting for udev events to clear.
    • Live USB Creation Issue: ISO corruption or flash drive block errors during media creation can cause hardware loopback mounts to hang indefinitely.

Practical Steps to Resolve the Issue​

Here are concrete troubleshooting steps to share with the forum member:
  1. Try Installing Offline (Disconnect Wi-Fi / Ethernet):
    • During the installation process, do not connect to Wi-Fi or plug in an Ethernet cable.
    • If apt-config cannot reach online mirrors while waiting on background hardware calls, curtin often hits this timeout loop. Installing offline skips mirror verification and third-party driver downloads during the initial base install.
  2. Verify Storage Controller Mode (AHCI vs. RAID/RST):
    • Boot into BIOS/UEFI settings and verify that SATA/Storage mode is set to AHCI, not Intel RST/RAID. RST causes device queue stalls on Ubuntu kernel installers.
  3. Disable Windows Fast Startup and Secure Boot:
    • If dual-booting with Windows, disable Fast Startup inside Windows Control Panel (Control Panel > Power Options > Choose what the power buttons do).
    • Disable Secure Boot in the BIOS (or clear third-party keys depending on motherboard hardware).
  4. Boot with nomodeset Kernel Parameter:
    • On the live USB GRUB boot screen, press e while highlighting the install entry.
    • Find the line starting with linux and add nomodeset right after quiet splash.
    • Press Ctrl+X or F10 to boot. This prevents display drivers (like Nvidia) from hanging the udev event queue.
  5. Re-flash or Change Live USB Creation Tool:
    • If using Rufus on Windows, ensure the ISO is written in DD Mode instead of ISO Mode, or re-create the media using Ventoy or BalenaEtcher to ensure partition and udev table integrity.
 
Last edited:
alright @Bot im up for whatever answers so i will answer as well lol

X1704Z is the exact model
the distribution was from the Ubuntu site, no torrens or 3rd party site
the USB was created using Rufus
All attemps has used the same USB stick
it did recognize the internal drive
it fails during the "copying files" stage
 
Antimalware18 said:
alright @Bot im up for whatever answers so i will answer as well lol X1704Z is the exact model the distribution was from the Ubuntu site, no torrens or 3rd party site the USB was created using Rufus All attemps has used the same USB stick it did recognize the internal drive it fails during the "copying files" stage
Click to expand...


That narrows it down considerably.

Because the installer can see and select the internal SSD, this is not the usual VMD/RST problem where Linux cannot access the drive at all. VMD could still be involved in a lower-level driver timeout, but the log does not establish that—and with no BitLocker recovery key, do not change VMD, Secure Boot, or other firmware settings yet.

The Gemini reply correctly identified the immediate fatal error: udevadm settle timed out after 120 seconds. It overstates matters by calling that the clear root cause. It tells us that a device-event queue did not finish; it does not identify which device caused it. Wi-Fi, Nvidia, RST, USB and so forth are possibilities, not findings from that excerpt. BitLocker also does not “hold a hardware lock” on the drive. Installing offline is a reasonable isolation test, but an APT mirror cannot directly explain a local udevadm settle timeout.

The strongest practical clue now is:

Every attempt used the same physical USB stick.
Click to expand...

A marginal flash drive can boot successfully and then produce errors during sustained reads. Getting the ISO from Ubuntu confirms its source, but not that the download and written media are error-free. “Copying files” is also only a broad progress label; the log shows the installer had reached APT configuration when it finally aborted.

I would test it in this order​


  1. Use a different physical USB stick, not merely reformat the current one.
  2. Download a fresh, fully released Ubuntu ISO—preferably the current LTS point release, not a daily image.
  3. In Windows, verify its hash:

Code: 
   Get-FileHash "C:\path\to\ubuntu-desktop-amd64.iso" -Algorithm SHA256

Compare it with Ubuntu’s SHA256SUMS for that exact release. Ubuntu documents the verification process here.

4. Write it directly with the current Rufus release using its defaults. Ubuntu’s current instructions specifically say to choose ISO Image mode, not DD mode. Ventoy would add another variable, so I would not use it for this test. See Ubuntu’s Rufus instructions.
5. Use another USB port, with no hub or adapter. Run the media-integrity check if the boot menu offers one.
6. For this one controlled attempt, install offline and decline updates/third-party drivers. That reduces variables; it is not because the network has been proven responsible.

I would not use nomodeset unless the display is freezing or the kernel log shows graphics-driver errors. Likewise, Ubuntu supports Secure Boot, so disabling it without evidence would just be firmware roulette—with BitLocker sitting nearby holding the loaded dice.

If the newly downloaded ISO on a different stick still fails, return to the live desktop immediately after the failure and run:

Code: 
sudo udevadm settle --timeout=10
echo "udev exit code: $?"

sudo journalctl -b -u systemd-udevd --no-pager | tail -n 300

sudo journalctl -k -b --no-pager |
grep -Ei 'nvme|vmd|usb|uas|squashfs|i/o|timeout|reset|error|fail'

lsblk -e7 -o NAME,MODEL,SIZE,TYPE,TRAN,FSTYPE,MOUNTPOINTS

Those results should reveal whether the repeating event concerns the USB media, NVMe drive, VMD controller or something else. An exit code of 1 from the first command means the udev queue is still stuck; 0 means it eventually cleared.

Also, “from the Ubuntu site” still does not give the Ubuntu version. Please provide the exact ISO filename. There has previously been an installer bug with the same final udevadm settle exception that was later marked fixed, so the bundled installer version matters—but an identical last exception alone does not prove it is the same bug (Launchpad report).

For now, my first suspect is the repeatedly reused USB stick, not VMD. Test that without risking the existing Windows installation.

Sources
 
Jonny Quest said:
I thought I'd ask what my Gemini Plus thought, as I had 3 successful installs of Mint Cinnamon on two HP computers (laptop and a EliteDesk) and a Surface 5 laptop. I submitted your post and log file. You can compare notes with the Bots reply. In my case, #3 was a issue, disabling Secure Boot (fast start up was already disabled), and FWIW, I used BalenaEtcher.

Looking closely at the log provided, the root cause of the installation failure is clear.
The installer crashed during the configuring apt stage:
Plaintext

Oct 29 11:05:14 ubuntu subiquity_log.3256[14677]: Running command ['udevadm', 'settle'] with allowed return codes [0] (capture=False)
Oct 29 11:07:14 ubuntu subiquity_log.3256[14677]: TIMED subp(['udevadm', 'settle']): 120.052
...
curtin.util.ProcessExecutionError: Unexpected error while running command.
Command: ['udevadm', 'settle']
Exit code: 1

Key Issues Identified in the Log​

  1. udevadm settle Timeout (Primary Failure):
    • The subiquity/curtin installer executed udevadm settle after mounting the target filesystem to configure apt.
    • udevadm settle waits for the system kernel's device event queue to handle all pending hardware events.
    • It hit a 120-second hard timeout and returned Exit Code 1, triggering a fatal crash in the Ubuntu subiquity-desktop-bootstrap installer engine.
  2. Why udevadm settle Times Out:
    • Stuck Hardware Queue: A device driver or kernel module is failing to respond or hanging while trying to initialize hardware (common with proprietary Wi-Fi cards, Nvidia GPUs, USB controllers, or storage controllers).
    • Virtualization or Fast Boot / RST Conflicts: If the storage controller is set to Intel RST/RAID instead of AHCI in the BIOS, or if Windows Fast Startup / BitLocker is holding a hardware lock on the drive, the kernel gets stuck waiting for udev events to clear.
    • Live USB Creation Issue: ISO corruption or flash drive block errors during media creation can cause hardware loopback mounts to hang indefinitely.

Practical Steps to Resolve the Issue​

Here are concrete troubleshooting steps to share with the forum member:
  1. Try Installing Offline (Disconnect Wi-Fi / Ethernet):
    • During the installation process, do not connect to Wi-Fi or plug in an Ethernet cable.
    • If apt-config cannot reach online mirrors while waiting on background hardware calls, curtin often hits this timeout loop. Installing offline skips mirror verification and third-party driver downloads during the initial base install.
  2. Verify Storage Controller Mode (AHCI vs. RAID/RST):
    • Boot into BIOS/UEFI settings and verify that SATA/Storage mode is set to AHCI, not Intel RST/RAID. RST causes device queue stalls on Ubuntu kernel installers.
  3. Disable Windows Fast Startup and Secure Boot:
    • If dual-booting with Windows, disable Fast Startup inside Windows Control Panel (Control Panel > Power Options > Choose what the power buttons do).
    • Disable Secure Boot in the BIOS (or clear third-party keys depending on motherboard hardware).
  4. Boot with nomodeset Kernel Parameter:
    • On the live USB GRUB boot screen, press e while highlighting the install entry.
    • Find the line starting with linux and add nomodeset right after quiet splash.
    • Press Ctrl+X or F10 to boot. This prevents display drivers (like Nvidia) from hanging the udev event queue.
  5. Re-flash or Change Live USB Creation Tool:
    • If using Rufus on Windows, ensure the ISO is written in DD Mode instead of ISO Mode, or re-create the media using Ventoy or BalenaEtcher to ensure partition and udev table integrity.
Click to expand...
to quote this message specifically,
the ISO Was not written in DD mode it was written in the default, im not very good at this side of computing at all, so my hope was Rufus would work right out of the box. it always has in the past.

option 4 is beyond my territory

is option 3 even viable if my plan is to completely erase windows?

option 2 is not a option in my bios. the only option out of all those that i can actually change is VMD controll from on to off, thats it. no other choices. it mentions RST and what its on and the driver. but no actual option to change anything

I will try number 1. i just really hate having to go and download all the extra's and codec's lol
 
Bot said:
That narrows it down considerably.

Because the installer can see and select the internal SSD, this is not the usual VMD/RST problem where Linux cannot access the drive at all. VMD could still be involved in a lower-level driver timeout, but the log does not establish that—and with no BitLocker recovery key, do not change VMD, Secure Boot, or other firmware settings yet.

The Gemini reply correctly identified the immediate fatal error: udevadm settle timed out after 120 seconds. It overstates matters by calling that the clear root cause. It tells us that a device-event queue did not finish; it does not identify which device caused it. Wi-Fi, Nvidia, RST, USB and so forth are possibilities, not findings from that excerpt. BitLocker also does not “hold a hardware lock” on the drive. Installing offline is a reasonable isolation test, but an APT mirror cannot directly explain a local udevadm settle timeout.

The strongest practical clue now is:



A marginal flash drive can boot successfully and then produce errors during sustained reads. Getting the ISO from Ubuntu confirms its source, but not that the download and written media are error-free. “Copying files” is also only a broad progress label; the log shows the installer had reached APT configuration when it finally aborted.

I would test it in this order​


  1. Use a different physical USB stick, not merely reformat the current one.
  2. Download a fresh, fully released Ubuntu ISO—preferably the current LTS point release, not a daily image.
  3. In Windows, verify its hash:

Code: 
   Get-FileHash "C:\path\to\ubuntu-desktop-amd64.iso" -Algorithm SHA256

Compare it with Ubuntu’s SHA256SUMS for that exact release. Ubuntu documents the verification process here.

4. Write it directly with the current Rufus release using its defaults. Ubuntu’s current instructions specifically say to choose ISO Image mode, not DD mode. Ventoy would add another variable, so I would not use it for this test. See Ubuntu’s Rufus instructions.
5. Use another USB port, with no hub or adapter. Run the media-integrity check if the boot menu offers one.
6. For this one controlled attempt, install offline and decline updates/third-party drivers. That reduces variables; it is not because the network has been proven responsible.

I would not use nomodeset unless the display is freezing or the kernel log shows graphics-driver errors. Likewise, Ubuntu supports Secure Boot, so disabling it without evidence would just be firmware roulette—with BitLocker sitting nearby holding the loaded dice.

If the newly downloaded ISO on a different stick still fails, return to the live desktop immediately after the failure and run:

Code: 
sudo udevadm settle --timeout=10
echo "udev exit code: $?"

sudo journalctl -b -u systemd-udevd --no-pager | tail -n 300

sudo journalctl -k -b --no-pager |
grep -Ei 'nvme|vmd|usb|uas|squashfs|i/o|timeout|reset|error|fail'

lsblk -e7 -o NAME,MODEL,SIZE,TYPE,TRAN,FSTYPE,MOUNTPOINTS

Those results should reveal whether the repeating event concerns the USB media, NVMe drive, VMD controller or something else. An exit code of 1 from the first command means the udev queue is still stuck; 0 means it eventually cleared.

Also, “from the Ubuntu site” still does not give the Ubuntu version. Please provide the exact ISO filename. There has previously been an installer bug with the same final udevadm settle exception that was later marked fixed, so the bundled installer version matters—but an identical last exception alone does not prove it is the same bug (Launchpad report).

For now, my first suspect is the repeatedly reused USB stick, not VMD. Test that without risking the existing Windows installation.

Sources
Click to expand...

And I heard it both ways, as far as Secure Boot, for what I was going through. It installed with Secure Boot off, so I asked Gemini if I should re-enable it, but didn't, as it wasn't broke, so I did fix it. I had mentioned that in my post to Gemini, so maybe it took it that it needed to be done, i.e. disabling Secure Boot :)
 
Jonny Quest said:
And I heard it both ways, as far as Secure Boot, for what I was going through. It installed with Secure Boot off, so I asked Gemini if I should re-enable it, but didn't, as it wasn't broke, so I did fix it. I had mentioned that in my post to Gemini, so maybe it took it that it needed to be done, i.e. disabling Secure Boot :)
Click to expand...


That is fair: you found a working fix for your Mint installations. If Secure Boot was the only variable changed, it is strong evidence that it was the blocker on that hardware, though it does not identify the exact incompatible component.

Linux Mint’s own guide lists disabling Secure Boot as a remedy for a Secure Boot Violation. Its alternative is reinstalling without selecting third-party graphics/Wi-Fi software, since unsigned or improperly enrolled third-party modules are often where Secure Boot becomes troublesome (Linux Mint documentation).

The distinction is that Gemini appears to have turned “this fixed Jonny’s Mint installation” into a general step for Antimalware18’s different failure. His log shows a udevadm settle timeout, not a signature or Secure Boot violation. Ubuntu supplies signed shim, GRUB and kernel components specifically so it can operate with Secure Boot enabled (Ubuntu documentation). Therefore, switching it off remains a possible diagnostic test—but it is not yet the evidence-led first test here, particularly when he cannot obtain his BitLocker recovery key.

Re-enabling it on your Mint systems may work, but unsigned drivers could then stop loading or the system could refuse to boot. Leaving it disabled avoids that compatibility issue, at the cost of Secure Boot’s protection against unauthorized bootloaders and kernels. So yes, your fix is valid for your machines; it just should not be promoted to a universal Linux installation commandment. Gemini took a useful anecdote and gave it a clipboard and a job title.

Sources
 
Antimalware18 said:
to quote this message specifically,
the ISO Was not written in DD mode it was written in the default, im not very good at this side of computing at all, so my hope was Rufus would work right out of the box. it always has in the past.

option 4 is beyond my territory

is option 3 even viable if my plan is to completely erase windows?

option 2 is not a option in my bios. the only option out of all those that i can actually change is VMD controll from on to off, thats it. no other choices. it mentions RST and what its on and the driver. but no actual option to change anything

I will try number 1. i just really hate having to go and download all the extra's and codec's lol
Click to expand...

No problem, take it all with a grain of salt :) Bot on this forum does a really good job, it does have 3? types of AI engines behind it, I believe.
 
Bot said:
That narrows it down considerably.

Because the installer can see and select the internal SSD, this is not the usual VMD/RST problem where Linux cannot access the drive at all. VMD could still be involved in a lower-level driver timeout, but the log does not establish that—and with no BitLocker recovery key, do not change VMD, Secure Boot, or other firmware settings yet.

The Gemini reply correctly identified the immediate fatal error: udevadm settle timed out after 120 seconds. It overstates matters by calling that the clear root cause. It tells us that a device-event queue did not finish; it does not identify which device caused it. Wi-Fi, Nvidia, RST, USB and so forth are possibilities, not findings from that excerpt. BitLocker also does not “hold a hardware lock” on the drive. Installing offline is a reasonable isolation test, but an APT mirror cannot directly explain a local udevadm settle timeout.

The strongest practical clue now is:



A marginal flash drive can boot successfully and then produce errors during sustained reads. Getting the ISO from Ubuntu confirms its source, but not that the download and written media are error-free. “Copying files” is also only a broad progress label; the log shows the installer had reached APT configuration when it finally aborted.

I would test it in this order​


  1. Use a different physical USB stick, not merely reformat the current one.
  2. Download a fresh, fully released Ubuntu ISO—preferably the current LTS point release, not a daily image.
  3. In Windows, verify its hash:

Code: 
   Get-FileHash "C:\path\to\ubuntu-desktop-amd64.iso" -Algorithm SHA256

Compare it with Ubuntu’s SHA256SUMS for that exact release. Ubuntu documents the verification process here.

4. Write it directly with the current Rufus release using its defaults. Ubuntu’s current instructions specifically say to choose ISO Image mode, not DD mode. Ventoy would add another variable, so I would not use it for this test. See Ubuntu’s Rufus instructions.
5. Use another USB port, with no hub or adapter. Run the media-integrity check if the boot menu offers one.
6. For this one controlled attempt, install offline and decline updates/third-party drivers. That reduces variables; it is not because the network has been proven responsible.

I would not use nomodeset unless the display is freezing or the kernel log shows graphics-driver errors. Likewise, Ubuntu supports Secure Boot, so disabling it without evidence would just be firmware roulette—with BitLocker sitting nearby holding the loaded dice.

If the newly downloaded ISO on a different stick still fails, return to the live desktop immediately after the failure and run:

Code: 
sudo udevadm settle --timeout=10
echo "udev exit code: $?"

sudo journalctl -b -u systemd-udevd --no-pager | tail -n 300

sudo journalctl -k -b --no-pager |
grep -Ei 'nvme|vmd|usb|uas|squashfs|i/o|timeout|reset|error|fail'

lsblk -e7 -o NAME,MODEL,SIZE,TYPE,TRAN,FSTYPE,MOUNTPOINTS

Those results should reveal whether the repeating event concerns the USB media, NVMe drive, VMD controller or something else. An exit code of 1 from the first command means the udev queue is still stuck; 0 means it eventually cleared.

Also, “from the Ubuntu site” still does not give the Ubuntu version. Please provide the exact ISO filename. There has previously been an installer bug with the same final udevadm settle exception that was later marked fixed, so the bundled installer version matters—but an identical last exception alone does not prove it is the same bug (Launchpad report).

For now, my first suspect is the repeatedly reused USB stick, not VMD. Test that without risking the existing Windows installation.

Sources
Click to expand...

I actually think it might the online/offline issue. because the WiFi card in this PC is not currently "really" supported by linux, I.E some people have gotten it working with alot of work arounds. the step AI told me for that part was to switch it out with a new wifi card. I however have a dongle. I have teens. i cant putt he PC's into the shop just on a whim lol

although I am about to put it in a shop with the express order to be "just put ubuntu on it, and get it working" lol

Also @Bot I did confrim the Hash's. i had to use AI to know what to put in powershell. my intro to windows really started with XP so a little beyond the DOS era. (although the PC's when i was in kindergarten were DOS (atleast i think, they always booted into a terminal type invironment) but i still remember playing Wagon Trail on them 😁
 
Antimalware18 said:
I actually think it might the online/offline issue. because the WiFi card in this PC is not currently "really" supported by linux, I.E some people have gotten it working with alot of work arounds. the step AI told me for that part was to switch it out with a new wifi card. I however have a dongle. I have teens. i cant putt he PC's into the shop just on a whim lol although I am about to put it in a shop with the express order to be "just put ubuntu on it, and get it working" lol Also @Bot I did confrim the Hash's. i had to use AI to know what to put in powershell. my intro to windows really started with XP so a little beyond the DOS era. (although the PC's when i was in kindergarten were DOS (atleast i think, they always booted into a terminal type invironment) but i sti […]
Click to expand...


That makes the offline test more plausible, although it still is not proven to be the cause. An unreachable mirror would normally produce a network/APT error; however, a poorly supported Wi-Fi adapter or its driver could contribute to the device queue that udevadm settle is waiting for.

For a clean test:

  1. Unplug the Wi-Fi dongle and every unnecessary USB device. Leave only the installer USB.
  2. Boot Ubuntu and turn Wi-Fi off from the live desktop.
  3. Start the installer without connecting to a network.
  4. Decline downloading updates and third-party drivers during installation.
  5. Leave VMD and Secure Boot unchanged for this attempt.

If it installs, boot into Ubuntu, connect the known-working dongle, and install updates, drivers and codecs afterward. You are not permanently giving those up; you are only keeping them out of the installation process.

If it fails with the same udevadm settle timeout, being online was probably not the explanation. The internal Wi-Fi hardware could still be involved because its driver may load even while disconnected, but the next practical test should be a different physical USB stick and port. Confirming the ISO hash rules out a damaged download; it does not test the flash drive or the data written to it. Rufus’s default ISO mode is valid—you did nothing wrong there.

If your priority is simply getting Ubuntu installed rather than identifying the precise variable, combine the two likely low-risk changes: different USB stick, same verified ISO, offline installation.

On the Windows question: once you have backed up everything and genuinely commit to erasing Windows, losing access to that BitLocker installation no longer matters. Nevertheless, there is still no reason to disable VMD or Secure Boot before trying the safer tests. Firmware roulette is not improved by having fewer recovery keys.

I would not pay a shop just yet. This offline attempt and one different USB stick are worth trying first. If you do use a shop, give them the log and explicitly tell them that no BitLocker key is available and that they must not assume Windows can be recovered after changing storage settings.
 
Bot said:
That makes the offline test more plausible, although it still is not proven to be the cause. An unreachable mirror would normally produce a network/APT error; however, a poorly supported Wi-Fi adapter or its driver could contribute to the device queue that udevadm settle is waiting for.

For a clean test:

  1. Unplug the Wi-Fi dongle and every unnecessary USB device. Leave only the installer USB.
  2. Boot Ubuntu and turn Wi-Fi off from the live desktop.
  3. Start the installer without connecting to a network.
  4. Decline downloading updates and third-party drivers during installation.
  5. Leave VMD and Secure Boot unchanged for this attempt.

If it installs, boot into Ubuntu, connect the known-working dongle, and install updates, drivers and codecs afterward. You are not permanently giving those up; you are only keeping them out of the installation process.

If it fails with the same udevadm settle timeout, being online was probably not the explanation. The internal Wi-Fi hardware could still be involved because its driver may load even while disconnected, but the next practical test should be a different physical USB stick and port. Confirming the ISO hash rules out a damaged download; it does not test the flash drive or the data written to it. Rufus’s default ISO mode is valid—you did nothing wrong there.

If your priority is simply getting Ubuntu installed rather than identifying the precise variable, combine the two likely low-risk changes: different USB stick, same verified ISO, offline installation.

On the Windows question: once you have backed up everything and genuinely commit to erasing Windows, losing access to that BitLocker installation no longer matters. Nevertheless, there is still no reason to disable VMD or Secure Boot before trying the safer tests. Firmware roulette is not improved by having fewer recovery keys.

I would not pay a shop just yet. This offline attempt and one different USB stick are worth trying first. If you do use a shop, give them the log and explicitly tell them that no BitLocker key is available and that they must not assume Windows can be recovered after changing storage settings.
Click to expand...
that was actually well put @Bot i will try all those, tomorrow. I have been up now 29hrs with no sleep (not because of this issue, no worries) so any brain taxing tryouts will be tomorrow, when i am off lol
 
Antimalware18 said:
that was actually well put @Bot i will try all those, tomorrow. I have been up now 29hrs with no sleep (not because of this issue, no worries) so any brain taxing tryouts will be tomorrow, when i am off lol
Click to expand...


Good call. A disk-erasing installer and 29 hours without sleep are a terrible double act. Leave it alone for now.

Tomorrow’s low-risk plan:

  1. Confirm anything important in Windows is backed up.
  2. Use a different USB stick and, if possible, another USB port.
  3. Write the already verified ISO with Rufus’s default ISO mode.
  4. Disconnect the Wi-Fi dongle and other unnecessary USB devices.
  5. Install offline, declining updates and third-party software for now.
  6. Leave VMD and Secure Boot unchanged.

Codecs, updates and drivers can all be added after a successful boot. If it fails again, keep the new log; comparing the same failure under those controlled conditions will be much more informative than changing several firmware settings at once. Get some sleep before giving the partition table ideas.
 
Have you tried MX Linux? Its installer scans your computer's components during the installation process and notifies you of any problems before proceeding. It also includes a built-in tool that supports installing even very old drivers, especially network drivers. You can find this tool at the following link.

HELP: MX Network Assistant – MX Linux

mxlinux.org mxlinux.org
 

Recently browsing

Members who viewed this thread in the last 5 minutes

You may also like...

Back
Top