op 30-08-14 02:44, Roberto Spadim schreef: > i'm considering that you are using x86, x86_64 hardware, what's your > application? I am a sysadmin and I administrate many machines: webservers and mailservers located in a datacenter, fileservers located at firms, etc. > there's no bios test (must check if the newer version of this server > have uefi and work differente), it just don't boot the disk and go to > next boot > but for your question: yes... maybe with 'lucky' it can't boot, a > "bad" (crashed) grub could stop server startup > > maybe others questions that you could check before solving this boot > problem is why use a "bad" disk? I would replace it when I would know it's bad. > why shutdown a server? Kernel updates. > why remote startup a server? Because it's work to go to such a location. > why use a 'bad' disk? I would replace it when I would know it's bad. > if it's a ha system, Not really. Maybe. > include a human to check monthly, or something > like it, if the server is ok clean,something like it, You can't check that way if a MBR boots. > since ha > probably include a real time application or a security or risk > application, or anything like it I don't know about such an application. But maybe it would be possible to read the MBR and check it with a copy. I was looking for a redundant solution, maybe I must forget that. > probably you must check others solutions at hardware level, some > computers have dual bios (yes if one bios is lost you have the other > to boot the computer), That's not the problem. I did not see often problems with a bad bios on a good-running system. > maybe an openbios could help It's difficult to buy hardware for coreboot. And I don't think coreboot can check the booting process. >, or a uefi bios, must check what's better Do you know about UEFI bios-es who can check the process? With regards, Paul van der Vlis. > > > 2014-08-29 18:47 GMT-03:00 Paul van der Vlis <paul@xxxxxxxxxxxxx>: >> Hi Roberto, >> >> op 29-08-14 22:44, Roberto Spadim schreef: >>> i use two or more boot disks, if the first raid1 disk don't boot bios >>> go to second boot disk, third, etc etc, >> >> In my opinion this only works when the boot-disk is completely defect or >> removed. Not when the data in the MBR on that boot-disk is corrupt. >> >> Or did you test this, or do you have other reasons to believe that your >> bios will handle this correct? >> >> With the boot-disk I mean the disk what's in the bios the first disk. So >> this could also be the second raid1 disk. Or an USB stick. >> >>> you must write grub to mbr of each disk >> >> Of course. >> >> With regards, >> Paul van der Vlis. >> >>> i'm using dell server r410 if i'm not wrong >>> >>> 2014-08-29 17:31 GMT-03:00 Paul van der Vlis <paul@xxxxxxxxxxxxx>: >>>> Hello, >>>> >>>> I like mdadm and I am using it many years. But in my opinion it has one >>>> disadvantage: when the MBR of the boot-disk is corrupt, the machine will >>>> not boot. >>>> >>>> A bios could check this. Wait for some kind of signal from Grub or >>>> Linux, and after a timeout boot from another disk. But I don't know >>>> about a bios with that feature. >>>> >>>> A PCIe card could do something like that, but I don't know about such a >>>> PCIe card. >>>> >>>> Is there such hardware? >>>> What do you do to avoid this problem? >>>> >>>> With regards, >>>> Paul van der Vlis. >>>> >>>> >>>> >>>> >>>> -- >>>> Paul van der Vlis Linux systeembeheer, Groningen >>>> http://www.vandervlis.nl/ >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in >>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> >>> >> >> >> >> >> >> -- >> Paul van der Vlis Linux systeembeheer, Groningen >> http://www.vandervlis.nl/ >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-raid" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- Paul van der Vlis Linux systeembeheer, Groningen http://www.vandervlis.nl/ -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
