🚀 go-pugleaf

Bodek wrote:

> Man do mkuzip(8) podaje
> mkuzip [-v] [-o outfile] [-s cluster_size] infile
> 
> Gdzie infile to obraz dysku.
> Jak powstaje ten obraz dysku?

Obraz ten może powstawać w różny sposób.
Dla LiveCD powstaje zazwyczaj tak:

1) tworz się plik obrazu, np. za pomocą dd

# dd if=/dev/zero of=plik_obrazu bs=1M count=256

2) tworzy się "RAMdysk" używając pliku obrazu:

# mdconfig -a -t vnode  -f plik_obrazu

3) tworzy się system plików na "RAMdysku" (mdconfig podało md0)

# newfs /dev/md0

4) montuje się obraz pliku:

# mount /dev/md0 /mnt

5) zapisuje się na tym dysku dane (np. instaluje się soft)

6) odmontowuje się obraz i zwalnia RAMdysk

# umount /dev/md0 && mdconfig -du 0

Gotowe!

> Problem się wziął z próby modyfikacji liveCD.
> Rozpakować *.uzip da się łatwo, ale jak z powrotem
> spakować?

Po rozpakowaniu musisz zamontować obraz jak w punktach 2) i 4) powyżej, 
potem zmodyfikować zawartość obrazu (dodać/usunąć soft/konfigurację...)

Następnie musisz odmontować obraz i zwolnić zasób jak w punkcie 6),
a potem spakować w obraz w uzip-a.

# mkuzip -o plik.uzip plik_obrazu

I powinno być.

-- 
Piotr Sietnik
s i e t p [@] p o c z t a [na] . o n e t . p l

at Mon 11 of Jan 2010 12:09, PetruS wrote:

> Bodek wrote:
> 
>> Man do mkuzip(8) podaje
>> mkuzip [-v] [-o outfile] [-s cluster_size] infile
>> 
>> Gdzie infile to obraz dysku.
>> Jak powstaje ten obraz dysku?
> 
> Obraz ten może powstawać w różny sposób.
> Dla LiveCD powstaje zazwyczaj tak:
> 
> 1) tworz się plik obrazu, np. za pomocą dd
> 
> # dd if=/dev/zero of=plik_obrazu bs=1M count=256
> 
> 2) tworzy się "RAMdysk" używając pliku obrazu:
> 
> # mdconfig -a -t vnode  -f plik_obrazu
> 
> 3) tworzy się system plików na "RAMdysku" (mdconfig podało md0)
> 
> # newfs /dev/md0
> 
> 4) montuje się obraz pliku:
> 
> # mount /dev/md0 /mnt
> 
> 5) zapisuje się na tym dysku dane (np. instaluje się soft)
> 
> 6) odmontowuje się obraz i zwalnia RAMdysk
> 
> # umount /dev/md0 && mdconfig -du 0
> 
> Gotowe!
> 
>> Problem się wziął z próby modyfikacji liveCD.
>> Rozpakować *.uzip da się łatwo, ale jak z powrotem
>> spakować?
> 
> Po rozpakowaniu musisz zamontować obraz jak w punktach 2) i 4)
> powyżej, potem zmodyfikować zawartość obrazu (dodać/usunąć
> soft/konfigurację...)

Nie mogę modyfikować bo montuję jako CD.
Ale całe drzewko mogę skopiować na HD poczym odmontować CD.
Następnie poprawiam drzewko na dysku, szacuję pojemność drzewka
(np 'du -sh'), zakładam plik kilka procent większy od oszacowanego,
tworzę ramdysk... i właśnie tutaj utknąłem. Przed punktem 3
robiłem niepotrzebnie bsdlabel. To się wzięło z rutynowego
przerabiania obrazów CD na pamięci USB - ludziska gały wytrzeszczały
jak zobaczyły, że bootuję kompa z aparatu fotograficznego ;-)


> Następnie musisz odmontować obraz i zwolnić zasób jak w punkcie 6),
> a potem spakować w obraz w uzip-a.
> 
> # mkuzip -o plik.uzip plik_obrazu
> 
> I powinno być.


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.

Dzięki za naprowadzenie!
Mam nadzieje, że to zadziała.

-- 
Bodek

at Tue 12 of Jan 2010 01:42, Bodek wrote:



> Dzięki za naprowadzenie!
> Mam nadzieje, że to zadziała.

Nie zadziałało. Na razie odpuszczam, bo właśnie zasysam
nowa wersja frenzy, która zapewne załatwi to co chciałem
podmienić. Rosyjska wersja lite sprzed dwóch tygodni
była bardzo obiecująca..


-- 
Bodek

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.



-- 
Bodek

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

Następnie zamontować podobnie jak montuje się zwykły obraz iso:

mount_cd9660 /dev/`mdconfig -af obraz.uzip`.uzip /mnt

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

Bodek wrote:

> at Mon 18 of Jan 2010 12:40, PetruS wrote:
> 
>> Bodek wrote:
>> 
>> 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.

Nie montuje się, bo trzeba jeszcze dodać punkt montowania:

# ./obraz.uzip /mnt

> 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/
> [...]
> #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/
> [..]
> 
> #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?

Rozumiem, że ten pierwszy du był robiony na zamontowanym CD,
a ten drugi na HD?

A co daje polecenie:

# du -shA /mnt/v /5/v

Który teraz jest większy? ;)

Zrób mkisofs dla katalogu na dysku, zamontuj obraz i porównaj wyniki du.
Zdaduję: będą "takie same" jak dla obrazu frenzy.uzip (/mnt/v) wyżej.

-- 
Piotr Sietnik
s i e t p [@] p o c z t a [na] . o n e t . p l

at Tue 19 of Jan 2010 11:48, PetruS wrote:

> Bodek wrote:
> 
>> at Mon 18 of Jan 2010 12:40, PetruS wrote:
>> 
>>> Bodek wrote:
>>> 
>>> 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.
> 
> Nie montuje się, bo trzeba jeszcze dodać punkt montowania:
> 
> # ./obraz.uzip /mnt
> 
>> 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/
>> [...]
>> #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/
>> [..]
>> 
>> #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?
> 
> Rozumiem, że ten pierwszy du był robiony na zamontowanym CD,
> a ten drugi na HD?

Oczywiście.


> A co daje polecenie:
> 
> # du -shA /mnt/v /5/v
> 
> Który teraz jest większy? ;)

Proszę bardzo:
#du -shA /mnt/v /5/v
183M    /mnt/v
179M    /5/v

Ten na dysku jest nawet mniejszy (wykasowane rr_moved)

> Zrób mkisofs dla katalogu na dysku, zamontuj obraz i porównaj wyniki
> du. Zdaduję: będą "takie same" jak dla obrazu frenzy.uzip (/mnt/v)
> wyżej.

Oczywiście (nie wiem, czemu by miało być inaczej):

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

Ale problem w tym, że obraz iso (z podfolderów
dyskowych na /5/v) spakowany pkuzip-em daje
większy plik i tylko o to mi chodzi:

#ls -hl /tmp/2/
-r-xr-xr-x   1 root  wheel    68M 10 Jan 10:02 frenzy.uzip # oryginalny
-r-xr-xr-x   1 root  wheel    87M 14 Jan 04:24 f2.uzip* # po rozpakowaniu frenzy.uzip i spakowaniu

Reasumując - problem zaczyna się już w momencie kopiowania CD na HD
a kończy na spakowaniu pkuzipem.

Rozwiązanie widzę w niestandardowym utworzeniu file systemu
na HD przed skopiowaniem zawartości CD (tego z obrazu), 
albo niestandardowym tworzeniem obrazu ISO  - używam 
'mkisofs -v -R -U ...', taki alias utworzyłem przed laty 
i zawsze działało jak trzeba. Teraz też nie widzę, jaki
mogłoby to mieć wpływ na puchnięcie pliku wynikowego.


-- 
Bodek

Bodek wrote:

> at Tue 19 of Jan 2010 11:48, PetruS wrote:
> 
>> Bodek wrote:
> Ale problem w tym, że obraz iso (z podfolderów
> dyskowych na /5/v) spakowany pkuzip-em daje
> większy plik i tylko o to mi chodzi:
> 
> #ls -hl /tmp/2/
> -r-xr-xr-x   1 root  wheel    68M 10 Jan 10:02 frenzy.uzip # oryginalny
> -r-xr-xr-x   1 root  wheel    87M 14 Jan 04:24 f2.uzip* # po rozpakowaniu
> frenzy.uzip i spakowaniu
> 
> Reasumując - problem zaczyna się już w momencie kopiowania CD na HD
> a kończy na spakowaniu pkuzipem.
> 
> Rozwiązanie widzę w niestandardowym utworzeniu file systemu
> na HD przed skopiowaniem zawartości CD (tego z obrazu),
> albo niestandardowym tworzeniem obrazu ISO  - używam
> 'mkisofs -v -R -U ...', taki alias utworzyłem przed laty
> i zawsze działało jak trzeba. Teraz też nie widzę, jaki
> mogłoby to mieć wpływ na puchnięcie pliku wynikowego.

Musisz dobrze dobrać parametr -s dla mkuzip.

Polecenie:

# mkuzip -s 1024 -o obraz.uzip obraz.iso

da Ci wiele większy plik wynikowy niż standardowo (bez -s).

Natomiast -s ustawione na maksa (1024 * 128 - 512) da obraz najmniejszy,
ale ciut wolniejszy w użyciu.

Pokombinuj więc z doborem tego parametru.

-- 
Piotr Sietnik
s i e t p [@] p o c z t a [na] . o n e t . p l

at Tue 19 of Jan 2010 15:56, PetruS wrote:

> Bodek wrote:
> 
>> at Tue 19 of Jan 2010 11:48, PetruS wrote:
>> 
>>> Bodek wrote:
>> Ale problem w tym, że obraz iso (z podfolderów
>> dyskowych na /5/v) spakowany pkuzip-em daje
>> większy plik i tylko o to mi chodzi:
>> 
>> #ls -hl /tmp/2/
>> -r-xr-xr-x   1 root  wheel    68M 10 Jan 10:02 frenzy.uzip #
>> oryginalny
>> -r-xr-xr-x   1 root  wheel    87M 14 Jan 04:24 f2.uzip* # po
>> rozpakowaniu frenzy.uzip i spakowaniu
>> 
>> Reasumując - problem zaczyna się już w momencie kopiowania CD na HD
>> a kończy na spakowaniu pkuzipem.

Takie dobre założenia, a kompletnie przeoczyłem 
parametr '-s' w mkuzip :-)

>> 
>> Rozwiązanie widzę w niestandardowym utworzeniu file systemu
>> na HD przed skopiowaniem zawartości CD (tego z obrazu),
>> albo niestandardowym tworzeniem obrazu ISO  - używam
>> 'mkisofs -v -R -U ...', taki alias utworzyłem przed laty
>> i zawsze działało jak trzeba. Teraz też nie widzę, jaki
>> mogłoby to mieć wpływ na puchnięcie pliku wynikowego.
> 
> Musisz dobrze dobrać parametr -s dla mkuzip.
> 
> Polecenie:
> 
> # mkuzip -s 1024 -o obraz.uzip obraz.iso
> 
> da Ci wiele większy plik wynikowy niż standardowo (bez -s).
> 
> Natomiast -s ustawione na maksa (1024 * 128 - 512) da obraz
> najmniejszy, ale ciut wolniejszy w użyciu.
> 
> Pokombinuj więc z doborem tego parametru.

Maksymalny cluster daje w wyniku plik 72 MB, 
wobec 79 przy domyślnym i 68 MB oryginalnego pliku.
Znaczący postęp.
Dzięki!


To już drugi problem w ostatnim czasie, którego rozwiązaniem jest 
zwiększenie wielkości łopaty do przenoszenia danych.
Znaczy wypada potrenować blok-size w newfs. Domyślna 
jego wartość jest taka sama jak cluster w mkuzip :-)


-- 
Bodek

Bodek <nbody@nowhere.net> wrote:
> Man do mkuzip(8) podaje
> mkuzip [-v] [-o outfile] [-s cluster_size] infile
> 
> Gdzie infile to obraz dysku.
> Jak powstaje ten obraz dysku?

zrób sobie albo osobną partycję albo plik i użyj mdconfig

a na nim zrób filesystem jaki chcesz.

opcja 3 chyba najprostsza - zrób filesystem iso9660 używając mkisofs