Fwd: Debian installer and raid0
grub installation of lacking grub on the CPU-GPU raid1 machine (gig64) by the command grub-install /dev/sdb was successful (Installation finished. No error reported) with either the two victim 250GB disks and then with the two 1000GB disks. I can't explain my failure to do so in the recent past. The pipe command that I described before proved equivalent to what you described, i.e., physically testing whether grub is installed, each disk at a time. Thanks a lot francesco -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Tue, Oct 8, 2013 at 5:11 PM Subject: Re: Debian installer and raid0 To: debian-users debian-u...@lists.debian.org, amd64 Debian debian-amd64@lists.debian.org I hope not to bother beyond the limit, but the security of mirror raid is something of utmost importance, at least in my work of biochemist, with very limited ability in recovering from disk failures. I planned to use the double-opteron, two sockets, server, tya 64, as a victim for the test you suggested. However, the test root@tya64:/home/francesco# dd bs=512 count=1 if=/dev/sda 2/dev/null | strings ZRr= `|f \|f1 GRUB Geom Hard Disk Read Error root@tya64:/home/francesco# dd bs=512 count=1 if=/dev/sdb 2/dev/null | strings ZRr= `|f \|f1 GRUB Geom Hard Disk Read Error suggested that grub was installed on both disks. Using one disk at a time, as you suggested, was in accordance. Then I carried out the pipe test with the recent machine, gig64: root@gig64:/home/francesco# dd bs=512 count=1 if=/dev/sda 2/dev/null | strings ZRr= `|f \|f1 GRUB Geom Hard Disk Read Error root@gig64:/home/francesco# dd bs=512 count=1 if=/dev/sdb 2/dev/null | strings root@gig64:/home/francesco# indicating that grub is installed on sda only. Confirmed by using one disk at a time. 500GB disks on tya64 came from a dismissed doubleOpteron four socket server that I had assembled several years ago. Probably at that time in my activity as a biochemist I was left more time to be careful about linux. With gig64 the two 1000GB disks came recently from the store and the described failure as to installing grub on sdb was with them. Unless the problem is different, related to the particular gig64 machine. QUESTIONS: (1) If there is any chance that the particular hardware of gig64, comprising two GPUs (I called gig64 a server, while, unlike the real server tya64, it is a consumer mainboard GA-X79-UD3 with Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz and two GTX680 GPUs, leading to very fast number crunching, NOT overclocked) can interfere with installation of grub on the second disk, it seems to me that gig64 is the appropriate victim. However, by replacing the two 1000GB disks with two spare victim disks that I should have somewhere (amd64 on both, and likely grub too). If anything, linux is unable to tell anything about the GPUs (and even nvidia-smi tools tell very little, which my lend suspicion on why the grub installation of the second disk failed). Fundamentally, it is a game machine, so that no chance to get mirror raid even mentioned by bloggers of this type of computers. (2) Is the above pipe test (that grub installed leads to some message when failure is encountered, while no message means no grub available) always reliable and equivalent to detaching disks? thanks francesco On Mon, Oct 7, 2013 at 10:38 PM, Bob Proulx b...@proulx.com wrote: Francesco Pietra wrote: I forgot asking naively how to boot safely to the grub menu. Press a key on the keyboard before the 5 second count down timer counts all of the way down. Pressing a key stops the timer and causes it to stay on the menu waiting for keyboard input. Bob
Fwd: Debian installer and raid0
I forgot asking naively how to boot safely to the grub menu. With both servers, the system boots straightforwardly to the linux prompt, then, if I need the X server and manager, I command startx and then gnome-session thanks francesco -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Sat, Oct 5, 2013 at 9:21 AM Subject: Re: Debian installer and raid0 To: debian-users debian-u...@lists.debian.org, amd64 Debian debian-amd64@lists.debian.org Thanks so much. I am also using raid1 since I met Debian, so many years ago. However the poor way I described. I'll do what you suggest as soon time permits, although the cables to the HDs in the old server are difficultly accessible. And, in the meantime, I would be at a single server, insecure as with a bad raid1. Failure that I described in adding grub to the other HD was in a single trial and now the HDs are different, taken from a dismissed four-sockets dual-core AMD server. cheers francesco On Fri, Oct 4, 2013 at 10:13 PM, Bob Proulx b...@proulx.com wrote: Francesco Pietra wrote: Bob Proulx wrote: After installing simply run the grub install script against both disks manually and then you will be assured that it has been installed on both disks. I had problems with that methodology and was unable to detect my error. From a thread on debian dated Mar 2, 2013: ... grub-install /dev/sdb was reported by complete installation. No error, no warning. On rebooting, GRUB was no more found. Then entering in grub rescue prefix/root/ were now wrong. If the command does not work on the command line then it won't work from the installer either. The installer is doing the same things that you can do from the command line. Therefore asking if it is in the installer won't help. Because if it doesn't work then it doesn't work either place. If it does work then it will work either place. That is my conjecture at least. And since I have been using this feature I believe it does work. Works for me anyway. I have been using RAID1 for a long time and have not encountered the problem you describe. That doesn't mean that such an error doesn't occur. Just that I can't recreate it. Or rather after much user have never recreated it. This applies to both the good grub version 1 as well as the newer and IMNHO buggier grub version 2 rewrite. They are completely different from each other. Statements made about one do not apply to the other because it was a complete rewrite. But it is certainly possible that in your configuration that you have a case that does not work. I have a workbench with a variety of hardware. When I want to test something like this I construct a victim system in which to try the action. If you could do the same I think it would help to get to the root cause of the problem. I would create a victim machine with two drives for installation testing. Then test the installation. After install and reboot then shutdown, unplug one disk, test boot. Do not boot all of the way to the system. Simply boot to the grub menu and stop there. Then power off, switch disks, and test boot again. Do not boot all of the way to the system. Simply boot to the grub menu and again stop there. If you can get to the grub menu from either disk then grub has been installed on both disks. If not then plug both disks in and boot the system and test the grub-install script on the non-booting disk and then repeat the single disk boot. The reason to only boot to the grub menu is of course so that the RAID1 doesn't get split. If booting with one disk and then the other one disk it will get a split brain of course. No real problem on a victim machine. But it is faster to keep them in sync. So I only boot to the grub menu when testing the grub boot code. Avoiding booting the system avoids splitting the raid unnecessarily and speeds up the debugging. By testing this way you can verify that you can boot either disk in isolation after the other disk has failed. By using a victim machine you can experiment. Then if you find a bug you will have a recipe to recreate it and can file a bug report on it. Being able to recreate the problem is the most valuable part. And here is the challenge. I think if you do this you will find that it does actually work. But feel free to write back here and tell me that I am wrong and that there is a problem with it. :-) As the great Mark Twain wrote There is nothing so annoying as a good example. If you can get to a repeatable test case that fails that would be awesome. Now I am in the same situation, two servers with mirroring raid, grub on /dev/sda only. Identical data on both servers to cope with grub on one disk only. Not smart from my side. Two servers so that you can switch your services from one server to the other in case one of the servers cannot boot? If you have two servers and one is
