[NBLUG/talk] target

Rick Moen rick at linuxmafia.com
Wed Nov 30 12:37:27 PST 2016


Quoting Alex Kleider (akleider at sonic.net):

> On 2016-11-29 13:12, Rick Moen wrote:
> 
> snip
> 
> ># mount | grep sdc  ##Make sure the thumb drive is unmounted
> >before proceeding
> ># cp /tmp/debian-8.6.0-amd64-netinst.iso /dev/sdc
> >
> >Note that the target should be the block device as a whole.  (You
> >should
> >use whatever device _your_ kernel reports, not necessarily /dev/sdc.)
> >
> >Also, in case it wasn't obvious, that cp operation will overwrite the
> >target (which I'm sure you realise, and accounts for your commendable
> >caution about making sure of the target).
> >
> >Happy Debianing!
> >
> >[1] The dmesg logfile, the kernel's ring buffer, is actually ASCII and
> >kept in a rotated set of archived copies as /var/log/dmesg[.N][.gz] .
> >So, you can just do 'less /var/log/dmesg' instead of using dmesg(1), if
> >you prefer..
> 
> Clarification please.
> 
> Did you mean 'umount' rather than 'mount?

Nope.

The command 'mount' with no options returns a list
of everything that's mounted.  Filtering that output through a grep
selecting out only any line mentioning 'sdc' suppresses noise lines
you're not interested in -- the objective in this being 'Verify that
nothing on /dev/sdc is currently mounted'. 

Basically, 'mount | grep sdc' returns null if no filesystem on /dev/sdc
is mounted, and null's exactly what you wish to see before doing the cp
operation.  Null means you're ready to go.  Non-null means there's a
problem.

> I would have used umount /dev/sdc1

Well, yes, that's how you unmount something if you know or suspect it's
mounted (or don't care whether it's currently mounted or not but just
want to make sure it isn't).  Certainly, that's one way of verifying
that the filesystem isn't mounted -- forcing that state -- or is it?
Consider:  Having done that umount, the truly cautious would 
examine mounts to make sure one's umount command succeeded, right?
And that would require something like 'mount | grep sdc'.

As it happens, /bin/umount _does_ pretty much reliably complain if for
some reason it cannot carry out your request, so subsequent verification
of success after umount has carried out its work without diagnostic
mutterings is 99.9% superfluous.  But my (small) point is that the
mindset of 'Order that it be so' differs in kind from that of 'Verify
that it's so'.

That's in part a professional experience thing.  I used to tell my
sysadmin staff at Linuxcare that our departmental mottos were 'Make only
_new_ mistakes' and 'It's not done until it's verified' -- because one of
the classic ways junior SAs get in trouble is through _not verifying_,
e.g., (to pick a dramatic example) thinking 'OK, I messed around with
some startup scripts, but, no, I needn't bother carry out a test boot to
make sure the system's OK.  Surely it'll be fine.  What could go wrong?'  

If the desired outcome state is 'System must boot in X specific
fashion', then logically the task must include reboot to verify
successful outcome as specified -- otherwise, according to my
department's guidelines, the task hasn't been completed and is still
open.  (Worst case, system might not even boot at all, and you might
learn this hard lesson at any unplanned future time.  Bad.  This
actually happened on a critical Internet server, and yes, it was a
junior SA who'd done it ~a week before.  We then had another talk about
'It's not done until it's verified', and about task definition.)

> I don't understand what exactly is done by piping mount (or umount)
> into grep sdc.

I hope my explanation clarifies.

> I would have used dd rather than cp- I was under the impression that
> cp only copies files, not 'bare metal' data.

Don't forget that one of the central conceits of Unix is that
_everything_ is a file, including block devices like /dev/sdc .  But
sure, you could use dd, if you preferred.

I just happened to have recently skim-read a Debian doc about installing
from a flash drive, and it used cp.  (The page, as quoted below, also
adds a 'sync' command to make sure the write cache is flushed out to the
hardware.  Yeah, really good idea.)
https://www.debian.org/releases/jessie/amd64/ch04s03.html.en Quoting:

  The CD or DVD image you choose should be written directly to the USB
  stick, overwriting its current contents. For example, when using an
  existing GNU/Linux system, the CD or DVD image file can be written to a
  USB stick as follows, after having made sure that the stick is
  unmounted:

  # cp debian.iso /dev/sdX
  #  sync

  [...]
  Important: The image must be written to the whole-disk device and not a
  partition, e.g. /dev/sdb and not /dev/sdb1. Do not use tools like
  unetbootin that alter the image.

-- 
Cheers,                "It's easier to act your way into a new way of thinking
Rick Moen              than think your way into a new way of acting."
rick at linuxmafia.com                        -- Jerry Sternin 
McQ! (4x80)


More information about the talk mailing list