[conspire] Live Distro on USB

[Rick Moen]

Quoting Paul Zander (paulz at ieee.org):

> Yet another update. I have narrowed the problem further.

Yes, perhaps.  I'm trying to spend at least a few minutes trying to
think this through in advance of the CABAL meeting:  The problem with 
'I'll just get help with this at a LUG meeting', in the case of
difficult problems, is that sometimes everyone else at the LUG meeting is
starting exactly where you are -- and then the hustle and noise of LUG
venues becomes a problem.

Some problems are best cracked by quiet thinking and Internet research.

Anyway:  You have ISOs.  You have (some sorts of) USB-connectable
mass-storage drives.  Following perfectly sensible online instructions
from a Debian FAQ, you install an ISO onto a CD drive using dd.  OK so
far.

Something I noticed:  

> CHECK DEVICES WITHOUT USB DRIVE
> $: ls -l /dev/sd[h-l]* 
> 
> INSERT USB DRIVE 
> $: ls -l /dev/sd[h-l]* 
> brw-rw---- 1 root disk   8, 128 Feb 21 11:59 /dev/sdi 
> brw-rw---- 1 root disk   8, 129 Feb 21 11:59 /dev/sdi1 
> USB DRIVE IS /dev/sdi

I surmise from the above that you determined the USB drive to be
/dev/sdi by noting creation of device nodes /dev/sdi and /dev/sdi1
(by udev) immediately after you attached the drive.  Hmm, that's
commendably empirical of you, and probably fine -- but FWIW isn't the
way I'd recommend.

'dmesg | tail' will show you the bottom ten lines of dmesg output
(stuff in /var/log/dmesg), and that will give you confidence that the
/dev/sd?? information shown is right, if only because it'll include the
make/model of hardware in question.

> /var/log/dmesg doesn't have any related entries

Really?   You're sure?  There are always entries when the kernel's
autoprobing code recognises a piece of hardware, modprobes the relevant
driver, and discovers contents on the device.

It wouldh't have occurred to me to watch for autopopulation of /dev
device nodes because of my old-school years of experience where /dev is
a static tree.

I quoted the above line out of context from the end of your posting.
To clarify, I infer that you mean there are no entries concerning the
USB drive to which you dd'd the Debian ISO (upon connecting the USB
drive.

Irrespective of what contents a USB drive has, including no contents at
all or gibberish contents, connecting it to a running Linux system
should result in dmesg entries, because, gosh, it's a mass-storage-type
USB drive.  Which means the kernel should immediately assign it a
/dev/sdX device node and then probe it to find anything that the kernel
recognises as a partition.


Anyway, back the thing I noticed:  Your notes reveal this USB drive to
start out as a partitioned drive with VFAT partition /dev/sdi1 -- but
then you do (simplifying):

# dd if=linuxmint-17.1-cinnamon-64bit.iso of=/dev/sdi

Not /dev/sdi1, but rather /dev/sdi .  In other words, right at the front
of the drive, overwriting the partition table and everything else.  And
I'm not at all saying that's wrong.  I'm just trying to pay close
attention.

Immediately after that, udevd enforces the existence of device nodes
/dev/sdi, /dev/sdi1, and /dev/sdi2, and your desktop environment's
automounter duly mounts /dev/sdi1 as a filesystem of type iso9660 (CD
format):

> REINSERT USB DRIVE 
> PACMAN FILE MANAGER OPENS DIALOG BOX ASKING TO MOUNT THE FILE 
> $: ls -l /dev/sd[h-l]* 
> brw-rw---- 1 root disk   8, 128 Feb 21 13:14 /dev/sdi 
> brw-rw---- 1 root disk   8, 129 Feb 21 13:14 /dev/sdi1 
> brw-rw---- 1 root disk   8, 130 Feb 21 13:14 /dev/sdi2 
> 
> $: mount | grep sdi 
> /dev/sdi1 on /media/paulz/Linux Mint 17.1 Cinnamon 64-bit type iso9660
> (ro,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,mode=0400,dmode=0500,uhelper=udisks2) 

Again, I wouldn't be relying on udevd to tell me about the existence and
nonexistence of devices.  I'd be looking at dmesg to observe them being
parsed and dealt with by the kernel.

I also would _personally_ prefer to mount filesystems myself, for a lot
of reasons including being in greater control and being more confident
in my knowledge of what's going on.  OTOH, automounters invariably are
part of the DE (desktop environment) bundle, and I guess they're part of
what DE users are seeking.

The above makes me wonder what is on /dev/sdi2 and what _it_ is for,
though.  Maybe this is GPT stuff and one of these is the EFI System
Partition?

And that reminds me:  You reported that the DE automounter mounted the
Linux Mint /deve/sdi1 as type iso9660, but personally I'd have also
looked at the contents.  Like with ls, and like that.  And I've have
tried to figure out what /dev/sdi2 was, and mounted it if it were a
reasonable filesystem, to see what the contents are.

(Update:  I see in your second, follow-up post, you did 'ls' the
/dev/sdi1 iso9660 partition, revealing it to have EFI stuff.  But you
didn't look into the contents of /dev/sdi2.)

About connecting the USB drive with the Debian iso contents dd'd onto
it:

> REMOVE DRIVE, WAIT, RE-INSERT.  NOT RECOGNIZED 
> 
> $: ls -l /dev/sd[h-l]* 

I'm guessing you mean seeing no previously-not-there device node
/dev/sdX, when you say 'drive... not recognized'.

Again, the procedure I would use is:

1.  See new entries in dmesg output revealing what /dev/sdX nodes just
got assigned to newly-noticed software.  This should happen
irrespective of what is on the drive.  If Linux also recognises 
things _on_ the mass storage device in question, then there will be more
information echoed, e.g., listing entries in any observed partition
table.

2.  Armed with the /dev/sdX identity and (if found) /dev/sdXN partition
device nodes, you can try to mount partitions (if partition entries were
found), which of course works only if there are both partition table
entries and an actual filesystem present.  Or you could do 'fdisk
/dev/sdX' to examine the partition table directly.

Immeidately foregoing passage assumes an old-school IBM/Microsoft aka
MBR partition table.  /sbin/fdisk can't parse an Intel GPT (GUID
Partition Table).  For a GPT, you'd need to switch to parted, or some
similar GPT-aware tool.

GPT is A Good Thing if you are using very large drives and very large
partitions.  Personally, I've managed to avoid its complications so far.


By the way, not that it matters a lot, but in referring to 'USB drives',
you have been leaving unclear whether these are hard drives or
flash-stype thumb drives.  (I suspect the latter.)


> Well the problem is related to the laptop (probably the BIOS.) 

Well, yes, I was thinking that was a strong possibility.

There's a reason why it's difficult to debug '[thing x] won't boot'
problems:  Any of a large number of suspects could be at fault, there's
essentially no logging, and it's difficult or impossible to break the
process down into stages to test each one separately.