Hey folks,
I have a remote server that needs to be upgraded to FC6 (read: fresh install) At the moment it's up and running with FC1. This machine is also on the (local) network where I have all the iso's needed to install. Now, normally, when I am at that location, I will grab the vmlinuz and initrd files off of the first ISO, put them on the machine to be upgraded, add the necessary lines to grub and reboot the thing. Once it reboots and goes into the installer, I tell it to do an NFS install and off I go.
However, that approach won't work right now because I'm not physically there nor is there anyone else who can do the initial stuff for me. Now, since FC6 can run a vnc server during installation, I can then remote install the system, right? So my question is, what parameters do I feed grub to tell it a) launch 'linux vnc' instead of just linux, and b) have the ip address fed to it directly (with all other parameters the installer asks for, language, keyboard settings, network settings and the NFS server information). Remember, I'm not there to type anything on the keyboard and I know the installer is going to ask me for the IP information before it launches vnc.
Anyone?
Ashley M. Kirchner wrote:
I have a remote server that needs to be upgraded to FC6 (read: fresh install) At the moment it's up and running with FC1. This machine is also on the (local) network where I have all the iso's needed to install. Now, normally, when I am at that location, I will grab the vmlinuz and initrd files off of the first ISO, put them on the machine to be upgraded, add the necessary lines to grub and reboot the thing. Once it reboots and goes into the installer, I tell it to do an NFS install and off I go.
However, that approach won't work right now because I'm not physically there nor is there anyone else who can do the initial stuff for me. Now, since FC6 can run a vnc server during installation, I can then remote install the system, right? So my question is, what parameters do I feed grub to tell it a) launch 'linux vnc' instead of just linux, and b) have the ip address fed to it directly (with all other parameters the installer asks for, language, keyboard settings, network settings and the NFS server information). Remember, I'm not there to type anything on the keyboard and I know the installer is going to ask me for the IP information before it launches vnc.
I haven't played with the vnc install much yet, but I've been saving this article from Red Hat magazine in my browser to remind me that I need to do so. Perhaps it will help answer some of your questions?
http://www.redhat.com/magazine/024oct06/features/kickstart/?sc_cid=bcm_edmse...
Todd Zullinger wrote:
I haven't played with the vnc install much yet, but I've been saving this article from Red Hat magazine in my browser to remind me that I need to do so. Perhaps it will help answer some of your questions?
http://www.redhat.com/magazine/024oct06/features/kickstart/?sc_cid=bcm_edmse...
Thanks Todd. One small issue: it doesn't explain how to specify which interface to use. This machine has three NICs in it and for this install to work, I need to tell it to use eth1 since that's the one wired to the local network where the ISO's are sitting on an NFS export.
8:32pm Ashley M. Kirchner said:
Todd Zullinger wrote:
I haven't played with the vnc install much yet, but I've been saving this article from Red Hat magazine in my browser to remind me that I need to do so. Perhaps it will help answer some of your questions?
http://www.redhat.com/magazine/024oct06/features/kickstart/?sc_cid=bcm_edmse...
Thanks Todd. One small issue: it doesn't explain how to specify which interface to use. This machine has three NICs in it and for this install to work, I need to tell it to use eth1 since that's the one wired to the local network where the ISO's are sitting on an NFS export.
Append this to the kernel too: ksdevice=eth1
http://kbase.redhat.com/faq/FAQ_80_531.shtm
../C
Curtis Doty wrote:
Append this to the kernel too: ksdevice=eth1
Since I'm not using a kickstart file, can I safely assume that I can append 'device=eth1' to the kernel line in grub and have it work?
Ashley M. Kirchner wrote:
Curtis Doty wrote:
Append this to the kernel too: ksdevice=eth1
Since I'm not using a kickstart file, can I safely assume that I can append 'device=eth1' to the kernel line in grub and have it work?
Also, I need to tell it to load the e100 module for the NICs.
On Thursday 01 February 2007 23:10, Ashley M. Kirchner wrote:
Curtis Doty wrote:
Append this to the kernel too: ksdevice=eth1
I tried to do this with a local box - while it did boot - at some point it still asks for config info on the other cards - i suspect you may have to use a kickstart file ...
Since I'm not using a kickstart file, can I safely assume that I canappend 'device=eth1' to the kernel line in grub and have it work?
-- H | It's not a bug - it's an undocumented feature. +-------------------------------------------------------------------- Ashley M. Kirchner mailto:ashley@pcraft.com . 303.442.6410 x130 IT Director / SysAdmin / Websmith . 800.441.3873 x130 Photo Craft Imaging . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
Mail List wrote:
I tried to do this with a local box - while it did boot - at some point it still asks for config info on the other cards - i suspect you may have to use a kickstart file ...
Does it do that before vnc+anaconda kick in? All I want is for the grub and the installer to come up, load eth1 so it can get to the NFS iso files and load up vnc and anaconda. From there I can do everything else, including configuring the other ethernet devices.
On Friday 02 February 2007 00:13, Ashley M. Kirchner wrote:
Mail List wrote: Does it do that before vnc+anaconda kick in? All I want is for the grub and the installer to come up, load eth1 so it can get to the NFS iso files and load up vnc and anaconda. From there I can do everything else, including configuring the other ethernet devices.
What happened for me - I booted the installer out of grub with kernel ... vnc vncconnect=<ip> ip=dhcp lang=en_US keymap=us device=ethX
it boots and anaconda prompts for other eth device info before starting up vnc - so I had to type at console to tell it info about the other nics - after that it talks the listening vnc client at remote end -
Mail List wrote:
What happened for me - I booted the installer out of grub with kernel ... vnc vncconnect=<ip> ip=dhcp lang=en_US keymap=us device=ethX
it boots and anaconda prompts for other eth device info before starting up vnc - so I had to type at console to tell it info about the other nics - after that it talks the listening vnc client at remote end -
Grrrrr... Okay, is there a parameter that tells it to IGNORE eth0 and eth2, as in don't even bother to probe. I don't care if it ignores them throughout the entire installation process, I can configure them after the system comes back up.
By the way, I noticed you didn't specify a module for your ethernet device...or maybe you just didn't include it. Can I assume it will magically load up the e100 module that these cards need?
On Friday 02 February 2007 00:24, Ashley M. Kirchner wrote:
Mail List wrote:
What happened for me - I booted the installer out of grub with kernel ... vnc vncconnect=<ip> ip=dhcp lang=en_US keymap=us device=ethX
it boots and anaconda prompts for other eth device info before starting up vnc - so I had to type at console to tell it info about the other nics - after that it talks the listening vnc client at remote end -
Grrrrr... Okay, is there a parameter that tells it to IGNORE eth0and eth2, as in don't even bother to probe. I don't care if it ignores them throughout the entire installation process, I can configure them after the system comes back up.
If yoiu figure it out let me know - a kickstart may work - i didn't try it - looks like it might - i didnt do anything with nic modules ...
Btw - you have to specify lan and kbd or else it prompts for those at console as well.
I got bored - and since I had the vnc after a little fiddling I stopped - i told myself _next_ time i'll fiddle with a kickstart to see if I get mroe joy.
By the way, I noticed you didn't specify a module for your ethernetdevice...or maybe you just didn't include it. Can I assume it will magically load up the e100 module that these cards need?
Mail List wrote:
What happened for me - I booted the installer out of grub with kernel ... vnc vncconnect=<ip> ip=dhcp lang=en_US keymap=us device=ethX
it boots and anaconda prompts for other eth device info before starting up vnc - so I had to type at console to tell it info about the other nics - after that it talks the listening vnc client at remote end -
Well, I went ahead and tried with the following:
---------- title Fedora Core 6 Install root (hd0,0) kernel /boot/vmlinuz-FC6 lang=en_US keymap=us method=nfs:192.168.2.24:/Fedora vnc device=eth1 ip=192.168.2.10 netmask=255.255.255.0 gateway=192.168.2.1 dns=192.168.2.1 initrd /boot/initrd-FC6.img ----------
Rebooted, installer came up and asked exactly 1 question: Which device to configure. All I had to do was highlight eth1 and hit return and it continued on. Didn't ask me for any more information and went straight into Anaconda and launched VNC after which I was able to connect.
My co-worker now dubs himself 'The Monkey that pushed the button.'
So it seems the installer ignores the device= option. A bug perhaps?
1:00pm Ashley M. Kirchner said:
Rebooted, installer came up and asked exactly 1 question: Which device to configure. All I had to do was highlight eth1 and hit return and it continued on. Didn't ask me for any more information and went straight into Anaconda and launched VNC after which I was able to connect.
My co-worker now dubs himself 'The Monkey that pushed the button.'
So it seems the installer ignores the device= option. A bug perhaps?
Did you even try with the ksdevice=eth1 I had previously suggested?
../C
Curtis Doty wrote:
Did you even try with the ksdevice=eth1 I had previously suggested?
I did not simply because that applied to a kickstart configuration, which I'm *not* using. Are you suggesting that any of the ks* variables available to grub can be applied regardless of one using kickstart or not?
On Fri, 2007-02-02 at 13:00 -0700, Ashley M. Kirchner wrote:
Mail List wrote:
What happened for me - I booted the installer out of grub with kernel ... vnc vncconnect=<ip> ip=dhcp lang=en_US keymap=us device=ethX
it boots and anaconda prompts for other eth device info before starting up vnc - so I had to type at console to tell it info about the other nics - after that it talks the listening vnc client at remote end -
Well, I went ahead and tried with the following:
title Fedora Core 6 Install root (hd0,0) kernel /boot/vmlinuz-FC6 lang=en_US keymap=us method=nfs:192.168.2.24:/Fedora vnc device=eth1 ip=192.168.2.10 netmask=255.255.255.0 gateway=192.168.2.1 dns=192.168.2.1 initrd /boot/initrd-FC6.img
Rebooted, installer came up and asked exactly 1 question: Whichdevice to configure. All I had to do was highlight eth1 and hit return and it continued on. Didn't ask me for any more information and went straight into Anaconda and launched VNC after which I was able to connect.
My co-worker now dubs himself 'The Monkey that pushed the button.' So it seems the installer ignores the device= option. A bug perhaps?
More like a "which NIC is eth1?" problem. I don't know if there's a way to specify which NIC to use on the kernel line when there's multiple NICs installed. Perhaps a new parameter, "hwaddr=" or something along that nature.
---------------------------------------------------------------------- - Rick Stevens, Senior Systems Engineer rstevens@vitalstream.com - - VitalStream, Inc. http://www.vitalstream.com - - - - Is that a buffer overflow or are you just happy to see me? - ----------------------------------------------------------------------
Rick Stevens wrote:
More like a "which NIC is eth1?" problem. I don't know if there's a way to specify which NIC to use on the kernel line when there's multiple NICs installed. Perhaps a new parameter, "hwaddr=" or something along that nature.
That might be the case, however don't the devices come up in sequence in which they're plugged into the motherboard starting at PCI1 down to however many the board has? I've always had cards come up that way and it's been consistently that way, at least for me. I can always count on eth1 being the second card on the bus.
Heh, I may be stuck again. The installation ran fine and when I hit Reboot at the end, I was disconnected, as I would expect... However, the machine has yet to go down and reboot. It's been over 10 minutes now. I can still ping it's IP, and nmap tells me that both ports 5901 and 6001 are open (X11 and vnc) however I can no longer connect to vnc. At this point I'll just have to let it sit there till Monday since there's no one there anymore...no monkey to push a button again.
Anyone have any idea why it would be stuck, and/or on what?
The saving grace here is that since it hasn't rebooted yet, it also hasn't configured any public interfaces, so it's still only visible on the local network and (fairly) safe from external attacks. Had it rebooted properly and for some reason not allowed me to reconnect, then I'd be a bit more concerned. Oh well, live and learn.
On 2/2/07, Ashley M. Kirchner ashley@pcraft.com wrote:
Heh, I may be stuck again. The installation ran fine and when I hitReboot at the end, I was disconnected, as I would expect... However, the machine has yet to go down and reboot. It's been over 10 minutes now. I can still ping it's IP, and nmap tells me that both ports 5901 and 6001 are open (X11 and vnc) however I can no longer connect to vnc. At this point I'll just have to let it sit there till Monday since there's no one there anymore...no monkey to push a button again.
Anyone have any idea why it would be stuck, and/or on what?
If you have a uniprocessor system adding "apm=power_off" to grub may fix the problem. Its a known kernel bug which appeared when the uniprocessor and smp kernels were combined.
The saving grace here is that since it hasn't rebooted yet, it alsohasn't configured any public interfaces, so it's still only visible on the local network and (fairly) safe from external attacks. Had it rebooted properly and for some reason not allowed me to reconnect, then I'd be a bit more concerned. Oh well, live and learn.
-- H | It's not a bug - it's an undocumented feature. +-------------------------------------------------------------------- Ashley M. Kirchner mailto:ashley@pcraft.com . 303.442.6410 x130 IT Director / SysAdmin / Websmith . 800.441.3873 x130 Photo Craft Imaging . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
On Fri, 2007-02-02 at 15:58 -0700, Ashley M. Kirchner wrote:
Rick Stevens wrote:
More like a "which NIC is eth1?" problem. I don't know if there's a way to specify which NIC to use on the kernel line when there's multiple NICs installed. Perhaps a new parameter, "hwaddr=" or something along that nature.
That might be the case, however don't the devices come up insequence in which they're plugged into the motherboard starting at PCI1 down to however many the board has? I've always had cards come up that way and it's been consistently that way, at least for me. I can always count on eth1 being the second card on the bus.
They vary based on the PCI bus layout, kernel version and a bunch of other things. That's why the network startup scripts allow you to specify the "HWADDR=" to make sure what _you_ want as eth0 stays eth0. I should think a similar item should be included for network installs.
I've had two different kernels on the same machine swap NICs on me when I didn't specify the "HWADDR=" in the network configs. Damned frustrating, it was!
---------------------------------------------------------------------- - Rick Stevens, Senior Systems Engineer rstevens@vitalstream.com - - VitalStream, Inc. http://www.vitalstream.com - - - - "Doctor! My brain hurts!" "It will have to come out!" - ----------------------------------------------------------------------
Rick Stevens wrote:
They vary based on the PCI bus layout, kernel version and a bunch of other things.
As far as the board layout goes, I always make a point to figure out which is the first slot, so whether it's at the top or bottom doesn't really matter. However, my assumption always was that the kernel would scan the bus starting at the first slot and number devices accordingly. I haven't had the same type of switcharoo that you have happened to you (maybe that's a good thing) so maybe that's why I assumed it's always the same. From what you're telling me, it sounds like that's not the case. So much for consistency...I thought Winblows was the only one with that problem...
On Fri, 2007-02-02 at 17:26 -0700, Ashley M. Kirchner wrote:
Rick Stevens wrote:
They vary based on the PCI bus layout, kernel version and a bunch of other things.
As far as the board layout goes, I always make a point to figure outwhich is the first slot, so whether it's at the top or bottom doesn't really matter. However, my assumption always was that the kernel would scan the bus starting at the first slot and number devices accordingly. I haven't had the same type of switcharoo that you have happened to you (maybe that's a good thing) so maybe that's why I assumed it's always the same. From what you're telling me, it sounds like that's not the case. So much for consistency...I thought Winblows was the only one with that problem...
Nope. And here's a real fun one...the Dell 1850/1950 series and the Dell 2850/2950 scan backwards. On the 1850/1950, NICs in the PCI bus are enumerated BEFORE the ones on the motherboard. On the 2850/2950, the motherboard-based ones are first.
"Hell, if it was easy, EVERYONE'd be doing it!" Fun, fun, fun!
---------------------------------------------------------------------- - Rick Stevens, Senior Systems Engineer rstevens@vitalstream.com - - VitalStream, Inc. http://www.vitalstream.com - - - - To understand recursion, you must first understand recursion. - ----------------------------------------------------------------------
Rick Stevens wrote:
Nope. And here's a real fun one...the Dell 1850/1950 series and the Dell 2850/2950 scan backwards. On the 1850/1950, NICs in the PCI bus are enumerated BEFORE the ones on the motherboard. On the 2850/2950, the motherboard-based ones are first.
Now see, I knew there was a reason why I stay away from Dell. :)
-
Ashley M. Kirchner -
Curtis Doty -
Genes MailLists -
Kam Leo -
Rick Stevens -
Todd Zullinger