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
