Skip site navigation (1)Skip section navigation (2)
Date:      08 Nov 2002 16:52:59 +0000
From:      Doug Rabson <dfr@nlsystems.com>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/lib/libdisk write_alpha_disk.c
Message-ID:  <1036774379.21473.3.camel@builder02.qubesoft.com>
In-Reply-To: <XFMail.20021108113932.jhb@FreeBSD.org>
References:  <XFMail.20021108113932.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2002-11-08 at 16:39, John Baldwin wrote:
> On 08-Nov-2002 Doug Rabson wrote:
> > On Thursday 07 November 2002 2:42 pm, John Baldwin wrote:
> >> On 07-Nov-2002 John Baldwin wrote:
> >> > jhb         2002/11/07 06:39:22 PST
> >> >
> >> >   Modified files:
> >> >     lib/libdisk          write_alpha_disk.c
> >> >   Log:
> >> >   Get this closer to working.  The Write_Disk() function's for loop
> >> > needed to use the same start condition as the i386 version.  However,
> >> > since Alpha's only have one fake "slice" from sysinstall's perspective we
> >> > don't need to use a loop, but can just write out the BSD label in the
> >> > first fake "slice".
> >>
> >> Unfortunately a newly installed disk does not boot, however.  *sigh*
> > 
> > Does it load the bootstrap at all? If not, then its almost certainly just the 
> > checksum being wrong. If it tries to load the bootstrap then crashes, 
> > probably the field pointing to the bootstrap is wrong.
> 
> It's the checksum.  So far I've verified that when libdisk first writes
> the label to the disk it is correct.  I've tried closing the disk and
> immediately re-opening the disk and re-computing the checksum and it is
> still ok.  However, after install, the disklabel's are different (I made
> a backup copy on the disk so I could compare them).  The differences are
> all within the actual array of partitions within the disklabel itself.
> phk@ has suggested that certain ioctl's can dink with those fields in the
> kernel and neither sysinstall nor libdisk use those ioctls.  However, newfs
> does so my current guess is that when newfs uses those ioctl's, it goes in
> and changes the disklabel on disk resulting in the checksum being invalid.
> The problematic ioctl() seems to be in rewritelabel().  I don't know why
> newfs now doesn't produce the same disklabel as libdisk.  Perhaps libdisk's
> disklabel's are buggy but no one's noticed because newfs fixes them up?

I'm sure that rewritelabel() used to have some extra code that
re-calculated the SRM checksum. Has this rotted away?




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1036774379.21473.3.camel>