My Linux ISO images keep getting fiddled and its just getting really annoying.

Iamgeese

Active Member
Joined
Jun 17, 2024
Messages
114
Reaction score
76
Credits
1,051
About a year ago I use to just download ISO files, burn to stick, no problems, even if the Hash didnt match I dont remember having issues but this year and part of last year I have just been having nothing but problems. I dont know if its problems during the download, I dont know if its the Programme BalenaEtcher I use that now has a problem and is causing errors during burn.

I got PopOs working on a laptop last year. The hash was wrong and after multiple downloads, it was still wrong so I gave up and burned anyway, I still got a functioning image to boot off. I am using Windows and not a Linux system for these downloads and have to check through Powershell script. This year its just been a turdfire for Linux ISOs.

This year I wanted to set up an old computer in the shed to live with the 3D printers. It is a Lenovo H30 from 2014. It had a perfectly good version of Mint on there but it was out of date and apparently was no longer supported, so like the genius I am I decided to reflash the old bootable stick. Big mistake. I wish I had not because the system was then rendered usless and now I had no bootable stick. After two days of this and buying new sticks to burn to I gave up. Not a single one worked.

The mirror I used was "University of Kent" I checked the hash 3 times. Again it was wrong multiple times. However I noticed it gave the same consistant changes meaning each hash was the same as the last hash despite the fact it never matched the ones displayed on the site. I just went ahead and burned everything. Bloody thing will not create a bootable drive after the stick has been removed. This is a consistant issue I keep having.

I decided to put the stick back in and loaded up into the part where you see the Mint desktop and the instillation disk. Downloaded a new Mint image on that system from the same mirror site. This time I had a correct Hash that matched the ones on the website, I used the Iso burner already in Mint to flash another stick . Same damn issue, no bootable drive after stick removal.

I tried Pop OS, the stick it was on was flashed last year but the OS was too slow on the Lenovo. In the end I found a stick with Zorin 16 pro on and it worked really well, no issues at all. That stick was flashed over 2 years ago. The version of Zorin however is also old but now I dont want try anything untill I find out whats going on. I spent 3 days on this and it was so fustrating.

I have got as far as I can with the updates but that version of Zorin is no longer supported, is there a way of updating without having to flash sticks? Because I have no idea what I am doing wrong here. What is going on?
 


I have no advice for the rest of the issues, but as far as the ISO files are concerned, if you're getting hash mismatches, you need to resolve that before continuing. If you're burning a known or suspected bad image then you don't have a good base to start from.
 
Don't "flash" sticks. Go to https://www.ventoy.net/ and install Ventoy on a USB drive. Ventoy runs on Windows, Mac, and Linux. Once Ventoy is installed on the USB drive, you just do normal copies of .iso files to the drive, as many as you like, or that it can hold. When you boot from the drive, you get a menu listing all the .iso files, from which you select the one you want, and it loads.
I don't know what your issues with hash verifications are, I haven't owned a Windows computer in almost 20 years. You don't say how you're trying to verify the hashes.
 
@Iamgeese :-

Hash verifications aside, from what I understand Balena Etcher has been, shall we say, "problematic" the last year or so. We don't use it in 'Puppy'; it doesn't work for us, because our Pup has a very odd setup that Etcher can't recognise, so we use our own, native tools instead.

@Brickwizard can, I think, confirm if this is the case or not.


Mike. ;)
 
I think, confirm if this is the case or not.
That was the case at the beginning of last year, but there was a newer version came out, I have not come across any negativity on the new version YET. Rufus also had problems burning iso's, but this has largely been over come if you do it right, below is an Ubuntu tutorial, if you scroll halfway down you will find instructions on using windows+ Rufus These instructions can be used for any distribution

 
I have had zero problems with .iso files here. and use a variety of tools to burn them Etcher works well as does mintstick (Linux mint usb writer which is available on many .deb distros.) Ventoy works as well Also have used Fedora's imaage writer. there are many choices so not sure where your problems lay. One thing for sure you should not be using downloaded files from unknown sources and the hash should match.
 
@Iamgeese - I have a couple of alternatives available for you, but would first need to know what distro you wish to work with.

I have a couple of questions for you, and the first one is do you want to upgrade your obsolete Zorin, on the computer it is on?

If Yes,

2. Is it working currently?
3. Do you have the firewall enabled?
4. If not sudo ufw enable will at least provide a certain level of protection until the upgrade is accomplished.
5. Do not run your Firefox or other browser fullscreen, that will lower the attack surface available for bad actors to work with.
6. Have you run sudo apt update && sudo apt upgrade? If not, do so, and then come back to here for further instructions.

Cheers

Wizard
 
On

...is there a way of updating without having to flash sticks? Because I have no idea what I am doing wrong here

Likely, yes, but I would need to know which distro you wish to use.
 
I don't usually use ISO files on USB sticks but I set up grub to boot from an ISO file once just to prove to myself that it worked. I used a Tiny Core ISO but I suppose it would work with any bootable ISO file. Below is an excerpt showing the relevant lines in grub.cfg. Note that, in the linux= and initrd= lines, you have to know where in the ISO's directory tree the relevant files are located and their names.

The ISO itself had the isolinux bootloader installed, which I ignored. With some other OS I might have had to look at the config file(s) for isolinux for tips on any kernel codes that might be required. I suspect one could simply chain load isolinux from the ISO but I didn't try that.

Code:
set BOOTUUID=<UUID_OF_FS_ON_USB_STICK>

search --no-floppy --fs-uuid --set=root ${BOOTUUID}

#####
#
# 2025-07-15 00:45
#
menuentry "core16.1_64bit_iso" {
  set ISO=${root}/boot/isodir/CorePure64-16.1.iso

  loopback loop ${ISO}
  linux=(loop)boot/vmlinuz64
  initrd=(loop)boot/corepure64.gz
}
#
#####
 
I like that Mike, but would not encourage Newbies/Beginners to start tinkering with grub.cfg, first thing it says in many distros is

# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

That being said, there is also grml-rescueboot, which I wrote about here

https://www.linux.org/threads/how-t...a-usb-dvd-sd-wizards-corner.56273/post-265342

I was going to mention it to the OP subject to my identifying which distros he was looking at.

grml-rescueboot method leaves grub.cfg out of the picture, but provides the desired response. It only works on Debian, Ubuntu and Mint based distros, but there are likely other solutions.

Debian's net install feature is one such.

Cheers and Avagudweegend

Chris
 
I like that Mike, but would not encourage Newbies/Beginners to start tinkering with grub.cfg, first thing it says in many distros is

# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

Ummm... yeah. I gathered from many of the posts I've seen here and elsewhere that there are tools for updating grub.cfg. In fact, upon first looking into such things, I realized that at least some of those tools are actually installed along with grub2 - I just never had occasion to use them and have never used anything other than a hand-crafted grub.cfg.

Actually, the excerpt I showed above is a simplified edit showing only the relevant parts of my actual grub.cfg - the working file has a bit of scripting built into it (its a lot like shell scripting in some respects) such that at this point I wouldn't dare let the high-level tools touch it.
 
I have had zero problems with .iso files here. and use a variety of tools to burn them Etcher works well as does mintstick (Linux mint usb writer which is available on many .deb distros.) Ventoy works as well Also have used Fedora's imaage writer. there are many choices so not sure where your problems lay. One thing for sure you should not be using downloaded files from unknown sources and the hash should match.
Agreed, I learned long ago that if you don't trust the src and it can't be verified don't do it.

Would a Live usb session of Fedora allow OP to use the image writer and have success that way?
Rather then using ventory?
 
@Brickwizard :-

See, we always found that the problem with Etcher wasn't Etcher itself. The problem was with Puppy. Not because Puppy doesn't work like mainstream distros - on the whole (variations aside) she does - but rather, it boiled down to what Etcher expects to find versus what it did find (or rather, didn't).

Etcher expects to see a partition with a full file system written into it. With Puppy, what Etcher finds is one or more uniquely-named directories, each containing a collection of highly-compressed SFS packages, a kernel, plus a handful of text files & scripts. Until the initrd.gz runs, sets up a virtual file-system in RAM, then decompresses Puppy's read-only SFS files and copies their contents into that virtual file-system.....until all that happens, Puppy's file-system doesn't even exist.

The Puppy file-system lives in RAM for the duration of the session.....and while it does, the contents of the "save-folder" are merged with it via the magic of AUFS or OverlayFS. To all intents & purposes, the user sees exactly the same set-up as in any mainstream distro.....the underlying mechanisms perform some very neat and rather unique "tricks" in the background, but the end-user doesn't need to know how it all works....just that it does.

~~~~~~~~~~~~~~~~~~~~​

At shutdown, user changes are saved to the file-system 'layer' that contains the 'save-folder', the "virtual filesystem" is consigned to the oblivion of cyber-space.....ad at next boot, the process starts all over again. The "background trickery" MAY seem totally pointless to most people, but it's what makes our Pup as flexible as she is.....and capable of running in the most unique & unexpected ways.

Aye, she's an "acquired taste", all right.....but most Puppians - once they've got the hang of her - wouldn't have things any other way.....and tend to remain extremely loyal.


Mike. ;)
 
Last edited:
@Iamgeese :-

Hash verifications aside, from what I understand Balena Etcher has been, shall we say, "problematic" the last year or so. We don't use it in 'Puppy'; it doesn't work for us, because our Pup has a very odd setup that Etcher can't recognise, so we use our own, native tools instead.

@Brickwizard can, I think, confirm if this is the case or not.


Mike. ;)
Interesting that everyone seems to have problems with etcher but me.

I use etcher with Easy OS.
I use etcher with Puppy Linux.
I use etcher with LMDE.

Not a problem and I've used several versions that are recent releases.

I don't know what everyone else is doing with etcher to have problems with it.

I just download and create bootable usbs without problems.

I've never used the hash marks or check sums or whatever it's called although I download directly from the distros source.
 
Agreed, I learned long ago that if you don't trust the src and it can't be verified don't do it.

Would a Live usb session of Fedora allow OP to use the image writer and have success that way?
Rather then using ventory?
Yes should work ok though I have not personally tried it. It is available for Linux, Mac and Windows also.
 
Some of this has to do with the way the image was created. So distro's force "read only" images.
Other do not. Rufus for example will let you create many images in either ISO mode (read/write) or DD mode
(read only in some case)... Just the fact that the read/write bits are changed will change the checksum
of a distro. Some distros; (fedora/redhat in particular) will not boot if there is a checksum mismatch.
 
There's another possibility, which is that you're a victim of DNS hijacking via rootkit malware on either your router or your machine. Very insidious and very difficult to get rid of. This is not like the DNS hijacking of the olden days, where the end result was your browser brings up loads of ads for Rolex watches and viagra. It's a more intelligent kind of attack which will redirect all your attempts to download any operating system (linux or windows) to malicious servers that, when installed, will attempt to embed themselves in the firmware. I read an article about Interpol hunting and finding a large organised crime ring, I believe in Russia, that had a whole array of servers with many possible permutations of operating system and version etc. - all hacked in some way to introduce keyloggers and other telemetry.

It's a very slim possibility, and it's likely that if you catch rootkit malware that enables dns hijacking, you were
specifically targeted for some reason. One method that allows this type of rootkit to propagate might be via a BadUSB attack. Maybe it's a 1 in 1000 chance... so I'm not saying this is definitely the case, but if you think it's worth looking into try this:

Buy a new sealed USB stick from a physical shop and use a completely unrelated router and linux machine to download and calculate the sha256 (or sha512 etc) hash. Avoid using MD5 as these have been reverse engineered for some time. If it turns out the hash of this new download is correct and matches the hash on the download page (if you're overcautious or paranoid maybe viewed on a third, totally separate system) they you might need to reflash the firmware on your motherboard. Again, download the UEFI BIOS binary on a trusted machine from the manufacturer's website. My Asus motherboard allows flashing without turning the computer on (computer is switched off but mains is still connected) by attaching a FAT32 flash drive into a particular slot and pressing a button on the back of the machine. Some system that allows you to flash "early" might be fine too. The router would also be suspect and if that's the case, reflash or throw away. If the bootloader has been subverted, then the router could show phoney "factory reset" flashing lights but actually be doing nothing and keeping the malware as it is. Any attempts to reset passwords will result in a keylogger sending your password to..... ok that's enough for now!

I hope it's something a lot more simple and like I said it's extremely unlikely this describes your situation, but whether it is or not, good luck getting your favourite distro up and running again!
 


Follow Linux.org

Staff online

Members online


Top