[opensuse] RAID 1 10.3 install doesn't boot
Just got a new box with 2 identical SATA drives. Followed (as best as my poor eyes could see the screenshots) the advice given at http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID (first time trying the RAID thing) Everything pretty much went as expected, but the system would not reboot from the HD(s) at the midpoint of the install. I then discovered the moment in "install" where one has the opportunity to do "select mode: other" and boot from installed system, and the installer picked up again just fine. (booting from /dev/md2) So, all seems well until I try rebooting normally. The thing hangs just where you would expect grub to take over. Repeatedly. Trying through the installer with the above trick works again but... that's not really an acceptable system. fdisk -l shows the following, but also emits a bunch of Disk /dev/md0 doesn't contain a valid partition table Disk /dev/md1 doesn't contain a valid partition table Disk /dev/md2 doesn't contain a valid partition table Disk /dev/md3 doesn't contain a valid partition table Wonder what that means...... TIA. Disk /dev/sda: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors/track, 19457 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000af2c7 Device Boot Start End Blocks Id System /dev/sda1 * 1 131 1052226 fd Linux raid autodetect /dev/sda2 132 393 2104515 fd Linux raid autodetect /dev/sda3 394 6921 52436160 fd Linux raid autodetect /dev/sda4 6922 19457 100695420 fd Linux raid autodetect Disk /dev/sdb: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors/track, 19457 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000312b4 Device Boot Start End Blocks Id System /dev/sdb1 * 1 131 1052226 fd Linux raid autodetect /dev/sdb2 132 393 2104515 fd Linux raid autodetect /dev/sdb3 394 6921 52436160 fd Linux raid autodetect /dev/sdb4 6922 19457 100695420 fd Linux raid autodetect Disk /dev/md0: 1077 MB, 1077465088 bytes 2 heads, 4 sectors/track, 263053 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk identifier: 0x00000000 Disk /dev/md1: 2155 MB, 2155008000 bytes 2 heads, 4 sectors/track, 526125 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk identifier: 0x00000000 Disk /dev/md2: 53.6 GB, 53694554112 bytes 2 heads, 4 sectors/track, 13109022 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk identifier: 0x00000000 Disk /dev/md3: 103.1 GB, 103112036352 bytes 2 heads, 4 sectors/track, 25173837 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk identifier: 0x00000000 Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Michael Fischer wrote:
Just got a new box with 2 identical SATA drives.
Followed (as best as my poor eyes could see the screenshots) the advice given at
http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID
(first time trying the RAID thing)
Everything pretty much went as expected, but the system would not reboot from the HD(s) at the midpoint of the install.
I then discovered the moment in "install" where one has the opportunity to do "select mode: other" and boot from installed system, and the installer picked up again just fine. (booting from /dev/md2)
So, all seems well until I try rebooting normally. The thing hangs just where you would expect grub to take over. Repeatedly. Trying through the installer with the above trick works again but... that's not really an acceptable system.
Is your /boot on the RAID array? If so, that's likely your problem. -- Use OpenOffice.org <http://www.openoffice.org> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, May 06, James Knott wrote:
Michael Fischer wrote:
Just got a new box with 2 identical SATA drives.
Followed (as best as my poor eyes could see the screenshots) the advice given at
http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID
(first time trying the RAID thing)
Everything pretty much went as expected, but the system would not reboot from the HD(s) at the midpoint of the install.
I then discovered the moment in "install" where one has the opportunity to do "select mode: other" and boot from installed system, and the installer picked up again just fine. (booting from /dev/md2)
So, all seems well until I try rebooting normally. The thing hangs just where you would expect grub to take over. Repeatedly. Trying through the installer with the above trick works again but... that's not really an acceptable system.
Is your /boot on the RAID array? If so, that's likely your problem.
Yes, according to the advice on http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID But perhaps I misunderstood it.... Would it be advisable to just raid / and /home, or just /home, according to needs and preferences? Of course, that loses the possibility of booting from disk b when a goes bad, etc, etc.. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Michael Fischer wrote:
On Tue, May 06, James Knott wrote:
Michael Fischer wrote:
Just got a new box with 2 identical SATA drives.
Followed (as best as my poor eyes could see the screenshots) the advice given at
http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID
(first time trying the RAID thing)
Everything pretty much went as expected, but the system would not reboot from the HD(s) at the midpoint of the install.
I then discovered the moment in "install" where one has the opportunity to do "select mode: other" and boot from installed system, and the installer picked up again just fine. (booting from /dev/md2)
So, all seems well until I try rebooting normally. The thing hangs just where you would expect grub to take over. Repeatedly. Trying through the installer with the above trick works again but... that's not really an acceptable system.
Is your /boot on the RAID array? If so, that's likely your problem.
Yes, according to the advice on
http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID
But perhaps I misunderstood it....
Would it be advisable to just raid / and /home, or just /home, according to needs and preferences? Of course, that loses the possibility of booting from disk b when a goes bad, etc, etc..
Michael
You may have done everything 100% correct and the problem may be in your bios settings. In the bios did you enable any of the "fake raid" features to define the raid setup? No problem if you did, I have 3 raid 1 system running currently all with the software raid installed via yast. I ran into the non-booting problem on one or two of the systems. The solution was to tell the bios to make the raid bootable. You might have to poke around a little, it may even be in your separate bios raid setup, but I would be willing to wager that you will find an option that will make the raid setup bootable. After you have found it, I bet you boot without any problem. If for some reason you don't have that option, you may want to try installing the boot loader again with grub-install (see man grub-install). I have also had to do that after the yast installer finished, but got confused for some reason. -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Michael Fischer wrote:
On Tue, May 06, James Knott wrote:
Michael Fischer wrote:
Just got a new box with 2 identical SATA drives.
Followed (as best as my poor eyes could see the screenshots) the advice given at
http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID
(first time trying the RAID thing)
Everything pretty much went as expected, but the system would not reboot from the HD(s) at the midpoint of the install.
I then discovered the moment in "install" where one has the opportunity to do "select mode: other" and boot from installed system, and the installer picked up again just fine. (booting from /dev/md2)
So, all seems well until I try rebooting normally. The thing hangs just where you would expect grub to take over. Repeatedly. Trying through the installer with the above trick works again but... that's not really an acceptable system.
Is your /boot on the RAID array? If so, that's likely your problem.
Yes, according to the advice on
http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID
But perhaps I misunderstood it....
Would it be advisable to just raid / and /home, or just /home, according to needs and preferences? Of course, that loses the possibility of booting from disk b when a goes bad, etc, etc..
Michael
That's for RAID 1, which I haven't used. On RAID 5, /boot cannot be on RAID. -- Use OpenOffice.org <http://www.openoffice.org> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Michael Fischer wrote:
Just got a new box with 2 identical SATA drives.
Followed (as best as my poor eyes could see the screenshots) the advice given at
http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID
(first time trying the RAID thing)
Everything pretty much went as expected, but the system would not reboot from the HD(s) at the midpoint of the install.
I then discovered the moment in "install" where one has the opportunity to do "select mode: other" and boot from installed system, and the installer picked up again just fine. (booting from /dev/md2)
So, all seems well until I try rebooting normally. The thing hangs just where you would expect grub to take over. Repeatedly. Trying through the installer with the above trick works again but... that's not really an acceptable system.
fdisk -l shows the following, but also emits a bunch of
Disk /dev/md0 doesn't contain a valid partition table Disk /dev/md1 doesn't contain a valid partition table Disk /dev/md2 doesn't contain a valid partition table Disk /dev/md3 doesn't contain a valid partition table
Wonder what that means......
It means that each multi-disk (md) pseudo-device listed does not contain a valid partition table. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Michael Fischer wrote:
Just got a new box with 2 identical SATA drives.
Followed (as best as my poor eyes could see the screenshots) the advice given at
http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID
(first time trying the RAID thing)
Everything pretty much went as expected, but the system would not reboot from the HD(s) at the midpoint of the install.
I then discovered the moment in "install" where one has the opportunity to do "select mode: other" and boot from installed system, and the installer picked up again just fine. (booting from /dev/md2)
So, all seems well until I try rebooting normally. The thing hangs just where you would expect grub to take over. Repeatedly. Trying through the installer with the above trick works again but... that's not really an acceptable system.
fdisk -l shows the following, but also emits a bunch of
Disk /dev/md0 doesn't contain a valid partition table Disk /dev/md1 doesn't contain a valid partition table Disk /dev/md2 doesn't contain a valid partition table Disk /dev/md3 doesn't contain a valid partition table
Wonder what that means......
So you are using MD Raid (Linux Raid). This is different than the "bios" raid that David mentioned. In your case you don't need to set anything in the bios for this to work properly. You didn't mention what Raid level you are using, but from your drive info it looks like you are stetting up a Mirror on two partitions. This is what I did. There was much debate on this list (and many others that I googled over it) about putting swap on the mirror raid, but I wound up putting it on MD raid and it works well. The only thing about this is you will have to disable "resume" for swap to work. MD raid will not handle swap with "resume"at present, you have to set "noresume". (You will loose the ability to put your system in standby. Not an issue on my install). You could put swap on a non MD raid partition, but for the sake of ease of replacing a drive should one fail, I put it on the MD raid. I put all partitions of this install on MD raid, similar to yours, but I had a problem with /boot not working if it was on an extended partition. The only way I could get it to work was to make a primary partition for boot (two actually, 1 on each drive, the same size - make the partition first, format it with MD raid later). Then I made an extended partition to for all the other partitions. Then I set up each MD raid, boot on the primary partition, all the rest including swap on the separate extended partitions and all has been working well. I'm not sure if you have the option to make /boot on a primary, or at least a logical partition or not. Hope this helps. Jim F -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Michael Fischer wrote:
Just got a new box with 2 identical SATA drives.
Followed (as best as my poor eyes could see the screenshots) the advice given at http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID
(first time trying the RAID thing)
Everything pretty much went as expected, but the system would not reboot from the HD(s) at the midpoint of the install. This sounds like a problem either of grub not being written to the mbr (i.e. md0-4 do not have an mbr). For this to work with raid 1, just make sure you tell Yast which actual drive to write GRUB to, write it to
On 05/07/2008 07:16 PM, Jim Flanagan wrote: the MBR, and verify that the line in menu.lst says an actual disk, [i.e. root (hd1,4) which is what mine has], and that the kernel line has the right root line, i.e. root=/dev/md0. Here is what part of mine looks like (md0 is /, which includes /boot, and md1 is /home). jmorris:/home/joe # cat /boot/grub/menu.lst # Modified by YaST2. Last modification on Tue Feb 12 22:23:05 PHT 2008 default 0 timeout 8 gfxmenu (hd1,4)/boot/message ###Don't change this comment - YaST2 identifier: Original name: linux### title openSUSE 10.3 - 2.6.22.17-0.1 root (hd1,4) kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/md0 vga=0x31a resume=/dev/sda1 splash=verbose showopts initrd /boot/initrd-2.6.22.17-0.1-default
You didn't mention what Raid level you are using, Check subject. I put all partitions of this install on MD raid, similar to yours, but I had a problem with /boot not working if it was on an extended partition. My boot is on the same raid one extended partition as /. The only way I could get it to work was to make a primary partition for boot (two actually, 1 on each drive, the same size - make the partition first, format it with MD raid later). Then I made an extended partition to for all the other partitions. Then I set up each MD raid, boot on the primary partition, all the rest including swap on the separate extended partitions and all has been working well.
I'm not sure if you have the option to make /boot on a primary, or at least a logical partition or not. I think his problem is getting GRUB written to the MBR, and then telling grub which INDIVIDUAL disk to read its files from, since it cannot read from md raid until it loads the initrd. To be able to load that, it needs to start off booting from an individual disk. I have read some time ago newer versions of grub can read directly from an md device, but I have never seen it in action.
-- Joe Morris Registered Linux user 231871 running openSUSE 10.3 x86_64 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Joe Morris wrote:
Michael Fischer wrote:
Just got a new box with 2 identical SATA drives.
Followed (as best as my poor eyes could see the screenshots) the advice given at http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID
(first time trying the RAID thing)
Everything pretty much went as expected, but the system would not reboot from the HD(s) at the midpoint of the install. This sounds like a problem either of grub not being written to the mbr (i.e. md0-4 do not have an mbr). For this to work with raid 1, just make sure you tell Yast which actual drive to write GRUB to, write it to the MBR, and verify that the line in menu.lst says an actual disk, [i.e. root (hd1,4) which is what mine has], and that the kernel line has the right root
On 05/07/2008 07:16 PM, Jim Flanagan wrote: line, i.e. root=/dev/md0. Here is what part of mine looks like (md0 is /, which includes /boot, and md1 is /home). jmorris:/home/joe # cat /boot/grub/menu.lst # Modified by YaST2. Last modification on Tue Feb 12 22:23:05 PHT 2008 default 0 timeout 8 gfxmenu (hd1,4)/boot/message
###Don't change this comment - YaST2 identifier: Original name: linux### title openSUSE 10.3 - 2.6.22.17-0.1 root (hd1,4) kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/md0 vga=0x31a resume=/dev/sda1 splash=verbose showopts initrd /boot/initrd-2.6.22.17-0.1-default
You didn't mention what Raid level you are using, Check subject. I put all partitions of this install on MD raid, similar to yours, but I had a problem with /boot not working if it was on an extended partition. My boot is on the same raid one extended partition as /. The only way I could get it to work was to make a primary partition for boot (two actually, 1 on each drive, the same size - make the partition first, format it with MD raid later). Then I made an extended partition to for all the other partitions. Then I set up each MD raid, boot on the primary partition, all the rest including swap on the separate extended partitions and all has been working well.
I'm not sure if you have the option to make /boot on a primary, or at least a logical partition or not. I think his problem is getting GRUB written to the MBR, and then telling grub which INDIVIDUAL disk to read its files from, since it cannot read from md raid until it loads the initrd. To be able to load that, it needs to start off booting from an individual disk. I have read some time ago newer versions of grub can read directly from an md device, but I have never seen it in action.
As I stated my install is reading /boot on /dev/MD0 with no problems. But it would not work if /dev/MD0 was on an extended partition, it would only work on a primary partition (but I suspect a logical partition would work as well). Jim F -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Jim Flanagan wrote:
Joe Morris wrote:
Michael Fischer wrote:
Just got a new box with 2 identical SATA drives.
Followed (as best as my poor eyes could see the screenshots) the advice given at http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID
(first time trying the RAID thing)
Everything pretty much went as expected, but the system would not reboot from the HD(s) at the midpoint of the install. This sounds like a problem either of grub not being written to the mbr (i.e. md0-4 do not have an mbr). For this to work with raid 1, just make sure you tell Yast which actual drive to write GRUB to, write it to the MBR, and verify that the line in menu.lst says an actual disk, [i.e. root (hd1,4) which is what mine has], and that the kernel line has the right root
On 05/07/2008 07:16 PM, Jim Flanagan wrote: line, i.e. root=/dev/md0. Here is what part of mine looks like (md0 is /, which includes /boot, and md1 is /home). jmorris:/home/joe # cat /boot/grub/menu.lst # Modified by YaST2. Last modification on Tue Feb 12 22:23:05 PHT 2008 default 0 timeout 8 gfxmenu (hd1,4)/boot/message
###Don't change this comment - YaST2 identifier: Original name: linux### title openSUSE 10.3 - 2.6.22.17-0.1 root (hd1,4) kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/md0 vga=0x31a resume=/dev/sda1 splash=verbose showopts initrd /boot/initrd-2.6.22.17-0.1-default
You didn't mention what Raid level you are using, Check subject. I put all partitions of this install on MD raid, similar to yours, but I had a problem with /boot not working if it was on an extended partition. My boot is on the same raid one extended partition as /. The only way I could get it to work was to make a primary partition for boot (two actually, 1 on each drive, the same size - make the partition first, format it with MD raid later). Then I made an extended partition to for all the other partitions. Then I set up each MD raid, boot on the primary partition, all the rest including swap on the separate extended partitions and all has been working well.
I'm not sure if you have the option to make /boot on a primary, or at least a logical partition or not. I think his problem is getting GRUB written to the MBR, and then telling grub which INDIVIDUAL disk to read its files from, since it cannot read from md raid until it loads the initrd. To be able to load that, it needs to start off booting from an individual disk. I have read some time ago newer versions of grub can read directly from an md device, but I have never seen it in action.
As I stated my install is reading /boot on /dev/MD0 with no problems. But it would not work if /dev/MD0 was on an extended partition, it would only work on a primary partition (but I suspect a logical partition would work as well).
Jim F This is of course on Raid 1, I don't have any experience with Raid 5.
Jim F -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Jim Flanagan wrote:
So you are using MD Raid (Linux Raid). This is different than the "bios" raid that David mentioned. In your case you don't need to set anything in the bios for this to work properly.
You didn't mention what Raid level you are using, but from your drive info it looks like you are stetting up a Mirror on two partitions. This is what I did. There was much debate on this list (and many others that I googled over it) about putting swap on the mirror raid, but I wound up putting it on MD raid and it works well. The only thing about this is you will have to disable "resume" for swap to work. MD raid will not handle swap with "resume"at present, you have to set "noresume". (You will loose the ability to put your system in standby. Not an issue on my install). You could put swap on a non MD raid partition, but for the sake of ease of replacing a drive should one fail, I put it on the MD raid.
I put all partitions of this install on MD raid, similar to yours, but I had a problem with /boot not working if it was on an extended partition. The only way I could get it to work was to make a primary partition for boot (two actually, 1 on each drive, the same size - make the partition first, format it with MD raid later). Then I made an extended partition to for all the other partitions. Then I set up each MD raid, boot on the primary partition, all the rest including swap on the separate extended partitions and all has been working well.
I'm not sure if you have the option to make /boot on a primary, or at least a logical partition or not. Hope this helps.
Jim F
I agree Jim that sw raid doesn't need anything to be set in the bios, but if the fake raid *has* been configured, then it will need to be set as bootable on some boards or the boards will refuse to boot from those drives at all. My Gigabyte 7N400 is a perfect example of that. In the bios, you have a Promise (or nVidia) Raid utility that selects the drives included in the array, provides a hardware rebuild function, and determines whether the raid array is bootable or not. This may not apply to Michael's case, but if his board offered any raid function, even the windows fake raid, and he set the array up in the bios, the in some cases he *will* have to set that as bootable before the bios will pass control to the array to boot. 2 out of 3 of the last 3 raid 1 systems I set up were like that. Configuring the bios raid does have a benefit. The benefit of configuring the fake raid is that it tests the array before boot, and provides a hardware rebuild in case one drive fails. In the case of a drive failure, you just install a new drive, and it is rebuilt before you ever hit the first boot in Linux. Just a couple of observations from person experience in building 3 raid 1 systems on 10.3 since January. May not apply, but may help. -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, May 07, David C. Rankin wrote:
Jim Flanagan wrote:
So you are using MD Raid (Linux Raid). This is different than the "bios" raid that David mentioned. In your case you don't need to set anything in the bios for this to work properly.
You didn't mention what Raid level you are using, but from your drive info it looks like you are stetting up a Mirror on two partitions. This
Yes, RAID 1.
I put all partitions of this install on MD raid, similar to yours, but I had a problem with /boot not working if it was on an extended partition. The only way I could get it to work was to make a primary partition for boot (two actually, 1 on each drive, the same size - make the partition first, format it with MD raid later). Then I made an extended partition to for all the other partitions. Then I set up each MD raid, boot on the primary partition, all the rest including swap on the separate extended partitions and all has been working well.
All partitions were made "primary".
I agree Jim that sw raid doesn't need anything to be set in the bios, but if the fake raid *has* been configured, then it will need to be set as bootable on some boards or the boards will refuse to boot from those drives at all. My Gigabyte 7N400 is a perfect example of that. In the bios, you have a Promise (or nVidia) Raid utility that selects the drives included in the array, provides a hardware rebuild function, and determines whether the raid array is bootable or not.
Hmm. I poked at the bios, saw that it had "Raid Mode" for the SATA drives, but left it in "SATA Mode" when I did the install, so I think that should not be interfering with my install. I could reboot and check in the bios to see that such is still the case. I wonder if in some odd way the bios thinks that the "boot sequence" does not include the SATA drives... have to check that.
This may not apply to Michael's case, but if his board offered any raid function, even the windows fake raid, and he set the array up in the bios, the in some cases he *will* have to set that as bootable before the bios will pass control to the array to boot. 2 out of 3 of the last 3 raid 1 systems I set up were like that.
The 'fdisk -l' I posted shows that both /dev/sda1 and /dev/sdb1 (where I put /boot) are marked as Boot. Thanks to all who have chipped in here. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue May 6 2008 20:44:49 Michael Fischer wrote:
Just got a new box with 2 identical SATA drives.
Followed (as best as my poor eyes could see the screenshots) the advice given at
http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID
(first time trying the RAID thing)
Everything pretty much went as expected, but the system would not reboot from the HD(s) at the midpoint of the install.
I was not able to pass the midpoint when I formatted the root partition (RAID1) with ext3, but it worked fine if I used Reiser on the same partition. I reported this as a bug here: https://bugzilla.novell.com/show_bug.cgi?id=350992 Did you try to use Reiser on your partition containing /boot? -- Carlos FL "It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that." - G. H. Hardy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
----- Original Message ----- From: "Carlos F. Lange" <carlos.lange@ualberta.ca> To: "Michael Fischer" <michael@visv.net>; "opensuse" <opensuse@opensuse.org> Sent: Wednesday, May 07, 2008 9:49 AM Subject: Re: [opensuse] RAID 1 10.3 install doesn't boot
On Tue May 6 2008 20:44:49 Michael Fischer wrote:
Just got a new box with 2 identical SATA drives.
Followed (as best as my poor eyes could see the screenshots) the advice given at
http://en.opensuse.org/How_to_install_openSUSE_on_software_RAID
(first time trying the RAID thing)
Everything pretty much went as expected, but the system would not reboot from the HD(s) at the midpoint of the install.
I was not able to pass the midpoint when I formatted the root partition (RAID1) with ext3, but it worked fine if I used Reiser on the same partition. I reported this as a bug here: https://bugzilla.novell.com/show_bug.cgi?id=350992
Did you try to use Reiser on your partition containing /boot?
Huh? All my boxes boot from ext3 on software raid1. All my boxes have /boot on a small raid1 with ext3, all software raid, no fake-raid and any fake-raid options in the bios disabled. My typical setup is anywhere from 4 to 12 identical drives, each with identical partitioning, 3 primary partitions: 1: 128M raid1 /boot ext3 2: 512M raid0 swap 3: remainder raid10 / reiser3 I almost always have to use the "boot installed system" option in the installer and manually edit /etc/grub.conf, /boot/grub/device.map, and /boot/grub/menu/lst, and then run grub --batch </etc/grub.conf For an 8-drive box it looks like this: /etc/gub.conf: setup (hd0) (hd0,0) setup (hd1) (hd1,0) setup (hd2) (hd2,0) setup (hd3) (hd3,0) setup (hd4) (hd4,0) setup (hd5) (hd5,0) setup (hd6) (hd6,0) setup (hd7) (hd7,0) quit /boot/grub/device.map: (hd0) /dev/sda (hd1) /dev/sdb (hd2) /dev/sdc (hd3) /dev/sdd (hd4) /dev/sde (hd5) /dev/sdf (hd6) /dev/sdg (hd7) /dev/sdh /boot/grub/manu.lst: default 0 timeout 30 title openSUSE 10.3 (hd0) root (hd0,0) kernel /vmlinuz root=/dev/md2 console=ttyS0,115200n8 noresume showopts initrd /initrd title openSUSE 10.3 (hd1) root (hd1,0) kernel /vmlinuz root=/dev/md2 console=ttyS0,115200n8 noresume showopts initrd /initrd The things to note are, * You may not have to edit devices.map, usually the drives are listed out of order but they're all there, I just usually install from a bootable usb stick, and usually the usb stick is included in devices.map, and I don't want it in there. It would have been /dev/sdi in this case. * The grub.conf settings cause grub to be set up on each individual drive such that if the drives were unplugged and moved around in the hot-swap bays, or if the bios settings alter the dricve discovery order, any drive will boot to the grub menu and load the kernel and inirtrd. So you can boot from any drive. * menu.lst has a stanza to boot from the 2nd drive just in case there is a problem with the /boot partition on the 1st drive, it's a fastest way to boot up and get running again. could make more stanzas to boot from any of the 8 drives but you'd never use them. * I usually have to edit menu.lst to put it back this way after any kernel updates. /boot/vmlinuz is always a symlink that points to whatever is the current kernel, same for initrd so menu.lst never actually needs to change, but yast edits the file during the update. * you probably don't want the console= option in menu.lst * the paths to vmlinuz and initrd in menu.lst are correct. in the context of the rest of this setup, vmlinuz is /vmlinuz not /boot/vmlinuz, because /boot is it's own filesystem, not a directory in / * setting up multiple partitions the same way on 8 or more drives would be a tedious drag in yast but autoyast does it automatically in a second, or you can use sfdisk at one of the other virtual consoles to do one drive and quickly duplicate it to the others non-interactively. For some unfathomable reason, once in a great while the installer does actually manage to create a working /boot on it's own. The config files look different than above but it boots. I haven't yet figured out how to get it to work all on it's own reliably. I gave up trying and just set up the above configuration manually every time. -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed May 7 2008 19:55:33 Brian K. White wrote:
----- Original Message ----- From: "Carlos F. Lange" <carlos.lange@ualberta.ca> [...]
I was not able to pass the midpoint when I formatted the root partition (RAID1) with ext3, but it worked fine if I used Reiser on the same partition. I reported this as a bug here: https://bugzilla.novell.com/show_bug.cgi?id=350992
Did you try to use Reiser on your partition containing /boot?
Huh? All my boxes boot from ext3 on software raid1. All my boxes have /boot on a small raid1 with ext3, all software raid, no fake-raid and any fake-raid options in the bios disabled.
That is interesting. I don't have many systems to test, but my experience was consistent on a few machines with 2 disks in RAID1.
My typical setup is anywhere from 4 to 12 identical drives, each with identical partitioning, 3 primary partitions: 1: 128M raid1 /boot ext3 2: 512M raid0 swap 3: remainder raid10 / reiser3
I almost always have to use the "boot installed system" option in the installer and manually edit /etc/grub.conf, /boot/grub/device.map, and /boot/grub/menu/lst, and then run grub --batch </etc/grub.conf
I don't use a separate partition for /boot, but I think the fact that you use Reiser for your other partition doesn't invalidate the comparison, because it is just /boot that counts when grub is trying to find a kernel. My configuration usually is: 1: 1GB swap (each disk, no RAID) 2: 16GB / RAID1 (reiser3) 3: rest /home RAID1 (ext3) My installation stops in the middle saying it can't find an operating system, if I use ext3 in the root partition. Could it be because of the "stage2" option in the default grub.conf? /etc/grub.conf: setup --stage2=/boot/grub/stage2 (hd0,1) (hd0,1) quit Thanks for the ideas of replicating grub in every drive and setting a backup boot pointer. I will use those. -- Carlos FL "It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that." - G. H. Hardy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 08 May 2008 14:58:55 Carlos F. Lange wrote:
On Wed May 7 2008 19:55:33 Brian K. White wrote:
----- Original Message ----- From: "Carlos F. Lange" <carlos.lange@ualberta.ca> [...]
I was not able to pass the midpoint when I formatted the root partition (RAID1) with ext3, but it worked fine if I used Reiser on the same partition. I reported this as a bug here: https://bugzilla.novell.com/show_bug.cgi?id=350992
Did you try to use Reiser on your partition containing /boot?
Huh? All my boxes boot from ext3 on software raid1. All my boxes have /boot on a small raid1 with ext3, all software raid, no fake-raid and any fake-raid options in the bios disabled.
That is interesting. I don't have many systems to test, but my experience was consistent on a few machines with 2 disks in RAID1.
My typical setup is anywhere from 4 to 12 identical drives, each with identical partitioning, 3 primary partitions: 1: 128M raid1 /boot ext3 2: 512M raid0 swap 3: remainder raid10 / reiser3
I almost always have to use the "boot installed system" option in the installer and manually edit /etc/grub.conf, /boot/grub/device.map, and /boot/grub/menu/lst, and then run grub --batch </etc/grub.conf
I don't use a separate partition for /boot, but I think the fact that you use Reiser for your other partition doesn't invalidate the comparison, because it is just /boot that counts when grub is trying to find a kernel. My configuration usually is: 1: 1GB swap (each disk, no RAID) 2: 16GB / RAID1 (reiser3) 3: rest /home RAID1 (ext3)
My installation stops in the middle saying it can't find an operating system, if I use ext3 in the root partition. Could it be because of the "stage2" option in the default grub.conf?
/etc/grub.conf: setup --stage2=/boot/grub/stage2 (hd0,1) (hd0,1) quit
Thanks for the ideas of replicating grub in every drive and setting a backup boot pointer. I will use those.
-- Carlos FL "It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that." - G. H. Hardy
I'm curious about this subject. I tried to install 10.3 64bit onto intel ich7 in several way. What ever I did yast partitioned them to device mapper.... and the install failed out when it came to install the boot manager. Grub errors. All the files were correctly installed on the discs and the problem seemed to be entirely down to what the installer passed on to grub. Interestingly suse 10 installed perfectly on more or less the same set up but the discs weren't readable with more recent software. Knoppix 4.02 could deal with them perfectly. Knoppix 5.02 located them correctly but the data wasn't read correctly. I didn't intend to upgrade from 10 until 11 had been out for a while but cpu and board broke. The above resulted in hours and hours of fruitless effort. I went on to 10.3 because 10.0 repositories seemed to have dropped of the planet. Can the installer be made to work with an ich7 motherboard? Maybe I missed something. John -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu May 8 2008 09:11:13 John wrote:
I'm curious about this subject. I tried to install 10.3 64bit onto intel ich7 in several way. What ever I did yast partitioned them to device mapper.... and the install failed out when it came to install the boot manager. Grub errors. All the files were correctly installed on the discs and the problem seemed to be entirely down to what the installer passed on to grub.
John, I think you may have better luck starting a new thread by sending a new message (not a reply) with your point. By replying within this thread (what some call thread-hijacking), your question gets buried under a pile of unrelated others, when threading is used to display the messages. -- Carlos FL "It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that." - G. H. Hardy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John wrote:
I'm curious about this subject. I tried to install 10.3 64bit onto intel ich7 in several way. What ever I did yast partitioned them to device mapper.... and the install failed out when it came to install the boot manager. Grub errors. All the files were correctly installed on the discs and the problem seemed to be entirely down to what the installer passed on to grub.
That sounds like a new bug report. Unless GRUB just doesn't support booting off such a RAID-setup. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 13 May 2008 14:45:39 Per Jessen wrote:
John wrote:
I'm curious about this subject. I tried to install 10.3 64bit onto intel ich7 in several way. What ever I did yast partitioned them to device mapper.... and the install failed out when it came to install the boot manager. Grub errors. All the files were correctly installed on the discs and the problem seemed to be entirely down to what the installer passed on to grub.
That sounds like a new bug report. Unless GRUB just doesn't support booting off such a RAID-setup.
/Per Jessen, Zürich
Yes it does but I'm still clearing my mind. This started in another thread. Comments were made about must be a hardware raid as they are automatic/transparent etc. Also that the kernel since 2.6 ( I think) doesn't support them. One thing that I'm sure has changed is that 2.4/5 used a different on disc format. I could only read my old drives with V4 knoppix. They mounted on V5 but showed garbage. I had to use that for data recovery on the previous motherboard which broke. Taking each in turn anything that boots and must subsequently load drivers -. eg linux - must use bios calls to load the drivers. I find it very hard to believe that these have been changed. They must function what ever drive arrangement is connected. The kernel clearly does support ich7 otherwise it wouldn't have been able to write the files or read them for that matter. There's an ext3 driver available for windoze now so it's easy to check if one is dual booting. In that case they are being read via the intel ich7 bios. Grub comes up with a numerical error which strongly suggests that it's been told to do something stupid. It to must make use of bios calls. The install partitioner maps the drives twice. Once to devicemapper and then again to individual discs. Confusing or what? Partitions are only mapped to device mapper though which I suppose helps. My motherboard came with a kernel patch to enable it to use the intel bios. The bios is loaded into memory. Same as a hard raid. No way to apply the patch unless it boots and the kernel can clearly cope with out it. All sounds like stinking fish to me. This is an installer problem. John -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John wrote:
Comments were made about must be a hardware raid as they are automatic/transparent etc. Also that the kernel since 2.6 ( I think) doesn't support them.
Because the support has been moved dmraid, yes.
The kernel clearly does support ich7 otherwise it wouldn't have been able to write the files or read them for that matter. There's an ext3 driver available for windoze now so it's easy to check if one is dual booting. In that case they are being read via the intel ich7 bios.
Grub comes up with a numerical error which strongly suggests that it's been told to do something stupid. It to must make use of bios calls.
Quite probably, yes. Why don't you just write the bug report and see what happens? You've got debug output from GRUB which is a place to start.
The install partitioner maps the drives twice. Once to devicemapper and then again to individual discs. Confusing or what? Partitions are only mapped to device mapper though which I suppose helps.
Another bug report I think. Unless your BIOS presents the disks both as individuals and as a RAID'ed array.
All sounds like stinking fish to me. This is an installer problem.
Report it. Provide the diags. Help improve openSUSE. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 13 May 2008 17:22:17 Per Jessen wrote:
John wrote:
Comments were made about must be a hardware raid as they are automatic/transparent etc. Also that the kernel since 2.6 ( I think) doesn't support them.
Because the support has been moved dmraid, yes.
The kernel clearly does support ich7 otherwise it wouldn't have been able to write the files or read them for that matter. There's an ext3 driver available for windoze now so it's easy to check if one is dual booting. In that case they are being read via the intel ich7 bios.
Grub comes up with a numerical error which strongly suggests that it's been told to do something stupid. It to must make use of bios calls.
Quite probably, yes. Why don't you just write the bug report and see what happens? You've got debug output from GRUB which is a place to start. No I haven't. I have re installed with none raided discs and problems at least 3 times since then. No grub debug.
The install partitioner maps the drives twice. Once to devicemapper and then again to individual discs. Confusing or what? Partitions are only mapped to device mapper though which I suppose helps.
Another bug report I think. Unless your BIOS presents the disks both as individuals and as a RAID'ed array. Thanks for helping with the bug report. The duplicate discs had the same id's.
All sounds like stinking fish to me. This is an installer problem.
Report it. Provide the diags. Help improve openSUSE.
/Per Jessen, Zürich
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, May 07, Brian K. White wrote:
I almost always have to use the "boot installed system" option in the installer and manually edit /etc/grub.conf, /boot/grub/oevice.map, and /boot/grub/menu/lst, and then run grub --batch </etc/grub.conf
Indeed, my problem was solved by doing the "install grub to MBR on both disks" routine. grub> find /boot/grub/stage1 (hd0,0) (hd1,0) grub> device (hd0) /dev/sda root (hd0,0) setup (hd0) device (hd0) /dev/sdb root (hd0,0) setup (hd0) And reboot works fine. For some unfathomable reason, once in a great while the installer does
actually manage to create a working /boot on it's own. The config files look different than above but it boots. I haven't yet figured out how to get it to work all on it's own reliably. I gave up trying and just set up the above configuration manually every time.
That *does* seem to be the more common situation. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Michael Fischer wrote:
On Wed, May 07, Brian K. White wrote:
I almost always have to use the "boot installed system" option in the installer and manually edit /etc/grub.conf, /boot/grub/oevice.map, and /boot/grub/menu/lst, and then run grub --batch </etc/grub.conf
Indeed, my problem was solved by doing the "install grub to MBR on both disks" routine.
grub> find /boot/grub/stage1 (hd0,0) (hd1,0) grub>
device (hd0) /dev/sda root (hd0,0) setup (hd0)
device (hd0) /dev/sdb root (hd0,0) setup (hd0)
And reboot works fine.
For some unfathomable reason, once in a great while the installer does
actually manage to create a working /boot on it's own. The config files look different than above but it boots. I haven't yet figured out how to get it to work all on it's own reliably. I gave up trying and just set up the above configuration manually every time.
That *does* seem to be the more common situation.
Michael
Good for you. 10.3 seems to have had more of these issues than any previously release I can remember. I guess it's due to the increase in the number of things you can now boot from. I know I have had at least 2 systems that required the manual grub-install to the boot drive. Perseverance has paid off. -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (10)
-
Brian K. White -
Carlos F. Lange -
David C. Rankin -
James Knott -
Jim Flanagan -
Joe Morris -
John -
Michael Fischer -
Per Jessen -
Sam Clemens