On 07/01/2010 06:57 PM, Pascal wrote:
Hi,
I'm using archiso: very good job! Oh yes works very well, but is not my job, I am just a eventually contributor. When you do an apropos something in the iso, there's no result... So in my makefile there's a chroot $(WORKDIR)/root-image /usr/bin/mandb -qc
May be directly in archiso...
That is true. But there is one issue with iso images sizes (core-dual.iso) 1) current (2010.05) official media is 659MB, so addding "1.7MB+compression" is not an issue. 2) current (today generated images 2010.07.01) is 702MB!. Size is over 2MB of the allowed limit for a CD-ROM, adding more data become a problem++. Anyway if big size is a problem for next iso, I think that dual images need to be generated with archiso2dual "-T split" instead of (like now) "-T basic" (man-db -qc can be run inside the live environment, just take about 1 minute) CC: to arch-releng to notify about space issue for next snapshot images. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Thu, Jul 1, 2010 at 5:54 PM, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 07/01/2010 06:57 PM, Pascal wrote:
Hi,
I'm using archiso: very good job!
Oh yes works very well, but is not my job, I am just a eventually contributor.
When you do an apropos something in the iso, there's no result... So in my makefile there's a chroot $(WORKDIR)/root-image /usr/bin/mandb -qc
May be directly in archiso...
That is true. But there is one issue with iso images sizes (core-dual.iso)
1) current (2010.05) official media is 659MB, so addding "1.7MB+compression" is not an issue. 2) current (today generated images 2010.07.01) is 702MB!. Size is over 2MB of the allowed limit for a CD-ROM, adding more data become a problem++.
Anyway if big size is a problem for next iso, I think that dual images need to be generated with archiso2dual "-T split" instead of (like now) "-T basic"
(man-db -qc can be run inside the live environment, just take about 1 minute)
CC: to arch-releng to notify about space issue for next snapshot images.
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
If I may add my input, I don't know ho the core packages are generated exactly, but theoretically setting xz to the most compressed ratio would mean that it would save more space and shouldn't take that much longer to extract. Basically, the machine generating the packages would be what takes the most time from what I understand (though I could be wrong, if so feel free to correct me :)). Due to this, perhaps core only could be generated with this setting. Just a suggestion. Smartboy
Am 02.07.2010 02:54, schrieb Gerardo Exequiel Pozzi:
On 07/01/2010 06:57 PM, Pascal wrote:
So in my makefile there's a chroot $(WORKDIR)/root-image /usr/bin/mandb -qc
May be directly in archiso...
Careful! Doing that once the ISO has already booted will fail on systems with few memory. Currently, we generate the locales in the live system, and that also fails with less than 128MB memory - and takes quite a long time.
That is true. But there is one issue with iso images sizes (core-dual.iso)
1) current (2010.05) official media is 659MB, so addding "1.7MB+compression" is not an issue. 2) current (today generated images 2010.07.01) is 702MB!. Size is over 2MB of the allowed limit for a CD-ROM, adding more data become a problem++.
Hmm, weird, can you find out what's so big? 702MB is okay for a CD (I think the limit without overburning is 703), but that growth has to come from somwhere.
Anyway if big size is a problem for next iso, I think that dual images need to be generated with archiso2dual "-T split" instead of (like now) "-T basic"
A few things we could/should do: 1) Create separate core-pkgs for i686, x86_64 and any. It's a bit complex to do that, but it'll save some duplication. 2) Add more architecture-independent files from the squashfs to a common squashfs. Also very complex though. 3) Clean the squashfs from files we don't need in the live environment - not sure which, but there might be some. 4) Use lzma for squashing. It is a problem, because that won't be in 2.6.35 and likely neither 2.6.36. However, small and working patches do exist, Linus just rejected them for maintainability and quality reasons. We could have a separate kernel26-archiso which differs from kernel26 just by having squashfs-lzma capability - just until the new lzma compression code is finished.
On 07/02/2010 04:09 AM, Thomas Bächler wrote: > Am 02.07.2010 02:54, schrieb Gerardo Exequiel Pozzi: >> On 07/01/2010 06:57 PM, Pascal wrote: >>> So in my makefile there's a >>> chroot $(WORKDIR)/root-image /usr/bin/mandb -qc >>> >>> May be directly in archiso... >>> > Careful! Doing that once the ISO has already booted will fail on systems > with few memory. Currently, we generate the locales in the live system, > and that also fails with less than 128MB memory - and takes quite a long > time. > With less than 128MB of RAM (for example 96MB) => kernel panic while unpacking initramfs. >> That is true. >> But there is one issue with iso images sizes (core-dual.iso) >> >> 1) current (2010.05) official media is 659MB, so addding >> "1.7MB+compression" is not an issue. >> 2) current (today generated images 2010.07.01) is 702MB!. Size is over >> 2MB of the allowed limit for a CD-ROM, adding more data become a problem++. > Hmm, weird, can you find out what's so big? 702MB is okay for a CD (I > think the limit without overburning is 703), but that growth has to come > from somwhere. 2010.07/2010.05: 166/160 175/169 336/324: +6 +6 +12 2010.07/2010.05: 345/324 362/340 702/659: +21 +22 +43 Some packages has grow for example kernel-lts, new kernel26-docs... >> Anyway if big size is a problem for next iso, I think that dual images >> need to be generated with archiso2dual "-T split" instead of (like now) >> "-T basic" > A few things we could/should do: > 1) Create separate core-pkgs for i686, x86_64 and any. It's a bit > complex to do that, but it'll save some duplication. Yup, a the gain is small (~12MB) but will help in future. (this currently not implemented in archiso2dual) > 2) Add more architecture-independent files from the squashfs to a common > squashfs. Also very complex though. Yes and this is implemented in archiso2dual (using -T split) /usr/share is removed of both root-images.sqfs and a separate usrshare.sqfs is created. Only doing will be again below 700MB barrier: 645M archlinux-2010.07.01-core-dual.iso (-T split) > 3) Clean the squashfs from files we don't need in the live environment - > not sure which, but there might be some. I think when -T split option does not satisfy 700M removing files can be and option. (currently archiso2dual -T full, read a file called removefiles.lst that by default removes: boot usr/include usr/share/doc usr/share/info usr/share/man usr/src) > 4) Use lzma for squashing. It is a problem, because that won't be in > 2.6.35 and likely neither 2.6.36. However, small and working patches do > exist, Linus just rejected them for maintainability and quality reasons. > We could have a separate kernel26-archiso which differs from kernel26 > just by having squashfs-lzma capability - just until the new lzma > compression code is finished. Yes :( The gain is about ~40MB is root-image.sqfs -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
participants (3)
-
Gerardo Exequiel Pozzi
-
Smartboy
-
Thomas Bächler