[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help Creating A Bootable USB Disk



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.