🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.os.bsd
Article #21148

Re: mkuzip - skąd infile

#21148
From: Bodek
Date: Mon, 18 Jan 2010 20:21
125 lines
5847 bytes
at Mon 18 of Jan 2010 12:40, PetruS wrote:

> Bodek wrote:
> 
>> at Tue 12 of Jan 2010 01:42, Bodek wrote:
>> 
>> ...
>> 
>>> Właściwie źle zadałem pytanie. Mój problem to:
>>> jest bootowalny pendrive z obrazem CD na jednej
>>> z partycji, rozpakowywanym podczas bootowania.
>>> I właśnie ten obraz CD chciałem zmodyfikować.
>>> i z powrotem wrzucić na pendrive.
>> 
>> Pierwsze co się narzucało to mkisofs.
>> Jakby nie było narzędzie do tworzenia obrazu CD.
>> Czyli 'mkisofs -o obraz.iso drzewko'
>> Stworzyłem więc obraz drzewka podkartotek obraz.iso.
>> Po spakowaniu pliku obraz.iso powstał obraz.uzip.
>> Ale po rozpakowaniu obraz.uzip czyli utworzeniu /dev/md.uzip
>> zamiast drzewka powstawał plik obraz.iso.
>> 
>> Dzisiaj powtarzam jeszcze raz i jest mniej więcej OK.
>> Po dodaniu dodaniu jednego parunastowego pliku do drzewka
>> obraz powiększył się o parę megabajtów, nazwy skopane itp
>> ale to da się naprawić - kosmetyka.
>> 
>> Dlaczego poprzednim razem było źle? Trzeba uważać z mdconfig.
>> Jeśli tworzonego obrazu nie wyzeruje się, dzieją się dziwne
>> rzeczy, np z pliku 500 MB, wydawałoby się powstanie mdysk
>> około 500 MB. A bywa, że jest 130 MB tak jak któryś, utworzony
>> wcześniej. Poza tym, jak mówiłem o CD i kopiowaniu z CD,
>> to ten CD nie był faktyczny ale właśnie mdysk z obrazu,
>> i na nim był plik, z którego był tworzony następny mdisk.
> 
> Jeśli chcesz używać obrazu iso jako uzip, to powinieneś zrobić tak:
> 
> # mkuzip -o obraz.uzip obraz.iso

Z tym nie mam najmniejszego problemu. Problem jak w subject,
czyli skąd wziąć obraz.iso, raz się nie udało z powodu
zagnieżdżenia kolejnych memory disk. Reszta tak rutynowa, 
że poza aliasami utworzonymi lata temu niczego innego
nie używam.

> 
> Następnie zamontować podobnie jak montuje się zwykły obraz iso:
> 
> mount_cd9660 /dev/`mdconfig -af obraz.uzip`.uzip /mnt

Składnię można podejrzeć przeglądając zawartość obraz.uzip
i teoretycznie wystarczyłoby:
 ./obraz.zip
praktycznie nie działa, bo albo nie montuje, albo gubi się
na 'kldstat', więc trzeba montować ręcznie.

Teraz został mały problem, też związany z tematem tego wątku.
Jak utworzyć obraz.iso, tak aby nie spuchł o kilkanaście
procent objętości.

Na konkretnym przykładzie. Mamy:
 http://frenzy.bspu.ru/frenzy/iso/frenzy-1.2-reincarnation-mini-en-release.iso
z tego pliku wyłuskujemy plik frenzy.uzip. Następnie frenzy.uzip 
rozpakowujemy, montujemy jako CD o takiej zawartości: 

#ls -lF /mnt/v
total 85
-rw-r--r--   1 root  wheel    798 10 Jan 09:50 .cshrc
-rw-r--r--   1 root  wheel    265 10 Jan 09:50 .profile
-r--r--r--   1 root  wheel   6206 10 Jan 09:50 COPYRIGHT
drwxr-xr-x   2 root  wheel   6144 10 Jan 09:59 bin/
drwxr-xr-x   7 root  wheel   4096 10 Jan 09:59 boot/
dr-xr-xr-x   2 root  wheel   2048 10 Jan 09:57 dev/
drwxr-xr-x  20 root  wheel  12288 10 Jan 09:59 etc/
drwxr-xr-x   3 root  wheel   8192 10 Jan 09:53 lib/
drwxr-xr-x   2 root  wheel   2048 10 Jan 09:52 libexec/
drwxr-xr-x   2 root  wheel   2048 10 Jan 09:50 media/
drwxr-xr-x   5 root  wheel   2048 30 Nov 21:42 mnt/
dr-xr-xr-x   2 root  wheel   2048 10 Jan 09:50 proc/
drwxr-xr-x  10 root  wheel   6144  7 Jan 19:35 root/
dr-xr-xr-x  80 root  wheel  10240 10 Jan 09:59 rr_moved/
drwxr-xr-x   2 root  wheel  14336 10 Jan 09:59 sbin/
drwxrwxrwt   2 root  wheel   2048 10 Jan 09:59 tmp/
drwxr-xr-x   9 root  wheel   2048 10 Jan 09:59 usr/
drwxr-xr-x  24 root  wheel   4096 10 Jan 09:59 var/

#du -sh /mnt/v
175M    /mnt/v

Aby poprawić coś z tej zawartości, trzeba całość
skopiować na HD. Otrzymujemy takie coś:

#ls -lF /5/v
total 40
-rw-r--r--   1 root  wheel   798 10 Jan 09:50 .cshrc
-rw-r--r--   1 root  wheel   265 10 Jan 09:50 .profile
-r--r--r--   1 root  wheel  6206 10 Jan 09:50 COPYRIGHT
drwxr-xr-x   2 root  wheel  1024 10 Jan 09:59 bin/
drwxr-xr-x   7 root  wheel   512 10 Jan 09:59 boot/
dr-xr-xr-x   2 root  wheel   512 10 Jan 09:57 dev/
drwxr-xr-x  20 root  wheel  2048 10 Jan 09:59 etc/
drwxr-xr-x   3 root  wheel  1536 10 Jan 09:53 lib/
drwxr-xr-x   2 root  wheel   512 10 Jan 09:52 libexec/
drwxr-xr-x   2 root  wheel   512 10 Jan 09:50 media/
drwxr-xr-x   5 root  wheel   512 30 Nov 21:42 mnt/
dr-xr-xr-x   2 root  wheel   512 10 Jan 09:50 proc/
drwxr-xr-x  10 root  wheel  1024  7 Jan 19:35 root/
 [rr_moved skasowane ręcznie dla potrzeb przyszłego mkisofs]
drwxr-xr-x   2 root  wheel  2048 10 Jan 09:59 sbin/
drwxrwxrwt   2 root  wheel   512 10 Jan 09:59 tmp/
drwxr-xr-x   9 root  wheel   512 10 Jan 09:59 usr/
drwxr-xr-x  24 root  wheel   512 10 Jan 09:59 var/

#du -sh /5/v
195M    /5/v


Rzuca się w oczy różnica objętości drzewa plików
i liczba bloków systemu plików. 
Pytanie - jak zminimalizować tę różnicę objętości
drzewa plików?


-- 
Bodek
Technical Details
Message-ID: <hj2frq$3e7$1@news.dialog.net.pl>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.gazeta.pl!newsfeed.pionier.net.pl!news.nask.pl!news.nask.org.pl!news.task.gda.pl!news.dialog.net.pl!not-for-mail
References: <hicpra$9v2$1@news.dialog.net.pl> <hif0tk$frr$1@news.onet.pl> <higgic$di0$1@news.dialog.net.pl> <hihmog$t1$1@news.dialog.net.pl> <hj1hd3$lm3$1@news.onet.pl>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.gazeta.pl!newsfeed.pionier.net.pl!news.nask.pl!news.nask.org.pl!news.task.gda.pl!news.dialog.net.pl!not-for-mail
From: Bodek <nbody@nowhere.net>
Newsgroups: pl.comp.os.bsd
Subject: Re: mkuzip - skąd infile
Date: Mon, 18 Jan 2010 21:21:18 +0100
Organization: Dialog Net
Lines: 126
Message-ID: <hj2frq$3e7$1@news.dialog.net.pl>
References: <hicpra$9v2$1@news.dialog.net.pl> <hif0tk$frr$1@news.onet.pl> <higgic$di0$1@news.dialog.net.pl> <hihmog$t1$1@news.dialog.net.pl> <hj1hd3$lm3$1@news.onet.pl>
NNTP-Posting-Host: dynamic-78-8-129-238.ssp.dialog.net.pl
Mime-Version: 1.0
X-Trace: news.dialog.net.pl 1263846075 3527 78.8.129.238 (18 Jan 2010 20:21:15 GMT)
X-Complaints-To: abuse@dialog.net.pl
NNTP-Posting-Date: Mon, 18 Jan 2010 20:21:15 +0000 (UTC)
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit