Veljko wrote:
> Thanks for all your help, Bob. I don't usually need this step by
> step approach but in this case I needed to be sure I won't loose my
> data. Your patience and answers are much appreciated.
You are very welcome for the help. Don't worry about it at all. It's
no trouble. Just ke
On Thu, Nov 07, 2013 at 02:12:02AM -0700, Bob Proulx wrote:
> > > I'm offered to reassemble RAID. Is it safe to use auto reconfigure
> > > option or should I assemble all three manually?
>
> As long as all of the disks are to be assembled then automatic mode
> should be okay. Don't use automatic
Veljko wrote:
> Veljko wrote:
> > I replaced sdd drive and that went without problem, but after
> > replacing sda, the drive with boot partition and MBR, system
> > stalled at "veryfying dmi pool data". So I inserted debian CD and
> > went with rescue mode. I haven't used it so I have some question
On Tue, Nov 05, 2013 at 02:15:07PM +0100, Veljko wrote:
> On Thu, Oct 31, 2013 at 02:41:01PM -0600, Bob Proulx wrote:
> > But if you are concerned about writes to sdb
> > then I would simply plan to boot from the debian-installer image in
> > rescue mode, assemble the raid, sync, then replace sdb,
On Thu, Oct 31, 2013 at 02:41:01PM -0600, Bob Proulx wrote:
> But if you are concerned about writes to sdb
> then I would simply plan to boot from the debian-installer image in
> rescue mode, assemble the raid, sync, then replace sdb, and repeat.
> You can always install grub to the boot sectors af
On 11/1/2013 12:23 PM, Pascal Hambourg wrote:
> Stan Hoeppner a écrit :
>> On 11/1/2013 9:19 AM, Pascal Hambourg wrote:
>>> Stan Hoeppner a écrit :
This is precisely why I use hardware RAID HBAs for boot disks (and most
often for data disks as well). The HBA's BIOS makes booting transp
Stan Hoeppner a écrit :
> On 11/1/2013 9:19 AM, Pascal Hambourg wrote:
>> Stan Hoeppner a écrit :
>>> This is precisely why I use hardware RAID HBAs for boot disks (and most
>>> often for data disks as well). The HBA's BIOS makes booting transparent
>>> after drive failure. In addition you only h
On 11/1/2013 9:19 AM, Pascal Hambourg wrote:
> Stan Hoeppner a écrit :
>>
>> This is precisely why I use hardware RAID HBAs for boot disks (and most
>> often for data disks as well). The HBA's BIOS makes booting transparent
>> after drive failure. In addition you only have one array (hardware)
>>
On Fri, Nov 01, 2013 at 03:18:12PM +, Jonathan Dowland wrote:
> On Fri, Nov 01, 2013 at 01:47:37PM +0100, Veljko wrote:
> > Isn't that to inform the OS of partition table changes? In this case,
> > partition table stays the same.
>
> It has changed: prior to sgdisk, sda has no partitions and
On Fri, Nov 01, 2013 at 01:47:37PM +0100, Veljko wrote:
> Isn't that to inform the OS of partition table changes? In this case,
> partition table stays the same.
It has changed: prior to sgdisk, sda has no partitions and sda1, sda2
etc. do not exist. After you clone the table from sdb, they do. M
Stan Hoeppner a écrit :
>
> This is precisely why I use hardware RAID HBAs for boot disks (and most
> often for data disks as well). The HBA's BIOS makes booting transparent
> after drive failure. In addition you only have one array (hardware)
> instead of 3 (mdraid).
MD RAID arrays can be part
On Fri, Nov 01, 2013 at 03:13:51PM +0100, Pascal Hambourg wrote:
> > I don't know either, but in case that boot sector is not copied, could I
> > just
> > copy first 446 bytes? It is the place where MBR is located, without touching
> > partition table. So could something like this work:
> >
> > d
Hello,
Veljko a écrit :
>
> I think it is BIOS boot ordering. I don't remember how I installed MBR. Is it
> even possible to have MBR on both sda and sdb?
Of course.
> I don't know either, but in case that boot sector is not copied, could I just
> copy first 446 bytes? It is the place where MBR
On Fri, Nov 01, 2013 at 12:23:07PM +, Jonathan Dowland wrote:
> On Thu, Oct 31, 2013 at 03:41:18PM +0100, Veljko wrote:
> > # sgdisk --backup=table /dev/sdb
> > # sgdisk --load-backup=table /dev/sda
> > # sgdisk -G /dev/sda
>
> I'm not familiar wiht sgdisk but you may need to call "partprobe"
On Thu, Oct 31, 2013 at 03:41:18PM +0100, Veljko wrote:
> # sgdisk --backup=table /dev/sdb
> # sgdisk --load-backup=table /dev/sda
> # sgdisk -G /dev/sda
I'm not familiar wiht sgdisk but you may need to call "partprobe"
after these stages and before these ones…
> # mdadm --manage /dev/md0 --add /
Hello,,
On Thu, Oct 31, 2013 at 05:06:33PM -0500, Stan Hoeppner wrote:
> On 10/31/2013 3:41 PM, Bob Proulx wrote:
> > Is this a BIOS boot ordering boot system booting from sda? In which
> > case replacing sda won't have an MBR to boot from. You can probably
> > use your BIOS boot to select a dif
On 10/31/2013 3:41 PM, Bob Proulx wrote:
> Veljko wrote:
>> I'm using four 3TB drives, so I had to use GPT. Although I'm pretty
>> sure I know what I need to do, I want to make sure so I don't loose
>> data. Three drives are dying so I'm gonna replace them one by one.
>
> Sounds like a good plan t
Veljko wrote:
> I'm using four 3TB drives, so I had to use GPT. Although I'm pretty
> sure I know what I need to do, I want to make sure so I don't loose
> data. Three drives are dying so I'm gonna replace them one by one.
Sounds like a good plan to me. It is what I would do. It is what I
have d
Hi guys,
I'm using four 3TB drives, so I had to use GPT. Although I'm pretty sure
I know what I need to do, I want to make sure so I don't loose data.
Three drives are dying so I'm gonna replace them one by one.
This is the situation:
sda and sdb have four partitions.
sda1, sdb1 - 1MB partiti
19 matches
Mail list logo
