You are not logged in.

#1 2014-12-04 19:58:56

penright14
Member
Registered: 2014-11-20
Posts: 35

[SOLVED] PXE boot a remaster ISO on Windows TFTPD

[Note: Someone who knows better can correct me. Also should this be added to a wiki somewhere? I might have misunderstood, but all the wiki's I saw was how to network boot using a Linux box and as I learned my issue was trying it from a windows box.]

Solved.....
Setting the stage:
The biggest issue was me taking for granted the "pxe" boot environment. I thought it was some what standard, but just like booting from a hard drive, "network booting" has many different ways. Here is the list I have tried so far, pxelinux.0, ipxe, and grldr. Also, PXE is the code burned into the nic rom. I am looking at this way, PXE is the first stage and (pxelinux.0, ipxe, grldr) are the 1.5 stage. IPXE was written to replace PXE. PXE can only use TFTP to load the 1.5 stage, where as IPXE supports TFTP, HTTP, NFS, and so on. The is a IPXE bin version that PXE (so you don't have to change the network boot rom) will chain load to, but I did not mess with that. After PXE has chain to the IPXE, you are still at a 1.5 stage boot.

The answer:
My Rosetta stone was this web site. http://sysphere.org/~anrxc/j/archives/2 … rch_linux/
There were several points that was gleaned from the web site. First was how to get the initrd img. Using the the install disk as per the web site I was able to get a working initrd .img (initramfs_x86_64.img). Then I was able to find the correct kernel parameters to pxe boot it.

label linux
kernel images/arch/arch-installer/amd64/vmlinuz_x86_64
append initrd=images/arch/arch-installer/amd64/initramfs_x86_64.img gpt panic=60 vga=normal loglevel=3

Now I am halfway there. I know I want the initramfs-linux.img out of the boot in the "working" directory. I think my next hurdle is, the initramfs-linux.img expects the archiso.img somewhere/how. I need to figure out how to make a initramfs with all the stuff I need, since I can not depend on HTTP or NFS to finish loading the file system.

One of the things I learned is about mkinitcpio and  lstinitcpio. To build my initramfs archiso might not be the right tool. I am starting to think all I have to do is create a archlinx install inside of my host archlinux environment and use mkinitcpio to build the initramfs and kernel. I am thinking I will save this discussion for a new thread. This one is about worn out. :-) Not sure if that discussion is a newbie one or not (open to suggestions) If I do start a new post, I will come back here and update this line with the URL.


Original Post ........
I currently have a remaster rootfs from a live cd P.I.N.G http://www.windowsdream.com/ping.html. It my understanding it was built off of LFS.
The issue is the kernel needed for newer hardware has passed the rootfs libs. Since it is stripped down, I can not chroot to make updates. I have been just patching the files, building a new loop 'initrd', compressing it 'initrd.gz' then skipping the step to make the actual ISO. Then with the kernel and initrd.gz file, I can PXE boot it or grub4dos boot the same 'initrd.gz' file. Latter I will give both the menu.lst and pxelinux.cfg/default boot configurations. In the past I did not know ground level how the boot process worked, I was able to make what I need work from a 30,000 foot understanding.

I am thinking that arch linux using archiso would give me the best chance to maintain a what was my initrd.gz. For me to do this I need to understand both archiso build and boot processes. I started by remastering a baseline archiso and the iso did boot. I notice it pre-boot was a lot different. I guess I will start to try and understand the boot process for both LFS and Archlinux better.

I know there is not a question yet....
1. Any 30,000 foot pointers as I get started? (BTW, I am studing the wiki http://www.syslinux.org/wiki/index.php/PXELINUX)
2. Looks like archlinux has both x86 and 64bit enviroments, all I need is 64bit. Does this help make it simpler?
3. Is there a "What can I delete from a rootfs" if there will not be any updates once it is built?

The really good questions will come once I start to understand things better and can ask them. I have to start somewhere. :-)

oops, forgot to post the grub4dos (menu.lst) and pxelinux.0/default
Again all of the linux load the same image, I just control the scripts with kernel parameters.
One other note, the menu.lst handles the windows boot also. The windows back office has two hard drives that are cloned, but not mirrored. Then at certain times databases are back up, but not the whole drive. That way when windows dll corrupts, the second hard drive will still boot.  The (tech 1 to 2) label will "re-clone" after some install (registry changes for example). It boot the same rootfs that the pxe serves. Then the two window partitions are mounted. They have labels "Primary" and "Backup" to make sure the right mount points are hit. Then a simple rsync happens. I can do all this with a batch file. Just set the default label in the menu.lst to the 'tech 1 to 2' and boot. Then Linux runs the script at start up, then sets the default able back to windows and boots. Then we are back in windows. We have over 285 locations doing this.

pexlinux.0/default

DEFAULT LoadNoPrompts
PROMPT 1
TIMEOUT 0
DISPLAY boot.txt


LABEL autoimage
KERNEL kernel
APPEND pxe init=/linuxrc root=/dev/ram0 rw noapic nolapic lba devfs=nomount ramdisk_size=60000 load_ramdis=1 promp_ramdisk=0 initrd=initrd.gz vga=normal pci=noacpi acpi=off apm=off Server=10.77.77.30 Share=PartImage$ user=PartImageShare passwd=PingAcess1 Directory=/ CIFS_Preferred=Y Image_To_Restore=Auto_Sda_Hda Restore_Only=Y After_Completion=shell AUTO=Y Extend_Parts_Whenever_Possible=N If_Hda_Image_To_Restore=xx23 If_Sda_Image_To_Restore=xx56 Restore_BIOS=N Version_File_List=VersionFileList.txt

LABEL Par7700
KERNEL kernel
APPEND pxe init=/linuxrc root=/dev/ram0 rw noapic nolapic lba devfs=nomount ramdisk_size=60000 load_ramdis=1 promp_ramdisk=0 initrd=initrd.gz vga=normal pci=noacpi acpi=off apm=off Server=10.77.77.30 Share=PartImage$ user=PartImageShare passwd=PingAcess1 Directory=/ CIFS_Preferred=Y Image_To_Restore=Auto_Sda_Hda Restore_Only=Y After_Completion=shell AUTO=Y Extend_Parts_Whenever_Possible=N If_Hda_Image_To_Restore=xx23 If_Sda_Image_To_Restore=Par7700 Restore_BIOS=N Version_File_List=VersionFileList.txt

LABEL Par7200
KERNEL kernel
APPEND pxe init=/linuxrc root=/dev/ram0 rw noapic nolapic lba devfs=nomount ramdisk_size=60000 load_ramdis=1 promp_ramdisk=0 initrd=initrd.gz vga=normal pci=noacpi acpi=off apm=off Server=10.77.77.30 Share=PartImage$ user=PartImageShare passwd=PingAcess1 Directory=/ CIFS_Preferred=Y Image_To_Restore=Auto_Sda_Hda Restore_Only=Y After_Completion=shell AUTO=Y Extend_Parts_Whenever_Possible=N If_Hda_Image_To_Restore=xx23 If_Sda_Image_To_Restore=Par7200 Restore_BIOS=N Version_File_List=VersionFileList.txt


LABEL tech
KERNEL kernel
APPEND pxe init=/linuxrc root=/dev/ram0 rw noapic nolapic lba devfs=nomount ramdisk_size=60000 load_ramdis=1 promp_ramdisk=0 initrd=initrd.gz vga=normal pci=noacpi acpi=off apm=off Server=10.77.77.30 Share=PartImage$ user=PartImageShare passwd=PingAcess1 Directory=/ CIFS_Preferred=Y

LABEL TechBackup
KERNEL kernel
APPEND pxe init=/linuxrc root=/dev/ram0 rw noapic nolapic lba devfs=nomount ramdisk_size=60000 load_ramdis=1 promp_ramdisk=0 initrd=initrd.gz vga=normal pci=noacpi acpi=off apm=off Server=10.77.77.30 CIFS_Preferred=Y

Menu.lst

timeout 5
default 0

title Windows
root (hd0,0)
chainloader +1

title=Tech1
root(hd0,1)
kernel /user/braums/PXE/i386/templates/kernel pxe init=/linuxrc root=/dev/ram0 rw noapic nolapic lba devfs=nomount ramdisk_size=60000 load_ramdis=1 promp_ramdisk=0 cmd_0="/etc/Braums/scripts/BraumsSetUpEnv.sh" cmd_3="/etc/Braums/scripts/SavePingLog.sh"
initrd /user/braums/PXE/i386/templates/initrd.gz

title=Tech1(1to2)
root(hd0,1)
kernel /user/braums/PXE/i386/templates/kernel pxe init=/linuxrc root=/dev/ram0 rw noapic nolapic lba devfs=nomount ramdisk_size=60000 load_ramdis=1 promp_ramdisk=0 cmd_0="/etc/Braums/scripts/BraumsInit.sh Sync1to2" cmd_3="/etc/Braums/scripts/SavePingLog.sh"
initrd /user/braums/PXE/i386/templates/initrd.gz

title=ArchLinux
root(hd0,1)
kernel /user/braums/PXE/i386/templates/vmlinuz
initrd /user/braums/PXE/i386/templates/archiso.img
APPEND archisobasedir=arch archisolabel=ARCH_201412

title Windows (2nd Hard Drive)
root (hd1,0)
chainloader +1

Last edited by penright14 (2014-12-11 13:35:21)

Offline

#2 2014-12-04 21:20:56

nomorewindows
Member
Registered: 2010-04-03
Posts: 3,252

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

Why not just use Arch's diskless root nfs hosted from an Arch machine.  I'm not sure about what is special about the initrd.gz file you've got going here.  You can have a fully operational PXE client running arch instead of just a LiveCD solution.  The initramfs image that Arch makes can include anything you'd probably add to the ping image.  Rootfs libs out-of-date?  Arch is bleeding edge so that shouldn't be a problem, and most Linux distributions are rehashes of the same sources.  Start reading the Arch diskless root nfs wiki, and it's basically like installing Arch with a convenient initramfs builder, and with pacman is easy to use from an already running Arch installation.  Most OSs have to rebuild the kernel everytime it gets updated everytime you want to include something like NFS/network services on boot.  Arch uses stateless dhcp, so many clients (not just a handcoded few like *BSD) from one installation.


I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.

Offline

#3 2014-12-04 23:43:56

penright14
Member
Registered: 2014-11-20
Posts: 35

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

nomorewindows wrote:

Why not just use Arch's diskless root nfs hosted from an Arch machine.  I'm not sure about what is special about the initrd.gz file you've got going here.  You can have a fully operational PXE client running arch instead of just a LiveCD solution.  The initramfs image that Arch makes can include anything you'd probably add to the ping image.  Rootfs libs out-of-date?  Arch is bleeding edge so that shouldn't be a problem, and most Linux distributions are rehashes of the same sources.  Start reading the Arch diskless root nfs wiki, and it's basically like installing Arch with a convenient initramfs builder, and with pacman is easy to use from an already running Arch installation.  Most OSs have to rebuild the kernel every time it gets updated every time you want to include something like NFS/network services on boot.  Arch uses stateless dhcp, so many clients (not just a handcoded few like *BSD) from one installation.

First, I think I may be using the terms rootfs wrong. I used some of your terminology and ran across this https://www.kernel.org/doc/Documentatio … tramfs.txt. I will need to study it some and may have more questions.
I did look at NFS, so you may have the answer and I not sure how to convert what you are saying from a Linux OS (PXE/NFS) to Windows OS (PXE only).


Some more detail on the original post here https://bbs.archlinux.org/viewtopic.php?id=190677. I added it after I realized I did not post the boot config files for both gurb4dos and pxe boot.

Basically....
I wasn't sure of how to explain. Let me go from 30,000 to 50,000 feet. We have retail stores with about 7 point of sale terminals. The back office is windows. Running on the back office is TFTPD. This works as a DHCP and PXE boot server. The P.I.N.G is basically a huge pearl script, that use partimage to save partitions to a share.  The purpose of the P.I.N.G (Partimage Is Not Gost) is kind of like Ghost but to a share. So you can boot on the live cd, save the image to some share. Then sometime latter, boot on the live cd and restore the image just as it was saved. The pearl scripts handle all the partition, mapping shares, and restoring. Really kind of a cool tool. So when I say remaster the live cd, what I mean is, just the steps up to the point of creating the ISO. Then use that for the PXE boot. Back to my application, I use it to save the registers image and put them on a share on the back office window pc. Then when a tech replaces a hard drive, he can pxe boot the register, which loads loads the rootfs of the P.I.N.G live cd, not the actual live cd. I have hack the script so it just runs with per-loaded options. Kind of cool.

Back down to 30,000 feet. So I think in the work folder is what I need. My problem is I got it all to work by coping syntax off the web, and not deeply understanding the boot process. Now to convert "this technique" I will have to. :-)

I know clear as mud. :-)

Last edited by penright14 (2014-12-05 00:15:25)

Offline

#4 2014-12-05 14:16:31

nomorewindows
Member
Registered: 2010-04-03
Posts: 3,252

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

Partimage itself is in the Arch repos.  Just storing the image and recording it back to a new station (POS), doesn't necessarily require Windows vs. Linux.  It should do the same thing.  You should be able to serve Windows images from any PXE server.  You can use wimlib from the AUR to modify imageX images.  If you're using windows in the office, then that's probably what you'll be using, which will most likely keep you using the existing ping setup.  Windows already has RIS, and if this is what you are using, oh I get it, you're using partimage instead of ghost to do the task, but yeah, RIS does most of that now.


I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.

Offline

#5 2014-12-05 15:12:57

penright14
Member
Registered: 2014-11-20
Posts: 35

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

nomorewindows wrote:

RIS does most of that now.

I have not studied RIS, since we have been using this technique for a while. What little I have looked at it, you need to sysprep/create your OBE scripts to automate it. My "sysprep" is a batch file that forces an image to workgroup, clears out GUID for WSUS server, Symantec Endpoint Client, and so on. Then there is a startup bat file that sees I have never been configured, and so on.... Make managing images a lot easier. Side Note, we are moving from XP to Win 7 (backoffice)/Win 7 embedded (POS), both 64bit. To do the volume licensing, we now will need a server, instead of a sticker. Not sure how all that is going to effect things.

nomorewindows wrote:

Just storing the image and recording it back to a new station (POS), doesn't necessarily require Windows vs. Linux

I understand, the POS software requires the back office and POS to be windows. So I am just utilizing the equipment. We have over 285 back office and 2500 POS, if I could get rid of MS licensing, I would $$$$.


nomorewindows wrote:

Partimage itself is in the Arch repos.

I am not too worried about integrating the P.I.N.G process. Of course I have not started it yet, but I don't expect it to be that hard.
My issue has been the first time I got it (PXE, P.I.N.G, Remaster, and such) working I understand enough to be able to cut and past to get things working. Now to port from LFS/System V init to Archlinux/systemd, I need to understand things at a deeper level. I think my issue is in the way archlinux discovers the architecture and volume to mount. See this may not be a archlinux thing, it might be a modern Linux thing. I am not getting the file system to mount. It keeps falling back into interactive prompt. Example of what I mean about understanding. I got the back office to boot using grldr and the POS to PXE (When needed, once imaged then they boot to their hard drives) using syslinux. When I configured the TFTPD DHCP boot program I used pxelinux.0. In all this research, I found where I could use grldr for the PXE boot program. All I do is replace pxelinux.0 with grldr in the DHCP boot configuration.  I understand the process that TFTPD server is doing. Now I don't have the grldr boot process working on the other linux image, so there are details that I need to discover. That is the same for booting archlinux.

Something that does pertain to this thread, I may be able to phrase my question better.
Does anyone have a example menu boot/config file either both or one of pxelinux.0 or gdlr for PXE booting. Also there may need to be changes to the archiso build process to use the vmlinuz and archiso.img.
Do these questions make more sense?

Offline

#6 2014-12-05 15:42:42

nomorewindows
Member
Registered: 2010-04-03
Posts: 3,252

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

Are you using UEFI, because it'll use something other than pxelinux.0, I think.  To make your diskless nfs root work (if using Arch), you'll need to modify the PXE clients /etc/mkinitcpio.conf to include nfs(4) modules, and you'll only need base, udev, net(4), autodetect hooks.  You don't have to use grub loader.   If you are using Arch PXE client, the initramfs arguments will be different.  The ones you have reflect ping.  Oh, darn, if you PXE boot the POS and it stays running Arch and then you don't even need to go through this whole process (but your programs are probably POS specific and nothing has been ported over yet).


I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.

Offline

#7 2014-12-05 16:54:59

penright14
Member
Registered: 2014-11-20
Posts: 35

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

nomorewindows wrote:

Are you using UEFI, because it'll use something other than pxelinux.0, I think.

I think you are right. I have not played with UEFI per say, but my PC/POS hardware boots BIOS. The old Linux booted ok with pxelinux.0.

nomorewindows wrote:

You don't have to use grub loader.

FIrst, just to be clear when you say grub loader, we are talking over PXE. I hear you, I just did not know I could before use grub before. Now I have not got the old Linux to boot yet using grub, but that's OK, pxelinux.0 works. Just cant get my archlinux to load. Something interesting, not sure if this tell us anything, but I did find the menu config to boot an ISO with grub.

title=ArchLinuxISO
map --mem (pd)/archlinux-2014.12.04-x86_64.iso (0xff)
map --hook
chainloader (0xff)
boot

I use the same ISO that I burned to a cd (that boots all the way to tty) to pxe boot and I get the same error. After loading the CD image, then chain loading to it, I did see the CD's boot menu. Picked it, then when it tried to switch the 'label archlinux-2014' to the 'archiso/bootmnt' it failed also. I am betting there is something I need to add to the mkinitcpio.conf something else. Also, when I am trying to load the kernel/archiso.img, the switch error is different. There may need to be something else so archlinux can find the right file system.  Between this and your other commit on 'mkinitcpio', I may have my Rosetta stone.

nomorewindows wrote:

To make your diskless nfs root work (if using Arch), you'll need to modify the PXE clients /etc/mkinitcpio.conf to include nfs(4) modules, and you'll only need base, udev, net(4), autodetect hooks.

Ok, let me try them, stay tune ...

nomorewindows wrote:

If you are using Arch PXE client, the initramfs arguments will be different.  The ones you have reflect ping.

Well actually the ones on the end is used by the P.I.N.G script, the others are for LFS (Linux From Scratch). That is why I was looking for an example for archlinux.

nomorewindows wrote:

Oh, darn, if you PXE boot the POS and it stays running Arch and then you don't even need to go through this whole process (but your programs are probably POS specific and nothing has been ported over yet).

Actually, when PXE booting, the tech is using it as a recovery CD. Again, technically it is not a CD and PXE is not booting the ISO, I want to boot the archlinux kernel and mount a file system that will be the same as recovery CD. It re-images the harddrive with windows and the POS software, then boots to it. So the recovery process goes something like....
1. Configure the bios to PXE boot instead of harddrive
2. PXE boot, rung the P.I.N.G script that restores the image.
3. Boot back into BOIS, change the default boot back to harddrive.
4. Boot back to windows.

Offline

#8 2014-12-05 18:39:10

nomorewindows
Member
Registered: 2010-04-03
Posts: 3,252

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

The arguments go like this (from the wiki):

label <label>
kernel /srv/tftp/arch64/boot/vmlinuz-linux
append init=/usr/lib/systemd/systemd initrd=arch64/boot/initramfs-linux.img root=/dev/nfs rootfstype=nfs nfsroot=<IP>:/srv/tftp/arch64,v3,rsize=16384,wsize=16384 ip=::::::dhcp

Usually just pushing a function key like F10, F12, F2 will get you some kind of boot device menu if not BIOS setup.   You usually have to tell it network booting for the option to show up (usually on F12), but otherwise it might be manually selected some other way.  PXE boot can be on a boot by boot basis.

Last edited by nomorewindows (2014-12-05 18:41:46)


I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.

Offline

#9 2014-12-05 20:31:39

penright14
Member
Registered: 2014-11-20
Posts: 35

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

nomorewindows wrote:

The arguments go like this (from the wiki):

label <label>
kernel /srv/tftp/arch64/boot/vmlinuz-linux
append init=/usr/lib/systemd/systemd initrd=arch64/boot/initramfs-linux.img root=/dev/nfs rootfstype=nfs nfsroot=<IP>:/srv/tftp/arch64,v3,rsize=16384,wsize=16384 ip=::::::dhcp

Thanks I will try that. Just curious, which wiki did you see that in? I really do spend researching this stuff. :-)


nomorewindows wrote:

Usually just pushing a function key like F10, F12, F2 will get you some kind of boot device menu if not BIOS setup.   You usually have to tell it network booting for the option to show up (usually on F12), but otherwise it might be manually selected some other way.  PXE boot can be on a boot by boot basis.

Yes, the old POS hardware does not do that, you have to change the boot order. The new POS hardware will give a "boot" button that you can then select PXE, then it boots back to the default.

Before I can test the parameters, the ./build.sh is complaining when it trying to build the kernel. I used net(4), and of course it can't find it. I trying to find the right name now.

Offline

#10 2014-12-05 21:35:37

nomorewindows
Member
Registered: 2010-04-03
Posts: 3,252

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

Net was the old hook, but I think you have to use net4 in hooks and nfs4 in modules.  ./build.sh from where?  All you would need from Arch is mkinitcpio -p linux on your PXE client.  NFS diskless wiki.  Of course, if you went straight Linux, you could just remove the drives and it would go straight to PXE.  I wish I were in PXE hurray! hurray!

Last edited by nomorewindows (2014-12-05 21:50:05)


I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.

Offline

#11 2014-12-05 22:52:47

penright14
Member
Registered: 2014-11-20
Posts: 35

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

nomorewindows wrote:

Net was the old hook, but I think you have to use net4 in hooks and nfs4 in modules.

Here is what I have in MkInitcpio.conf HOOKS="base udev archiso net4 block filesystems autodetect" What do you mean nfs4 in modules?

nomorewindows wrote:

./build.sh from where?

That the the script that archiso uses to build the iso.
Also, the ./build.sh threw the error with net4. It looks like it might be building the kernel, there is a message like ==>Starting build: 3.17.4-1-ARCH
Then there is one for each of the hooks -> Running build hook: [xxxx] where xxxx is each parameter in the MkInitcpio.conf. When it gets to the net4 then there is a ==> ERROR: Hook 'net4' cannot be found
Are we talking same here?


nomorewindows wrote:

I wish I were in PXE hurray! hurray!

LOL

Offline

#12 2014-12-05 23:03:29

nomorewindows
Member
Registered: 2010-04-03
Posts: 3,252

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

Net4 was to differentiate between nfs version 3 and nfs version 4, so just try net instead.  I'm not using the archiso for it so I don't use ./build.sh and don't need it for an Arch PXE server/client.  You do have mkinitcpio-nfs-utils installed don't you?  You don't even need filesystems or block because it is using the nfs filesystem and mounting it, but if you're using archiso, it might be a redundant hook.

Last edited by nomorewindows (2014-12-05 23:03:58)


I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.

Offline

#13 2014-12-05 23:16:18

penright14
Member
Registered: 2014-11-20
Posts: 35

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

nomorewindows wrote:

Net4 was to differentiate between nfs version 3 and nfs version 4, so just try net instead.  I'm not using the archiso for it so I don't use ./build.sh and don't need it for an Arch PXE server/client.  You do have mkinitcpio-nfs-utils installed don't you?  You don't even need filesystems or block because it is using the nfs filesystem and mounting it, but if you're using archiso, it might be a redundant hook.

Yes, same thing.
I think we are getting some traction, let me go back and study the NFS wiki again. I am not connecting the dots. Ruff day, wife driving my GXP got hit today. Not really on top of it. http://www.grandprixforums.net/threads/ … ost1302391

I think I heading home for the weekend, Can I pick it back up Monday? Thanks again.

Offline

#14 2014-12-08 14:37:06

penright14
Member
Registered: 2014-11-20
Posts: 35

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

penright14 wrote:

Can I pick it back up Monday?

Some of this is for future Newbie's....
Before I could get to the wiki, I wanted a better understanding of mkinitcpio.conf 'hooks' section. I found how to list them 'mkinitcpio -L' and this is what I saw ...

==> Available hooks
archiso			         base			lvm2		        sata¹		        systemd
archiso_kms		         block			mdadm			scsi¹		        udev
archiso_loop_mnt	        consolefont		mdadm_udev		sd-encrypt	        usb¹
archiso_pxe_common              encrypt                memdisk			sd-lvm2			usbinput²
archiso_pxe_http	        filesystems		mmc¹			sd-shutdown		usr
archiso_pxe_nbd		        fsck		        modconf			sd-vconsole		virtio¹
archiso_pxe_nfs		        fw¹		        pata¹		        shutdown
archiso_shutdown	        keyboard	        pcmcia			sleep
autodetect		        keymap			resume			strip

¹ This hook is deprecated in favor of 'block'
² This hook is deprecated in favor of 'keyboard'

I need to do more research, but I notice the base .conf file had archiso, when I tried to -H archiso it said there was no help. So I started opening the scripts looking. I know I have made a step, I can see the next mountain, but it is still off in the distance.

Quick question, since my pxe server is expecting FTP (TFTPD 64 windows), I guessing I need archiso_pxe_common and archiso_pxe_http? What order? (archiso_pxe_common, archiso_pxe_http, archiso)

Offline

#15 2014-12-08 14:55:29

nomorewindows
Member
Registered: 2010-04-03
Posts: 3,252

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

If you're using the archiso, those hooks would already be in place on the archiso.


I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.

Offline

#16 2014-12-10 17:45:46

penright14
Member
Registered: 2014-11-20
Posts: 35

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

Still don't have it. I think my problem is in the TFTPD program by Philippe Jounin at http://tftpd32.jounin.net/tftpd32_download.html I think it only supports TFTP and all the PXE boot examples and wiki only discuss using http or nfs. I am using TFTPD because of windows. It whats already out and working. I think I understand the issue better, but I can't find anything on it.

Offline

#17 2014-12-10 18:21:24

nomorewindows
Member
Registered: 2010-04-03
Posts: 3,252

Re: [SOLVED] PXE boot a remaster ISO on Windows TFTPD

It could be that you do need nfs, because tftp just sends the kernel files, and then it has to boot the nfs (or sshfs) filesystem from there.  You can even boot your machine with the same kernel that you would normally use, to boot your local hard disk (but PXE is something you can do to impress your friends).  You would of course give it the same kernel parameters to point to your local disk root=/dev/sdxxxx.  Look MA! No disk!  You can serve the windows RIS/PXE isos from tftp just fine and from Arch PXE just the same. 
You can, however, have your cake and eat it too!  Just put your nfs server somewhere on the network and point your PXE client to it with kernel parameters!

Last edited by nomorewindows (2014-12-11 17:59:04)


I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.

Offline

Board footer

Powered by FluxBB