Re: Some help with dd backing up into an iso
Thomas Schmitt:
> 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 fault, I thought it was brackets to remind me to enter my own
filename and the second one was missing ;)
> 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.
Makes perfect sense now!
> 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.
I tried to improvise to get it to work in between "sessions" and I
couldn't see what it was doing so I can correct it. A long time to wait
for 0 output.
>> it unzipped the imagefile into an uncompress file
>
> The man page iof bzip2 says:
> "bunzip2 (or bzip2 -d) decompresses all specified files.
Going back and forth in help documents I realized this although I have
learned to not assume much.
> As with compression, supplying no filenames causes decompression from
> standard input to standard output."
...aka screen dump?
>> and burned it ...
>
> The file ? The USB stick ?
> Not with flames and smoke, i hope ...
It got really close to being recycled ... :)
>> 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.
Yeap!
> 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.)
Now it is at the state of being all thrown to trashcan (too big for it
so it gets deleted permanently) and a new project will begin sometime
next week ....
>> $ 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
I think it was that dreadful Calamares installer that came with this sid
distro that locks onto the disk and prevents ovewriting.
But when I tried to install it in a small partition of the disk and used
its installation option of encrypting .... guess what? It took the
passphrase and when it was done I entered it like there was no
encryption at all ... I thought it would go somehow in the grub menu
and ask me for a pass to boot it, it ruined my grub, it would boot up
directly not giving me an option for the other installations, and go
straight into the login screen.
But the usb was so hard locked that gparted would erase its partition,
change the file system, rechange and repartition, and the thing was
still there. So I burned a debian installation disk on it, then
repaired everything on hd, and deleted any evidence (I think) that
siduction even came close to the system.
>>>> 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
> ?
No it is all connected line and I don't think I can change this. But so
much for the serial number theory as two different disks have the same
exact address. That gets really confusing if you don't change the
labels on them.
> 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".
So are you saying the problem may lie in the name length that xorriso
can't handle?
> (The theory that it might be a symbolic link effect is dead meanwhile.)
the question I have is if this is ....part1 where is the other part/s?
> 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 /
I will report back as I am fried for the day ...
drwxr-xr-x 3 root root 4096 Mar 12 16:23
/mnt/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1
xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project.
Drive current: -outdev 'usb_part1.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 451g free
xorriso : UPDATE : 6000 files added in 1 seconds
xorriso : UPDATE : 13800 files added in 2 seconds
xorriso : UPDATE : 24000 files added in 3 seconds
xorriso : UPDATE : 32400 files added in 4 seconds
xorriso : UPDATE : 36400 files added in 5 seconds
xorriso : UPDATE : 36500 files added in 7 seconds
xorriso : UPDATE : 36900 files added in 8 seconds
xorriso : UPDATE : 37700 files added in 12 seconds
xorriso : UPDATE : 38600 files added in 14 seconds
xorriso : UPDATE : 41700 files added in 15 seconds
xorriso : UPDATE : 47300 files added in 18 seconds
xorriso : UPDATE : 49200 files added in 20 seconds
xorriso : UPDATE : 58300 files added in 21 seconds
xorriso : UPDATE : 65300 files added in 22 seconds
xorriso : UPDATE : 71400 files added in 23 seconds
xorriso : UPDATE : 80900 files added in 24 seconds
xorriso : UPDATE : 93500 files added in 25 seconds
xorriso : UPDATE : 105000 files added in 26 seconds
xorriso : UPDATE : 116500 files added in 28 seconds
xorriso : FAILURE : Cannot open as source directory:
'/media/user/sid/lost+found'
xorriso : UPDATE : 127528 files added in 29 seconds
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
No file created
But sid is only the mountable partition of the disk where the system is.
There is the swap partition (empty) and I assume some hidden stuff at
the beggining of the disk, not?
> Have a nice day :)
> Thomas
You have one too! ;)
kAt
--
"The most violent element in society is ignorance" rEG
Reply to: