You are not logged in.
Arch linux iso sha256 sum changes when copied into my usbdrive's directory. I think that is why I failed to boot many times while booting from usbdrives(Kernel panics or some other errors). I already installed arch but i want to keep an extra copy as backup.
I do not know how to use pictures in this forum so Im giving the terminal log
~/distribution-iso
❯ sha256sum archlinux-2022.12.01-x86_64.iso
de301b9f18973e5902b47bb00380732af38d8ca70084b573ae7cf36a818eb84c archlinux-2022.12.01-x86_64.iso
~/distribution-iso [⏱ 9s]
❯ cp archlinux-2022.12.01-x86_64.iso /mnt/usbdrives
~/distribution-iso [⏱ 4m7s]
❯ cd /mnt/usbdrives
/mnt/usbdrives
❯ ls
archlinux-2022.12.01-x86_64.iso
/mnt/usbdrives
❯ sha256sum archlinux-2022.12.01-x86_64.iso
d6f246197314cf7bd3ad2243aec6a81eb2c5e96d29f8dfe1248aaf61bb16596f archlinux-2022.12.01-x86_64.iso
/mnt/usbdrives [⏱ 15s]
❯
I have mounted my usbdrive in /mnt/usbdrives. I downloaded the iso in ~/distribution-iso via qbittorent. As you can see when I checked the sum in ~/distribution-iso directory the iso sum matched but when I checked the sum in /mnt/usbdrives directory it did not match.
Things to note
1.Im using Ventoy(https://github.com/ventoy/Ventoy) to multiboot isos. That is why Im copying it into the usbdirve directory instead of flashing.
2.I used rufus(windows) to boot into the in the past but failed a lot of times and I think this is why.
Is there a way to fix this ?
Last edited by Tipt (2023-01-04 05:40:11)
Offline
1.Im using Ventoy(https://github.com/ventoy/Ventoy) to multiboot isos. That is why Im copying it into the usbdirve directory instead of flashing.
Me too.
When copying the ISO, its hash has to be the same.
Maybe your USB drive is failing?
<49,17,III,I> Fama di loro il mondo esser non lassa;
<50,17,III,I> misericordia e giustizia li sdegna:
<51,17,III,I> non ragioniam di lor, ma guarda e passa.
Offline
My initial thought is that the usb drive could probably have some area damaged. I would propose to use an alternative usbdrive to copy and check the drive for damaged blocks.
Offline
cmp ~/distribution-iso/archlinux-2022.12.01-x86_64.iso /mnt/usbdrives/archlinux-2022.12.01-x86_64.iso
cmp would tell you exactly where the difference is located
it's a bit unusual since there's also filesystem cache involved, i.e. those commands don't necessarily re-read data from the disk at all (if the USB wasn't remounted/unplugged in between and your RAM is not full). at that point you can also consider running a memtest.
Last edited by frostschutz (2022-12-28 08:43:42)
Offline
those commands don't necessarily re-read data from the disk at all (if the USB wasn't remounted/unplugged in between and your RAM is not full)
Hey frostschutz, when copying ISOs into my Ventoy USB I always perform a hash check inside the USB drive on the copied-over ISOs.
I can confirm the data is actually read again from the USB drive becuase I see I/O operations via iotop.
So... Is iotop telling me lies?
<49,17,III,I> Fama di loro il mondo esser non lassa;
<50,17,III,I> misericordia e giustizia li sdegna:
<51,17,III,I> non ragioniam di lor, ma guarda e passa.
Offline
setup:
# head -c 888M < /dev/urandom > randomfile.img
# time sha256sum randomfile.img
c08ba360ee9f71a3165ebac22b4aaa08fbcb4380597e601204a35637e9170706 randomfile.img
real 0m0.491s
# time cp randomfile.img /mnt/usb/iso/
real 0m0.516s
# time sync
(…several seconds later…)
test (with and without cache):
# time sha256sum /mnt/usb/iso/randomfile.img
c08ba360ee9f71a3165ebac22b4aaa08fbcb4380597e601204a35637e9170706 /mnt/usb/iso/randomfile.img
real 0m0.463s
# echo 3 > /proc/sys/vm/drop_caches
# time sha256sum /mnt/usb/iso/randomfile.img
c08ba360ee9f71a3165ebac22b4aaa08fbcb4380597e601204a35637e9170706 /mnt/usb/iso/randomfile.img
real 0m3.259s
it might also depend on the filesystems involved whether or not this is cached at all, but normally... it's not re-read from disk if it was just written and still in the cache
but usually you can expect this test to only test ram rather than the physical storage device. you have to deliberately drop caches or unmount / unplug / remount to invalidate caches for this filesystem and device
Last edited by frostschutz (2022-12-28 09:01:46)
Offline
My initial thought is that the usb drive could probably have some area damaged. I would propose to use an alternative usbdrive to copy and check the drive for damaged blocks.
As per your suggestion I checked the usb drive for damaged blocks using "sudo badblocks -w -s -o error.log /dev/sdb". I did find a few errors . Archwiki said to do it like this" mkfs.filesystem-type -l ~/error.log /dev/sdb1" but the command did not work so i formatted it as usual. After formatting it the issue still persisted , the checksum doesnt match .
cmp ~/distribution-iso/archlinux-2022.12.01-x86_64.iso /mnt/usbdrives/archlinux-2022.12.01-x86_64.iso
cmp would tell you exactly where the difference is located.
According to your suggestion checked for differences and the terminal log is,
/mnt/usbdrives [⏱ 51s]
❯ cmp ~/distribution-iso/archlinux-2022.12.01-x86_64.iso /mnt/usbdrives/archlinux-2022.12.01-x86_64.iso
~/distribution-iso/archlinux-2022.12.01-x86_64.iso /mnt/usbdrives/archlinux-2022.12.01-x86_64.iso differ: byte 86824974, line 338360
So there is a difference but I dont know what it is.I also want to mention that the difference changes every time I copy it to the directory.
Last edited by Tipt (2022-12-28 14:41:28)
Offline
As per your suggestion I checked the usb drive for damaged blocks using "sudo badblocks -w -s -o error.log /dev/sdb". I did find a few errors . Archwiki said to do it like this" mkfs.filesystem-type -l ~/error.log /dev/sdb1" but the command did not work so i formatted it as usual.
You are not meant to copy that command verbatim. Rather, you're supposed to substitute 'filesystem-type' with the relevant filesystem type. For example
mkfs.ext4 -l ~/error.log /dev/sdb1 # If sdb1 has a filesystem of type ext4.
mkfs.vfat -l ~/error.log /dev/sdb1 # If sdb1 has a filesystem of type vfat.
mkfs.fat -l ~/error.log /dev/sdb1 # If sdb1 has a filesystem of type fat.
mkfs.ext2 -l ... # If sdb1 has a filesystem of type ext2.
...
If you still get an error, post the exact command and output.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
I was able to fix it by using another flashdrive . So i will mark this as solved
Offline