I’m rewriting this as the original was a little verbose.
I tried running a dual boot HDD so I could pick between XP and Linux. It worked well, but I need Windows apps for work stuff, and my wife just doesn’t want to learn Linux. Meaning when I booted to Linux, she found the system of little use other than Firefox and messaging. I then realized the only reason I want Linux at this point is to use Putty to tunnel to the system from work. (Hell, this is going to be verbose no matter what.)
I config’d what seems like a decent SSH program for Windows, but I’d rather just have a second system to run Linux to do it from. So I decided I’m running this on XP and networking the linux system. I have everything I need except the motherboard and case, which I’m getting next weekend.
Anyway, I have a 6GB HDD I picked up and want to get it set and ready for the new box.
So, long story short (too late) I’m installing Linux to it (it’s physically in the main box). I’m going to boot from the liveCD and install it, but a question about getting to it.
After the install, I assume I have to change the BIOS to boot from the 6GB drive first, right? Then reboot and change the BIOS to boot from the main HD? Leaving it that way when I build the new box?
An incredibly simple answer, answered in the question, I’m sure. I just want to make sure. And pick up any tips I don’t know about.
Thanks in advance for any advice, and apologies for being too wordy.
It seems to me that you are using a very big stick to control a very little problem.
If you are, as you say, only using the Linux machine to connect to a computer at work, you could simply use Putty for windows.
You could also simply run the Linux OS under VMware or MS Virtual Machine (I think it’s called). There are probably others that are around, and better, but that’s what jumps to mind immediately. Then you only need to start the Linux virtual machine when you need it, and at all other times you just use windows. That could be a little resource hungry though.
You could also (and this does not really get around the reboot option, I know), simply boot Linux from a CD, using one of the flavours that requires no install, and runs entirely from your PC’s memory. I have never used one of those, so I do not know how good they are, to be honest.
Failing all of these options, then yes, you would just need to change the BIOS setting to be a different boot order. I do not know that all BIOSes support HDD0 or HDD1 booting. My current one does, but as far as I can recall, none of my previous ones have done so. Assuming that your main windows machine is relatively new, you should have no problems doing that.
It might also be that the BIOS supports a “boot menu”, whereby hitting a key (mine is F11) will bring up a menu that offers you every IDE device that is available (it may also include SATA or SCSI devices, I have none to check that with at the moment). Then you can simply navigate to the correct one (to make it easier you might put them on different IDE chains), and it will look there first.
Hey duffer – I don’t think you should have to change anything. That is, if you have it set to boot from the CD, but there’s no bootable CD in the drive, the computer will attempt to boot from the next device (usually, the hard disk). At least, I think that’s what you’re asking. Unless you’re going to be dual-booting again (but from a different computer)? In which case, I’m not sure what’s changed…
BTW - I’m not sure what distro you finally decided to install, but I recently installed Ubuntu 6.06 from the LiveCD. Easiest installation I’ve ever done (going back about 12 years). And two more things: (1) if you want Unix functionality in Windows, you might want to look into Cygwin, which has an ssh client and server (command-line, at least). Also, a story about Damn Small Linux was just posted on Slashdot. One of the comments mentioned using Damn Small Linux on a flash drive and using QEMU to run Linux within Windows.
That last is something I have no experience with whatsoever (and am most certainly not advocating it as a solution to anything), but if you were willing to make the effort to dual boot in the first place, I figured you might appreciate some more adventures…
If I understand things right, your current dual boot PC (PC A) is going to be XP only, and your new PC (PC L) is going to be Linux only. You also want to get the HD for upcoming PC L ready by installing Linux on it using PC A.
IMHO, things would be a lot simpler if you just installed the OS when you got PC L up and running. I’m not sure how much hardware is auto-detected at install, but installing on the hardware you’re going to use is always best.
If you do go ahead, you might want to just leave the BIOS alone and let Linux control the boot sector with GRUB or LILO, and boot through that. When you swap out the HD, re-write the boot sector through the XP Recovery Console using the FIXMBR command. Of course, this assumes you can access the RC, which many people don’t 'cause they don’t have an Admin passwd.
OTOH, Linux is way overkill for SSH. I’m pretty happy with Putty.
Ohhh – is that the question? :smack: Yeah, you’d most likely be better off just waiting until you get the case and other equipment and let the install do its hardware detection thing.
An O/S hates having its motherboard pulled out from under it. This is rarely advised and unlikely to result in satisfactory performance unless the mobos are identical.
If by this, you mean people who use XP in admin mode without logging in, the password has never been set. When Setup asks for it, just press enter, and you’re into the RC.
No, I mostly mean people with OEM installs of XP. There have been dozens of times where a single RC command could have fixed everything, but it couldn’t be done because we couldn’t log in.
That’s exactly what I was doing. I agree with everyone I guess as I’ve decided to just wait until I get the other box.
And Cygwin is what I’m using along with Putty to do it from work. As far as overkill, I’d like to have a Linux box just to play around with to learn the OS and the re-familiarize myself with command-line operation.