Root FS corruption

[Yar Tikhiy]

On Sat, May 27, 2006 at 10:43:07PM -0700, Julian Elischer wrote:
> Yar Tikhiy wrote:
> >
> >Folks, I have good news for all of us:  This kind of corruption
> >isn't done by the kernel.  Thanks to Ian Dowse, I found out that
> >/boot/loader would rewrite nextboot.conf through libufs or whatever.
> >This is done in support.4th, the word is rewrite_nextboot_file.
> >Initially I missed a clear sign of the problem being caused by the
> >loader:  The corrupted data started with `nextboot_enable="NO" \n',
> >which is the string written from support.4th.  The actual bug must
> >be hiding in libufs, or whatever loader uses to access UFS.
> >
> >Recent technical details of my investigation have been filed
> >in PR bin/98005:
> >
> >	http://www.freebsd.org/cgi/query-pr.cgi?pr=98005
> >
> >The conclusion is:  Avoid nextboot(8) for now.
> 
> the current nextboot fails to provide  all the designed functionality
> of the previous nextboot. (which is why we still use the old one at 
> ironport)
> One day I'll get around to reimplementing the old one..
> 
> (the design criteria were:)
> 
> Store the nextboot info "not in a filesystem". (the filesystem may be 
> corrupt
> or there ma be several types of filesystem available).
> Change that info from boot0 without writing to a filesystem.
> (to note that it was used)
> Be able to store different stuff on different disks at the same time.
> Be able to ensure that you could specify how many times the
> information was used before falling back to something else.

The present problem seems to lurk in the BIOS disk access mini-library
used by the /sys/boot code, while nextboot just triggers it.  Ian
Dowse sent me a patch to test.  I hope that the fixed library will
facilitate your efforts on implementing the new nextboot.  Thanks!

-- 
Yar