Marcelo,
We checked with Ted T'so on whether ignoring the compatible flag on
system mount patch idea would be hazardous as a fix to the linuxBIOS
booting after unclean-shutdown problem we have; as you can see from the
attached mail, the answer seems to be "no worse than grub is already".
Would you generate us a patch for the BIOS payload Linux ext2
implementation to ignore the file system compatibility flag on a
read-only mount? We can put that in buildrom (there is no intention of
mainstreaming this patch, or reason to do so that I can see).
Then we can mount the file system and do the kexec reliably (or at least
as reliably as Grub would do anyway).
Thanks greatly,
- Jim
--
Jim Gettys
One Laptop Per Child
--- Begin Message ---
On Mon, Aug 28, 2006 at 01:30:50PM -0400, Jim Gettys wrote:
> Here's the problem:
>
> The bootloader ("payload") Linux being used as a bootloader has just
> ext2 compiled in (to save space; ext3 is significantly bigger). We want
> it to be able to boot an ext3 file system.
>
> The mount fails if the incompatible bit is set due to an unclean mount,
> even though, all we want to do is kexec the real Linux kernel coming off
> the ext3 file system.
>
> Do you see anything evil about patching our payload ext2 file system to
> go ahead and ignore the compatibility bit so we can read only mount the
> file system (even though it was shutdown improperly) long enough to
> kexec the kernel?
If the filesystem is being mounted read-only, it should be OK,
although it is not 100% safe in the sense that if the kernel or
anything else necessary for kexec were modified just before the
unclean shutdown, you might not be *able* to kexec the kernel; the
bootloader Linux system might panic or return some kind of error
instead. There is also a even less likely chance caused by any of the
containing directories getting modified and in the middle of a btree
node split during or just before the unclean shutdown, such that the
journal replay is necessary in order to bring the filesystem back to a
consistent state.
The chances are (relatively) low, but they aren't non-zero. Still,
that's what grub depends on --- it also accesses the filesystem before
the journal recovery has taken place, and grub generally works OK ---
although usually grub relies on much less of the filesystem being sane
than than your payload Linux bootloader might, especially if you're
running arbitrary shell/python scripts.
I do have to emphasize that it is critically important that the
filesystem be kept read-only. If it is read-write, then that's a
completely different store, and that would be far, far more dangerous.
Regards,
- Ted
--- End Message ---
_______________________________________________
Devel mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/devel
