On 11/28/2011 12:54 PM, Gerardo Exequiel Pozzi wrote:

On 11/28/2011 12:43 PM, Dieter Plaetinck wrote:

...

On Mon, 28 Nov 2011 12:37:11 -0300 Gerardo Exequiel Pozzi wrote:

...

Not that mkinitcpio-0.8.0 hits core, I pushed all archiso patched to master. Wait for next next testbuild, or build yourself!

5b9eba9 [archiso] Add checksum support to pxe_curl cd359bc [archiso] Checksum only aitab and *.sfs (per architecture) 0411fc9 [configs/releng] Make all syslinux bootloaders works with the sames configs. 8bd0674 [archiso] Add DNS resolver support to archiso_pxe_common 76dea16 [archiso] Add PXE NFS support 8eb4c62 [archiso] Add archiso_pxe_curl hook 1edaf15 [archiso] Split archiso_pxe_nbd in two hooks. 4096546 [configs/*] chroot to root-image for initramfs build 334db09 [archiso] Check if /run/archiso/bootmnt is a mountpoint. f097724 [archiso] Only accepts aitab inside e03ed81 [archiso] Use different logic when archisodevice == cow_device e135003 [archiso] simplify _mnt_dev() (mount is now from util-linux)

there's probably a bunch of pxe/archiso stuff that should become mentioned/explained in the official install guide. if you're willing to write the initial draft I could review it and fix the language mistakes, at least in so far I can find them. http://projects.archlinux.org/aif.git/tree/doc/official_installation_guide_e...

Dieter

I am just writing at this moment in https://wiki.archlinux.org/index.php/Archiso_as_pxe_server

Draft at: https://wiki.archlinux.org/index.php/Archiso_as_pxe_server#HTTP.2FFTP_and_NF... -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1

Am 28.11.2011 16:49, schrieb Thomas Bächler:

Am 28.11.2011 16:37, schrieb Gerardo Exequiel Pozzi:

...

Not that mkinitcpio-0.8.0 hits core, I pushed all archiso patched to master. Wait for next next testbuild, or build yourself!

5b9eba9 [archiso] Add checksum support to pxe_curl cd359bc [archiso] Checksum only aitab and *.sfs (per architecture) 0411fc9 [configs/releng] Make all syslinux bootloaders works with the sames configs. 8bd0674 [archiso] Add DNS resolver support to archiso_pxe_common 76dea16 [archiso] Add PXE NFS support 8eb4c62 [archiso] Add archiso_pxe_curl hook 1edaf15 [archiso] Split archiso_pxe_nbd in two hooks. 4096546 [configs/*] chroot to root-image for initramfs build 334db09 [archiso] Check if /run/archiso/bootmnt is a mountpoint. f097724 [archiso] Only accepts aitab inside e03ed81 [archiso] Use different logic when archisodevice == cow_device e135003 [archiso] simplify _mnt_dev() (mount is now from util-linux)

Can you also build a .tar file of everything but the bootloader files and the core sfs? That would be:

checksums aitab sfs (except core) kernels initramfs

I want to use this for my internet boot stuff (as an alternative, we could extract the netinstall-dual ISO in the releng scripts and delete the bootloader files, not sure what is better).

I think this could be done in releng: Dieter, what about this: After the ISOs have been made, run this (in the ISO folder): $ bsdtar -xf archlinux-$VERSION-netinstall-dual.iso arch/ $ chmod -R u+w arch/ $ rm -r arch/boot/{syslinux,memtest{,.COPYING}} This way, every ISO folder would have a subdirectory arch/ with the files I need: $ LANG=C ls -RF arch arch: aitab any/ boot/ checksum.md5 i686/ x86_64/ arch/any: usr-share.fs.sfs arch/boot: i686/ x86_64/ arch/boot/i686: archiso.img vmlinuz arch/boot/x86_64: archiso.img vmlinuz arch/i686: lib-modules.fs.sfs root-image.fs.sfs arch/x86_64: lib-modules.fs.sfs root-image.fs.sfs

On 11/28/2011 12:49 PM, Thomas Bächler wrote:

Am 28.11.2011 16:37, schrieb Gerardo Exequiel Pozzi:

...

Not that mkinitcpio-0.8.0 hits core, I pushed all archiso patched to master. Wait for next next testbuild, or build yourself!

5b9eba9 [archiso] Add checksum support to pxe_curl cd359bc [archiso] Checksum only aitab and *.sfs (per architecture) 0411fc9 [configs/releng] Make all syslinux bootloaders works with the sames configs. 8bd0674 [archiso] Add DNS resolver support to archiso_pxe_common 76dea16 [archiso] Add PXE NFS support 8eb4c62 [archiso] Add archiso_pxe_curl hook 1edaf15 [archiso] Split archiso_pxe_nbd in two hooks. 4096546 [configs/*] chroot to root-image for initramfs build 334db09 [archiso] Check if /run/archiso/bootmnt is a mountpoint. f097724 [archiso] Only accepts aitab inside e03ed81 [archiso] Use different logic when archisodevice == cow_device e135003 [archiso] simplify _mnt_dev() (mount is now from util-linux)

Can you also build a .tar file of everything but the bootloader files and the core sfs? That would be:

checksums aitab sfs (except core) kernels initramfs

I want to use this for my internet boot stuff (as an alternative, we could extract the netinstall-dual ISO in the releng scripts and delete the bootloader files, not sure what is better).

OK: Just for confirmation, what your want is this inside a tarball: $ tree arch -I syslinux arch ├── aitab ├── any │ └── usr-share.fs.sfs ├── boot │ ├── i686 │ │ ├── archiso.img │ │ └── vmlinuz │ ├── memtest │ ├── memtest.COPYING │ └── x86_64 │ ├── archiso.img │ └── vmlinuz ├── checksum.i686.md5 ├── checksum.x86_64.md5 ├── i686 │ ├── lib-modules.fs.sfs │ └── root-image.fs.sfs └── x86_64 ├── lib-modules.fs.sfs └── root-image.fs.sfs (remove memtest?) It can be done in config/releng/build.sh. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1

On 11/28/2011 01:06 PM, Thomas Bächler wrote:

Am 28.11.2011 17:02, schrieb Gerardo Exequiel Pozzi:

...

OK: Just for confirmation, what your want is this inside a tarball:

$ tree arch -I syslinux arch ├── aitab ├── any │ └── usr-share.fs.sfs ├── boot │ ├── i686 │ │ ├── archiso.img │ │ └── vmlinuz │ ├── memtest │ ├── memtest.COPYING │ └── x86_64 │ ├── archiso.img │ └── vmlinuz ├── checksum.i686.md5 ├── checksum.x86_64.md5 ├── i686 │ ├── lib-modules.fs.sfs │ └── root-image.fs.sfs └── x86_64 ├── lib-modules.fs.sfs └── root-image.fs.sfs

(remove memtest?)

It can be done in config/releng/build.sh. Exactly, remove memtest. What I need in the end is this extracted as a subfolder of http://releng.archlinux.org/isos/$VERSION/. As stated in another post, this could also be done in the releng script, by extracting the netinstall-dual ISO with bsdtar. I don't know which way to prefer, as long as the files are there in the end.

Yes. Waiting for Dieter answer. But I think making a tarball is a bit reduntant, anyway releng scripts should extract it in the correct location. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1

On Mon, 28 Nov 2011 13:10:13 -0300 Gerardo Exequiel Pozzi wrote:

On 11/28/2011 01:06 PM, Thomas Bächler wrote:

...

...

OK: Just for confirmation, what your want is this inside a tarball:

$ tree arch -I syslinux arch ├── aitab ├── any │ └── usr-share.fs.sfs ├── boot │ ├── i686 │ │ ├── archiso.img │ │ └── vmlinuz │ ├── memtest │ ├── memtest.COPYING │ └── x86_64 │ ├── archiso.img │ └── vmlinuz ├── checksum.i686.md5 ├── checksum.x86_64.md5 ├── i686 │ ├── lib-modules.fs.sfs │ └── root-image.fs.sfs └── x86_64 ├── lib-modules.fs.sfs └── root-image.fs.sfs

(remove memtest?)

It can be done in config/releng/build.sh. Exactly, remove memtest. What I need in the end is this extracted as a subfolder of http://releng.archlinux.org/isos/$VERSION/. As stated in another post, this could also be done in the releng

Am 28.11.2011 17:02, schrieb Gerardo Exequiel Pozzi: script, by extracting the netinstall-dual ISO with bsdtar. I don't know which way to prefer, as long as the files are there in the end.

Yes. Waiting for Dieter answer. But I think making a tarball is a bit reduntant, anyway releng scripts should extract it in the correct location.

yes, it seems trivial to script the extracting of an iso in the releng scripts. however, since this effectively produces another "installation medium" I think it makes more sense to perform this in build.sh (or whatever); this also makes it easier for others who want to build the same end-product (the dir with files) themselves. Dieter

On Mon, 28 Nov 2011 17:32:02 +0100 Thomas Bächler wrote:

Am 28.11.2011 17:16, schrieb Dieter Plaetinck:

...

yes, it seems trivial to script the extracting of an iso in the releng scripts. however, since this effectively produces another "installation medium" I think it makes more sense to perform this in build.sh (or whatever); this also makes it easier for others who want to build the same end-product (the dir with files) themselves.

Actually, it is not a new medium: It is the netinstall-dual ISO with files removed (the removal of files is unnecessary, but I like things minimalistic).

I think you should add the commands I posted in the other mail [1] to the releng scripts instead. It doesn't matter to me that much, I would just love to get this done before the next ISO build, so I can write and test scripts that autogenerate the syslinux configs for my netboot.

so how about users who want to create this directory with files themselves? shouldn't they have an easy way to do it? (having them setup the releng environment != easy) Dieter

On Tue, 29 Nov 2011 11:07:52 +0100 Thomas Bächler wrote:

Am 29.11.2011 11:00, schrieb Dieter Plaetinck:

...

...

It doesn't matter to me that much, I would just love to get this done before the next ISO build, so I can write and test scripts that autogenerate the syslinux configs for my netboot.

so how about users who want to create this directory with files themselves? shouldn't they have an easy way to do it? (having them setup the releng environment != easy)

They mount or extract the ISO, same as we do. I don't quite understand what your question is.

okay, in that case, yes it's fine to do it in the releng environment. Dieter

On 11/29/2011 09:13 AM, Thomas Bächler wrote:

Am 29.11.2011 11:16, schrieb Thomas Bächler:

...

...

Not that mkinitcpio-0.8.0 hits core, I pushed all archiso patched to master. Wait for next next testbuild, or build yourself!

8bd0674 [archiso] Add DNS resolver support to archiso_pxe_common The DNS resolver does not work. First, the symlinks /lib/libnss_{files,dns}.so.2 are missing, only the

Am 28.11.2011 16:37, schrieb Gerardo Exequiel Pozzi: libnss_{files,dns}-2.14.1.so are there.

If I create the right symlinks, the resolver seems to do something, but times out. Using an IP address works fine. I don't know what's wrong with the resolver, I might have a look later.

I inserted an IP address instead of a name for the moment, you can try netbooting by running qemu -m 1G -kernel gpxe.lkrn [1] Download takes a while, but the image boots up fine.

[1] https://releng.archlinux.org/pxeboot/gpxe_text.lkrn Okay, I think I found the problem:

The ip= command line option doesn't pass a DNS server! The ipconfig utility simply uses the same as the remote server - which is wrong in the case of qemu.

Instead of IPAPPEND 3, I now use ip=dhcp and the resolver works. The issue will be when machine has two or more network devices. You need to pass manually BOOTIF option, otherwise ipconfig will setup all network devices with the same settings.

-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1

----- Mensaje original -----

De: Thomas Bächler Para: arch-releng@archlinux.org CC: Enviado: martes, 29 de noviembre de 2011 13:16 Asunto: Re: [arch-releng] [archiso] pxe_curl/pxe_nfs now in master ;)

Am 29.11.2011 14:06, schrieb Gerardo Exequiel Pozzi:

...

...

Instead of IPAPPEND 3, I now use ip=dhcp and the resolver works. The issue will be when machine has two or more network devices. You need to pass manually BOOTIF option,

More issues: If I use "IPAPPEND 2" (appends BOOTIF=) in combination with ip=dhcp, ipconfig bails out.

If I use "IPAPPEND 3", pxelinux doesn't pass a DNS, and thus resolution in initramfs may fail.

For now, just adding "ip=dhcp" without BOOTIF seems to work fine, but I only use one network interface.

...

otherwise ipconfig will setup all network devices with the same settings.

Wow. I thought it would configure the interface where it gets a DHCP reply. Weird.

When using ip=dhcp no issue, ipconfig will try to set via dhcp all interfaces. Of course if no dhcp response is received from other interfaces.  The problem is when you pass ip= with some ip (for example from the response of DHCP passed via IPAPPEND) without setting a net device. For example running ipconfig ip=192.168.0.7:192.168.0.1:192.168.0.1:255.255.255.0

Am 29.11.2011 11:16, schrieb Thomas Bächler:

I inserted an IP address instead of a name for the moment, you can try netbooting by running qemu -m 1G -kernel gpxe.lkrn [1] Download takes a while, but the image boots up fine.

[1] https://releng.archlinux.org/pxeboot/gpxe_text.lkrn

For testing better use this: qemu -net nic,model=virtio -net user -m 1G -kernel gpxe.lkrn Without the virtio interface, download rates are tiny. With virtio, I just downloaded the images with almost 3MB/s.

On 11/29/2011 01:13 PM, Thomas Bächler wrote:

Am 29.11.2011 13:18, schrieb Thomas Bächler:

...

Am 29.11.2011 11:16, schrieb Thomas Bächler:

...

I inserted an IP address instead of a name for the moment, you can try netbooting by running qemu -m 1G -kernel gpxe.lkrn [1] Download takes a while, but the image boots up fine.

[1] https://releng.archlinux.org/pxeboot/gpxe_text.lkrn For testing better use this: qemu -net nic,model=virtio -net user -m 1G -kernel gpxe.lkrn Without the virtio interface, download rates are tiny. With virtio, I just downloaded the images with almost 3MB/s. This was a false alert: Due to some local transparent proxy, I had better speed when booting it the second time.

I want such internet connection! :P You can remove archisobasedir=arch from bootparam, is the default ;) This start looking good. If you need some help please let me know. btw: http://releng.archlinux.org/pxeboot/boot/cfg/gen_config.sh -> 403 -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1

On 11/30/2011 06:44 AM, Thomas Bächler wrote:

Am 30.11.2011 03:29, schrieb Gerardo Exequiel Pozzi:

...

You can remove archisobasedir=arch from bootparam, is the default ;) This start looking good. If you need some help please let me know. Actually, I do: It is impossible to set archisobasedir to an empty string - archiso will set "arch" as a default if it is empty. Should I use archisobasedir=/ in such cases? Yes. Set as "/" ;) btw: http://releng.archlinux.org/pxeboot/boot/cfg/gen_config.sh -> 403 Well, yes - you don't need to download it.

I know, most users do not need it, just I am curious. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1

On Tue, 29 Nov 2011 21:27:53 -0600 C Anthony Risinger wrote:

wow ... very cool. i like how the boot image is only 304K

www.stopabusingsiprefixes.org

On Wed, 30 Nov 2011 04:32:35 -0600 C Anthony Risinger wrote:

On Wed, Nov 30, 2011 at 3:23 AM, Dieter Plaetinck wrote:

...

On Tue, 29 Nov 2011 21:27:53 -0600 C Anthony Risinger wrote:

...

wow ... very cool.  i like how the boot image is only 304K

www.stopabusingsiprefixes.org

bah! i was under the impression that omitting the `B` in this context was accepted as meaning binary, specifically because the SI prefix for `kilo` is a lowercase `k`. tbh, i think i just read this somewhere recently, probably wikipedia:

http://en.wikipedia.org/wiki/JEDEC_memory_standards

... i know several tools behave this way -- the `qemu` command in this thread uses G or M, `parted` uses binary units for K/M/G (and SI for the variants that include the `b`), and i know there is at least one other ... IIRC `parted` behaving this way is what got me reading up on it in the first place :-)

but really, i wholly agree -- the entire situation is somewhat ridiculous -- everything in the industry is binary-based and there is no reason for anyone/anywhere/anytime to use the suffixes in the context of computing with the SI meaning ...

... ehm, well, unless you're a hard disk manufacturer with a shady/greedy marketing team and an unethical intention of duping the 90% who likely DGAF (then), and still DGAF :-(now) ... thanks guys!!!

JEDEC is a disgrace to [computer] science. they do more harm than good. (they formalize and promote incorrect usage of SI prefixes) I see they succeeded at confusing you. Dieter