Im trying to install on my machine. I have had no luck. I have used rufus to put the ISO onto a bootable mediun. Boots and it goes to dracut premount hook, sits there, and shuts down. Taking my camera in slow motion to the monitor reveals that it says there are corrupted files. Ive only been able to boot it ONCE and that was in legacy mode (so I could not even install it since it doesnt support legacy but even in legacy it did this error many times)
It happens legacy or uefi. It happens with the open source nvidia drivers or the proprietary nvidia drivers. No matter the version. No matter the source (sourceforge or direct)
Ive tried ventoy. Ive tried normal mode. Ive tried grub2 mode. Doesnt work! Ive tried searching for solutions. Nothing has worked. Only similar issue I found was this but it does not apply to me as I have tried everything there. Version that I have done this test is with garuda-dr460nized-linux-zen-251103.iso
SHA256 from when I download it.
864c15a7c55175e0c6c41897b1e0c5a5447f4b6ecbab31605d471f118eae7bf8
Matches with the SHA256 file.
864c15a7c55175e0c6c41897b1e0c5a5447f4b6ecbab31605d471f118eae7bf8
SHA256 when its on my bootable drive on ventoy with the EXACT same file on it and tested on ventoy.
I’m not seasoned enough to make sense of the kernel panic, but the above suggests an integrity issue. Try to copy the ISO again. With Ventoy, the ISO files may appear to copy quickly, but you do have to wait a while when ejecting the drive so that they can finish actually writing to disk.
Hey! I just got home. I just grabbed the USB stick and copied the ISO off of the stick and ran the hash…
864c15a7c55175e0c6c41897b1e0c5a5447f4b6ecbab31605d471f118eae7bf8
When copying the .iso file, it is important that you do a “safe eject” of the USB drive. Linux systems (not Garuda) lie to you and pretend file copies are complete before they are actually complete.
The safe eject feature on removable media exists for a reason
To correctly verify the hash:
Copy the .iso file to the ventoy drive
Wait for the copy to finish
SAFELY EJECT the ventoy drive
UNPLUG THE VENTOY DRIVE ONCE THE SAFE EJECT IS COMPLETE
Plug the ventoy drive back in
THEN check the checksum.
The checksum verification done by the ISO file itself is very robust and not usually prone to failure. I would trust its judgement. This does not seem like a Garuda Linux issue to me, this seems like a “whatever distro you’re currently using is not communicating write caching to you” issue.
The checksum that I got from copying to the drive that was the same as the one on the site was after doing this already. I am currently copying from windows 11 (25H2) and I have already ejected the drive before removal. Plugging the drive back in and calculating the hash results in the same hash that I get from the sha256 file but the exact same ISO results in a different hash. This is why I think it is an issue with the ISO.
A different hash on the exact same file would suggest a flaw in sha256, rather than in the file itself! Right click and select properties for both files, see if the size matches. Most likely it is still not copying in full.
Please try again with a different USB stick and a different USB port. After that, you should also make sure that the USB stick is booted in UEFI mode in the BIOS boot menu.
Edit:
Short test with garuda-dr460nized-linux-zen-251103.iso in a VM and on bare metal (bootable stick created with KDE isoimagewriter) - no issues.
I went and got 4 USB sticks. None of them have worked. I tried ventoy, rufus and directly copying the files. The latter didnt work at all as expected and the first two said there were corrupted files. Windows says both ISO files from my downloads folder and C drive are the exact same filesize.
If you still get corrupted files, then it looks like something on your end (WinDOS) isn’t working properly.
Have you tried another Garuda spin (for example Garuda Xfce w/ LTS kernel) or a different Linux distribution (for example CachyOS, EndeavourOS or Debian) to check if it works at all?
I encourage you to check the SMART stats of the drive you are downloading to, because this behavior does not sound right. This is especially relevant to check if you are about to install to it! Since you are on Windows, you could install CrystalDiskInfo with winget using an admin terminal:
winget install CrystalDewWorld.CrystalDiskInfo
Feel free to screenshot, including Raw Values.
Maybe you can try downloading directly to the flash drive instead to bypass your primary drive if it’s failing. If there is still corruption when saving directly to the flash drive, and you have confirmed your disks are fully intact, you may wish to run memtest to confirm your RAM is working correctly.
I have tried other distros and they seem to work, no distro of garuda works. And for tech, the drive is working quite well. Screenshot may be a little hard to read but its a 1tb NVME (smallest form factor) with about 1.2-1.3tb written or read. I have tried downloading directly, using different computers and even swapped out using 4 different sticks of ram (I am currently on a fwl12 with one stick of laptop ddr5 and I have 4 other sticks of laptop ddr5 which work about the same)
Also, garuda-dr460nized-linux-zen-250916.iso for me is 3,307,356,160 bytes (3,307,360,256 on disk) (on C drive) and on the flash drive it is 3,307,356,160 byes and 3,307,470,848 on disk.
Just realized, before you ask, yes, I think the example I gave you was an older version of the ISO. This is because I was also testing older versions. No version of any iso I can find has worked but still has the same checksum until ventoy calculates it and same filesize. After ventoy calculates it, it is still the same checksum if you calculate it while the drive is plugged into my windows install
You forgot to make the repo public, but I’m interested to see.
The size on disk doesn’t actually matter, just the checksum. The size is different because different disks often have different block sizes. Even large contiguous files are ultimately stored in tiny blocks. If you are interested in the details, see this section called “Block Sizes: The Units of Data Storage”
