Whenever I try to install QubesOS from the USB stick and run “Test this media and install QubesOS …” it says that the image is corrupted. However, this only happens on one PC, which is most surprising. I test after downloading the iso with sha256sum and the sha256 hash I pull from several sources over different internet connections and the iso is not corrupt. What I noticed is that in the list of events, the white areas of the texts look corrupt until shortly before the start of the check, as in the case of RAM damage (marked in the screenshot).
USB test with random data which I checked with sha256sum
the iso written from different PC to different USB sticks
out of desperation I wrote the iso to an SSD and connected it via sata and booted it
since the installation of fedora is very similar I wrote the fedora iso on the USB stick and booted and tested it without any problems
i have connected only the minimun to the PC and used other input devices
All tests have shown no error and everything I have tried has not helped. I am not the biggest newbie in this area and have already installed QubesOS countless times and on this PC. I can’t understand why it doesn’t work on this PC but it does on all the others.
I hope someone can help me and thanks in advance also for reading through.
I have been looking for the problem on the internet for some time but only found posts indicating that the iso was corrupt. however, what I could have thought of earlier is to look for the same problem on fedora.
I found the following:
which is a very identical error I have also noticed that from the moment I booted the PC with the USB stick this error also occurs on other PCs so something is changed on the USB stick.
I am currently trying to work out what is being changed but does anyone have any ideas?
**Edit
i have checked every file on the USB stick from the accessible partitions with sha256sum before and after booting and there is no difference and no new files have been added or anything like that… so what is being changed?
Is it possible that some hardware component, be it the UEFI/BIOS, is changing data outside of accessible partitions?
But then why is only QubesOS affected and not fedora and other systems?
I don’t use the test option, I just straight install. Is there a reason you don’t do that ? How are you writing the iso to USB ? I use DD and have never had any issues
If possible i always use the test option because something can always go wrong when writing the usb stick and in the past it has happened once.
I could skip the test but that doesn’t change the fact that for whatever reason something is modified the usb stick that shouldn’t be.
When i write the iso to the USB stick, i always use the recommended dd command from the QubesOS documentation sudo dd if=Qubes-RX-x86_64.iso of=/dev/sdY status=progress bs=1048576 conv=fsync
I have never had any problems with it so far too and on other PC’s there are no problems only on the one.
I still had an older QubesOS iso and i just tried to boot it and did the self test without any problems, it’s just the latest iso that doesn’t work for me. Which probably indicates a software problem.
Yes
1:
i have used 2 USB sticks from different manufacturers for the current problem treatment. i have also written to the USB sticks from another QubesOS from a fedora vm and also from another pc with debian.
before every write operation i test the iso with the hash sum via sha256sum
then I run “sudo dd if=Qubes-R4.2.2-x86_64.iso of=/dev/sdc status=progress bs=1048576 conv=fsync”
to be sure i run sync an unplug the USB stick
2: (PC-A)
Mainboard: Gigabyte Z490 GAMING X
CPU: intel i5-10600
RAM: 2x 16GB 2666.66MHz
– Qubes-R4.2.0-rc1-x86_64.iso - passes the media test
– Qubes-R4.2.1-x86_64.iso - fails the media test
– Qubes-R4.2.2-x86_64.iso - fails the media test
– Fedora-Workstation-Live-x86_64-40-1.14.iso - passes the media test
3: (PC-B)
Mainboard: Asus P8B75-M
CPU: intel i7-3770
RAM: 2x 8GB Random ones
– Qubes-R4.2.0-rc1-x86_64.iso - passes the media test
– Qubes-R4.2.1-x86_64.iso - passes the media test
– Qubes-R4.2.2-x86_64.iso - passes the media test
– Fedora-Workstation-Live-x86_64-40-1.14.iso - passes the media test
I used the same USB stick for both PCs each time and booted it first into PC-B and then into PC-A and then the other way round after a rewrite. After it was booted in PC-A, it could no longer run the test on PC-B without failing too BUT only with Qubes-R4.2.2-x86_64.iso.
**edit
Something that has also crossed my mind:
What if it is a Bootkit?
well the PC has only ever had QubesOS running on it since it came out of the box except now when testing Windows for the intel diagnostic tool. The PC has also not had an internet connection for at least half a year. And apart from that, I am very far away from the Bootkit target group.
**edit
I just tested the Qubes-R4.2.1-x86_64.iso where i have the same effects.
Do you have Windows installed on PC-A?
Did you plug your USB in PC-A while working in Windows?
Windows can automatically write some files in EFI System partition on the USB disk that will cause the disk check to fail.
I only installed windows on an HDD for the CPU test, the HDD is no longer in the PC-A. Otherwise I only have GNU/Linux systems in use (QubesOS, Debian 12, Fedora 40).
If all systems would fail I would say that something in the PC changes / corrupts the data but it really only happens with the mentioned QubesOS iso and only when I boot from it.
Try to check it like this:
Write Qubes-R4.2.2-x86_64.iso on media using PC-B.
Check that it passes the media test on PC-B (try it twice).
Check if it passes the media test on PC-A.
If it fails then connect the media to PC-B and run diff between the files in EFI System partition between the media and ISO.
Have you tested different combination of UEFI & legacy boot on PC-A & PC-B? To see if the media verification fails on all possible combinations? (there should be 4 possible cases).
I have already done this.
I wrote the iso to the USB stick and did run “find /media/user/sdc1 -type f -print0 | xargs -0 sha256sum >> sha256sum.txt” and the same for the sdc2, so for both mountable partitions.
Then i booted the USB stick from PC-B and it passed the test, then i used “sha256sum -c sha256sum.txt” to check the data after mounting the partitions and all were ok. then i booted again on PC-B with success and then on PC-A where it failed again.
Then I tested it again with sha256 and again all data was ok … . That was the moment when I thought I was getting crazy so I booted the USB stick again on PC-B but again failed. What I am testing right now is what I should have done before to test the partitions directly with sha256sum so “sha256sum /dev/sdc1” I am doing that right now it just takes time as rewriting the whole USB stick does need time.
I also think that this is exactly what the media tester does, isn’t it? i.e. testing the parttion directly
It has something to do with the CSM support of my mainboard.
I have already tested if it works with UEFI and legacy and both failed. But I have not yet tested what happens if I deactivate CSM support, i.e. legacy boot support, completely. After I started it in UEFI without CSM support activated it works without problems !
But, for whatever reason other systems do not have the problem like fedora. I have tested it again fedora which also checks the medium does not fail neither in UEFI, Legacy and with and without CSM support.
Even if the error is permernent from the moment it has booted with CSM Support Activated, the partitions are not changed, which still confuses me.
Because the error persists despite the fact that the partitions have not been changed, i now hash the entire usb stick but this takes some time.
Is this a bug I should report ? I mean the CSM support also does something that it is not supposed to do when booting in UEFI mode, but other systems can handle it except Qubes-R4.2.1-x86_64.iso, Qubes-R4.2.2-x86_64.iso.
I would investigate the content of EFI partition after booting with CSM enabled. To see if it adds anything suspicious to it. Specially if the Fast Boot or Ultra Fast Boot options are enabled in motherboard setup.
You have to find out what it does to the EFI partition (and why). Then it is up to you to decided to report (and complain) about it or not. I am not sure if Gigabyte would take any action about it. Their Microsoft Windows users love their Ultra Fast Boot tweak.
Regarding the Qubes R4.2.1+ complains, it has more strict verification compared to most other Distros. It is imaginable that its verification would fail while Fedora would pass
As I said the partitions are not changed (not even the efi) the hash remains the same, something outside is changed.
From now on I don’t know much about it but what I can say is that the sha256 checksum of each partition remains the same but the whole hash of the USB stick is changed.
Could be beyond that. It could have modified anywhere within ISO9660 hybrid table. This is bizarre. It is the 1st time I have encountered a moderboard which modifies a bootable USB stick. This is truly worth of investigation.
i built a little script which gives me the info from fdisk, creates hashes and creates an .img of the drive via dd so i used an 8GB one that the .img does not get too big.
VM = Fedora 40 on an another PC
PC-A = is the one with the CSM Support problems
PC-B = is the test PC
VM: write Qubes-R4.2.2-x86_64.iso to the USB stick
execute script to collect data before.txt:
Unfortunately, I don’t know what to look for in the .img data or directly on the USB stick, that’s now outside the fields I know.
I would also be willing to provide the .img files, but they are 14,6GiB and I don’t know where I can upload them anonymously.
