[arch-releng] [archiso] pxe_curl/pxe_nfs now in master ;)
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) -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Mon, 28 Nov 2011 12:37:11 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> 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
On 11/28/2011 12:43 PM, Dieter Plaetinck wrote:
On Mon, 28 Nov 2011 12:37:11 -0300 Gerardo Exequiel Pozzi<vmlinuz386@yahoo.com.ar> 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 -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
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<vmlinuz386@yahoo.com.ar> 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: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).
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:59 PM, Thomas Bächler wrote:
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}} Or $ bsdtar -x --exclude=syslinux --exclude memtest* -f archlinux-$VERSION-netinstall-dual.iso arch
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
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
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.
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
Am 28.11.2011 17:10, schrieb Gerardo Exequiel Pozzi:
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.
I agree. You can extract the ISO with bsdtar, so there is no reason for an extra tarball.
On Mon, 28 Nov 2011 13:10:13 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> 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
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. [1] https://mailman.archlinux.org/pipermail/arch-releng/2011-November/002220.htm...
On Mon, 28 Nov 2011 17:32:02 +0100 Thomas Bächler <thomas@archlinux.org> 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
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.
On Tue, 29 Nov 2011 11:07:52 +0100 Thomas Bächler <thomas@archlinux.org> 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
Am 29.11.2011 11:10, schrieb Dieter Plaetinck:
On Tue, 29 Nov 2011 11:07:52 +0100 Thomas Bächler <thomas@archlinux.org> 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.
Gerardo posted a very short command above (slightly modified by me): $ bsdtar -x --exclude=arch/boot/syslinux --exclude memtest* -f archlinux-$date-netinstall-dual.iso arch/ This is all we need.
On Mon, Nov 28, 2011 at 12:37:11PM -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)
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
You should enable the post-receive hook in the archiso.git repo on gerolde. We'll get notification of this sort of stuff automatically like we do for mkinitcpio, initscripts, pacman... Nice work. This is pretty exciting. d
Am 28.11.2011 16:53, schrieb Dave Reisner:
You should enable the post-receive hook in the archiso.git repo on gerolde. We'll get notification of this sort of stuff automatically like we do for mkinitcpio, initscripts, pacman...
Nice work. This is pretty exciting.
d
Gerardo only has a git-shell account. I can set this up later if I don't forget.
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!
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 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
Am 29.11.2011 11:16, 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!
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 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.
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. However, you still need to create the libnss_*.so.2 symlinks manually right now.
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
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.
----- Mensaje original -----
De: Thomas Bächler <thomas@archlinux.org> 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 19:52, schrieb Gerardo Exequiel Pozzi:
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
Alright. I'll keep using ip=dhcp without IPAPPEND for now. Btw, there is a homepage now, and one working image: https://releng.archlinux.org/pxeboot/
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.
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.
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.
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.
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
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?
btw: http://releng.archlinux.org/pxeboot/boot/cfg/gen_config.sh -> 403
Well, yes - you don't need to download it.
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, Nov 29, 2011 at 6:18 AM, Thomas Bächler <thomas@archlinux.org> wrote:
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.
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.
wow ... very cool. i like how the boot image is only 304K -- after selecting the real image, i was looking at a prompt about 30sec later ... neat :-) i didn't have 1G of ram to use at that moment, so i tried 512M instead, seemed to work ok ... whats the minimum? might be a bit bandwidth intensive tho -- would be cool to see flurry/torrent-like method (eg, libtorrent) of gathering the images ... might be a bit "out there", but i would seed the images ;-), and i have a pretty nice connection. -- C Anthony
On Tue, 29 Nov 2011 21:27:53 -0600 C Anthony Risinger <anthony@xtfx.me> wrote:
wow ... very cool. i like how the boot image is only 304K
www.stopabusingsiprefixes.org
On Wed, Nov 30, 2011 at 3:23 AM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Tue, 29 Nov 2011 21:27:53 -0600 C Anthony Risinger <anthony@xtfx.me> 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!!! -- C Anthony
On Wed, 30 Nov 2011 04:32:35 -0600 C Anthony Risinger <anthony@xtfx.me> wrote:
On Wed, Nov 30, 2011 at 3:23 AM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Tue, 29 Nov 2011 21:27:53 -0600 C Anthony Risinger <anthony@xtfx.me> 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
Am 30.11.2011 04:27, schrieb C Anthony Risinger:
i didn't have 1G of ram to use at that moment, so i tried 512M instead, seemed to work ok ... whats the minimum?
I didn't compute it. You need almost 200MB for the downloaded files, and a few MB to run Linux. You can try 256MB.
might be a bit bandwidth intensive tho -- would be cool to see flurry/torrent-like method (eg, libtorrent) of gathering the images ... might be a bit "out there", but i would seed the images ;-), and i have a pretty nice connection.
The initramfs is already 17MB, more clients make it bigger. The plan is to provide a mirror selection when downloading releases - of course, there is no release yet that supports booting over http.
On 11/29/2011 07:16 AM, Thomas Bächler wrote:
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.
brb! I always use bad add_symlink()! (confusion with ln -s) add_symlink symlink file ln -s file symlink Fixed on master. commit f3a3526ab01ceea9cf84828c44a718a46f6311ee Author: Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> Date: Tue Nov 29 09:39:30 2011 -0300 [archiso] Fix libnss symlinks. Otherwise does not work. 22100 Nov 29 09:29 ./lib/libnss_dns-2.14.1.so 20 Nov 29 09:29 ./lib/libnss_dns.so.2 -> libnss_dns-2.14.1.so 46732 Nov 29 09:29 ./lib/libnss_files-2.14.1.so 22 Nov 29 09:29 ./lib/libnss_files.so.2 -> libnss_files-2.14.1.so Looks like my test was made before introducing symlinks and using directly libnss_dns-$VERSION.so.2 as libnss_dns.so.2. Signed-off-by: Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> diff --git a/archiso/install/archiso_pxe_common b/archiso/install/archiso_pxe_common index 7dc1ebb..ce54f7a 100644 --- a/archiso/install/archiso_pxe_common +++ b/archiso/install/archiso_pxe_common @@ -18,9 +18,9 @@ build () add_binary "/lib/initcpio/ipconfig" "/bin/ipconfig" # Add hosts support files+dns - add_symlink $(readlink /lib/libnss_files.so.2) /lib/libnss_files.so.2 + add_symlink /lib/libnss_files.so.2 $(readlink /lib/libnss_files.so.2) add_binary $(readlink -f /lib/libnss_files.so.2) - add_symlink $(readlink /lib/libnss_dns.so.2) /lib/libnss_dns.so.2 + add_symlink /lib/libnss_dns.so.2 $(readlink /lib/libnss_dns.so.2) add_binary $(readlink -f /lib/libnss_dns.so.2) echo "hosts: files dns" > $BUILDROOT/etc/nsswitch.conf } . -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
participants (5)
-
C Anthony Risinger
-
Dave Reisner
-
Dieter Plaetinck
-
Gerardo Exequiel Pozzi
-
Thomas Bächler