Re: [arch-releng] Status report about building archiso images today
--- El mié 14-jul-10, Thomas Bächler <thomas@archlinux.org> escribió:
De: Thomas Bächler <thomas@archlinux.org> Am 14.07.2010 03:11, schrieb Gerardo Exequiel Pozzi:
Since new initscripts and mkinitcpio are in [core] new images can be build without doing "git/overlay hacks".
What kind of hacks are you talking about exactly?
* build packages from git and adding a custom repo * or install directly from git * or write modified files to overlay (ex: rc.sysinit)
{*} There is a bug in qemu-kvm that ide-cdrom (default used) does not work propertly, use instead and scsi-cdrom. [#1]
Are you sure that this only affects the qemu cdrom? Shouldn't we provide a simple workaround that catches all CD drives, no matter what kind of weird bugs there might be?
This is a bug in qemu-kvm ide cdrom drive implementation, does not implement or does not work the command "READ DISC INFORMATION". As workaround just boot on qemu as scsi cd-rom that works better than ide implementation. (I guess that adding a workaround in archiso should be in case of real machine where there is no choice)
{****} -T basic is how official dual media (2010.05) is build. Now this image size is 705MB, a bit larger for CD-ROMs. I guess for next official media -T split should be used (currently 637MB).
Can you summarize what exactly -T split does?
Sure -T basic: join both .iso keeping .sqfs intact. -T split: join both .iso modifiying .sqfs with the follow rules: * usrshare.sqfs (any) is build from i686 root-image.sqfs [this can be done since /usr/share for both archs is the same] * libmodules.sqfs (for each arch) is build from root-image.sqfs (respectively) [useful for boot 64Krnl/32User] * /usr/share and /lib/modudes are removed from both root-images.sqfs * core-any-pkg.sqfs (any) is build from i686 core-pkgs.sqfs. * *any* packages are removed from both core-pkgs.sqfs -T full: join both .iso doing all work in "split", but also removes specified files (listed on a file) from root-image.sqfs.
Also, there is the overlay: We used to have a separate overlay for each architecture, is that still necessary? If we add "Architecture = auto" to pacman.conf and use $arch in mirrorlist (is that already done?), it seems we can use the same overlay for both architectures.
Yes, anyway overlay.sqfs is 8192 bytes :P PS: sorry for email format I am out from my home. Sent via webmail, running under custom archiso with KDE with all "chiches" (toys) :P
Am 14.07.2010 21:28, schrieb Gerardo Exequiel Pozzi:
Are you sure that this only affects the qemu cdrom? Shouldn't we provide a simple workaround that catches all CD drives, no matter what kind of weird bugs there might be?
This is a bug in qemu-kvm ide cdrom drive implementation, does not implement or does not work the command "READ DISC INFORMATION".
As workaround just boot on qemu as scsi cd-rom that works better than ide implementation. (I guess that adding a workaround in archiso should be in case of real machine where there is no choice)
You don't know what kind of broken hardware exists out there, sadly.
Can you summarize what exactly -T split does?
Sure
-T basic: join both .iso keeping .sqfs intact. -T split: join both .iso modifiying .sqfs with the follow rules:
* usrshare.sqfs (any) is build from i686 root-image.sqfs [this can be done since /usr/share for both archs is the same] * libmodules.sqfs (for each arch) is build from root-image.sqfs (respectively) [useful for boot 64Krnl/32User] * /usr/share and /lib/modudes are removed from both root-images.sqfs * core-any-pkg.sqfs (any) is build from i686 core-pkgs.sqfs. * *any* packages are removed from both core-pkgs.sqfs
Okay, -T split looks cool.
-T full: join both .iso doing all work in "split", but also removes specified files (listed on a file) from root-image.sqfs.
Okay, what is that list?
Also, there is the overlay: We used to have a separate overlay for each architecture, is that still necessary? If we add "Architecture = auto" to pacman.conf and use $arch in mirrorlist (is that already done?), it seems we can use the same overlay for both architectures.
Yes, anyway overlay.sqfs is 8192 bytes :P
Still ... shouldn't be duplicated.
PS: sorry for email format I am out from my home. Sent via webmail, running under custom archiso with KDE with all "chiches" (toys) :P
No problem, seems like you're having fun.
On 14.07.2010 21:55, Thomas Bächler wrote:
Am 14.07.2010 21:28, schrieb Gerardo Exequiel Pozzi:
[I'm changing lots of stuff] [ololol] Can you please try to keep the wiki article up to date on the new archiso changes? I can't quite keep up with all the changes currently.
-- Sven-Hendrik
On 07/14/2010 05:02 PM, Sven-Hendrik Haase wrote:
On 14.07.2010 21:55, Thomas Bächler wrote:
Am 14.07.2010 21:28, schrieb Gerardo Exequiel Pozzi:
[I'm changing lots of stuff] [ololol] Can you please try to keep the wiki article up to date on the new archiso changes? I can't quite keep up with all the changes currently.
-- Sven-Hendrik
I'll see what I can do, in terms of changes related directly with archiso ;) -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On 07/14/2010 04:55 PM, Thomas Bächler wrote:
Am 14.07.2010 21:28, schrieb Gerardo Exequiel Pozzi:
Are you sure that this only affects the qemu cdrom? Shouldn't we provide a simple workaround that catches all CD drives, no matter what kind of weird bugs there might be?
This is a bug in qemu-kvm ide cdrom drive implementation, does not implement or does not work the command "READ DISC INFORMATION".
As workaround just boot on qemu as scsi cd-rom that works better than ide implementation. (I guess that adding a workaround in archiso should be in case of real machine where there is no choice) You don't know what kind of broken hardware exists out there, sadly. True.
Analyzing the situation in this way, perhaps we should think about the return of images with GRUB, because there are very bad BIOS, where the SYSLINUX does not work [#1].
Can you summarize what exactly -T split does? Sure
-T basic: join both .iso keeping .sqfs intact. -T split: join both .iso modifiying .sqfs with the follow rules:
* usrshare.sqfs (any) is build from i686 root-image.sqfs [this can be done since /usr/share for both archs is the same] * libmodules.sqfs (for each arch) is build from root-image.sqfs (respectively) [useful for boot 64Krnl/32User] * /usr/share and /lib/modudes are removed from both root-images.sqfs * core-any-pkg.sqfs (any) is build from i686 core-pkgs.sqfs. * *any* packages are removed from both core-pkgs.sqfs Okay, -T split looks cool.
-T full: join both .iso doing all work in "split", but also removes specified files (listed on a file) from root-image.sqfs. Okay, what is that list? By default, if no -R <removefiles.lst> is on command line, this file is /usr/share/archiso2dual/removefiles.lst with this contents: boot usr/include usr/share/doc usr/share/info usr/share/man usr/src
Also, there is the overlay: We used to have a separate overlay for each architecture, is that still necessary? If we add "Architecture = auto" to pacman.conf and use $arch in mirrorlist (is that already done?), it seems we can use the same overlay for both architectures.
Yes, anyway overlay.sqfs is 8192 bytes :P Still ... shouldn't be duplicated. ...true :P (working...) PS: sorry for email format I am out from my home. Sent via webmail, running under custom archiso with KDE with all "chiches" (toys) :P No problem, seems like you're having fun. haha you've discovered me :P
[#1] http://bugs.archlinux.org/task/19625 -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Am 15.07.2010 00:43, schrieb Gerardo Exequiel Pozzi:
Analyzing the situation in this way, perhaps we should think about the return of images with GRUB, because there are very bad BIOS, where the SYSLINUX does not work [#1].
I disagree. Contrary to GRUB, the people behind syslinux actually care about these issues and are motivated to fix them. syslinux device support seems to be much better than GRUB. This is also the first time ever that I heard of an ISO working with GRUB but not with syslinux.
By default, if no -R <removefiles.lst> is on command line, this file is /usr/share/archiso2dual/removefiles.lst with this contents: boot
/boot is on the boot medium and is not needed in squashfs - it should be removed anyway.
usr/include usr/share/doc usr/share/info usr/share/man usr/src
We should try to keep those whenever possible. I still hope that squashfs-lzma will be around soon ...
By default, if no -R<removefiles.lst> is on command line, this file is /usr/share/archiso2dual/removefiles.lst with this contents: boot /boot is on the boot medium and is not needed in squashfs - it should be removed anyway. yes, is here because logic under Makefile, to avoid rebuilds, of course
that a temporary location can be used here to keep in sync vmlinuz26, some logic should be changed in Makefile...
I still hope that squashfs-lzma will be around soon ...
Yes. I personally more hope about work from Valerie Aurora "writable overlays"[#1], It would be great, if VFS developers finally accept her work officially in the kernel. [#1] http://valerieaurora.org/union/ -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Am 15.07.2010 02:19, schrieb Gerardo Exequiel Pozzi:
I still hope that squashfs-lzma will be around soon ...
Yes. I personally more hope about work from Valerie Aurora "writable overlays"[#1], It would be great, if VFS developers finally accept her work officially in the kernel.
Oh yes, this would get rid of aufs for us. Her work has been reviewed and commented several times by some VFS developers on LKML, and it seems there are still some unsolved issues. I don't think we'll be there before 2.6.37. We could always create a special 'archiso' kernel with union-mounts and squashfs-lzma code - the code is there, it's just not 'official'.
On 07/14/2010 04:55 PM, Thomas Bächler wrote:
Am 14.07.2010 21:28, schrieb Gerardo Exequiel Pozzi:
Are you sure that this only affects the qemu cdrom? Shouldn't we provide a simple workaround that catches all CD drives, no matter what kind of weird bugs there might be?
This is a bug in qemu-kvm ide cdrom drive implementation, does not implement or does not work the command "READ DISC INFORMATION".
As workaround just boot on qemu as scsi cd-rom that works better than ide implementation. (I guess that adding a workaround in archiso should be in case of real machine where there is no choice) You don't know what kind of broken hardware exists out there, sadly. udev-161 adds a workaround for qemu.
PS: Please do not forget FS#20107 - [udev] Cleanup for arch-udev-rules.patch ( http://bugs.archlinux.org/task/20107 ) -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
participants (3)
-
Gerardo Exequiel Pozzi
-
Sven-Hendrik Haase
-
Thomas Bächler