|
Wordle 546 3/6
⬛🟨🟩🟩⬛
🟨⬛🟩🟩⬛
🟩🟩🟩🟩🟩
Get me coffee and no one gets hurt!
|
|
|
|
|
Wordle 546 4/6
🟨⬜⬜⬜⬜
⬜🟨🟩⬜⬜
⬜🟨🟩🟩⬜
🟩🟩🟩🟩🟩
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
It's gonna be one of those days...
If you've never heard of Ventoy, it's a utility that lets you boot from a USB thumbdrive, and then presents a menu made up of any number of bootable ISOs you just dump on the drive. You have to format the thumbdrive with it (so it can be made bootable and loads the app that looks for ISOs and builds the menu), but the ISO files themselves aren't touched in any way. So that's besides the point.
I just copied an .ISO file on the thumbdrive, stuck it into a laptop, booted from it and started installing the OS...halfway through it, it complained the image wasn't valid. Sure enough, if I compared SHA256 hashes between my original ISO file and the copy I made on the USB stick, they don't match. Easy enough fix, I'll just re-copy the file and be done with it. For good measure, before wasting my time reinstalling, I'll re-compare the hashes. They still didn't match.
I re-did it a third time, same thing again.
The original ISO file is on ComputerA, and the thumbdrive is in a USB port on ComputerB. I'm copying the file across the LAN and directly onto the USB stick. And I consistently get this mismatched hash.
So I took the USB stick and plugged it directly into ComputerA, and compared the hashes - they finally match (!)...
Why would the extra step of going over the LAN modify the data stream contained within the file? Given I was able to produce an identical copy of the file on the same USB thumbdrive by avoiding the LAN, I can't really blame the drive itself.
This isn't the analog world. Any read/write error should've been detected in transit, and reported by the OS. Yet it remains blissfully unaware the target no longer matches the source. How do you even explain that?
Additional details: ComputerA is an old system that can only do USB2. ComputerB is newer and the USB stick was hooked up to a USB3 port. Surely the difference in transfer speeds can't blindly introduce errors that get ignored?? Otherwise there's no way I could ever trust a transfer of any kind of binary data...
|
|
|
|
|
I know nothing about hashes for ISO files; but could it be including the timestamp in some form? From one computer to another the hash on the "sent" file won't match the clock (and hence the file write timestamp) on the receiving machine. If you copy directly from HDD to thumb drive all on the same PC, they will. The file content isn't modified, but the file metadata is.
|
|
|
|
|
The hash is calculated purely based on the file content, not its metadata. I think this rules out that theory.
|
|
|
|
|
I've seen this on other large files. For some reason SMB copies across networks can glitch. I suspect it's a bug in the Windows SMB implementation that only manifests on network links.
|
|
|
|
|
I'm inclined to believe this...however this would mean I'd end up with tons of corrupt files. The backups I create from my NAS are done across my LAN, and I have no inclination to believe any file has ever been corrupt in that way.
But now you have me worried 
|
|
|
|
|
To add my useless reply, just can't resist 
Some years (15?) ago, had just that happen copying files between two linux servers. The useless part is that I can't remember what the problem was (need to refresh my memory sticks and backups). I seem to remember throwing one of the (somewhat old) servers to the trash as I come to the conclusion (after switching network cards, memory sticks, disks, ...) that the problem was motherboard related.
Just a few tests you can do:
- redirect the ssh stream to output and sum that to check if the problem is in the network stack or local.
- write the file to disk instead of usb and do the sum on the disk file, the problem may be in writing to the usb.
- if using wifi try using a network cable
- if already using a network cable, try using a new one and(or connecting to a different port on the router/switch.
As obermd wrote, I also had no errors anywhere to show that something odd was happening.
|
|
|
|
|
Some good ideas in there. I'll give those a try, thanks.
|
|
|
|
|
Check for updates on your network and USB device drivers.
TLDR
Flew across the pond on a support call…
Your app crashes on startup.
Bring my desktop CPU (with app source, debugger, etc) all the way to customer site.
Fire up the app, no issues.
Client starts app on their system and it crashes.
Client is hosting the app on a network share.
Copy the app to the local hard drive and it works.
It turns out there was a bug in their network driver.
They updated the network driver and then it would load from the share.
|
|
|
|
|
What about introducing a new four-letter abbreviation: TMDC. Too Messy, Didn't Comprehend.
|
|
|
|
|
Start with driver updates/bug fixes on both systems.
It could save a trip 1/3 of the way around the world. (Probably not an outcome in this case)
|
|
|
|
|
dandy72 wrote: So I took the USB stick and plugged it directly into ComputerA, and compared the hashes - they finally match (!)...
Presumably this was after you recopied the ISO to the USB again right?
dandy72 wrote: Any read/write error should've been detected in transit, and reported by the OS.
Really depends on how it was transferred. Dropped packets happen more times than you'd think. If the mechanism you're using to transfer files uses UDP underneath the hood, then there is no error checking for packets.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Presumably this was after you recopied the ISO to the USB again right?
The original file sitting on ComputerA's hard disk, which I know has a valid hash.
Jeremy Falcon wrote: Dropped packets happen more times than you'd think. If the mechanism you're using to transfer files uses UDP underneath the hood, then there is no error checking for packets.
Copied the file by dragging/dropping with Windows Explorer. You'd hope it wouldn't use a protocol that allows packets to be dropped silently...
|
|
|
|
|
dandy72 wrote: Otherwise there's no way I could ever trust a transfer of any kind of binary data..
Imagine, a surgeon if you will. Explaining all this high-tech they have to assure you, and you see a VB6 interface on one of the monitors?
"Trust"?
Well, it goes as far as I can throw a brick, and that's literally so. Trust means complacency, so by default, there shouldn't be any.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
This can no longer be a coincidence.
I've lost count of the number of times where I've installed a Linux distribution on this old laptop of mine (which I primarily keep to tinker with different Linux distributions), I create my login username/password, everything's fine, then upon the first reboot...my password is rejected as if I've made a typo.
Yet if I type it into the username field, just to be able to view the individual characters (and ensure it's not a caps-lock type of thing), I can confirm I'm entering it correctly. This has happened with multiple versions of multiple distributions. Yet I've never had this happen with Windows. I always use the same password so I can type it reliably with muscle memory.
The laptop I'm installing Linux on isn't being used for anything particularly important and doesn't contain any important data, so my workaround, when this happens, is to reinstall (!) and then to simply set the password as 'password'. Pretty lame, but I swear, if I use a combination of uppercase/lowercase, digits, symbols, etc then any login attempt after the initial OS install fails to recognize it. It makes absolutely no sense, and I feel crazy just writing this down to ask if anyone's ever seen this. It has happened so many times to me it cannot be mere coincidence.
Am I losing my mind?
|
|
|
|
|
Could it be the keyboard layout? If it defaults to US layout for installation, and then changes to another layout when you reboot, the symbols may have moved. 
(Or have you already tried the "type it in the username box" trick both at creation and login?)
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I thought about that, but I don't change the keyboard layout. And yes, I did try temporarily entering the password in a field so it's visible both during the setup, and after. Like I said - zero sense.
|
|
|
|
|
Are you trying to logon as root ?
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
modified 17-Dec-22 3:56am.
|
|
|
|
|
I'm trying to login using the credentials I've supplied during the OS setup.
|
|
|
|
|
Check your keyboard-settings and the keyboard itself; I've had the same problem, a few times. One that always gets me is a Norwegian laptop I have, with the keyboard set to EN-US. Most of the characters are then where I expect them to be. Very confusing at the time I worked in Germany, where z and y are swapped.
Another time it happened simply because the keyboard needed cleaning. Sometimes an "e" came when typed, sometimes no "e", sometimes two or three. That's the downside of smoking behind your computer.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Are you using any special characters like < > | etc?
That might mess up a shell command/sed/regexp etc?
The setup might be collecting info into a template that barfs when it tries to read it back.
|
|
|
|
|
Not those characters specifically, but I do have some non-alphanumeric characters...but nothing that would even be rejected as part of a filename.
englebart wrote: The setup might be collecting info into a template that barfs when it tries to read it back.
I suppose if the installer is using one validation routine, but the login code uses something that's not 100% identical...that could mess things up? But you'd think this sort of thing would've been found/fixed - my password isn't that sophisticated...but who knows.
|
|
|
|
|
dandy72 wrote: Am I losing my mind?
Yes
Jeremy Falcon
|
|
|
|
|
Well...that was a rhetorical question. And I kinda already knew the answer to it. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
