Ross Boylan wrote:
On Fri, 2008-03-14 at 00:34 +0000, Steve Parker wrote:
From the bug report:
Robert>> Could you provide a suggested text?
Ross>> Since I don't understand what's going on, I'm afraid I can't.
Here's a suggested wording:
The "savedefault" option on unclean filesystems will cause grub to fail to boot
the kernel.
The "savedefault=false" option will avoid this problem. The alternative
workaround is to edit the grub menu interactively on boot.
Is this the meaning of the final sentence:
If you set savedefault=true and find that your system is unbootable, you
can start it by editing the grub menu interactively [how?] at boot time.
?
Also, some of the earlier discussion seemed to imply this was a problem
only with some file systems.
Ross
Setting "savedefault=false" in menu.lst is not possible if you are
unable to boot the system.
If you cannot boot the system, then an interactive session with Grub is
necessary (press "e" at the Grub prompt) to disable a per-item
"savedefault" setting.
I can confirm this behaviour with Reiserfs 3.6.19 (Debian Sid); XFS and
other journalling filesystems seem to have the same issue, which is
understandable; Grub can read unclean journalled filesystems, but cannot
do the log-replay which is needed before a write can be achieved. I
suspect that this feature will only work reliably with ext2/vfat or
whatever other non-logging filesystems Grub supports.
Personally, I would say that Grub's "savedefault" setting should be seen
as a preference, not a requirement, and that if it fails to write to the
filesystem, it should continue to pass control to the kernel on that
filesystem for it to deal with the unclean filesystem.
--
Steve Parker
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
