I have a broken fake raid on my machine (intel p67 chipset with one of the disks missing) and when trying to install F17 yesterday (with up-to-date respin done with pungi) I was greeted with the following message "disk sdXXX has bios raid information and..... blah..... is part of a broken raid, ignoring sdXXX". After ignoring the message later on I wasn't given the chance to use the spare disk.
I thought of patching anaconda to ignore the bios-raid-information and to allow me to use the disk as I single HDD but I was wondering if there are any side effects out of this?
I know that after doing this I will have to manually configure mdadm (and any other raid software) when the second disk arrives.
-- joshua
Hi,
On 10/15/2012 09:23 AM, Joshua C. wrote:
I have a broken fake raid on my machine (intel p67 chipset with one of the disks missing) and when trying to install F17 yesterday (with up-to-date respin done with pungi) I was greeted with the following message "disk sdXXX has bios raid information and..... blah..... is part of a broken raid, ignoring sdXXX". After ignoring the message later on I wasn't given the chance to use the spare disk.
I thought of patching anaconda to ignore the bios-raid-information and to allow me to use the disk as I single HDD but I was wondering if there are any side effects out of this?
Yes, the side effect of this is that if we wrongly detect an array as being broken and allow the user to use it, we will destroy the array, nuking any data on it. IOW ignoring this error is simply not an acceptable option.
What you can do is remove the bios raid metadata from the disk by going into a rescue shell on the system and run wipefs on the disk in question
Regards,
Hans
2012/10/15 Hans de Goede hdegoede@redhat.com:
Hi,
On 10/15/2012 09:23 AM, Joshua C. wrote:
I have a broken fake raid on my machine (intel p67 chipset with one of the disks missing) and when trying to install F17 yesterday (with up-to-date respin done with pungi) I was greeted with the following message "disk sdXXX has bios raid information and..... blah..... is part of a broken raid, ignoring sdXXX". After ignoring the message later on I wasn't given the chance to use the spare disk.
I thought of patching anaconda to ignore the bios-raid-information and to allow me to use the disk as I single HDD but I was wondering if there are any side effects out of this?
Yes, the side effect of this is that if we wrongly detect an array as being broken and allow the user to use it, we will destroy the array, nuking any data on it. IOW ignoring this error is simply not an acceptable option.
What you can do is remove the bios raid metadata from the disk by going into a rescue shell on the system and run wipefs on the disk in question
Regards,
Hans
I don't want to remove the bios data because this is the only way to rebild the raid when the next disk arrives. Currently I'm using the disk under Linux/Windows without any problems (in AHCI mode). Wipping the bios data will remove anything when later I build (re-build) the raid with the intel orom...
Can I just install anaything on the second disk and then manually adjust the fstab file to automount the disk from the broken raid? The raid is for my home partition.
--joshua
Hi,
On 10/15/2012 10:41 AM, Joshua C. wrote:
2012/10/15 Hans de Goede hdegoede@redhat.com:
Hi,
On 10/15/2012 09:23 AM, Joshua C. wrote:
I have a broken fake raid on my machine (intel p67 chipset with one of the disks missing) and when trying to install F17 yesterday (with up-to-date respin done with pungi) I was greeted with the following message "disk sdXXX has bios raid information and..... blah..... is part of a broken raid, ignoring sdXXX". After ignoring the message later on I wasn't given the chance to use the spare disk.
I thought of patching anaconda to ignore the bios-raid-information and to allow me to use the disk as I single HDD but I was wondering if there are any side effects out of this?
Yes, the side effect of this is that if we wrongly detect an array as being broken and allow the user to use it, we will destroy the array, nuking any data on it. IOW ignoring this error is simply not an acceptable option.
What you can do is remove the bios raid metadata from the disk by going into a rescue shell on the system and run wipefs on the disk in question
Regards,
Hans
I don't want to remove the bios data because this is the only way to rebild the raid when the next disk arrives. Currently I'm using the disk under Linux/Windows without any problems (in AHCI mode). Wipping the bios data will remove anything when later I build (re-build) the raid with the intel orom...
Can I just install anaything on the second disk and then manually adjust the fstab file to automount the disk from the broken raid?
Assuming your raid array is a mirror, and that you won't be partitioning it or something similar, just adding the existing /home partition to your fstab yes that should work. Although anaconda will not let you touch the mirror member during the install, if you've another disk, putting Fedora 17 on that other disk should work fine, and after that pointing fstab the disk will work.
BUT *IMPORTANT IMPORTANT IMPORTANT* you MUST remove the entry from fstab, before rebuilding the array, and then after the rebuild re-add the entry put now pointing to the raid and not to the single disk, otherwise Linux will keep using the single disk for your /home !!!
Regards,
Hans
2012/10/15 Hans de Goede hdegoede@redhat.com:
Hi,
On 10/15/2012 10:41 AM, Joshua C. wrote:
2012/10/15 Hans de Goede hdegoede@redhat.com:
Hi,
On 10/15/2012 09:23 AM, Joshua C. wrote:
I have a broken fake raid on my machine (intel p67 chipset with one of the disks missing) and when trying to install F17 yesterday (with up-to-date respin done with pungi) I was greeted with the following message "disk sdXXX has bios raid information and..... blah..... is part of a broken raid, ignoring sdXXX". After ignoring the message later on I wasn't given the chance to use the spare disk.
I thought of patching anaconda to ignore the bios-raid-information and to allow me to use the disk as I single HDD but I was wondering if there are any side effects out of this?
Yes, the side effect of this is that if we wrongly detect an array as being broken and allow the user to use it, we will destroy the array, nuking any data on it. IOW ignoring this error is simply not an acceptable option.
What you can do is remove the bios raid metadata from the disk by going into a rescue shell on the system and run wipefs on the disk in question
Regards,
Hans
I don't want to remove the bios data because this is the only way to rebild the raid when the next disk arrives. Currently I'm using the disk under Linux/Windows without any problems (in AHCI mode). Wipping the bios data will remove anything when later I build (re-build) the raid with the intel orom...
Can I just install anaything on the second disk and then manually adjust the fstab file to automount the disk from the broken raid?
Assuming your raid array is a mirror, and that you won't be partitioning it or something similar, just adding the existing /home partition to your fstab yes that should work. Although anaconda will not let you touch the mirror member during the install, if you've another disk, putting Fedora 17 on that other disk should work fine, and after that pointing fstab the disk will work.
BUT *IMPORTANT IMPORTANT IMPORTANT* you MUST remove the entry from fstab, before rebuilding the array, and then after the rebuild re-add the entry put now pointing to the raid and not to the single disk, otherwise Linux will keep using the single disk for your /home !!!
Regards,
Hans
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
This is what I ment. I'll report back after the installation. Thanks
-
Hans de Goede -
Joshua C.