[opensuse] Double check: /boot on RAID 1
Being one of the folks who tries to do the Subject, I recently ran across an old thread on the list which confirmed most of my experience with it, but mentioned that Yast (in the installer mode) might not be putting grub, etc. on both disks' MBR or /boot. After some web-digging, I tried the following: grub> find /boot/grub/stage1 (hd0,0) (hd1,0) Can someone competent in the matter confirm for me that the above does indeed mean that both disks in the array have had a working grub written to both disks, and therefore, in the event of the failure of one drive, the other is indeed bootable into a working system? If not, why not and what should I do to "fix" the matter. TIA. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
I think this implies that grub is installed on your RAID 1 (I assume you are talking about a raid 1 /boot partition using the first partition on each disk). This doesn't tell you anything about whether grub has updated the MBR. To install grub on both MBR's I would type (as root): grub grub> root (hd0,0) grub> setup (hd0) grub> root (hd1,0) grub> setup (hd1) grub> quit I would be interested in what others have to say on this and whether there is a way of specifying a "time out" so if the system can not boot from hd0 it attempts to boot from hd1? (my guess is this would be bios dependant) On 30 September 2011 21:59, Michael Fischer <michael@visv.net> wrote:
Being one of the folks who tries to do the Subject, I recently ran across an old thread on the list which confirmed most of my experience with it, but mentioned that Yast (in the installer mode) might not be putting grub, etc. on both disks' MBR or /boot. After some web-digging, I tried the following:
grub> find /boot/grub/stage1 (hd0,0) (hd1,0)
Can someone competent in the matter confirm for me that the above does indeed mean that both disks in the array have had a working grub written to both disks, and therefore, in the event of the failure of one drive, the other is indeed bootable into a working system?
If not, why not and what should I do to "fix" the matter.
TIA.
Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- "Clouds are not spheres, mountains are not cones, coastlines are not circles, and bark is not smooth, nor does lightning travel in a straight line." BENOIT MANDELBROT 1924 — 2010 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
I think this implies that grub is installed on your RAID 1 (I assume you are talking about a raid 1 /boot partition using the first partition on each disk). This doesn't tell you anything about whether grub has updated the MBR.
To install grub on both MBR's I would type (as root):
grub grub> root (hd0,0) grub> setup (hd0) grub> root (hd1,0) grub> setup (hd1) grub> quit
I would be interested in what others have to say on this and whether there is a way of specifying a "time out" so if the system can not boot from hd0 it attempts to boot from hd1? (my guess is this would be bios dependant)
On 30 September 2011 21:59, Michael Fischer <michael@visv.net> wrote:
Being one of the folks who tries to do the Subject, I recently ran across an old thread on the list which confirmed most of my experience with it, but mentioned that Yast (in the installer mode) might not be putting grub, etc. on both disks' MBR or /boot. After some web-digging, I tried the following:
grub> find /boot/grub/stage1 (hd0,0) (hd1,0)
Can someone competent in the matter confirm for me that the above does indeed mean that both disks in the array have had a working grub written to both disks, and therefore, in the event of the failure of one drive, the other is indeed bootable into a working system?
If not, why not and what should I do to "fix" the matter.
TIA.
Michael --
I've used this setup for a long time on my RAID 1 array. Michael, your syntax puts grub in the boot sector of the first partition on the first and second boot disks. Philip's syntax puts grub in the MBR of those disks. Note that if grub is being installed from the running OS (as opposed to the grub shell with no OS running) it will use /boot/grub/device.map to determine which of the disks correspond to hd0 and hd1, which may or may not be the same as the bios boot device sequence. Assuming hd0 and hd1 are the bios first and second boot devices, if booting from the first disk fails then the bios will call the sector on the second disk. The array is immaterial to this process. YaST's boot manager module can be instructed to install grub to both the partition boot sector and the master boot record. All YaST actually does is write out the file /etc/grub.conf with syntax similar to the above and then call grub in batch mode, the grub shell then does the actual install. As an aside, a twist on the above is to install grub in the partition boot sector, mark that partition active, and then install the "generic" boot code to the MBR (so YaST uses grub to do the the former and the latter it does itself). All the bios does in every case is hand-off to the strap code in the MBR of the first active partition in the table. If grub is there, it has a pointer to the /boot partition and using the file system locates the kernel. If the generic code is in the MBR, that code calls the strap in the boot sector in the first primary partition which is marked active (or "bootable"). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, Oct 01, dwgallien wrote:
I think this implies that grub is installed on your RAID 1 (I assume you are talking about a raid 1 /boot partition using the first partition on each disk). This doesn't tell you anything about whether grub has updated the MBR.
To install grub on both MBR's I would type (as root):
grub grub> root (hd0,0) grub> setup (hd0) grub> root (hd1,0) grub> setup (hd1) grub> quit
I would be interested in what others have to say on this and whether there is a way of specifying a "time out" so if the system can not boot from hd0 it attempts to boot from hd1? (my guess is this would be bios dependant)
On 30 September 2011 21:59, Michael Fischer <michael@visv.net> wrote:
Being one of the folks who tries to do the Subject, I recently ran across an old thread on the list which confirmed most of my experience with it, but mentioned that Yast (in the installer mode) might not be putting grub, etc. on both disks' MBR or /boot. After some web-digging, I tried the following:
grub> find /boot/grub/stage1 (hd0,0) (hd1,0)
Can someone competent in the matter confirm for me that the above does indeed mean that both disks in the array have had a working grub written to both disks, and therefore, in the event of the failure of one drive, the other is indeed bootable into a working system?
If not, why not and what should I do to "fix" the matter.
TIA.
Michael --
I've used this setup for a long time on my RAID 1 array.
Michael, your syntax puts grub in the boot sector of the first partition on the first and second boot disks. Philip's syntax puts grub in the MBR of those disks. Note that if grub is being installed from the running OS (as opposed to the grub shell with no OS running) it will use /boot/grub/device.map to determine which of the disks correspond to hd0 and hd1, which may or may not be the same as the bios boot device sequence. Assuming hd0 and hd1 are the bios first and second boot devices, if booting from the first disk fails then the bios will call the sector on the second disk. The array is immaterial to this process.
So... can you confirm that the grub output I posted means that I'm covered for a bootable drive in case either one (and only one at a time) goes bad on me? Or do I need to follow either Philip's grub commands (above) or yours (below) to insure such a setup? Thanks much for the extensive explanations.
YaST's boot manager module can be instructed to install grub to both the partition boot sector and the master boot record. All YaST actually does is write out the file /etc/grub.conf with syntax similar to the above and then call grub in batch mode, the grub shell then does the actual install.
As an aside, a twist on the above is to install grub in the partition boot sector, mark that partition active, and then install the "generic" boot code to the MBR (so YaST uses grub to do the the former and the latter it does itself). All the bios does in every case is hand-off to the strap code in the MBR of the first active partition in the table. If grub is there, it has a pointer to the /boot partition and using the file system locates the kernel. If the generic code is in the MBR, that code calls the strap in the boot sector in the first primary partition which is marked active (or "bootable").
Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
If you want to be 100% certain then you must test the installation by simply disconnecting each disk in turn and booting your system to the grub prompt... - you dont even have to boot the machine beyond the grub prompt (unless you want to break/rebuild the raid as a further test). Either install technique should do the job but I am not convinced that Yast will install MBR code to a second hard disk. My personal position is that I like to use a command prompt for such important work and usually install manually. Hope this helps a little.... On 2 October 2011 07:27, Michael Fischer <michael@visv.net> wrote:
On Sat, Oct 01, dwgallien wrote:
I think this implies that grub is installed on your RAID 1 (I assume you are talking about a raid 1 /boot partition using the first partition on each disk). This doesn't tell you anything about whether grub has updated the MBR.
To install grub on both MBR's I would type (as root):
grub grub> root (hd0,0) grub> setup (hd0) grub> root (hd1,0) grub> setup (hd1) grub> quit
I would be interested in what others have to say on this and whether there is a way of specifying a "time out" so if the system can not boot from hd0 it attempts to boot from hd1? (my guess is this would be bios dependant)
On 30 September 2011 21:59, Michael Fischer <michael@visv.net> wrote:
Being one of the folks who tries to do the Subject, I recently ran across an old thread on the list which confirmed most of my experience with it, but mentioned that Yast (in the installer mode) might not be putting grub, etc. on both disks' MBR or /boot. After some web-digging, I tried the following:
grub> find /boot/grub/stage1 (hd0,0) (hd1,0)
Can someone competent in the matter confirm for me that the above does indeed mean that both disks in the array have had a working grub written to both disks, and therefore, in the event of the failure of one drive, the other is indeed bootable into a working system?
If not, why not and what should I do to "fix" the matter.
TIA.
Michael --
I've used this setup for a long time on my RAID 1 array.
Michael, your syntax puts grub in the boot sector of the first partition on the first and second boot disks. Philip's syntax puts grub in the MBR of those disks. Note that if grub is being installed from the running OS (as opposed to the grub shell with no OS running) it will use /boot/grub/device.map to determine which of the disks correspond to hd0 and hd1, which may or may not be the same as the bios boot device sequence. Assuming hd0 and hd1 are the bios first and second boot devices, if booting from the first disk fails then the bios will call the sector on the second disk. The array is immaterial to this process.
So... can you confirm that the grub output I posted means that I'm covered for a bootable drive in case either one (and only one at a time) goes bad on me? Or do I need to follow either Philip's grub commands (above) or yours (below) to insure such a setup?
Thanks much for the extensive explanations.
YaST's boot manager module can be instructed to install grub to both the partition boot sector and the master boot record. All YaST actually does is write out the file /etc/grub.conf with syntax similar to the above and then call grub in batch mode, the grub shell then does the actual install.
As an aside, a twist on the above is to install grub in the partition boot sector, mark that partition active, and then install the "generic" boot code to the MBR (so YaST uses grub to do the the former and the latter it does itself). All the bios does in every case is hand-off to the strap code in the MBR of the first active partition in the table. If grub is there, it has a pointer to the /boot partition and using the file system locates the kernel. If the generic code is in the MBR, that code calls the strap in the boot sector in the first primary partition which is marked active (or "bootable").
Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- "Clouds are not spheres, mountains are not cones, coastlines are not circles, and bark is not smooth, nor does lightning travel in a straight line." BENOIT MANDELBROT 1924 — 2010 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 10/2/2011 4:28 AM, Philip Vossler wrote:
If you want to be 100% certain then you must test the installation by simply disconnecting each disk in turn and booting your system to the grub prompt... - you dont even have to boot the machine beyond the grub prompt (unless you want to break/rebuild the raid as a further test).
Either install technique should do the job but I am not convinced that Yast will install MBR code to a second hard disk.
My personal position is that I like to use a command prompt for such important work and usually install manually.
Hope this helps a little....
On 2 October 2011 07:27, Michael Fischer<michael@visv.net> wrote:
On Sat, Oct 01, dwgallien wrote:
I think this implies that grub is installed on your RAID 1 (I assume you are talking about a raid 1 /boot partition using the first partition on each disk). This doesn't tell you anything about whether grub has updated the MBR.
To install grub on both MBR's I would type (as root):
grub grub> root (hd0,0) grub> setup (hd0) grub> root (hd1,0) grub> setup (hd1) grub> quit
I would be interested in what others have to say on this and whether there is a way of specifying a "time out" so if the system can not boot from hd0 it attempts to boot from hd1? (my guess is this would be bios dependant)
On 30 September 2011 21:59, Michael Fischer<michael@visv.net> wrote:
Being one of the folks who tries to do the Subject, I recently ran across an old thread on the list which confirmed most of my experience with it, but mentioned that Yast (in the installer mode) might not be putting grub, etc. on both disks' MBR or /boot. After some web-digging, I tried the following:
grub> find /boot/grub/stage1 (hd0,0) (hd1,0)
Can someone competent in the matter confirm for me that the above does indeed mean that both disks in the array have had a working grub written to both disks, and therefore, in the event of the failure of one drive, the other is indeed bootable into a working system?
If not, why not and what should I do to "fix" the matter.
TIA.
Michael --
I've used this setup for a long time on my RAID 1 array.
Michael, your syntax puts grub in the boot sector of the first partition on the first and second boot disks. Philip's syntax puts grub in the MBR of those disks. Note that if grub is being installed from the running OS (as opposed to the grub shell with no OS running) it will use /boot/grub/device.map to determine which of the disks correspond to hd0 and hd1, which may or may not be the same as the bios boot device sequence. Assuming hd0 and hd1 are the bios first and second boot devices, if booting from the first disk fails then the bios will call the sector on the second disk. The array is immaterial to this process.
So... can you confirm that the grub output I posted means that I'm covered for a bootable drive in case either one (and only one at a time) goes bad on me? Or do I need to follow either Philip's grub commands (above) or yours (below) to insure such a setup?
Thanks much for the extensive explanations.
YaST's boot manager module can be instructed to install grub to both the partition boot sector and the master boot record. All YaST actually does is write out the file /etc/grub.conf with syntax similar to the above and then call grub in batch mode, the grub shell then does the actual install.
As an aside, a twist on the above is to install grub in the partition boot sector, mark that partition active, and then install the "generic" boot code to the MBR (so YaST uses grub to do the the former and the latter it does itself). All the bios does in every case is hand-off to the strap code in the MBR of the first active partition in the table. If grub is there, it has a pointer to the /boot partition and using the file system locates the kernel. If the generic code is in the MBR, that code calls the strap in the boot sector in the first primary partition which is marked active (or "bootable").
Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Yast won't install the 2nd mbr. Yast will run grub, and grub will, assuming you want to have grub's own stage1 in the mbr and not a generic mbr. You just have to have lines like this in /etc/grub.conf, which you can edit directly outside of yast, or in yast there is an advanced options that includes an option to edit the same file from within yast. setup (hd0) (hd0,0) setup (hd1) (hd1,0) Yast will create only one such line by itself, based on your choices in the various yast bootloader screens. You have to create other such lines for as many other drives as you want. The first line above puts grub stage1 and 1.5 into the mbr of drive 0 (hd0), and gets the stage1 and 1.5 images from /grub or /boot/grub on partition 0 of drive 0 (hd0,0) The second line is all the same but on drive 1. Once you put that 2nd (or 3rd 4th etc...) lines in grub.conf, they get executed every time yast or zypper or rpm does a kernel update or any time you manually run grub-install or grub --batch </etc/grub.conf For a simple setup with only a couple of drives, you probably don't have to worry about making sure "hd1" means what you think it means. Probably yast automatically populated /boot/grub/device.map with every drive in your system, but you might want to at least take a look at it and satisfy yourself it looks right. Those lines in grub.conf don't _really_ mean anything by themselves. "hd0" and "hd1" are totally defined in device.map Really there are no simple answers to questions about how to set up grub. You (not just you personally, anyone who wants to know how to make it work) must simply read the grub manual. It explains how the parts work together and has links to explanations about the unavoidable problems of the OS not really being able to know what the BIOS will do or how the BIOS "sees" the drives or what drives it even sees or what order it sees them in or what drives may have been manually set to boot first or last or totally ignored. All questions are already answered there. http://www.gnu.org/software/grub/manual/legacy/grub.html#setup -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, Oct 03, Brian K. White wrote:
Yast won't install the 2nd mbr.
Yast will run grub, and grub will, assuming you want to have grub's own stage1 in the mbr and not a generic mbr.
You just have to have lines like this in /etc/grub.conf, which you can edit directly outside of yast, or in yast there is an advanced options that includes an option to edit the same file from within yast.
setup (hd0) (hd0,0) setup (hd1) (hd1,0)
Hmm. My /etc/grub.conf has (without my intervention) setup --stage2=/boot/grub/stage2 --force-lba (hd0) (hd0,0) setup --stage2=/boot/grub/stage2 --force-lba (hd1,0) (hd0,0) quit
The first line above puts grub stage1 and 1.5 into the mbr of drive 0 (hd0), and gets the stage1 and 1.5 images from /grub or /boot/grub on partition 0 of drive 0 (hd0,0)
The second line is all the same but on drive 1.
Once you put that 2nd (or 3rd 4th etc...) lines in grub.conf, they get executed every time yast or zypper or rpm does a kernel update or any time you manually run grub-install or grub --batch </etc/grub.conf
While respecting your comments (and helpful url) regarding RTFM, is it safe to run either of the above grub commands while running a system normally, or should I do it from a rescue disk or try to drop into a grub prompt at a reboot?
For a simple setup with only a couple of drives, you probably don't have to worry about making sure "hd1" means what you think it means. Probably yast automatically populated /boot/grub/device.map with every drive in your system, but you might want to at least take a look at it and satisfy yourself it looks right. Those lines in grub.conf don't _really_ mean anything by themselves. "hd0" and "hd1" are totally defined in device.map
Yeah, its just two disks, and /boot/grub/device.map looks right.
Really there are no simple answers to questions about how to set up grub. You (not just you personally, anyone who wants to know how to make it work) must simply read the grub manual. It explains how the parts work together and has links to explanations about the unavoidable problems of the OS not really being able to know what the BIOS will do or how the BIOS "sees" the drives or what drives it even sees or what order it sees them in or what drives may have been manually set to boot first or last or totally ignored. All questions are already answered there.
http://www.gnu.org/software/grub/manual/legacy/grub.html#setup
Thanks again. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Oct 03, Brian K. White wrote:
Yast won't install the 2nd mbr.
Yast will run grub, and grub will, assuming you want to have grub's own stage1 in the mbr and not a generic mbr.
You just have to have lines like this in /etc/grub.conf, which you can edit directly outside of yast, or in yast there is an advanced options that includes an option to edit the same file from within yast.
setup (hd0) (hd0,0) setup (hd1) (hd1,0)
Hmm. My /etc/grub.conf has (without my intervention)
setup --stage2=/boot/grub/stage2 --force-lba (hd0) (hd0,0) setup --stage2=/boot/grub/stage2 --force-lba (hd1,0) (hd0,0) quit
Re YaST, while you can within the Boot Loader module manually edit the /etc/grub.conf file, depending upon your setup, when you go back to the previous screens YaST will change the file. For example, if you edited the second line to be (hd1) (hd1,0) or (hd1) (hd0,0) in order to install grub to the MBR of the second disk, after you hit OK which returns you to Boot Loader Installation, that line will be removed by YaST because the module does not support installing to a second disk MBR. So this installation would need to be done from the command line. This raises the question I asked previously which I didn't see a reply for. In your original msg, it appeared you wanted to have grub boot from the second disk in the event the first *disk* failed, and still have a "working system". This question can't be answered without knowing how the root is set up on the disk(s) and what type of RAID you are using. Aside from the manual install, it's usually trivial to get the bios to call grub from the second disk. But do you also want to load the OS from the second disk, since the first disk has failed? That's a different matter altogether.
The first line above puts grub stage1 and 1.5 into the mbr of drive 0 (hd0), and gets the stage1 and 1.5 images from /grub or /boot/grub on partition 0 of drive 0 (hd0,0)
The second line is all the same but on drive 1.
That second line is not the same because (hd1,0) (hd0,0), installs grub stage1 to the boot sector of the first partition on the second disk, pointing it to find stage2 on the first partition of the first disk; the first line is installing stage1 to the MBR of the first disk. If you want grub on the second disk to be called by the bios, install it to the MBR of the second disk, i.e., change (hd1,0) to (hd1). The above second line (hd1,0) syntax can be used if generic MBR code has been installed and sdb1's active flag has been set. The remainder of the line, (hd0,0), is correct only if you are calling stage2 from the first disk. Calling stage2 and the kernel from the second disk would be (hd1,1). But, again, see my question above.
Once you put that 2nd (or 3rd 4th etc...) lines in grub.conf, they get executed every time yast or zypper or rpm does a kernel update or any time you manually run grub-install or grub --batch </etc/grub.conf
A point of clarification re the above "grub-install". In openSUSE, that script is not the same as the script of the same name which comes with the vanilla grub package. In openSUSE, all this script does is run the batch command above. In vanilla grub, the script attempts to do much more, essentially what YaST is doing. The vanilla grub-install script is still in openSUSE, but under the name "grub-install.unsupported".
While respecting your comments (and helpful url) regarding RTFM, is it safe to run either of the above grub commands while running a system normally, or should I do it from a rescue disk or try to drop into a grub prompt at a reboot?
For a simple setup with only a couple of drives, you probably don't have to worry about making sure "hd1" means what you think it means. Probably yast automatically populated /boot/grub/device.map with every drive in your system, but you might want to at least take a look at it and satisfy yourself it looks right. Those lines in grub.conf don't _really_ mean anything by themselves. "hd0" and "hd1" are totally defined in device.map
Yeah, its just two disks, and /boot/grub/device.map looks right.
Since your system only has 2 disks, the result will probably be the same regardless of from where you install grub. That said, note that the grub shell which does the install, only uses device.map when it is being run from a mounted OS. If you run the shell outside the OS or from a rescue disk that does not mount the root, it will attempt to determine the disk boot sequence by making a query call to the bios. In that case it may or may not figure out the sequence depending on the bios. So when outside the running OS it's always a good idea to use the grub "find" command to be sure you are working with the disk(s) you intend to be.
Really there are no simple answers to questions about how to set up grub. You (not just you personally, anyone who wants to know how to make it work) must simply read the grub manual. It explains how the parts work together and has links to explanations about the unavoidable problems of the OS not really being able to know what the BIOS will do or how the BIOS "sees" the drives or what drives it even sees or what order it sees them in or what drives may have been manually set to boot first or last or totally ignored. All questions are already answered there.
http://www.gnu.org/software/grub/manual/legacy/grub.html#setup
Thanks again.
Michael
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
snip >>
So... can you confirm that the grub output I posted means that I'm covered for a bootable drive in case either one (and only one at a time) goes bad on me? Or do I need to follow either Philip's grub commands (above) or yours (below) to insure such a setup?
Thanks much for the extensive explanations.
Michael, Before replying to your follow-up, I have a question: Is the entire OS on a single partition in a single array? Or if the root (and any other directory) is on a separation partition, is it also in an array, presumably RAID 1? And so in your scenario where the first *disk* fails (in contrast to a grub, partition, file system, or file problem), is it your intention to run the root from the second disk's partition alone outside of the array (in other words, as if there had been no array)? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (4)
-
Brian K. White
-
dwgallien
-
Michael Fischer
-
Philip Vossler