Hi,
I'm original author of the grub2 NILFS2 module.
Yes, it lacks roll back/forward or recovery to keep the boot loader simple.
It also prevent from unintentional boot, like old buggy kernel is used.
Aside from the way it works, the code itself is capable to boot from
any checkpoints. It happens to choose the latest one. The only thing
we need is the way to _choose_ the checkpoint from grub interface :(.
thanks
regards
--
Jiro SEKIBA <jir@xxxxxxxxxx>
At Thu, 03 May 2012 15:49:04 +0900 (JST),
Ryusuke Konishi wrote:
>
> Hi,
> On Tue, 1 May 2012 03:38:57 -0700 (PDT), Sven-Göran_Bergh wrote:
> > Hi list,
> >
> > I have done some observations with the combination
> > grub2 and nilfs2 on the boot partition. It would
> > be valuable to know if anyone else has done similar
> > observations or if this is a {,/un}known problem.
> >
> >
> > After some harsh handling the system is rebooted
> > and grub2 hangs during stage 1.5-2. Once grub2 has
> > encountered this problem it is consistent. It will
> > hang on every consecutive boot.
> >
> > However, if the filesystem (on a CF) is mounted by
> > another system there are no problems reported.
> > Furthermore, once the filesystem has been mounted
> > by another system grub2 has no problems booting it
> > again afterwards. There is no need to do anything
> > else with the fs than mounting it by another system
> > and then umount it again.
> > My preliminary analysis is:
> > * Nilfs2 is left in a disturbed state, due to some
> > rough handling (still unknown in detail).
> > * A normal mount has no problem to recover the fs
> > in such case.
> > * Grub2 lacks some of the recovery features
> > performed during a normal mount and will have
> > problem reading files on the fs.
> >
> > Currently I do not have a more exact description of
> > the problem. I still have to figure out exactly what
> > handling that triggers this state for the fs.
> >
> > This is an embedded project and a previous version
> >
> > is running grub legacy and ext2 without any signs of
> > similar problems. Grub legacy has never failed, even
> > with a (partly) corrupt ext2.
> >
> > My own knowledge in the nilfs2/grub2 internals is
> > limited and it is hard to troubleshoot since I
> > have no recipe reproduction. However, I have observed
> > it on several occasions on our test systems. I am on
> > a tight schedule, but when time permits, I will try
> > to find a way to reproduce this.
> >
> > Have anyone experienced similar behavior?
> >
> > Brgds
> > /Sven
>
> Thank you for reporting the issue in the nilfs2 boot loader of grub2.
>
> Your analysis seems right to me.
>
> The nilfs2 grub code looks to be lacking roll forwarding and crc
> verification (the latter both for super blocks and log blocks).
>
> It is incomplete, or rather I should say it took a good trade-off
> between simplicity and reliability as an early practicable
> implementation.
>
> Actually it works without trouble in most cases since most checkpoints
> coherently include files needed to boot up system even though that
> omission may lead the boot loader to read not-updated files after
> unclean shutdown.
>
> In my opinion, nilfs2 grub code does not have to do recovery, but it
> should scan the latest checkpoint in order to minimize troubles.
> However, I don't know whether it's possible or not in the boot loader.
>
> Of course, there is a possibility that simply an unknown bug caused
> your trouble. In that case, inserting debug print functions in the
> nilfs2 grub code and booting up with it, would be helpful to narrow
> down the cause of the problem.
>
>
> Thanks,
> Ryusuke Konishi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
