Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #178620 > unrolled thread

Re: Some help with dd backing up into an iso

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Some help with dd backing up into an iso "Thomas Schmitt" <scdbackup@gmx.net> - 2017-03-09 17:40 +0100
    Re: Some help with dd backing up into an iso David Wright <deblis@lionunicorn.co.uk> - 2017-03-09 19:00 +0100

#178620 — Re: Some help with dd backing up into an iso

Hi,

GiaThnYgeia wrote:
> /mnt/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1

Although it is ugly, i guess it is reproducible whenever you plug in
that stick and other sticks get other reproducible addresses.
(Better test whether the address is indeed the same each time.)


> How safe is it to relabel these to something more common and logical?

I assume the ugly one is created automatically.
Is it a symbolic link to something else, perhaps ?
This will tell after "->" a possible link target:
  ls -l /mnt/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1

In any case, i would rather create a symbolic link with a convenient name.
E.g. by

  ln -s /mnt/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1 /mnt/blue_kingston_1


> I downloaded a system from your neighbors "siduction"

Mind to tell me the URL of the ISO ?

> it does not register.

Register = Show up in some EFI boot manager ?

> On this one I added a boot flag on its primary partition and this is how
> it worked.

That's what i read as user report on grub-devel. Some EFIs when presented
an MBR partition table do not recognize the partition of type 0xef if there
is no boot flag on some other partition.
Another known firmware quirk is that some EFIs demand all partitions except
the 0xef partition to have type 0x00.
Debian installation ISOs avoid both pitfalls thanks to Matthew J. Garrett's
original research.

> The other pc is very similar,

What about the firmware's version numbers and release dates ?


> Strange behavior that makes no sense to me.

An EFI implementation has enough brain to outsmart everybody.


Have a nice day :)

Thomas

[toc] | [next] | [standalone]

#178622

I haven't seen the questions…

On Thu 09 Mar 2017 at 17:37:23 (+0100), Thomas Schmitt wrote:
> GiaThnYgeia wrote:
> > /mnt/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1
> 
> Although it is ugly, i guess it is reproducible whenever you plug in
> that stick and other sticks get other reproducible addresses.
> (Better test whether the address is indeed the same each time.)

Looks like you(it) got this out of /dev/disk/by-id/, made up of

access method (for want of a better term)
manufacturer
product
serial number

so you shouldn't run into uniqueness problems until you insert
real noname stuff like the cheapest mp3 players, and most of those
may have packed up by now, as mine have.

> > How safe is it to relabel these to something more common and logical?
> 
> I assume the ugly one is created automatically.
> Is it a symbolic link to something else, perhaps ?
> This will tell after "->" a possible link target:
>   ls -l /mnt/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1
> 
> In any case, i would rather create a symbolic link with a convenient name.
> E.g. by
> 
>   ln -s /mnt/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1 /mnt/blue_kingston_1

Was this stick automounted? Can the automounter be configured to
use something that's under your control, eg, look at /dev/disk/by-label/
or /dev/disk/by-uuid. Their contents (and uniqueness) are in your
hands. (by-path will vary by where you stick the stick.)

If you have (relatively) few sticks, labels are the neatest.
For bulk purchases, uuid might be better, unless you get a
batch where the FAT partition is cloned and the uuids likewise.

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web