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

Re: Some help with dd backing up into an iso



Hi,

i wrote:
> > bunzip2 <usbfilename.img | dd of=/dev/sdb

GiaThnYgeia wrote:
> bunzip2 imagefile | dd of=/dev/sdb

The small but decisive difference is the "<" in my example.

My example gives bunzip2 no file path, so that it begins to read from
standard input and writes to standard output. bunzip2's standard
input is redirected from file "imagefile". The standard output of
bunzip2 is then piped to standard input of dd, which due to lack of
option "if=" reads it. dd option "of=" then directs the data to /dev/sdb,
the USB stick's device file.

Your command gives bunzip2 the file path "imagefile" which means that
you want this file to be uncompressed. Any standard output from bunzip2
is piped to to dd which would copy it to /dev/sdb.
But i guess there were no bytes written to bunzip's standard output.


> it unzipped the imagefile into an uncompress file

The man page iof bzip2 says:
"bunzip2 (or bzip2 -d) decompresses all specified  files.
 ...
 As  with  compression, supplying no filenames causes decompression from
 standard input to standard output."


> and burned it ...

The file ? The USB stick ?
Not with flames and smoke, i hope ...


> bunzip2 imagefile  -f -t -v | dd of=/dev/sdb

Well, option -t means:
  -t --test
      Check  integrity  of the specified file(s), but don't decompress
      them.  This really performs a  trial  decompression  and  throws
      away the result.

So this run did nothing, i suppose.

In what state is "imagefile" now ? Compressed ? Uncompressed ? Ashes ?
(It is preferrable to marke bzip2'ed files by suffix .bz2, which bunzip2
 will remove when replacing the compressed file by the decompressed file.)


> $ ls -ld /mnt/u*
> drwxr-xr-x 2 root root 4096 Nov 24 11:14
> /mnt/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1

I simply have no clue why "xorriso -follow param" would then complain
about a (one single) file with a newline character in its path:
  /media/user/DebonUSB
  /usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1


> >> xorriso : FAILURE : Cannot determine attributes of source file
> >> '/media/user/DebonUSB
> >> /usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1'

> > Is the line break between "DebonUSB" and "/usb-Kingston" visible on the
> > terminal screen, too ? Or is it an artefact of copy+paste ?

> I changed it so it is easier to deal with

This is not an answer to my question.
Is the reported address a single line
  /media/user/DebonUSB/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1
or is it reported as two lines:
  /media/user/DebonUSB
  /usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1
?

The reason why i ask is that i wonder from where xorriso has this
strange two-line path.
It would be explainable if you had given it to xorriso command "-map".

(The theory that it might be a symbolic link effect is dead meanwhile.)

---------------------------------------------------------------------

New approach to get to a mount point of the stick:

If you do

  find /media/user/sid | less

while the stick is plugged in, do you see all the many file paths from
the stick ?
(No need to count them all. Just check whether it looks roughly like
the expected content.)

If so, then try that address instead of the lengthy one:

  xorriso \
  -for_backup \
  -outdev usb_part1.iso \
  -map /media/user/sid /


Have a nice day :)

Thomas


Reply to: