Hello lryder,

The Linux Automation environment starts up and tries to run the ADLAgent. This should be reported on the DS console. When you create the boot image using Boot Disk Creator (in PXE I suspect) you have the option to use the ADLAgent form the image or from the Deployment Server.

In order for the ADLAgent to run over the network Linux needs to be able to access the network.

I think there could be a problem in the networking or ADLAgent.

Are you trying to signal that my comment doesn't answer your question lryder?

If so I guess you could try to tell me what I missed or in which manner this doesn't help, so I can try to answer or help you. A reply would have done just as well if not better than a vote down ;).

Ludovic,

The negative vote was from me.  In my opinion your post was not exactly helpful.  lryder may or may not agree (and they can also vote positive or negative in either case, just as you can).  To make your post better (or more helpful) you might have offered some hints of where they can continue their troubleshooting.  Or if that was not possible, maybe requesting more information to help you help them.

 Ah ah, my bad not considering that voting can come from many different places.

I was kind of trying to get started there, because this isn't a clear cut problem. If the ADLAgent is not starting because of network issue the troubleshooting is limited to getting networking up, and that's something you can do mostly hands on (specially with drivers).

Then if it's an issue with DS you can alway s delete the computer from the console and make sure your initial deployment instructs the ADLAgent to wait.

In which case you can take control of the console to check things out.

Oh, and of course there's the option to drop a dir job from the DS console in automation, some script like "ls -lart > /dev/tty0" as we only have 2 consoles on the Linux preboot environment and the default is 0.

I guess I could have said all of this directly.

Hi Ludovic -I'm following you..... ;-)

Iryder -I've said this many a time, but I can't help it. I'm addicted to it. Wireshark is your friend. If you've never used it before, then solving this problem might give you a good motivation to start. You could see if there are any comms from the client, and you can even see the instructions being sent.

Anyway.... that aside.....

If Linux automation restarts really quickly... I'm thinking that the network is might be OK. I can't recall the last time I had a nic problem with Linux automation, but I'm sure that when it did it took ages for automation to give up and reboot. So, is it possible that Altiris is perhaps expecting you to be booting into a different Linux automation environment than what its getting?

If you are PXE booting your client you should be getting the right one (if you have several configured). However if you are booting from an embedded partition, CD or USB stick its concievable that its DS is not happy with the automation environment you're providing.

I've seen this with WinPE in the past, not with Linux though. So its entirely possible i'm barking up the wrong tree.

Kind Regards,
Ian./

All,

Many thanks for your replies, and Sorry I ahve not written anything yet.

So, for a recap

I ahve not yet solved the problem :(

All I need is for Altiris to download the Redhat vmlinuz Kernel and Boot Image, nothing more

This is taken from a pre-configured system, so we are looking into the steps in a semi-random order:

Open PXE Configuration utility and configure a new Linux pre-boot environment with "User supplied" image creation method

Point the "Manual Boot Image" selector to your local Linux netboot folder:

Click save and net boot a computer. Select the custom image [Karmic-Netboot here]

The boot selector from the netboot folder is loaded:

When you click on install the Linux image is loaded:

I suspect that you'll want to tweak the Linux netboot menu to not offer user selection and load your Linux image directly to start off your automate installation.

I think I'll get a detailed article on this later on, as it may proove useful.

PS: Here are a few more screen shots (click for full size) related to this question.

 

Thank you, were on the right track now,

so I cannot get the Redhat install to work yet, but I can load the vmlinuz kernel.

now need to get the initrd.img to load

How about these types of commands found searcing Google [*]:

Red Hat 6.2 network boot ( lename default.netboot-6.2):

default linux
serial 0,38400n8
label linux
kernel vmlinuz-6.2
append console=console=tty0 ttyS0,38400 load_ramdisk=1 \
initrd=initrd-6.2.img network \
ks=nfs:nfssrv:/data/Kickstart/ks-6.2.cfg

Red Hat 7.2 network boot ( lename default. netboot -7.2):

default linux
serial 0,38400n8
label linux
kernel vmlinuz-7.2
append ksdevice=eth1 console=tty0 console=ttyS0,38400 load_ramdisk=1 \
initrd=initrd-7.2.img network \
ks=nfs:nfssrv:/data/Kickstart/ks-72.cfg

[*] http://www.owlriver.com/tips/pxe-install/PXE-Kickstart.ps

Ludovic,

Where would I enter those details?

I also treid a different tactic

Run a Script which copies the vmlinuz, initrd.img, grub.conf and ks.cfg to d1,p2

but that failed.

The theory was to get grub.conf (Which points to the vmlinuz and initrd and ks file) in a hope that after a reboot, it will run.

But the script failed with Error 60 or Error 127 during script Exectution.

Here is the content of my Ubuntu netboot "default" file (which is handled when the boot option is selected):

include ubuntu-installer/i386/boot-screens/menu.cfg
default ubuntu-installer/i386/boot-screens/vesamenu.c32
prompt 0
timeout 0 

This points to menu.cfg which is a binary file. The file is loaded and eventual it get to a point were a file (again on my Ubuntu netboot) named text.cfg is called with the loading commands:

default install
label install
	menu label ^Install
	menu default
	kernel ubuntu-installer/i386/linux
	append vga=normal initrd=ubuntu-installer/i386/initrd.gz -- quiet 
label cli
	menu label ^Command-line install
	kernel ubuntu-installer/i386/linux
	append tasks=standard pkgsel/language-pack-patterns= pkgsel/install-language-support=false vga=normal initrd=ubuntu-installer/i386/initrd.gz -- quiet 

However you should not be copying files manually. Kickstart generates an answer file to your installation. You should just load the image pointing to the kickstart file. I did this succesfully in the past on Ubuntu to kickstart network installs (I didn't have the need to script it) but the theory is the same.

Grub will work once it get installed properly ;)