From: "Rick Moen" <rick@linuxmafia.com> Subject: Re: Help Creating A Bootable USB Disk Date: Mon, 3 Aug 2020 20:36:36 -0700
Quoting 'Christian Peeples' via BerkeleyLUG (berkeleylug@googlegroups.com):Thanks. Jitsied into SFlug and got a great deal of help Tom and Michael (including error checking from the terminal), found out one of the thumb drives I had bought was defective. We got it done and am now using 20.4 LTS.Excellent. Yes, defective media would do that, too. Echoing Michael's point, the GUIfied tools tend to hide / discard debugging information, with the result that when something goes wrong, you have little idea what happened and why. This is one of a number of reasons to gravitate towards standard command-line tools, at least when doing debugging. E.g., first check in the dammned GNOME 'Disks' app to make sure the device's filesystem(s) hasn't (/haven't) been mounted, and unmount if mounted. Then, open a terminal and do: $ dmesg | tail #Notice whether it's /dev/sdb or whatever, and #whether it has partitions, e.g., /dev/sdb1 $ sudo su - #Be wary that you're using root authority after #this, which is why the prompt changes from $ to #, #so that you're aware and on-guard. # fdisk -l /dev/sdb #Or whatever the device is. #This command displays its partition table, if any. If worried that the flash drive (or other external drive might be a dud, you can experimentally format it. Like this would format flash drive /dev/sdb's first partition /dev/sdb1 as FAT32: # mkfs -t vfat /dev/sdc1 # exit #Stop wielding root-user authority, now. $ Old-school tools for overwriting a disk from a disk-image file includ dd.
Yeah ... in our particular case, with the first flash media, it was only upon reading it back (cmp(1)) that the error was apparent. It gave no indications of errors upon write. But in both attempts to verify it after each of two attempts to write then verify, in both cases that media failed at the same location, so probable that USB flash is defective. I suggested badblocks(8) for further/subsequent testing/analysis. The other USB flash media worked perfectly fine, and verified 100% correctly after the first write. Also, in each case, to thwart any side-effects of operating system buffering of the media, after flash had finished writing and fully flushed out (checked both by completion of sync; sync and also LED activity on the USB flash stopped), we disconnected the flash, waited a bit, then reinserted it - only after that did we proceed to do the cmp(1) to do a verification check of the data. So ... in this particular case, dmesg and the like wouldn't have caught the error ... but cmp(1) and (presumably) badblocks(8) would. Sometimes flash fails in funky way. I myself have one USB flash drive that likewise failed very oddly - writes would appear to go okay, but reading the data back ... yeah, ... data read would not be at all like the data written ... egad. -- You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/20200808110403.11766qeoe7c5gfsw%40webmail.rawbw.com.