On Wed, Nov 07, 2001 at 11:08:00AM -0800, [EMAIL PROTECTED] wrote: > > But on the front of making the GRUB shell-based installer "grub-install" > run more reliably on random systems, I had an idea which I think should > be used even with the non-journaled filesystems. > > As is, there are GRUB shell-specific features like the "--stage2" option > in the "setup" command. > > #1: I think we add a "--mapdump" feature that spits out a simple > file listing all the blockmaps. Then we run the final stage of > the GRUB shell in "grub-install" something like 3 times with short > delays and compare the results to see if they are all identical (you > don't even need a terribly nice format, just something you can run a > binary compare on). If not, then a simple retry mechanism after a > delay, and if a few delays don't cause it to settle down, you give up. > > This also has the benefit of ensuring even non-journaled FSes are in > a stable state. > > #2: Add at least some support for journals, so that you can at least > recognize when it's not empty and maybe just error out in a way that > "grub-install" can then print out "journal not flushed, delaying...", > puts in a wait, then tries again. Obviously any such behavior where > it errors out would only be in the GRUB shell, not the bootloader > version.
I'm for that kind of solution since : - the GRUB shell is the only way to create virtual disks (and this is indeed a very powerfull ability) so to rely only on the native GRUB is not a solution; - the time efficiency of the GRUB shell is not a problem: one doesn't run this 10 times per second ;) - such solution is not a supplementary Linux hack FWIW, -- Thierry Laronde (Alceste) <[EMAIL PROTECTED]> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
