| Line 254: |
Line 254: |
| | | | |
| | | | |
| | + | == My Experience == |
| | | | |
| | + | My experience is loosely alluded to above, I upgraded the disk in a Dell server with two new Seagate 1Tb ST1000340NS from the 500Gb that came with the server, they are a Server Edition disk. |
| | | | |
| | + | The Disks were installed separately and allowed to come up and sync in the array, the first indication that something wasn't working was the machine would not boot when the 2nd disk was installed. I set back my original first disk and looked through the system log, noting th grub failures. ''It's not fatal'' was the message, but it did stop the machine from booting on the disk, perhaps that's just ''not living, therefore not fatal'', whatever, it's not terribly useful. It did this on both disks. |
| | | | |
| | + | What has happened is that disk partition was written too close to the start of the drive, so the boot record didn't have enough room for its GRUB staging - if thats the right term. |
| | | | |
| − | | + | To correct this, I removed the disk from the array, by failing it, then remove it, then repartitioning and add it back to the array. |
| − | | |
| − | | |
| − | | |
| − | ===The Leadup===
| |
| − | I'm not sure if I'm reporting a bug or just some manual maintenance
| |
| − | | |
| − | My Disk didn't respond correctly to the Menu option "Manage Disk Redundancy". I was upgrading the hard disks to 1Gb disks from the 500Gb that came with the Dell server, the new disks were the Seagate 1Tb ST1000340NS, they are a Server Edition disk. It did this on both disks
| |
| − | | |
| − | The Disk was installed as the 2nd Hard Disk during an Upgrade process
| |
| − | | |
| − | ''It's not fatal'', but it did stop the machine from booting on the disk, perhaps that's just ''not living, therefore not fatal'', whatever, it's not terribly useful.
| |
| − | | |
| − | | |
| − | and a look from fdisks view shows
| |
| − | | |
| − | Note the correct partitioning on sda
| |
| − | | |
| − | [root@ ~]# fdisk -lu /dev/sda
| |
| − |
| |
| − | Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
| |
| − | 255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
| |
| − | Units = sectors of 1 * 512 = 512 bytes
| |
| − |
| |
| − | Device Boot Start End Blocks Id System
| |
| − | /dev/sda1 * 63 208844 104391 fd Linux raid autodetect
| |
| − | /dev/sda2 208845 1953520064 976655610 fd Linux raid autodetect
| |
| − | | |
| − | What has happened here is the disk partition has been written too close to the start of the drive, so the boot record hasn't got enough room for its GRUB staging - if thats the right term.
| |
| − | | |
| − | To correct this, remove the disk from the array, you will need to fail it, then remove it, the repartition and add it back to the array | |
| − | | |
| − | {{Note box|I'm using sdb which was right for me, it might not be for you (if it's RAID 1, there is a 50% chance it's not !)}}
| |
| − | | |
| − | ===Here we go lets fix this===
| |
| − | | |
| − | | |
| − | and then I can use the wiki's proceedure to grow the disk - which is why I am here
| |
| | | | |
| | David Bray | | David Bray |
