Solved RockyLinux installation failing

Solved issue
T

TheRealDeal

New Member
Joined
Oct 9, 2025
Messages
11
Reaction score
0
Credits
181
THIS ISSUE HAS BEEN RESOLVED: If you encounter a similar / the same problem, I encourage you to read through the whole post, but If not, I'd like to refer you to the post with the solution, but if your also interested in the origin of this issue, you want to check out my latest statement, which might also help you identify the source of the same problem your encoutering, but maybe my pinpointed didn't help you. Best of luck :)

I'm at a road block, somehow I cannot install Rocky Linux on my homeserver. Back then I installed Proxmox on it and for about more than a year I'm running Debian Unstable on my Desktop so I'm not too unfamiliar with Linux. The issue is: I'm trying to boot from a bootable USB stick, but the installation process just won't start up. The output I'm getting at failure differentiates with the usb stick im using (so far I've tried it with three): purple, orange and black usb stick (the black being the one, which I bought for this matter to test whether the issue comes from purple or orange).
Before I get into the error output I'd like to adress all the GENERAL measures that I took:

  • deactivated XMP profile, running RAM on auto clock speed
  • ran a Memtest on my RAM (completely passed with no errors with one cpu core at use running via the Round Robin Algorithmn)
  • different iso images (their checksums matching those in the mirrors so they aren't corrupted): "minimal" and "dvd"
  • tried many different USB ports
  • Secure Boot is off
  • tried writing with dd-command, Ventoy and KDE ISO Writer

Here is the relevant hardware that my homeserver offers:

  • DDR4 32GB ECC RAM capable of 3200Mhz OC
  • AMD Ryzen 5 5600G
  • ASROCK B550M-ITX/ac

Interestingly, even with the black usb stick (the newly bought one) sudo cmp image.iso /dev/sda would always report a differentiation. According to this forum post it should either report nothing or EOF, but that never happened on any write that I've done on my USB sticks. I know that the orange and purple USB sticks are from some dusty corner in my home so it didn't suprise me that cmp told me that the writing differentiates with the iso on both of them, but I also got the same result from the black (newer) one and I wouldn't lay all my trust into the belief that it just so happened that I bought another broken/corrupted USB stick besides the orange and purple.

Now coming to the different outputs (when the iso was written with either dd-command or KDE ISO Writer):

- the BLACK usb stick didn't report anything lmao, it just blackscreens and that's all it has to offer.

- the PURPLE usb stick always reported the following:
--> "Initramfs unpacking failed: xz-compressed data is corrupt", according to this forum post it might has to do with multi-threaded xz-decompression, so I tried "nosmp acpi=off iommu=soft", but it still wouldn't work
--> for some reason, the last time I tried it with the purple usb stick it also spit before that initramfs error message something else out, of which i cannot make heads or tails about:
"BPF Invalid name_offset: 2943418394"
"sched_ext: Failed to register kfunc sets (-22)"

- the ORANGE usb stick always reports the following:
--> "uncompression error -- system halted"

So far I've only tried Ventoy on the orange and purple USB stick, where I'd always be facing the same issue:
I always had to manually load the kernel (vmlinuz) and initrd (which I did through the grub terminal), which where stored in /images/pxeboot/, but depending on the used USB stick I had different outcomes during that:

  • orange: I was able to load the kernel, but as soon as I initiated the boot the process would instantly crash.
  • purple: wouldn't even let me load the kernel: "invalid magic numbers"

---------------------------------------------------------------------------------------------

I've told you everything that I've tried so far. I find OS installation very annoying because of stuff like this, which I always have to encounter, but normally I get it done by myself. As you can see, this is something deeper and I cannot figure out by myself what is causing this installation failure. I don't know what the origin is, as far as it seems to me, it must be the USB sticks, but as said I'm getting suspicious whether any USB stick I get in my hands gets be broken as cmp reports and whether that is even a credible source. Please help me, I have no idea to do at this point or what is even the origin of this issue.
 
Last edited:


TheRealDeal said:
I'm at a road block, somehow I cannot install Rocky Linux on my homeserver. Back then I installed Proxmox on it and for about more than a year I'm running Debian Unstable on my Desktop so I'm not too unfamiliar with Linux. The issue is: I'm trying to boot from a bootable USB stick, but the installation process just won't start up. The output I'm getting at failure differentiates with the usb stick im using (so far I've tried it with three): purple, orange and black usb stick (the black being the one, which I bought for this matter to test whether the issue comes from purple or orange).
Before I get into the error output I'd like to adress all the GENERAL measures that I took:

  • deactivated XMP profile, running RAM on auto clock speed
  • ran a Memtest on my RAM (completely passed with no errors with one cpu core at use running via the Round Robin Algorithmn)
  • different iso images (their checksums matching those in the mirrors so they aren't corrupted): "minimal" and "dvd"
  • tried many different USB ports
  • Secure Boot is off
  • tried writing with dd-command, Ventoy and KDE ISO Writer

Here is the relevant hardware that my homeserver offers:

  • DDR4 32GB ECC RAM capable of 3200Mhz OC
  • AMD Ryzen 5 5600G
  • ASROCK B550M-ITX/ac

Interestingly, even with the black usb stick (the newly bought one) sudo cmp image.iso /dev/sda would always report a differentiation. According to this forum post it should either report nothing or EOF, but that never happened on any write that I've done on my USB sticks. I know that the orange and purple USB sticks are from some dusty corner in my home so it didn't suprise me that cmp told me that the writing differentiates with the iso on both of them, but I also got the same result from the black (newer) one and I wouldn't lay all my trust into the belief that it just so happened that I bought another broken/corrupted USB stick besides the orange and purple.

Now coming to the different outputs (when the iso was written with either dd-command or KDE ISO Writer):

- the BLACK usb stick didn't report anything lmao, it just blackscreens and that's all it has to offer.

- the PURPLE usb stick always reported the following:
--> "Initramfs unpacking failed: xz-compressed data is corrupt", according to this forum post it might has to do with multi-threaded xz-decompression, so I tried "nosmp acpi=off iommu=soft", but it still wouldn't work
--> for some reason, the last time I tried it with the purple usb stick it also spit before that initramfs error message something else out, of which i cannot make heads or tails about:
"BPF Invalid name_offset: 2943418394"
"sched_ext: Failed to register kfunc sets (-22)"

- the ORANGE usb stick always reports the following:
--> "uncompression error -- system halted"

So far I've only tried Ventoy on the orange and purple USB stick, where I'd always be facing the same issue:
I always had to manually load the kernel (vmlinuz) and initrd (which I did through the grub terminal), which where stored in /images/pxeboot/, but depending on the used USB stick I had different outcomes during that:

  • orange: I was able to load the kernel, but as soon as I initiated the boot the process would instantly crash.
  • purple: wouldn't even let me load the kernel: "invalid magic numbers"

---------------------------------------------------------------------------------------------

I've told you everything that I've tried so far. I find OS installation very annoying because of stuff like this, which I always have to encounter, but normally I get it done by myself. As you can see, this is something deeper and I cannot figure out by myself what is causing this installation failure. I don't know what the origin is, as far as it seems to me, it must be the USB sticks, but as said I'm getting suspicious whether any USB stick I get in my hands gets be broken as cmp reports and whether that is even a credible source. Please help me, I have no idea to do at this point or what is even the origin of this issue.
Click to expand...
Welcome!

It seems to me you have answered your own question with your comment: "it must be the USB sticks". The errors which you described in post #1 are all errors that relate to corrupted .iso files on the usbs in my experience. One solution is to use a commercially reputable usb of which there are a few, which may be more expensive, but should resolve the issue. I entered in google: "the most reputable usb drives" and it came up with the answer I expected which are the usbs that I use and have no trouble with. If by chance you are using such usbs, then there may be some other confounding variable in your process, but I can't see it at the moment from your post.

The dd command you mentioned makes a byte-by-byte copy, so if the shasum has checked out, the .iso file should be good on a good usb.

The cmp command usually compares files, rather than a file to a device as shown in post #1, so that command isn't likely to be of use. Here's an example of how it fails using as an example the minios.iso file which has been written to the usb device /dev/sda:
Code: 
[~]$ ls -al minios-trixie-xfce-ultra-amd64-5.0.0.iso
-rw-rw-r-- 1 ben ben 1783328768 Sep 12 19:10 minios-trixie-xfce-ultra-amd64-5.0.0.iso


[~]$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    1  14.3G  0 disk
├─sda1        8:1    1   1.7G  0 part
└─sda2        8:2    1  12.7G  0 part
sr0          11:0    1  1024M  0 rom
<snip>

[~]$ cmp minios-trixie-xfce-ultra-amd64-5.0.0.iso /dev/sda
minios-trixie-xfce-ultra-amd64-5.0.0.iso /dev/sda differ: byte 468, line 4

The output above shows cmp to have shown a difference, however the usb with minios works flawlessly.
 
Last edited:
You don't state which version of Rocky, if it's 10.. it doesn't run on all CPUs.

dos2unix

Post in thread 'Rocky 10 released'

I have been using Redhat 10, Alma 10 for a few days now. I just booted up Rocky 10 a few minutes ago.

They all discontinued 32-bit support.
No more networkd, ifup, ifdown ifcfg network scripts, it's all networkManager now.
No more dhclient, just use the dhcp client in networkManager.
No more network interface teaming, bonding only.

Here is a surprising one, and this will affect many users I suspect.
Multipath device Mapper is NOT supported on NVME drives.

No more X11 Xwindows... Wayland is the way.
LUKS uses a different (non-compatible with v1) algorythm.
/var/run is just /run...
  • Wow
  • redhat
 
dos2unix said:
You don't state which version of Rocky, if it's 10.. it doesn't run on all CPUs.

dos2unix

Post in thread 'Rocky 10 released'

I have been using Redhat 10, Alma 10 for a few days now. I just booted up Rocky 10 a few minutes ago.

They all discontinued 32-bit support.
No more networkd, ifup, ifdown ifcfg network scripts, it's all networkManager now.
No more dhclient, just use the dhcp client in networkManager.
No more network interface teaming, bonding only.

Here is a surprising one, and this will affect many users I suspect.
Multipath device Mapper is NOT supported on NVME drives.

No more X11 Xwindows... Wayland is the way.
LUKS uses a different (non-compatible with v1) algorythm.
/var/run is just /run...
  • Wow
  • redhat
Click to expand...
Indeed im trying to run Rocky 10, but AFAIK the Ryzen 5 5600G is supported since it is on Zen3: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
So this should be an issue with my cpu being to outdated.
 
osprey said:
I entered in google: "the most reputable usb drives" and it came up with the answer I expected which are the usbs that I use and have no trouble with
Click to expand...
Many people on a reddit post claimed that SanDisk and Samsung are working fine, the black usb stick that I bough is a Kingston. I'll probably return it and try SanDisk or Samsung. Which reputable brands do you have in mind?

osprey said:
The output above shows cmp to have shown a difference, however the usb with minios works flawlessly.
Click to expand...
So cmp isn't really a good indicator for a bad USB drive? I see...

The iso image were all fine I always checked them with the checksum. If I didn't misunderstood something wrong, this Wiki Post claims that all Zen3 processors, of which my Ryzen 5 5600G is one, should support all x86-64-v3 commands so this shouldn't be an incompatibility issue. Neither RAM or my BIOS configs should be an issue, so the only source that I can think of are the usb thumb drives that fail. I'll buy a SanDisk drive and see whether it'll do the job. I'll report to you after I've done that.
 
Last edited:
The current version is 10.0:-
Checking the integrity of the .iso is essential to ensure that your freshly downloaded .iso isn't corrupt.

PNY and Kingston usb have never failed me. The standard one's from Micro Center work well too.

PC requirements for Rocky Linux:

Code: 
CPU (Processor)¶

    1 GHz 64-bit (x86_64‑v3) or equivalent for other architectures
    Multi-core CPUs are recommended for server, desktop, or virtualization use

Rocky Linux 10 (Red Quartz) – Minimum Hardware Requirements - Documentation

docs.rockylinux.org docs.rockylinux.org

When you enter your BIOS and move to the >boot section....are the usb's showing?

If so, select the usb you won't to boot and ensure that: it is the first in the list.
 
Sweet mobo--
www.asrock.com

ASRock B550M-ITX/ac

Supports AMD AM4 Socket Ryzen™ 3000, 3000 G-Series, 4000 G-Series, 5000 and 5000 G-Series Desktop Processors<span style=color:red;>*</span>; Supports DDR4 4733+ (OC); 1 PCIe 4.0 x16; Graphics Output: DisplayPort, HDMI; 7.1 CH HD Audio (Realtek ALC887/897 Audio Codec); 4 SATA3, 1 Hyper M.2 (PCIe...
www.asrock.com www.asrock.com
 
Alexzee said:
When you enter your BIOS and move to the >boot section....are the usb's showing?

If so, select the usb you won't to boot and ensure that: it is the first in the list.
Click to expand...

I can select:

Install Rocky Linux, Test and Install Rocky Linux and Troubleshooting.
So yes the USB is booted, but the problem is as soon as I initiate the installation process, it crashes.
 
@osprey @Alexzee @dos2unix since my messages with official wiki links are not getting confirmed by staff, ill do a quick recap:

I now bought a SanDisk USB thumb drive. I wrote Rocky 10 on it and its not booting. I then tried Rocky 9.6 on the black Kingston (which I bought earlier), where there are no x86-64-v3 restrictions, and its still not booting, i get kicked out of the installation process two times and in the third attempt itll crash telling me: "uncompression error -- system halted"

At this point im just so exhausted and confused at the same time. I've tried all possible error vectors and nothing seems to be resolving this issue. I won't buy a third USB thumb drive to get rid of the possibility that the USB drive might be broken. I don't think chances can be that ridiculous to have 4 usb drives all broken, of which two of them are from reputable brands and newly bought.
My BIOS config seems fine, RAM passed Memtest with no errors, my Ryzen 5 5600G is from Zen3, it should be on x86-64-v3, but even if its not, it should still be able to do v2 (with Rocky 9.6 but that not even working as mentioned).

Im out of ideas, what could be causing this? I've gone through everything that I can think of as the origin of this issue.
Please help.
 
TheRealDeal said:
@osprey @Alexzee @dos2unix since my messages with official wiki links are not getting confirmed by staff, ill do a quick recap:

I now bought a SanDisk USB thumb drive. I wrote Rocky 10 on it and its not booting. I then tried Rocky 9.6 on the black Kingston (which I bought earlier), where there are no x86-64-v3 restrictions, and its still not booting, i get kicked out of the installation process two times and in the third attempt itll crash telling me: "uncompression error -- system halted"

At this point im just so exhausted and confused at the same time. I've tried all possible error vectors and nothing seems to be resolving this issue. I won't buy a third USB thumb drive to get rid of the possibility that the USB drive might be broken. I don't think chances can be that ridiculous to have 4 usb drives all broken, of which two of them are from reputable brands and newly bought.
My BIOS config seems fine, RAM passed Memtest with no errors, my Ryzen 5 5600G is from Zen3, it should be on x86-64-v3, but even if its not, it should still be able to do v2 (with Rocky 9.6 but that not even working as mentioned).

Im out of ideas, what could be causing this? I've gone through everything that I can think of as the origin of this issue.
Please help.
Click to expand...
A very frustrating experience.

It's not usually appropriate to just "tell" or suggest to respondents to do something outside of their requests, and I hesitate to do just that, but I did wonder if this problem is germane just to Rocky, in which case, my next thought was: would it happen with alma linux, which is a sort of close family relative in the Red Hat universe.

In any case, it might be interesting to check whether other distros are able to be installed on your system. If they were, the issue would appear to be confined to Rocky, but if other installations also fail, then the system would become the focus of attention.
 
TheRealDeal said:
@osprey @Alexzee @dos2unix since my messages with official wiki links are not getting confirmed by staff, ill do a quick recap:

I now bought a SanDisk USB thumb drive. I wrote Rocky 10 on it and its not booting. I then tried Rocky 9.6 on the black Kingston (which I bought earlier), where there are no x86-64-v3 restrictions, and its still not booting, i get kicked out of the installation process two times and in the third attempt itll crash telling me: "uncompression error -- system halted"

At this point im just so exhausted and confused at the same time. I've tried all possible error vectors and nothing seems to be resolving this issue. I won't buy a third USB thumb drive to get rid of the possibility that the USB drive might be broken. I don't think chances can be that ridiculous to have 4 usb drives all broken, of which two of them are from reputable brands and newly bought.
My BIOS config seems fine, RAM passed Memtest with no errors, my Ryzen 5 5600G is from Zen3, it should be on x86-64-v3, but even if its not, it should still be able to do v2 (with Rocky 9.6 but that not even working as mentioned).

Im out of ideas, what could be causing this? I've gone through everything that I can think of as the origin of this issue.
Please help.
Click to expand...

A follow up:
I now tried to install simple Debian, also crashing. Even though Memtest passed, I switched the entire RAM with ones i'm sure that work totally fine with no success. This tells me that this is a hardware issue either relying deep in the CPU, Motherboard or all of the usb thumb drives. I was getting the same behaviour with both new usb drives (SanDisk and Kingston), I always got the same behaviour: I initiate the installation process, it freezes and then I get kicked back into the selection menu. I then tried the usb drives on my laptop, which showed the same behaviour, which confirms for me that this must be an issue with either the writing or the usb drives itself. The isos aren't corrupted i always check with their sums and they match. It seems to me that whenever I write them to disk, whether with dd, Ventoy or KDE ISO Writer they always get corrupted and I have no idea how to fix this. To be honest I still kind of doubt that both of my new USB drives are broken, maybe it has something to do with the writing process always failing? I'll try writing from my laptop instead maybe my Desktop somehow always jams the writing process who knows.
 
Last edited:
osprey said:
In any case, it might be interesting to check whether other distros are able to be installed on your system. If they were, the issue would appear to be confined to Rocky, but if other installations also fail, then the system would become the focus of attention.
Click to expand...

I thought about this myself, which is why I tried to install plain simple Debian and it also fails.
I've written a detailed follow up and was able to safely narrow the origin of this issue down to the USB drives or more precise to the writing process. More about that in the latest message (above this one)
 
TheRealDeal said:
A follow up:
I now tried to install simple Debian, also crashing. Even though Memtest passed, I switched the entire RAM with ones i'm sure that work totally fine with no success. This tells me that this is a hardware issue either relying deep in the CPU, Motherboard or all of the usb thumb drives. I was getting the same behaviour with both new usb drives (SanDisk and Kingston), I always got the same behaviour: I initiate the installation process, it freezes and then I get kicked back into the selection menu. I then tried the usb drives on my laptop, which showed the same behaviour, which confirms for me that this must be an issue with either the writing or the usb drives itself. The isos aren't corrupted i always check with their sums and they match. It seems to me that whenever I write them to disk, whether with dd, Ventoy or KDE ISO Writer they always get corrupted and I have no idea how to fix this. To be honest I still kind of doubt that both of my new USB drives are broken, maybe it has something to do with the writing process always failing? I'll try writing from my laptop instead maybe my Desktop somehow always jams the writing process who knows.
Click to expand...

IT CANT BE REAL FOR SOME REASON DOES ANY WRITE ON MY DESKTOP FAIL!!!

I just wrote a Debian image on my laptop with KDE ISO Writer to the Kingston USB file and IT ACTUALLY WORKS!!!!
The installation process starts up!

I'm so relieved and confused at the same time. Why is any write process on my desktop failing, this kind of bothers me and makes me feel insecure about my Desktop environment, whether this might affect my system in any other way.
 
TheRealDeal said:
IT CANT BE REAL FOR SOME REASON DOES ANY WRITE ON MY DESKTOP FAIL!!!

I just wrote a Debian image on my laptop with KDE ISO Writer to the Kingston USB file and IT ACTUALLY WORKS!!!!
The installation process starts up!

I'm so relieved and confused at the same time. Why is any write process on my desktop failing, this kind of bothers me and makes me feel insecure about my Desktop environment, whether this might affect my system in any other way.
Click to expand...
Glad to hear that Debian is booting.

One of the first things that comes to mind for a write process failure is permission issues.:)

With my Slackware install I'm the root user and my guest and other users do not have permission's to write. Example: (a users or process lacks write permissions)

Maybe consider creating groups?

Is your kernel in "read only" mode? ACL control list's : Example: ACL's beyond standard permissions can impose more granular rules that prevent write.

Have a nice weekend!
 
TheRealDeal said:
So this should be an issue with my cpu being to outdated.
Click to expand...

No, it should work. But it would be interesting to see in 9 installs.

I have several installs of Rocky 10. In the cloud, on VMs, on local hosts... They all work fine for me.
Some are on Samsung, some on SanDisk some on Crucial, I never have any problems.

If Debian has the same issue, could it be a BIOS/UEFI setting? Some kind of protected disk thing.
 
dos2unix said:
No, it should work. But it would be interesting to see in 9 installs.

I have several installs of Rocky 10. In the cloud, on VMs, on local hosts... They all work fine for me.
Some are on Samsung, some on SanDisk some on Crucial, I never have any problems.

If Debian has the same issue, could it be a BIOS/UEFI setting? Some kind of protected disk thing.
Click to expand...

The original issue is now resolved. It seems that any write process on my desktop always corrupts the image that is being written to the usb thumb drive. I thereafter used my laptop with dd and the following command to make a valid Rocky 10 usb drive and it finally worked: sudo dd if=/PATH/TO/IMAGE.iso of=/dev/sdX bs=4M status= progress conv=fdatasync && sync and verified with sudo cmp /PATH/TO/IMAGE.iso /dev/sdX that it has been written sucessfully to the drive (which it did: it told me "EOF [...]"). This got me thinking that before when I was always writing the images to the stick from my desktop a broken hardware in my desktop might be corrupting the writing process alltogether, but multiple runs in Memtest and CPU stress-testing bust this theory. It's worth noting that written images with KDE ISO on my laptop also failed, but when I tried it with the dd command, it worked, always work with dd! It seems to me that writing images to a device is certainly a janky gamble.

Alexzee said:
One of the first things that comes to mind for a write process failure is permission issues
Click to expand...

I'm afraid I can't follow. I want to be clear that the writing process didn't fail per se, what I meant by "failing" is that during the writing process the image had always been written in a corrupt manner to the device. It had the necessary permissions to perform this writing process and it performed them successfully, but with a bad/corrupt result.
At this point I have no idea what caused this uncanny writing behavior on my desktop. I'm open for further ideas on what might be the cause of the bizarre writing on my desktop.
 
Last edited:
TheRealDeal said:
At this point I have no idea what caused this uncanny writing behavior on my desktop.
Click to expand...
You're not alone with it. I noticed the same behaviour with dd starting a few years back. Apparently corrupted images worked once I used "conv=fsync oflag=direct" flags, just issuing a sync did not suffice. While I can't tell you the reason, my guess is caching by the usb-storage subsystem. Since dd finishes quietly, it is not easy to know when to continue, but the flags solved that.

I've never had a problem using a simple cat PATH/TO/IMAGE.iso > /dev/sdX command, followed by a sync instead.
 
TheRealDeal said:
The original issue is now resolved. It seems that any write process on my desktop always corrupts the image that is being written to the usb thumb drive. I thereafter used my laptop with dd and the following command to make a valid Rocky 10 usb drive and it finally worked: sudo dd if=/PATH/TO/IMAGE.iso of=/dev/sdX bs=4M status= progress conv=fdatasync && sync and verified with sudo cmp /PATH/TO/IMAGE.iso /dev/sdX that it has been written sucessfully to the drive (which it did: it told me "EOF [...]"). This got me thinking that before when I was always writing the images to the stick from my desktop a broken hardware in my desktop might be corrupting the writing process alltogether, but multiple runs in Memtest and CPU stress-testing bust this theory. It's worth noting that written images with KDE ISO on my laptop also failed, but when I tried it with the dd command, it worked, always work with dd! It seems to me that writing images to a device is certainly a janky gamble.



I'm afraid I can't follow. I want to be clear that the writing process didn't fail per se, what I meant by "failing" is that during the writing process the image had always been written in a corrupt manner to the device. It had the necessary permissions to perform this writing process and it performed them successfully, but with a bad/corrupt result.
At this point I have no idea what caused this uncanny writing behavior on my desktop. I'm open for further ideas on what might be the cause of the bizarre writing on my desktop.
Click to expand...
A bizarre situation is all I can say.
As dos2unix said a BIOS setting or some protected disk utility enabled, perhaps?

FWIW, I have difficultly with using applications that make Linux .iso's bootable on my thumb drives.
The only thing that really works for me is the use of the dd cmd.

Have a great week ahead.
 
This could be related? -- https://linux.org/threads/how-to-create-a-linux-boot-usb-from-windows.55320/#post-258408

The problem is some distros check the checksum of the created iso.
The dd mode iso doesnt match the iso mode of the iso. Hence checksum differences, and refusal to install.


Title: PSA: Avoid Rufus ISO Mode for Linux Boot USBs – Use DD Mode Instead
Hey folks,
Just wanted to share some hard-earned experience for anyone creating Linux bootable USBs, especially if you're helping others or troubleshooting failed installs.

The Problem with Rufus ISO Mode​

Rufus is a popular tool for creating bootable USBs on Windows, but its "ISO Image Mode" can cause major headaches when used with many Linux distributions.
When you select an ISO in Rufus, it asks:
"How do you want to write the image?"
  • ISO Image Mode (Recommended)
  • DD Image Mode
Click to expand...
If you choose ISO Image Mode, Rufus extracts the ISO contents and writes them to a FAT32 or NTFS filesystem. This is fine for Windows ISOs, but it breaks the integrity of many Linux ISOs.
Why? Because many Linux distros (like Fedora, Ubuntu, etc.) include checksums in the bootloader or initrd. When the installer boots, it verifies the media. If the structure has been altered (as ISO mode does), the checksum fails. The installer may then refuse to proceed, warning that the image might be corrupted or tampered with — a logical and security-conscious response.

The Fix: Use DD Mode​

If you use DD Image Mode, Rufus writes the ISO bit-for-bit, preserving the original structure and checksum. This is equivalent to using dd on Linux or tools like balenaEtcher or Fedora Media Writer.

Why It Sometimes Works (e.g., Debian)​

Some distros like Debian are more forgiving. They don’t always enforce strict media checks, so Rufus ISO mode might appear to "work." But that’s not a guarantee — and it leads to confusion when other distros fail.

Recommended Tools for Linux USB Creation​

ToolPlatformMethodNotes
ddLinux/macOSRaw writePowerful but dangerous if you mistype the device path.
Fedora Media WriterWindows/Linux/macOSRaw writeGreat for Fedora and other Red Hat-based distros.
balenaEtcherCross-platformRaw writeSimple, reliable, and verifies the write.
Rufus (DD mode)WindowsRaw writeWorks well if you choose DD mode. Avoid ISO mode for Linux.
VentoyCross-platformBootloader-basedGreat for multi-ISO USBs, but some distros may not boot properly without tweaks.

TL;DR​

  • Avoid Rufus ISO mode for Linux ISOs.
  • Use DD mode or a raw-write tool like Etcher or Fedora Media Writer.
  • If you're helping others, label your USBs with the method used (e.g., "Ubuntu-DD" vs. "Ubuntu-ISO").
  • If you're using Ventoy, be aware that some ISOs may need extra config to boot properly.
 
You must log in or register to reply here.

Similar threads

R
Install boot failed, grub> (hd0): filesystem unknown
2
Replies
20
Views
2K
kc1di
kc1di
MikeRocor
"Can't fix stupid"...
2 3
Replies
56
Views
5K
KGIII
KGIII
J
File system keeps corrupting (need help)
2
Replies
30
Views
3K
Trml
Trml
D
Tried repeatedly, computer won't boot from usb
2
Replies
37
Views
4K
deb_user
D
J
Ubuntu ISO fails - autofs4
Replies
1
Views
757
kc1di
kc1di


Follow Linux.org

Members online

Total: 5,004 (members: 5, guests: 4,999)

Latest posts

Top