Hi,
is there a way to obtain the address of the disk-like device from which
Debian Live has booted ?
I would need shell commands with unambiguous outcome which surely list
the device address, if it is a disk-like device. Optical drives are not
of interest, but would not harm. They can be filtered out by the consumer
of the commands' output.
The overall goal is to make a script which proposes target candidates for
copying an ISO image file to a USB stick or memory card.
Of course it would be very undesirable if the script would choose the
device from which a Live system has booted and where it might have its
persistence filesystem.
Conventional system disks can be excluded by the kind of filesystems they
bear, or by the type of bus by which they are connected. But a Debian Live
stick intrinsically matches the description of a valid target device.
Given the eagerness of automounters i cannot use the mount status of the
candidate device as decisive criterion.
--------------------------------------------------------------------------
Examples of what the script does for now (mainly by help of lsblk):
$ xorriso-dd-target -with_sudo \
-image_file debian-live-10.0.0-amd64-xfce.iso \
-list_all
sda : NO : not_usb- has_vfat+ has_ext4- : ATA Samsung SSD 850
sdb : NO : not_usb- has_swap- has_ext4- : ATA WDC WD20EFRX-68A
sdc : YES : usb+ has_iso9660+ has_vfat+ : Intenso Ultra Line
sdd : NO : has_iso9660+ has_vfat+ has_ext2- : SanDisk Cruzer
sde : NO : has_iso9660+ has_vfat+ size_too_small- : INTENSO USB
When the recognition is trustworthy enough, i plan to enable this:
$ xorriso-dd-target -with_sudo \
-image_file debian-live-10.0.0-amd64-xfce.iso \
-DO_WRITE
sdc
Would do: sudo /bin/umount /dev/sdc /dev/sdc1 /dev/sdc2
Would do: sudo /bin/dd if='debian-live-10.0.0-amd64-xfce.iso' bs=1M
of=/dev/sdc ; sync
This will come to action only if exactly one candidate is found:
$ xorriso-dd-target -with_sudo \
-image_file debian-live-10.0.0-amd64-xfce.iso \
-look_for_iso \
-DO_WRITE
sdc
sdd
WILL NOT WRITE ! More than one candidate found for target device:
sdc : YES : usb+ has_iso9660+ has_vfat+ look_for_iso++ : Intenso Ultra Line
sdd : YES : usb+ has_iso9660+ has_vfat+ has_ext2- look_for_iso++ : SanDisk
Cruzer
HINT: Unplug the unwanted devices from the machine,
or add the desired name out of {sdc,sdd} as additional argument.
Following the hint:
$ xorriso-dd-target -with_sudo \
-image_file debian-live-10.0.0-amd64-xfce.iso \
-look_for_iso \
-DO_WRITE \
sdc
sdc : YES : usb+ has_iso9660+ has_vfat+ look_for_iso++
Would do: sudo /bin/umount /dev/sdc /dev/sdc1 /dev/sdc2
Would do: sudo /bin/dd if='debian-live-10.0.0-amd64-xfce.iso' bs=1M
of=/dev/sdc ; sync
Unfug is not allowed:
$ xorriso-dd-target -with_sudo \
-image_file debian-live-10.0.0-amd64-xfce.iso \
-look_for_iso \
-DO_WRITE \
sda
sda : NO : not_usb- has_vfat+ has_ext4- no_iso9660-
NO CANDIDATE FOR TARGET DEVICE AMONG THE GIVEN NAMES !
Overall available devices:
sda : NO : not_usb- has_vfat+ has_ext4- no_iso9660- : ATA Samsung SSD 850
sdb : NO : not_usb- has_swap- has_ext4- no_iso9660- : ATA WDC WD20EFRX-68A
sdc : YES : usb+ has_iso9660+ has_vfat+ look_for_iso++ : Intenso Ultra Line
sdd : YES : usb+ has_iso9660+ has_vfat+ has_ext2- look_for_iso++ : SanDisk
Cruzer
sde : NO : has_iso9660+ has_vfat+ look_for_iso++ size_too_small- : INTENSO
USB
--------------------------------------------------------------------------
Script text online:
https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/xorriso-dd-target/xorriso-dd-target
Reasons why i do not write this in C:
- lsblk -o TRAN is a smart piece of software, depending much on kernel
aspects.
- Restricting superuser power to the commands which really need it
is desirable but not a simple task in C.
- A C program would have to depend on libblkid directly.
The structure of script xorriso-dd-target looks more like BASIC than like
elaborate shell.
I would not deem an equivalent C program more readable than the script.
My main fear is that sudo can be talked into doing something unexpected
and the user can be tricked into authorizing this by the password.
(Sudo without password or running as superuser would offer easier ways to
do unwanted things.)
I will try to find shell experts who can review the script for this danger.
Have a nice day :)
Thomas
