|
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. 
|
|
|
|
|
Ok, for a real reply. Just assuming you're installing a distro that gets a GUI going by default.
If that's the case, then reboot into the console or single user mode if you know the root password. The switch user (su) command can be use for more than just root access. So, try something like this:
Quote: su - user2
If you can't login that way, there's a problem with your password.
And if that's the case, what you can do to make sure it's not the install process is create a second user after a fresh install and before you reboot. See if you can login with that user instead afterwards. If you can, then maybe the install process messed something up.
Jeremy Falcon
|
|
|
|
|
The problem is that the distro doesn't prompt you to create a root account and doesn't document what the default root password might be. Going through the entire installation process, I'm only ever prompted to create one set of credentials. Since those are no good, after a reboot...I'm basically completely locked out.
|
|
|
|
|
If that's the case, I'm willing to bet (hoping to bet) the install puts the default account as a sudoer. So, you should be able to run sudo su without needing the root password, to gain root access.
Jeremy Falcon
|
|
|
|
|
...right? But if I can't even reach a command prompt (because I have to login), how would I run sudo su at all?
|
|
|
|
|
You don't have access to the machine before the reboot? What distro is this?
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: You don't have access to the machine before the reboot? What distro is this?
Not sure if I've explained this right.
Clean hard drive, I boot from an ISO, and run the distro's installer. At some point, it'll ask you for credentials, and it creates that account. You're not prompted to supply a password for the root account. That means the distro creates the account you've just supplied credentials for as part of the sudoers list.
Finish the install, reboot, you have to supply credentials to login. That's when the password I had initially supplied is simply not recognized. Can't reach a command prompt to run sudo or anything else.
The laptop I was tinkering with was running some instance of Fedora at one point. Then it was running Zorin. Then (and this is where I did my tinkering last week) I installed Lubuntu. They all had the same problem.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
