strategy to replace mobo


Page 1 of 2 12 LastLast
Results 1 to 15 of 22

Thread: strategy to replace mobo

  1. #1
    Join Date
    Aug 2004
    Posts
    234

    Question strategy to replace mobo

    Hi--

    I farkled my mobo last night. Actually had a fire on it while installing new memory!

    So: now I am getting a new mobo. Old one was Intel 915GAVL; new one is Intel DG33FB with Intel core 2 duo E4300.

    The hardware tech says the bootup sequence (I currently have Ubuntu Dapper 6.06 on the HDD) does not recognize the chipset. Just to be sure I had something that I could put a new OS on, I had him put in a new serial ATA HDD 80 gig drive.

    Now my question is how do I go about restoring my system so I have access to what was there before, both data and apps and OS?

    1. Do I install Ubuntu Gutsy 7.10 on the new drive, boot from there and then mount the old drive with some new designation, like /olddrive?

    2. Do I simply get a live CD, boot from there and then make some changes in config files? Which config files or other changes?

    3. Something else entirely?

    It might help to know that I have an nvidia graphics card on it and from that am running dual monitors using Twinview.

    Thanks!
    :-Doug.

  2. #2
    Join Date
    Dec 1999
    Location
    Fargo, ND
    Posts
    1,816

    Question

    Dude, If you have a custome kernel, rebuild your kernel, and reboot.

    If you have one of ubuntu's generic kernels, just boot.
    You may have a little bit of wierdness if both motherboards had onboard nic's, but that's easily dealt with.

    [edit]How did you manage to set your mobo on fire when you were replacing memory, because, to my knowledge, you turn the computer off to do that.[/edit]
    Last edited by knute; 12-02-2007 at 06:07 PM. Reason: curious about fire on mobo
    Knute

    You live, you die, enjoy the interval!

  3. #3
    Join Date
    Aug 2004
    Posts
    234

    Question

    knute--

    Thanks for your quick reply!

    It will not boot. It is a generic kernel. It starts to boot and hangs at "waiting for root file system."

    After several minutes it says "PCI: Failed to allocate mem resource #6:" and a bunch of numbers. Then "ALERT! /dev/sda1 does not exits. Dropping to a shell!" Then it gives me a BusyBox shell.

    The fire? I shut down the computer, unplugged it. Inserted memory sticks. Powered back on. When I turned the power on, there was a little light that came on near the memory sticks, and near it, a flame! It took me a few seconds to figure out I needed to pull the plug instead of hit switches to shut off the power, but when I did, the fire died away. Tech guy said it could have been just the time for the mobo to give up. Or maybe I put the sticks in incorrectly. Bottom line: I don't know how it happened.

    Any idea how to get past that place in the boot sequence?

    Thanks, knute!
    Last edited by dgermann; 12-02-2007 at 06:57 PM.
    :-Doug.

  4. #4
    Join Date
    Dec 1999
    Location
    Fargo, ND
    Posts
    1,816
    Not sure about the mem resource thing, but if it can't find /dev/sda1 (which I'm guessing you had before as root), then it could be as simple as you may not have the SATA drive connected correctly.
    In the manual it showed that there were 4. Are you sure it's on the right one?

    If you are using grub, you can edit those in place (won't save, but you can change it). It's been so long since I've used lilo that I couldn't say one way or another.

    What I was saying about grub was that you could change the root option from /dev/sda1 to /dev/sda2 (or whatever just to check). There is also a way to search for a file with grub so that you can get the correct location.

    But to me, it sounds like a combination between boot option and drive on wron connector.
    HTH,
    Knute

    You live, you die, enjoy the interval!

  5. #5
    Join Date
    Aug 2004
    Posts
    234

    Question

    knute--

    Thanks for your help!

    Not sure what sda1 would be--All I had on it was one HDD. I think it was whatever Ubuntu set up as partitions--boot, and so forth.

    You suggest we may not have the SATA drive connected correctly. Because of this naming of something that does not exist (sda1) (Oh, and I tried changing the boot order in the BIOS and it will not change. There is a way to change it just for the current session by pressing F10 on boot up, and even though I said to boot from the hard disk, it still reports it cannot find sda1), I think you are on to something with saying things are not connected correctly.

    But I have no idea what a SATA drive is, or where in the box to look for the 4 connectors you mention....

    The new drive has a narrow (1/4 inch or so wide) red ribbon cable, while the old one has a grey flat one about 1.5 inches wide. It's hard to tell, but I don't see other places to plug this red cable into the mobo.

    Yes, I am using Grub. I don't see any options on the Grub menu that I get from hitting <esc> on bootup. Do you mean somewhere else? I see there is a c command line option. When I go find vmlinuz or any other file name, I hear a sound like 4 taps on the box with a metal pen, and then it says file not found. These 4 taps seem to be coming from the new hdd, not the old. Using the e option does not seem to give any help.

    Maybe I'd ought to take it back to the tech and have him recheck the drives are plugged in to the right places?

    He did say something about the old drive being one thing and the new one being serial ATA. (I think) Is that what you mean by SATA?

    Have I given us any clues, or is what I have said a bunch of nonsense?

    Thanks, knute!
    :-Doug.

  6. #6
    Join Date
    Dec 1999
    Location
    Fargo, ND
    Posts
    1,816
    Ok, let me explain a few thing here.
    /dev/sda1 refers to, from what I know a scsi drive, and from what little exposure I've had to serial ATA (SATA) drives, a sata. (If I am wrong here, please someone speak up! )
    If the sata connections (there are 4 on your mobo) are anything like the ide connections on a mobo there are primary and secondary, etc connections.

    The PDF Manual for your board will show you the locations of the SATA controllers.

    Ok, on rereading your post, do you have both the old drive and the new connected???

    If you do, then when grub comes up you need to hit e for edit, then go to where it says somthing about root equaling /dev/sda1, and changing it to /dev/hda1.

    This is accomplished by hilighting (most likely) the kernel line, and pressing enter. Then you can use the arrow keys to move along the line and then delete the s and change it to an h. Pressing enter will get out out of the edit mode, and then pressing b will cause your modifications to boot.

    Your changes are NOT permenant, so you will have to go into your /boot/grub/menu.lst file and make the changes in the file itself to make it permenant.

    That should boot you into your old system. Since your board seem to have only one ide port, and assuming that jumpers haven't been changed on your old drive, it should be all set up.

    Have you installed ubuntu onto the SATA drive yet?
    Knute

    You live, you die, enjoy the interval!

  7. #7
    Join Date
    Aug 2004
    Posts
    234

    Exclamation

    Knute--

    Thank you for your very helpful instructions and questions.

    Yes, both drives are in the machine. Since there is nothing on the new drive, if something here is pointing to it as the boot drive, then it makes sense that it is complaining that it cannot find the root system on sda1--because that drive has nothing on it yet.

    I wouldn't be surprised if the tech changed the jumpers to make the new drive the master and the old the slave.

    But I will try what you suggest and get back to you. But not tonight anymore--it does not make sense to do work like that when I am this tired!

    Thanks, Knute! You are a really great help!
    :-Doug.

  8. #8
    Join Date
    Sep 2003
    Location
    Rochester, MN
    Posts
    3,604
    Quote Originally Posted by dgermann
    I wouldn't be surprised if the tech changed the jumpers to make the new drive the master and the old the slave.
    SATA does not have a master-slave relationship, since each device gets its own cable. However, the port you plug a drive into and the number of other drives on the system can affect which /dev/sdX it gets assigned to.

  9. #9
    Join Date
    Apr 2001
    Location
    SF Bay Area, CA
    Posts
    14,936
    Quote Originally Posted by cybertron
    However, the port you plug a drive into and the number of other drives on the system can affect which /dev/sdX it gets assigned to.
    That's true, but it's not the only thing.

    SCSI scanning is now done in parallel (on the last few kernel releases anyway), which means that the sdX letter that gets assigned to any particular drive is now arbitrary, and unpredictable. In other words, DON'T use /dev/sdXY, as those devices may point to any disk (and the assignment can change in the future: this is a mapping that the kernel explicitly does not guarantee to stay the same, unless you only have one SCSI-type disk).

    What you should be using are the udev-created /dev/disk/by-* symlinks. These symlinks are guaranteed to always point to the same disk (as long as the disk is present).

    You can use by-uuid to get at a partition by the Universally Unique IDentifier that the filesystem generated when it was created (though this may cause problems if you clone an FS using e.g. dd). Or you can use by-label to get at a partition by the label that was applied when the FS was created (or was changed, e.g. by e2label).

    Or you can use by-id to get at the disk (or any of its partitions) by its own identifying string(s). Or, you can use by-path to get at the disk by its "physical device path".

    For example, "pci domain 0, bus 0, device 12, function 0, then ide, bus 0, device 0" (my first disk: primary master) is "/dev/disk/by-path/pci-0000:00:12.0-ide-0:0". Other drives off this same controller change the -0:0 at the end to e.g. -0:1 for primary slave, and -1:0 for secondary master. My first (and only) SATA disk is "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:0:0"; i.e. a different PCI bus (actually PCIe, but it's treated the same), then "SCSI", then port:host:bus:lun.

    Note that these device paths will change if you move the disk around, or place the IDE or SCSI card (if applicable) into a different PCI slot, so this may not be the best way to do it. Note also that the by-id links will disappear if you replace a drive (because the old one failed, for instance). They're both there to give the admin the choice of which one will probably happen.

  10. #10
    Join Date
    Sep 2003
    Location
    Rochester, MN
    Posts
    3,604
    Ah, that solves the mystery of why just adding a drive would render my system unbootable (which is how I discovered that /dev/sd* assignments were not fixed). Next time I'm futzing with my fstab I'll have to convert it to use those by-whatever paths.

  11. #11
    Join Date
    Jun 2004
    Location
    Newcastle upon Tyne
    Posts
    2,978
    The by device name is still usable and I for one do not find much bother with it.

    What is important is that the hardware connection should not be changed unless it is intended to achieve a special requirement.

    On the mobo there is an order for the connectors like Sata1, Sata2, Sata3... to Sata7 for example. If only Sata disks are used then the sda will go to the connection with the lowest number as it would be the order the hardware will be detected. Thus 3 Sata disks connected to Sata1, Sata2 and Sata3 will be permanently known in Linux as sda, sdb and sdc. These names do get changed at all until different disks are added. If sdc is nominated to boot first it is still a sdc but look upon by Grub as (hd0).

    For example if a Pata disk is added then the mobo may detect the IDE controller before the Sata controller and so the sda will go to the Pata disk and the 3 Sata disk will be named as sdb, sdc and sdd respectively.

    There is a fixed pattern and it is dependent on the mobo. I didn't find too much trouble with booting between 1 to 9 hard disks this way as long as I take note of the different disk types in the PC. Everything is quick logical top me and it would be the way I would arrange it if I am shouldered with the responsibility to name all disks as sda, sdb, sdc... etc.

    Historically IDE disks are available first, SCSI second and Sata is the third. Also internal hard disks are always detected before external disks. My mobo follows this rule except it detects SCSI before IDE disks.

    I would use the by-uuid, by-label or by-disk if the distro sets it up automatically but would change to the Linux device name whenever it suit me.
    Last edited by saikee; 12-03-2007 at 12:23 PM.
    Linux user started Jun 2004 - No. 361921
    Using a Linux live CD to clone XP
    To install Linux and keep Windows MBR untouched
    Adding extra Linux & Doing it in a lazy way
    A Grub menu booting 100+ systems & A "Howto" to install and boot 145 systems
    Just cloning tips Just booting tips A collection of booting tips

    Judge asked Linux "You are being charged murdering Windoze by stabbing its heart with a weapon, what was it?" Replied Linux "A Live CD"

  12. #12
    Join Date
    Apr 2001
    Location
    SF Bay Area, CA
    Posts
    14,936
    Quote Originally Posted by saikee
    The by device name is still usable and I for one do not find much bother with it.
    It's usable for now. It's not always guaranteed (by the kernel) to be stable.

    If/when the mapping changes in the future, who's going to have to do more work: the people that switch to by-* symlinks now, before it's required, gradually, or the people that don't?

    (Of course it doesn't matter if you only have one SCSI-ish disk; the order of a single disk can't change. But it sounds like that doesn't apply to you, and it doesn't apply to dgermann or cybertron either.)

    On the mobo there is an order for the connectors like Sata1, Sata2, Sata3... to Sata7 for example.
    That order holds for the BIOS, at least. But Linux doesn't run BIOS code unless absolutely necessary (e.g. for ACPI, or VESA). Of course, grub does, I think...

    If only Sata disks are used then the sda will go to the connection with the lowest number as it would be the order the hardware will be detected.
    That's true today. It's not guaranteed though! A future kernel could change it.

    For example if a Pata disk is added then the mobo may detect the IDE controller before the Sata controller and so the sda will go to the Pata disk and the 3 Sata disk will be named as sdb, sdc and sdd respectively.

    There is a fixed pattern and it is dependent on the mobo.
    Again, this is true for the BIOS, but not necessarily true for the kernel. Future kernels may elect to do their own disk discovery, and change the mapping from drive to sdX letter.

    Historically IDE disks are available first, SCSI second and Sata is the third. Also internal hard disks are always detected before external disks. My mobo follows this rule except it detects SCSI before IDE disks.
    That's probably because your SCSI disks are off a PCI card, right? Those cards insert their own custom BIOS into the system BIOS at boot time, and take over several different functions. Apparently yours (if that's what's happening) also takes over the BIOS-level disk controller enumeration.

    I would use the by-uuid, by-label or by-disk if the distro sets it up automatically but would change to the Linux device name whenever it suit me.
    And you'd be OK doing that, until the kernel switches it around on you and your existing scripts/fstabs/whatever start intermittently failing...

  13. #13
    Join Date
    Sep 2003
    Location
    Rochester, MN
    Posts
    3,604
    Quote Originally Posted by bwkaz
    Quote Originally Posted by saikee
    If only Sata disks are used then the sda will go to the connection with the lowest number as it would be the order the hardware will be detected.
    That's true today. It's not guaranteed though! A future kernel could change it.
    Actually, it's not even universally true today. That's what got me in trouble - the disk with my root partition was on the first SATA port, but when I added a third drive root got moved to sdb for some reason. At least that's what I remember happening. I don't have all three drives in the same system anymore so I can't check, but I know it caused me a lot of confusion at the time. It's comforting to know that it was simple user ignorance and not a stupidity of the kernel as I initially thought it was.

  14. #14
    Join Date
    Aug 2004
    Posts
    234

    Question

    Wow! You guys have sure taken this conversation a long way down the road. (And maybe beyond my ken!)

    Everyone: In any case, an update: It turns out that both the drives are SATA. The old drive is 200GB, the new is 80GB, if that helps.

    They are plugged into slots SATA0 (new drive) and SATA1 (old drive). The schematic says the other two SATA slots are SATA4 and SATA5. The grey cable is for a floppy.

    There was a sheet of paper in the mobo box which said that for non-Vista OS installation to go into bios > Advanced > Drive and change it to configure SATA as ide. It had been AHCI. I made this change but it still stopped at Waiting for Root File System

    Knute--OK, I found the places in Grub I think you referred to. The first entry is "root (hd0,0)". I don't think that is what to change.

    The second entry is "kernel /boot/vmlinuz-2.6.15-29-386 root=/dev/sda1 ro quiet splash". This looks like it. Changing sda1 to hda1.

    Nope, still stalls out at Waiting for root file system.

    If I switch to ctrl-alt-F1, I see this error: "[17179570.980000] PCI: Failed to allocate mem resource #6:20000@90000000 for 0000:01:00.0"

    This time it says /dev/hda1 does not exist. (Instead of sda1).

    Oh, it also says "/bin/sh: can't access tty; job control turned off".

    Everyone: Is any of this any progress?
    :-Doug.

  15. #15
    Join Date
    Aug 2004
    Posts
    234

    Question

    Hi all--

    I tried a live CD for Gutsy 7.10. Started gparted and it showed partitions on my old drive at sdb1 (had a boot flag), sdb2, and sdb5.

    Thinking I had this thing licked, I went in to grub and edited the kernel line that referred to sda1 to sdb1, and no go. Same waiting for root filesystem. Then tried sdb2 and sdb5, with same results.

    Are there any clues here?

    Thanks!
    :-Doug.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •