[arch-releng] updates to releng scripts for new dm_snapshot archiso
Hi, I've been updating the releng scripts for the new archiso (all my changes are in this commit: http://pastie.org/2318603) It seems to build the i686 iso's succesfully, but fails for x86_64 and I have no idea why. I only know `./build.sh all_iso_single` failed (exited >0) in the x86_64 chroot, but it doesn't give me any errors. Could it be because I do a `./build.sh clean_single` and `./build.sh clean_dual` first? (before doing x86_64, after i686). I know you gave instructions at http://mailman.archlinux.org/pipermail/arch-releng/2011-June/001835.html, but they don't mention when exactly i should do which clean commands. Here is the tail of my logfile: [mkarchiso] INFO: Creating SquashFS image for 'work/i686/core-any-pkgs', This may take some time... [mkarchiso] INFO: Image creation done in 00:22 minutes [mkarchiso] INFO: Configuration settings [mkarchiso] INFO: Command: iso [mkarchiso] INFO: Architecture: i686 [mkarchiso] INFO: Working directory: work/i686 [mkarchiso] INFO: Installation directory: arch [mkarchiso] INFO: Image name: archlinux-2011.08.04-core-i686.iso [mkarchiso] INFO: Disk label: ARCH_201108 [mkarchiso] INFO: Disk publisher: Arch Linux <http://www.archlinux.org> [mkarchiso] INFO: Disk application: Arch Linux Live/Rescue CD [mkarchiso] INFO: Target 'archlinux-2011.08.04-core-i686.iso' does not exist, making it from 'work/i686/iso' [mkarchiso] INFO: Creating ISO image... [mkarchiso] INFO: Done! | 367M archlinux-2011.08.04-core-i686.iso ===================================== =============== RELENG-REBUILD-IMAGES x86_64 =============== ===================================== cleaning build dir for x86_64 building images for x86_64 [mkarchiso] INFO: Configuration settings [mkarchiso] INFO: Command: create [mkarchiso] INFO: Architecture: x86_64 [mkarchiso] INFO: Working directory: work/x86_64 [mkarchiso] INFO: Installation directory: arch [mkarchiso] INFO: Pacman config file: /etc/pacman.conf [mkarchiso] INFO: Packages: base [mkarchiso] INFO: Installing packages to 'work/x86_64/root-image/'... [mkarchiso] INFO: Packages installed successfully! [mkarchiso] INFO: Configuration settings [mkarchiso] INFO: Command: create [mkarchiso] INFO: Architecture: x86_64 [mkarchiso] INFO: Working directory: work/x86_64 [mkarchiso] INFO: Installation directory: arch [mkarchiso] INFO: Pacman config file: /etc/pacman.conf [mkarchiso] INFO: Packages: memtest86+ syslinux mkinitcpio-nfs-utils nbd [mkarchiso] INFO: Installing packages to 'work/x86_64/root-image/'... [mkarchiso] INFO: Packages installed successfully! [mkarchiso] INFO: Configuration settings [mkarchiso] INFO: Command: create [mkarchiso] INFO: Architecture: x86_64 [mkarchiso] INFO: Working directory: work/x86_64 [mkarchiso] INFO: Installation directory: arch [mkarchiso] INFO: Pacman config file: /etc/pacman.conf [mkarchiso] INFO: Packages: aif b43-fwcutter btrfs-progs-unstable crda curl ddrescue dhclient dialog dmraid dnsmasq dnsutils dosfstools elinks gnu-netcat hdparm inetutils ipw2100-fw ipw2200-fw lftp lilo netcfg nfs-utils nilfs-utils nmap ntfs-3g ntfsprogs ntp openconnect openssh openvpn parted pptpclient rp-pppoe rsync speedtouch tcpdump vpnc wireless_tools wpa_actiond zd1211-firmware [mkarchiso] INFO: Installing packages to 'work/x86_64/root-image/'... ERROR: ./build.sh all_iso_single FAILED
On 08/04/2011 05:10 AM, Dieter Plaetinck wrote:
Hi, I've been updating the releng scripts for the new archiso (all my changes are in this commit: http://pastie.org/2318603) Good! It seems to build the i686 iso's succesfully, but fails for x86_64 and I have no idea why. I only know `./build.sh all_iso_single` failed (exited>0) in the x86_64 chroot, but it doesn't give me any errors. See below. Could it be because I do a `./build.sh clean_single` and `./build.sh clean_dual` first? (before doing x86_64, after i686). I know you gave instructions at http://mailman.archlinux.org/pipermail/arch-releng/2011-June/001835.html, but they don't mention when exactly i should do which clean commands. clean commands remove files created by build commands on current architecture.
clean_single $workdir/$arch + $arch.iso clean_dual $workdir/dual + dual.iso
Here is the tail of my logfile: [mkarchiso] INFO: Creating SquashFS image for 'work/i686/core-any-pkgs', This may take some time... [mkarchiso] INFO: Image creation done in 00:22 minutes
[mkarchiso] INFO: Configuration settings [mkarchiso] INFO: Command: iso [mkarchiso] INFO: Architecture: i686 [mkarchiso] INFO: Working directory: work/i686 [mkarchiso] INFO: Installation directory: arch [mkarchiso] INFO: Image name: archlinux-2011.08.04-core-i686.iso [mkarchiso] INFO: Disk label: ARCH_201108 [mkarchiso] INFO: Disk publisher: Arch Linux<http://www.archlinux.org> [mkarchiso] INFO: Disk application: Arch Linux Live/Rescue CD
[mkarchiso] INFO: Target 'archlinux-2011.08.04-core-i686.iso' does not exist, making it from 'work/i686/iso' [mkarchiso] INFO: Creating ISO image... [mkarchiso] INFO: Done! | 367M archlinux-2011.08.04-core-i686.iso ===================================== =============== RELENG-REBUILD-IMAGES x86_64 =============== ===================================== cleaning build dir for x86_64 building images for x86_64
[mkarchiso] INFO: Configuration settings [mkarchiso] INFO: Command: create [mkarchiso] INFO: Architecture: x86_64 [mkarchiso] INFO: Working directory: work/x86_64 [mkarchiso] INFO: Installation directory: arch [mkarchiso] INFO: Pacman config file: /etc/pacman.conf [mkarchiso] INFO: Packages: base
[mkarchiso] INFO: Installing packages to 'work/x86_64/root-image/'... [mkarchiso] INFO: Packages installed successfully!
[mkarchiso] INFO: Configuration settings [mkarchiso] INFO: Command: create [mkarchiso] INFO: Architecture: x86_64 [mkarchiso] INFO: Working directory: work/x86_64 [mkarchiso] INFO: Installation directory: arch [mkarchiso] INFO: Pacman config file: /etc/pacman.conf [mkarchiso] INFO: Packages: memtest86+ syslinux mkinitcpio-nfs-utils nbd
[mkarchiso] INFO: Installing packages to 'work/x86_64/root-image/'... [mkarchiso] INFO: Packages installed successfully!
[mkarchiso] INFO: Configuration settings [mkarchiso] INFO: Command: create [mkarchiso] INFO: Architecture: x86_64 [mkarchiso] INFO: Working directory: work/x86_64 [mkarchiso] INFO: Installation directory: arch [mkarchiso] INFO: Pacman config file: /etc/pacman.conf [mkarchiso] INFO: Packages: aif b43-fwcutter btrfs-progs-unstable crda curl ddrescue dhclient dialog dmraid dnsmasq dnsutils dosfstools elinks gnu-netcat hdparm inetutils ipw2100-fw ipw2200-fw lftp lilo netcfg nfs-utils nilfs-utils nmap ntfs-3g ntfsprogs ntp openconnect openssh openvpn parted pptpclient rp-pppoe rsync speedtouch tcpdump vpnc wireless_tools wpa_actiond zd1211-firmware
[mkarchiso] INFO: Installing packages to 'work/x86_64/root-image/'... ERROR: ./build.sh all_iso_single FAILED
There is no message "[mkarchiso] INFO: Packages installed successfully!" so pacman failed, enable verbose mode in build.sh to see exact error. (free space OK?) I build OK all images here. [mkarchiso] INFO: Done! | 179M archlinux-2011.08.04-netinstall-i686.iso [mkarchiso] INFO: Done! | 368M archlinux-2011.08.04-core-i686.iso [mkarchiso] INFO: Done! | 183M archlinux-2011.08.04-netinstall-x86_64.iso [mkarchiso] INFO: Done! | 375M archlinux-2011.08.04-core-x86_64.iso [mkarchiso] INFO: Done! | 304M archlinux-2011.08.04-netinstall-dual.iso [mkarchiso] INFO: Done! | 670M archlinux-2011.08.04-core-dual.iso Image size are reduced since elinks does not depend anymore on smbclient, and other few things :) About 4% on single and 8% on dual. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Am 04.08.2011 16:46, schrieb Gerardo Exequiel Pozzi:
There is no message "[mkarchiso] INFO: Packages installed successfully!" so pacman failed, enable verbose mode in build.sh to see exact error. (free space OK?)
Looks like the same error we had in the past, just that we didn't have a verbose mode to debug.
On Thu, 04 Aug 2011 16:57:24 +0200 Thomas Bächler <thomas@archlinux.org> wrote:
Am 04.08.2011 16:46, schrieb Gerardo Exequiel Pozzi:
There is no message "[mkarchiso] INFO: Packages installed successfully!" so pacman failed, enable verbose mode in build.sh to see exact error. (free space OK?)
Looks like the same error we had in the past, just that we didn't have a verbose mode to debug.
now I get this: (the libui-sh package is in /home/releng/repos/releng-any/libui-sh-2011.01.01-1-any.pkg.tar.xz and gets built with makepkg using the source available on http://releng.archlinux.org/packages/libui-sh-git/PKGBUILD weird that this doesn't work now, but worked before. ) [mkarchiso] INFO: Installing packages to 'work/i686/root-image/'... :: Synchronizing package databases... releng-any is up to date releng-i686 is up to date core is up to date extra is up to date community is up to date resolving dependencies... looking for inter-conflicts... Targets (68): libui-sh-2011.01.01-1 aif-2011.03.05-1 b43-fwcutter-014-1 btrfs-progs-unstable-0.19.20101006-1 wireless-regdb-2010.11.24-1 iw-0.9.22-1 crda-1.1.1-3 ca-certificates-20110421-3 libssh2-1.2.7-2 curl-7.21.7-1 ddrescue-1.14-1 dhclient-4.2.1.1-1 dialog-1.1_20110707-1 dmraid-1.0.0.rc16.3-2 dnsmasq-2.57-1 idnkit-1.0-1 dnsutils-9.8.0.P4-1 dosfstools-3.0.11-1 gpm-1.20.6-6 lua-5.1.4-6 libidn-1.22-1 nspr-4.8.8-1 js-1.8.5-3 gc-7.1-3 tre-0.8.0-1 elinks-0.13-7 gnu-netcat-0.7.1-3 hdparm-9.37-1 inetutils-1.8-3 ipw2100-fw-1.3-5 ipw2200-fw-3.1-3 libtasn1-2.9-1 nettle-2.1-1 gnutls-2.12.7-2 lftp-4.3.1-1 lilo-23.2-1 wireless_tools-29-4 net-tools-1.60-18 netcfg-2.5.5-1 libgssglue-0.1-4 libtirpc-0.2.2-1 rpcbind-0.2.0-3 librpcsecgss-0.19-5 nfsidmap-0.24-2 libevent-2.0.12-1 nfs-utils-1.2.3-3 nilfs-utils-2.0.20-1 nmap-5.51-1 fuse-2.8.5-1 ntfs-3g-2011.4.12-1 ntfsprogs-2011.4.12-1 ntp-4.2.6.p3-3 libxml2-2.7.8-1 libproxy-0.4.7-1 openconnect-1:3.02-1 libedit-20110709_3.0-1 openssh-5.8p2-9 lzo2-2.05-1 openvpn-2.2.0-1 parted-3.0-3 pptpclient-1.7.2-3 rp-pppoe-3.10-7 rsync-3.0.8-2 speedtouch-1.3.1-3 tcpdump-4.1.1-2 vpnc-0.5.3-3 wpa_actiond-1.1-2 zd1211-firmware-1.4-4 Total Download Size: 15.66 MB Total Installed Size: 83.78 MB Proceed with installation? [Y/n] :: Retrieving packages from releng-any... downloading aif-2011.03.05-1-any.pkg.tar.xz... :: Retrieving packages from releng-i686... downloading nilfs-utils-2.0.20-1-i686.pkg.tar.xz... :: Retrieving packages from core... downloading b43-fwcutter-014-1-i686.pkg.tar.xz... downloading btrfs-progs-unstable-0.19.20101006-1-i686.pkg.tar.xz... downloading wireless-regdb-2010.11.24-1-any.pkg.tar.xz... downloading iw-0.9.22-1-i686.pkg.tar.xz... downloading crda-1.1.1-3-i686.pkg.tar.xz... downloading dialog-1.1_20110707-1-i686.pkg.tar.xz... downloading dmraid-1.0.0.rc16.3-2-i686.pkg.tar.xz... downloading idnkit-1.0-1-i686.pkg.tar.xz... downloading dnsutils-9.8.0.P4-1-i686.pkg.tar.xz... downloading hdparm-9.37-1-i686.pkg.tar.xz... downloading inetutils-1.8-3-i686.pkg.tar.xz... downloading ipw2100-fw-1.3-5-any.pkg.tar.xz... downloading ipw2200-fw-3.1-3-any.pkg.tar.xz... downloading lilo-23.2-1-i686.pkg.tar.xz... downloading wireless_tools-29-4-i686.pkg.tar.xz... downloading netcfg-2.5.5-1-any.pkg.tar.xz... downloading libgssglue-0.1-4-i686.pkg.tar.xz... downloading libtirpc-0.2.2-1-i686.pkg.tar.xz... downloading rpcbind-0.2.0-3-i686.pkg.tar.xz... downloading librpcsecgss-0.19-5-i686.pkg.tar.xz... downloading nfsidmap-0.24-2-i686.pkg.tar.xz... downloading libevent-2.0.12-1-i686.pkg.tar.xz... downloading nfs-utils-1.2.3-3-i686.pkg.tar.xz... downloading openvpn-2.2.0-1-i686.pkg.tar.xz... downloading pptpclient-1.7.2-3-i686.pkg.tar.xz... downloading vpnc-0.5.3-3-i686.pkg.tar.xz... downloading wpa_actiond-1.1-2-i686.pkg.tar.xz... downloading zd1211-firmware-1.4-4-any.pkg.tar.xz... :: Retrieving packages from extra... downloading ddrescue-1.14-1-i686.pkg.tar.xz... downloading dhclient-4.2.1.1-1-i686.pkg.tar.xz... downloading dnsmasq-2.57-1-i686.pkg.tar.xz... downloading dosfstools-3.0.11-1-i686.pkg.tar.xz... downloading lua-5.1.4-6-i686.pkg.tar.xz... downloading libidn-1.22-1-i686.pkg.tar.xz... downloading nspr-4.8.8-1-i686.pkg.tar.xz... downloading js-1.8.5-3-i686.pkg.tar.xz... downloading gc-7.1-3-i686.pkg.tar.xz... downloading gnu-netcat-0.7.1-3-i686.pkg.tar.gz... downloading libtasn1-2.9-1-i686.pkg.tar.xz... downloading nettle-2.1-1-i686.pkg.tar.xz... downloading gnutls-2.12.7-2-i686.pkg.tar.xz... downloading lftp-4.3.1-1-i686.pkg.tar.xz... downloading nmap-5.51-1-i686.pkg.tar.xz... downloading fuse-2.8.5-1-i686.pkg.tar.xz... downloading ntfs-3g-2011.4.12-1-i686.pkg.tar.xz... downloading ntfsprogs-2011.4.12-1-i686.pkg.tar.xz... downloading ntp-4.2.6.p3-3-i686.pkg.tar.xz... downloading libxml2-2.7.8-1-i686.pkg.tar.xz... downloading libproxy-0.4.7-1-i686.pkg.tar.xz... downloading openconnect-1:3.02-1-i686.pkg.tar.xz... downloading parted-3.0-3-i686.pkg.tar.xz... downloading speedtouch-1.3.1-3-i686.pkg.tar.xz... downloading tcpdump-4.1.1-2-i686.pkg.tar.xz... :: Retrieving packages from community... downloading tre-0.8.0-1-i686.pkg.tar.gz... downloading elinks-0.13-7-i686.pkg.tar.xz... checking package integrity... :: File libui-sh-2011.01.01-1-any.pkg.tar.xz is corrupted. Do you want to delete it? [Y/n] error: failed to commit transaction (invalid or corrupted package) libui-sh-2011.01.01-1-any.pkg.tar.xz is invalid or corrupted Errors occurred, no packages were upgraded. error: failed to install all packages ERROR: ./build.sh all_iso_single FAILED
----- Mensaje original -----
De: Dieter Plaetinck <dieter@plaetinck.be> Para: Arch Linux Release Engineering <arch-releng@archlinux.org> CC: Enviado: jueves, 4 de agosto de 2011 16:52 Asunto: Re: [arch-releng] updates to releng scripts for new dm_snapshot archiso
On Thu, 04 Aug 2011 16:57:24 +0200 Thomas Bächler <thomas@archlinux.org> wrote:
Am 04.08.2011 16:46, schrieb Gerardo Exequiel Pozzi:
There is no message "[mkarchiso] INFO: Packages installed successfully!" so pacman failed, enable verbose mode in build.sh to see exact error. (free space OK?)
Looks like the same error we had in the past, just that we didn't have a verbose mode to debug.
now I get this: (the libui-sh package is in /home/releng/repos/releng-any/libui-sh-2011.01.01-1-any.pkg.tar.xz and gets built with makepkg using the source available on http://releng.archlinux.org/packages/libui-sh-git/PKGBUILD weird that this doesn't work now, but worked before.
checking package integrity... :: File libui-sh-2011.01.01-1-any.pkg.tar.xz is corrupted. Do you want to delete it? [Y/n] error: failed to commit transaction (invalid or corrupted package) libui-sh-2011.01.01-1-any.pkg.tar.xz is invalid or corrupted Errors occurred, no packages were upgraded. error: failed to install all packages ERROR: ./build.sh all_iso_single FAILED
Do you check free space on all filesystems?
On Thu, 4 Aug 2011 13:20:50 -0700 (PDT) Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Do you check free space on all filesystems?
yes, plenty of space (chroots are in /var/releng) [dieter@alberich releng]$ df -h Filesystem Size Used Avail Use% Mounted on udev 10M 104K 9.9M 2% /dev /dev/mapper/vg-root 6.8G 3.5G 3.0G 55% / shm 1005M 0 1005M 0% /dev/shm /dev/sda1 54M 17M 34M 34% /boot /dev/mapper/vg-home 9.9G 4.1G 5.8G 42% /home /dev/mapper/vg-releng 30G 22G 8.6G 72% /var/releng /dev/mapper/vg-srv 25G 21G 4.5G 82% /srv
----- Mensaje original -----
De: Dieter Plaetinck <dieter@plaetinck.be> Para: Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>; Arch Linux Release Engineering <arch-releng@archlinux.org> CC: Enviado: jueves, 4 de agosto de 2011 17:24 Asunto: Re: [arch-releng] updates to releng scripts for new dm_snapshot archiso
On Thu, 4 Aug 2011 13:20:50 -0700 (PDT) Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Do you check free space on all filesystems?
yes, plenty of space (chroots are in /var/releng)
[dieter@alberich releng]$ df -h Filesystem Size Used Avail Use% Mounted on udev 10M 104K 9.9M 2% /dev /dev/mapper/vg-root 6.8G 3.5G 3.0G 55% / shm 1005M 0 1005M 0% /dev/shm /dev/sda1 54M 17M 34M 34% /boot /dev/mapper/vg-home 9.9G 4.1G 5.8G 42% /home /dev/mapper/vg-releng 30G 22G 8.6G 72% /var/releng /dev/mapper/vg-srv 25G 21G 4.5G 82% /srv
OK. weird. do you check how look (size, md5) libui pkg copied/downloaded compared with the "original" in local repo?
On Thu, 4 Aug 2011 13:37:29 -0700 (PDT) Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
----- Mensaje original -----
De: Dieter Plaetinck <dieter@plaetinck.be> Para: Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>; Arch Linux Release Engineering <arch-releng@archlinux.org> CC: Enviado: jueves, 4 de agosto de 2011 17:24 Asunto: Re: [arch-releng] updates to releng scripts for new dm_snapshot archiso
On Thu, 4 Aug 2011 13:20:50 -0700 (PDT) Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Do you check free space on all filesystems?
yes, plenty of space (chroots are in /var/releng)
[dieter@alberich releng]$ df -h Filesystem Size Used Avail Use% Mounted on udev 10M 104K 9.9M 2% /dev /dev/mapper/vg-root 6.8G 3.5G 3.0G 55% / shm 1005M 0 1005M 0% /dev/shm /dev/sda1 54M 17M 34M 34% /boot /dev/mapper/vg-home 9.9G 4.1G 5.8G 42% /home /dev/mapper/vg-releng 30G 22G 8.6G 72% /var/releng /dev/mapper/vg-srv 25G 21G 4.5G 82% /srv
OK.
weird.
do you check how look (size, md5) libui pkg copied/downloaded compared with the "original" in local repo?
No, but if I try enough, sometimes it works. (this is also why even before the dm-snapshot merge into archiso, the iso builds were about every 5-8 days. the crontab is daily but it fails often, and only sometimes it works) anyway, now I hit a new problem: (..) 191420 extents written (373 MB) [mkarchiso] INFO: Done! | 374M archlinux-2011.08.05-core-x86_64.iso ===================================== =============== RELENG-REBUILD-IMAGES DUAL =============== ===================================== building dual images for i686 ERROR: i686 or x86_64 builds does not exist. usage build.sh net_iso_single | core_iso_single | all_iso_single | clean_single net_iso_dual | core_iso_dual | all_iso_dual | clean_dual ERROR: ./build.sh all_iso_dual FAILED the iso's do exist, but they are not in configs/releng/$work/i686/ and configs/releng/$work/x86_64/ like this script seems to assume. they are in configs/releng/ Note i did not move them, that's just where your script puts them, so why doesn't the all_iso_dual collect them from the right location? Dieter
Am 05.08.2011 15:35, schrieb Dieter Plaetinck:
do you check how look (size, md5) libui pkg copied/downloaded compared with the "original" in local repo?
No, but if I try enough, sometimes it works. (this is also why even before the dm-snapshot merge into archiso, the iso builds were about every 5-8 days. the crontab is daily but it fails often, and only sometimes it works)
This must be something with the VMWare storage. Btw, I rebooted the machine last night, hoped it might help (major kernel upgrade). Does this always happen with the same package? Or different ones? Can we have pacman auto-retry the download a few times?
On 08/05/2011 10:35 AM, Dieter Plaetinck wrote:
On Thu, 4 Aug 2011 13:37:29 -0700 (PDT) Gerardo Exequiel Pozzi<vmlinuz386@yahoo.com.ar> wrote:
----- Mensaje original -----
De: Dieter Plaetinck<dieter@plaetinck.be> Para: Gerardo Exequiel Pozzi<vmlinuz386@yahoo.com.ar>; Arch Linux Release Engineering<arch-releng@archlinux.org> CC: Enviado: jueves, 4 de agosto de 2011 17:24 Asunto: Re: [arch-releng] updates to releng scripts for new dm_snapshot archiso
On Thu, 4 Aug 2011 13:20:50 -0700 (PDT) Gerardo Exequiel Pozzi<vmlinuz386@yahoo.com.ar> wrote:
Do you check free space on all filesystems? yes, plenty of space (chroots are in /var/releng)
[dieter@alberich releng]$ df -h Filesystem Size Used Avail Use% Mounted on udev 10M 104K 9.9M 2% /dev /dev/mapper/vg-root 6.8G 3.5G 3.0G 55% / shm 1005M 0 1005M 0% /dev/shm /dev/sda1 54M 17M 34M 34% /boot /dev/mapper/vg-home 9.9G 4.1G 5.8G 42% /home /dev/mapper/vg-releng 30G 22G 8.6G 72% /var/releng /dev/mapper/vg-srv 25G 21G 4.5G 82% /srv
OK.
weird.
do you check how look (size, md5) libui pkg copied/downloaded compared with the "original" in local repo? No, but if I try enough, sometimes it works. (this is also why even before the dm-snapshot merge into archiso, the iso builds were about every 5-8 days. the crontab is daily but it fails often, and only sometimes it works)
weird :s
anyway, now I hit a new problem:
(..) 191420 extents written (373 MB) [mkarchiso] INFO: Done! | 374M archlinux-2011.08.05-core-x86_64.iso ===================================== =============== RELENG-REBUILD-IMAGES DUAL =============== ===================================== building dual images for i686 ERROR: i686 or x86_64 builds does not exist. usage build.sh net_iso_single | core_iso_single | all_iso_single | clean_single net_iso_dual | core_iso_dual | all_iso_dual | clean_dual
ERROR: ./build.sh all_iso_dual FAILED
the iso's do exist, but they are not in configs/releng/$work/i686/ and configs/releng/$work/x86_64/ like this script seems to assume. they are in configs/releng/
Nope, build.sh does not require "*.iso" (like archiso2dual) just use both working directories from single architectures. In other words, $work_dir/dual/iso is generated with links (hard) from $worr_dir/i686/iso and $work_dir/x86_64/iso Ensure that you are executing build.sh in the same directory where these both directories exists (like with others build.sh commands) PS: I have a commit in my experimental branch that allows working from other directory where "configs" reside, but this is another history...
Note i did not move them, that's just where your script puts them, so why doesn't the all_iso_dual collect them from the right location?
Dieter
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Fri, 05 Aug 2011 11:20:08 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 08/05/2011 10:35 AM, Dieter Plaetinck wrote:
On Thu, 4 Aug 2011 13:37:29 -0700 (PDT) Gerardo Exequiel Pozzi<vmlinuz386@yahoo.com.ar> wrote:
----- Mensaje original -----
De: Dieter Plaetinck<dieter@plaetinck.be> Para: Gerardo Exequiel Pozzi<vmlinuz386@yahoo.com.ar>; Arch Linux Release Engineering<arch-releng@archlinux.org> CC: Enviado: jueves, 4 de agosto de 2011 17:24 Asunto: Re: [arch-releng] updates to releng scripts for new dm_snapshot archiso
On Thu, 4 Aug 2011 13:20:50 -0700 (PDT) Gerardo Exequiel Pozzi<vmlinuz386@yahoo.com.ar> wrote:
Do you check free space on all filesystems? yes, plenty of space (chroots are in /var/releng)
[dieter@alberich releng]$ df -h Filesystem Size Used Avail Use% Mounted on udev 10M 104K 9.9M 2% /dev /dev/mapper/vg-root 6.8G 3.5G 3.0G 55% / shm 1005M 0 1005M 0% /dev/shm /dev/sda1 54M 17M 34M 34% /boot /dev/mapper/vg-home 9.9G 4.1G 5.8G 42% /home /dev/mapper/vg-releng 30G 22G 8.6G 72% /var/releng /dev/mapper/vg-srv 25G 21G 4.5G 82% /srv
OK.
weird.
do you check how look (size, md5) libui pkg copied/downloaded compared with the "original" in local repo? No, but if I try enough, sometimes it works. (this is also why even before the dm-snapshot merge into archiso, the iso builds were about every 5-8 days. the crontab is daily but it fails often, and only sometimes it works)
weird :s
anyway, now I hit a new problem:
(..) 191420 extents written (373 MB) [mkarchiso] INFO: Done! | 374M archlinux-2011.08.05-core-x86_64.iso ===================================== =============== RELENG-REBUILD-IMAGES DUAL =============== ===================================== building dual images for i686 ERROR: i686 or x86_64 builds does not exist. usage build.sh net_iso_single | core_iso_single | all_iso_single | clean_single net_iso_dual | core_iso_dual | all_iso_dual | clean_dual
ERROR: ./build.sh all_iso_dual FAILED
the iso's do exist, but they are not in configs/releng/$work/i686/ and configs/releng/$work/x86_64/ like this script seems to assume. they are in configs/releng/
Nope, build.sh does not require "*.iso" (like archiso2dual) just use both working directories from single architectures. In other words, $work_dir/dual/iso is generated with links (hard) from $worr_dir/i686/iso and $work_dir/x86_64/iso
Ensure that you are executing build.sh in the same directory where these both directories exists (like with others build.sh commands)
PS: I have a commit in my experimental branch that allows working from other directory where "configs" reside, but this is another history...
Aha, I see the problem. How we've always done it so far, is to have a complete separate dir for i686 and x86_64, so that they can have different configs and whatnot. [dieter@alberich scripts]$ ls -alh /home/releng/configs-do-not-change-rsync-from-usr-share-i686/ total 16K drwxr-xr-x 4 root root 4.0K Aug 5 13:52 . drwxrws--- 14 releng releng 4.0K Aug 5 10:46 .. drwxr-xr-x 5 root root 4.0K Aug 5 13:52 baseline drwxr-xr-x 7 root root 4.0K Aug 5 14:25 releng [dieter@alberich scripts]$ ls -alh /home/releng/configs-do-not-change-rsync-from-usr-share-x86_64/ total 16K drwxr-xr-x 4 root root 4.0K Aug 5 13:52 . drwxrws--- 14 releng releng 4.0K Aug 5 10:46 .. drwxr-xr-x 5 root root 4.0K Aug 5 13:52 baseline drwxr-xr-x 7 root root 4.0K Aug 5 14:57 releng [dieter@alberich scripts]$ ls -alh /home/releng/configs-do-not-change-rsync-from-usr-share-x86_64/releng/work/ total 12K drwxr-xr-x 3 root root 4.0K Aug 5 14:25 . drwxr-xr-x 7 root root 4.0K Aug 5 14:57 .. drwxr-xr-x 9 root root 4.0K Aug 5 14:57 x86_64 [dieter@alberich scripts]$ ls -alh /home/releng/configs-do-not-change-rsync-from-usr-share-i686/releng/work/ total 12K drwxr-xr-x 3 root root 4.0K Aug 5 13:52 . drwxr-xr-x 7 root root 4.0K Aug 5 14:25 .. drwxr-xr-x 9 root root 4.0K Aug 5 14:25 i686 This doesn't work with the new system, because the work directory is different. However, I find it useful to have these directories complete separate, it gives a lot of freedom to do stuff. (not that we have needed that freedom, so far) So maybe I should mount --bind the work directory (or symlink them) so that they are the same. Or do you really think it's better that everything is done in the same directory? (as we have packages.$arch and work/$arch anyway to separate them somehow, maybe this could be extended further later, if we need it) Dieter
On 08/05/2011 11:54 AM, Dieter Plaetinck wrote:
On Fri, 05 Aug 2011 11:20:08 -0300 Gerardo Exequiel Pozzi<vmlinuz386@yahoo.com.ar> wrote:
On 08/05/2011 10:35 AM, Dieter Plaetinck wrote:
On Thu, 4 Aug 2011 13:37:29 -0700 (PDT) Gerardo Exequiel Pozzi<vmlinuz386@yahoo.com.ar> wrote:
----- Mensaje original -----
De: Dieter Plaetinck<dieter@plaetinck.be> Para: Gerardo Exequiel Pozzi<vmlinuz386@yahoo.com.ar>; Arch Linux Release Engineering<arch-releng@archlinux.org> CC: Enviado: jueves, 4 de agosto de 2011 17:24 Asunto: Re: [arch-releng] updates to releng scripts for new dm_snapshot archiso
On Thu, 4 Aug 2011 13:20:50 -0700 (PDT) Gerardo Exequiel Pozzi<vmlinuz386@yahoo.com.ar> wrote:
Do you check free space on all filesystems? yes, plenty of space (chroots are in /var/releng)
[dieter@alberich releng]$ df -h Filesystem Size Used Avail Use% Mounted on udev 10M 104K 9.9M 2% /dev /dev/mapper/vg-root 6.8G 3.5G 3.0G 55% / shm 1005M 0 1005M 0% /dev/shm /dev/sda1 54M 17M 34M 34% /boot /dev/mapper/vg-home 9.9G 4.1G 5.8G 42% /home /dev/mapper/vg-releng 30G 22G 8.6G 72% /var/releng /dev/mapper/vg-srv 25G 21G 4.5G 82% /srv
OK.
weird.
do you check how look (size, md5) libui pkg copied/downloaded compared with the "original" in local repo? No, but if I try enough, sometimes it works. (this is also why even before the dm-snapshot merge into archiso, the iso builds were about every 5-8 days. the crontab is daily but it fails often, and only sometimes it works) weird :s
anyway, now I hit a new problem:
(..) 191420 extents written (373 MB) [mkarchiso] INFO: Done! | 374M archlinux-2011.08.05-core-x86_64.iso ===================================== =============== RELENG-REBUILD-IMAGES DUAL =============== ===================================== building dual images for i686 ERROR: i686 or x86_64 builds does not exist. usage build.sh net_iso_single | core_iso_single | all_iso_single | clean_single net_iso_dual | core_iso_dual | all_iso_dual | clean_dual
ERROR: ./build.sh all_iso_dual FAILED
the iso's do exist, but they are not in configs/releng/$work/i686/ and configs/releng/$work/x86_64/ like this script seems to assume. they are in configs/releng/ Nope, build.sh does not require "*.iso" (like archiso2dual) just use both working directories from single architectures. In other words, $work_dir/dual/iso is generated with links (hard) from $worr_dir/i686/iso and $work_dir/x86_64/iso
Ensure that you are executing build.sh in the same directory where these both directories exists (like with others build.sh commands)
PS: I have a commit in my experimental branch that allows working from other directory where "configs" reside, but this is another history... Aha, I see the problem. How we've always done it so far, is to have a complete separate dir for i686 and x86_64, so that they can have different configs and whatnot.
[dieter@alberich scripts]$ ls -alh /home/releng/configs-do-not-change-rsync-from-usr-share-i686/ total 16K drwxr-xr-x 4 root root 4.0K Aug 5 13:52 . drwxrws--- 14 releng releng 4.0K Aug 5 10:46 .. drwxr-xr-x 5 root root 4.0K Aug 5 13:52 baseline drwxr-xr-x 7 root root 4.0K Aug 5 14:25 releng [dieter@alberich scripts]$ ls -alh /home/releng/configs-do-not-change-rsync-from-usr-share-x86_64/ total 16K drwxr-xr-x 4 root root 4.0K Aug 5 13:52 . drwxrws--- 14 releng releng 4.0K Aug 5 10:46 .. drwxr-xr-x 5 root root 4.0K Aug 5 13:52 baseline drwxr-xr-x 7 root root 4.0K Aug 5 14:57 releng [dieter@alberich scripts]$ ls -alh /home/releng/configs-do-not-change-rsync-from-usr-share-x86_64/releng/work/ total 12K drwxr-xr-x 3 root root 4.0K Aug 5 14:25 . drwxr-xr-x 7 root root 4.0K Aug 5 14:57 .. drwxr-xr-x 9 root root 4.0K Aug 5 14:57 x86_64 [dieter@alberich scripts]$ ls -alh /home/releng/configs-do-not-change-rsync-from-usr-share-i686/releng/work/ total 12K drwxr-xr-x 3 root root 4.0K Aug 5 13:52 . drwxr-xr-x 7 root root 4.0K Aug 5 14:25 .. drwxr-xr-x 9 root root 4.0K Aug 5 14:25 i686
This doesn't work with the new system, because the work directory is different. However, I find it useful to have these directories complete separate, it gives a lot of freedom to do stuff. (not that we have needed that freedom, so far) So maybe I should mount --bind the work directory (or symlink them) so that they are the same. Or do you really think it's better that everything is done in the same directory? (as we have packages.$arch and work/$arch anyway to separate them somehow, maybe this could be extended further later, if we need it)
Yes this is why I setup a "shared" working directory between two chroots with bind mount (explained in the new README). This allows, making dual isos in trivial way, using hardlinks, saving storage space, without needing to specify where are working directories for single architectures. TIP: Personally, to use few space (I work on 3.3GiB tmpfs), when "build.sh all_iso_single" ends, I execute # find work/i686 -mindepth 1 -maxdepth 1 ! -path work/i686/iso -prune | xargs rm -r and # find work/x86_64 -mindepth 1 -maxdepth 1 ! -path work/x86_64/iso -prune | xargs rm -r respectively. So I delete all things not needed by "build.sh all_iso_dual". Maybe these commands can be added to build.sh, something like "prune_tmp_single".
Dieter
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Fri, 05 Aug 2011 12:41:44 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
TIP: Personally, to use few space (I work on 3.3GiB tmpfs), when "build.sh all_iso_single" ends, I execute # find work/i686 -mindepth 1 -maxdepth 1 ! -path work/i686/iso -prune | xargs rm -r and # find work/x86_64 -mindepth 1 -maxdepth 1 ! -path work/x86_64/iso -prune | xargs rm -r respectively. So I delete all things not needed by "build.sh all_iso_dual". Maybe these commands can be added to build.sh, something like "prune_tmp_single".
yes, that seems useful. Anyway, we managed to get new builds. (we switched to ext3 for the chroots and did a `pacman -Scc` in the chroots. i would switch back to ext4 later to see if it breaks again, but first let's have it run like this for a while and see how well it works) images are at http://releng.archlinux.org/isos/2011.08.06/ they are completely untested. any feedback is welcome (on http://www.archlinux.org/releng/feedback/ and bugtracker if you find issues) Dieter
Am 06.08.2011 18:17, schrieb Dieter Plaetinck:
images are at http://releng.archlinux.org/isos/2011.08.06/ they are completely untested. any feedback is welcome (on http://www.archlinux.org/releng/feedback/ and bugtracker if you find issues)
The dual netinstall ISO boots on x86_64, so not entirely untested! Btw, with these ISOs, you can do this: 1) Copy the /arch folder from any of the ISOs to the root of any USB drive (stick must be vfat, ext2/3/4 or btrfs) 2) Run 'extlinux -i $PATH_TO_USB/arch/boot/syslinux/' 3) Run 'sed 's|ARCH_201108|filesystemlabeloftheusb|' -i $PATH_TO_USB/arch/boot/syslinux/*.cfg 4) Install MBR to the USB and mark the partition active After these steps, you have a bootable USB without overwriting your whole USB with dd. Just did that to my USB drive again, so I have an up-to-date Arch system on it.
On Sat, Aug 6, 2011 at 11:35 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Btw, with these ISOs, you can do this: 1) Copy the /arch folder from any of the ISOs to the root of any USB drive (stick must be vfat, ext2/3/4 or btrfs) 2) Run 'extlinux -i $PATH_TO_USB/arch/boot/syslinux/' 3) Run 'sed 's|ARCH_201108|filesystemlabeloftheusb|' -i $PATH_TO_USB/arch/boot/syslinux/*.cfg 4) Install MBR to the USB and mark the partition active
After these steps, you have a bootable USB without overwriting your whole USB with dd. Just did that to my USB drive again, so I have an up-to-date Arch system on it.
nice ... very cool! tried this last night to fix a btrfs prob i was having. maybe it was obvious (i didn't spend much time investigating), but once inside, is there simple access to the boot partition? IOW, if i put the /arch directory on a USB stick with a single partition, how can i get access to the rest of the partition/FS and it's free space? would 2 partitions be the only clear way ATM? since the boot partition is already mounted and im assuming the loopback images mounted over the top i'd think the original partition would need to be --bind mounted ... i know btrfs can be mounted multiple times but i dont know about ext* (i put mine on ext4 ... i mean i WAS fixing a btrfs problem after all :-). i could possibly reach in thru /proc/1/cwd but that's a bit hacky ... ... it would be super cool if there was a way to make updates persistent, eg. an overlay file that existed on the remainder of the original FS or something that the init process could detect (or a passed param). i *know* i did this with ubuntu at one time, but i cant remember the tool that produced said USB image ... -- C Anthony
----- Mensaje original -----
De: C Anthony Risinger <anthony@xtfx.me> Para: Arch Linux Release Engineering <arch-releng@archlinux.org> CC: Enviado: martes, 9 de agosto de 2011 16:48 Asunto: Re: [arch-releng] updates to releng scripts for new dm_snapshot archiso
On Sat, Aug 6, 2011 at 11:35 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Btw, with these ISOs, you can do this: 1) Copy the /arch folder from any of the ISOs to the root of any USB drive (stick must be vfat, ext2/3/4 or btrfs) 2) Run 'extlinux -i $PATH_TO_USB/arch/boot/syslinux/' 3) Run 'sed 's|ARCH_201108|filesystemlabeloftheusb|' -i $PATH_TO_USB/arch/boot/syslinux/*.cfg 4) Install MBR to the USB and mark the partition active
After these steps, you have a bootable USB without overwriting your whole USB with dd. Just did that to my USB drive again, so I have an up-to-date Arch system on it.
nice ... very cool! tried this last night to fix a btrfs prob i was having.
maybe it was obvious (i didn't spend much time investigating), but once inside, is there simple access to the boot partition? IOW, if i put the /arch directory on a USB stick with a single partition, how can i get access to the rest of the partition/FS and it's free space? would 2 partitions be the only clear way ATM? since the boot partition is already mounted and im assuming the loopback images mounted over the top i'd think the original partition would need to be --bind mounted ... i know btrfs can be mounted multiple times but i dont know about ext* (i put mine on ext4 ... i mean i WAS fixing a btrfs problem after all :-). i could possibly reach in thru /proc/1/cwd but that's a bit hacky ...
if you have other partitions just mount it. You can mount the same filesystem on differents locations without bind mounts. This is a VFS feature.
... it would be super cool if there was a way to make updates persistent, eg. an overlay file that existed on the remainder of the original FS or something that the init process could detect (or a passed param). i *know* i did this with ubuntu at one time, but i cant remember the tool that produced said USB image ...
I will send some changes that cow files are stored on real device instead of tmpfs. I expect to be accepted. Not really useful for official images, but for custom images can get benefit from it. But for better support I am wating for next initscripts/mkinitcpio for clean shutdown.
--
C Anthony
On Tue, Aug 9, 2011 at 3:06 PM, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
i know btrfs can be mounted multiple times but i dont know about ext* (i put mine on ext4 ... i mean i WAS fixing a btrfs problem after all :-). i could possibly reach in thru /proc/1/cwd but that's a bit hacky ...
if you have other partitions just mount it.
You can mount the same filesystem on differents locations without bind mounts. This is a VFS feature.
ah ok -- i knew i would be able to mount other partitions but i was curious about the boot partition -- i didn't know the VFS layer was handling this (multiple mounts same FS) ... maybe i thought it was a btrfs feature as i vaguely remember trying to mount an FS multiple times in the past and getting an "already mounted" type of error. this must have changed or i was doing something odd and didn't realize it ... who knows :-) thanks, i'll try it out.
... it would be super cool if there was a way to make updates persistent, eg. an overlay file that existed on the remainder of the original FS or something that the init process could detect (or a passed param). i *know* i did this with ubuntu at one time, but i cant remember the tool that produced said USB image ...
I will send some changes that cow files are stored on real device instead of tmpfs. I expect to be accepted. Not really useful for official images, but for custom images can get benefit from it.
But for better support I am wating for next initscripts/mkinitcpio for clean shutdown.
nice ... i like these boot/recovery USBs but i tend to need/want custom spins of certain <insert here> and i'm too lazy to spin my own images every time i want to tweak something; i would find your additions very useful. -- C Anthony
On Tue, Aug 9, 2011 at 3:21 PM, C Anthony Risinger <anthony@xtfx.me> wrote:
On Tue, Aug 9, 2011 at 3:06 PM, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
if you have other partitions just mount it.
You can mount the same filesystem on differents locations without bind mounts. This is a VFS feature.
thanks, i'll try it out.
well 5 seconds of looking for myself reveals: ) why yes, you can indeed mount whatever, wherever, whenever ) the boot partition is available at /bootmnt ) ... im 100% loving these images :-) thanks again guys -- good stuff. -- C Anthony
On 08/09/2011 05:21 PM, C Anthony Risinger wrote:
i know btrfs can be mounted multiple times but i dont know about ext* (i put mine on ext4 ... i mean i WAS fixing a btrfs problem after all :-). i could possibly reach in thru /proc/1/cwd but that's a bit hacky ... if you have other partitions just mount it.
You can mount the same filesystem on differents locations without bind mounts. This is a VFS feature. ah ok -- i knew i would be able to mount other partitions but i was curious about the boot partition -- i didn't know the VFS layer was handling this (multiple mounts same FS) ... maybe i thought it was a btrfs feature as i vaguely remember trying to mount an FS multiple times in the past and getting an "already mounted" type of error.
On Tue, Aug 9, 2011 at 3:06 PM, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote: this must have changed or i was doing something odd and didn't realize it ... who knows :-) thanks, i'll try it out.
"already mounted" if you try to mount with other fs-options. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Am 09.08.2011 21:48, schrieb C Anthony Risinger:
On Sat, Aug 6, 2011 at 11:35 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Btw, with these ISOs, you can do this: 1) Copy the /arch folder from any of the ISOs to the root of any USB drive (stick must be vfat, ext2/3/4 or btrfs) 2) Run 'extlinux -i $PATH_TO_USB/arch/boot/syslinux/' 3) Run 'sed 's|ARCH_201108|filesystemlabeloftheusb|' -i $PATH_TO_USB/arch/boot/syslinux/*.cfg 4) Install MBR to the USB and mark the partition active
After these steps, you have a bootable USB without overwriting your whole USB with dd. Just did that to my USB drive again, so I have an up-to-date Arch system on it.
nice ... very cool! tried this last night to fix a btrfs prob i was having.
maybe it was obvious (i didn't spend much time investigating), but once inside, is there simple access to the boot partition? IOW, if i put the /arch directory on a USB stick with a single partition, how can i get access to the rest of the partition/FS and it's free space?
Have a look at /bootmnt/. You need to run mount -o remount,rw /bootmnt though to write to it - and I would recommend remounting read-only before shutting down as well.
would 2 partitions be the only clear way ATM?
Two partitions are actually bad. Right now, I use vfat for compatibility with Windows machines - Windows is very easily confused with USB drives with more than one partition.
On Thu, 04 Aug 2011 11:46:50 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 08/04/2011 05:10 AM, Dieter Plaetinck wrote:
Hi, I've been updating the releng scripts for the new archiso (all my changes are in this commit: http://pastie.org/2318603) Good! It seems to build the i686 iso's succesfully, but fails for x86_64 and I have no idea why. I only know `./build.sh all_iso_single` failed (exited>0) in the x86_64 chroot, but it doesn't give me any errors. See below. Could it be because I do a `./build.sh clean_single` and `./build.sh clean_dual` first? (before doing x86_64, after i686). I know you gave instructions at http://mailman.archlinux.org/pipermail/arch-releng/2011-June/001835.html, but they don't mention when exactly i should do which clean commands. clean commands remove files created by build commands on current architecture.
clean_single $workdir/$arch + $arch.iso
clean_dual $workdir/dual + dual.iso
huh? i don't understand the above commands, what's the $arch.iso command? it doesn't seem like an argument build.sh understands (as you listed those at http://mailman.archlinux.org/pipermail/arch-releng/2011-June/001835.html ) how about this? 1) share a common directory between two chroots (32 and 64 bits) for working directory. 2) execute in 32 bits chroot: ./build.sh clean_single && ./build.sh all_iso_single 3) execute in 64 bits chroot: ./build.sh clean_single && ./build.sh all_iso_single 4) execute in any chroot : ./build.sh clean_dual && ./build.sh all_iso_dual
----- Mensaje original -----
De: Dieter Plaetinck <dieter@plaetinck.be> Para: Arch Linux Release Engineering <arch-releng@archlinux.org> CC: vmlinuz386@yahoo.com.ar Enviado: jueves, 4 de agosto de 2011 12:40 Asunto: Re: [arch-releng] updates to releng scripts for new dm_snapshot archiso
On Thu, 04 Aug 2011 11:46:50 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 08/04/2011 05:10 AM, Dieter Plaetinck wrote:
Hi, I've been updating the releng scripts for the new archiso (all my changes are in this commit: http://pastie.org/2318603) Good! It seems to build the i686 iso's succesfully, but fails for x86_64 and I have no idea why. I only know `./build.sh all_iso_single` failed (exited>0) in the x86_64 chroot, but it doesn't give me any errors. See below. Could it be because I do a `./build.sh clean_single` and `./build.sh clean_dual` first? (before doing x86_64, after i686). I know you gave instructions at
http://mailman.archlinux.org/pipermail/arch-releng/2011-June/001835.html,
but they don't mention when exactly i should do which clean commands. clean commands remove files created by build commands on current architecture.
clean_single $workdir/$arch + $arch.iso
clean_dual $workdir/dual + dual.iso
huh? i don't understand the above commands, what's the $arch.iso command? it doesn't seem like an argument build.sh understands (as you listed those at http://mailman.archlinux.org/pipermail/arch-releng/2011-June/001835.html ) how about this?
Is the answer to what are doing (removing) the commands clean_single and clean_dual (in simplified way)
1) share a common directory between two chroots (32 and 64 bits) for working directory. 2) execute in 32 bits chroot: ./build.sh clean_single && ./build.sh all_iso_single 3) execute in 64 bits chroot: ./build.sh clean_single && ./build.sh all_iso_single 4) execute in any chroot : ./build.sh clean_dual && ./build.sh all_iso_dual
participants (4)
-
C Anthony Risinger
-
Dieter Plaetinck
-
Gerardo Exequiel Pozzi
-
Thomas Bächler