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
