Date: Fri, 11 Oct 2002 13:47:21 +0200 From: Bernd Walter <ticso@cicely8.cicely.de> To: Wilko Bulte <wkb@freebie.xs4all.nl> Cc: ticso@cicely.de, Poul-Henning Kamp <phk@critter.freebsd.dk>, freebsd-alpha@FreeBSD.ORG Subject: Re: booting UFS2 on alpha (was: cvs commit: src/sys/boot/common ufsread.c) Message-ID: <20021011114720.GZ17920@cicely8.cicely.de> In-Reply-To: <20021011130834.A12041@freebie.xs4all.nl> References: <20021010210124.GV17920@cicely8.cicely.de> <14845.1034332326@critter.freebsd.dk> <20021011104520.GY17920@cicely8.cicely.de> <20021011130834.A12041@freebie.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 11, 2002 at 01:08:34PM +0200, Wilko Bulte wrote: > On Fri, Oct 11, 2002 at 12:45:20PM +0200, Bernd Walter wrote: > > On Fri, Oct 11, 2002 at 12:32:06PM +0200, Poul-Henning Kamp wrote: > > > In message <20021010210124.GV17920@cicely8.cicely.de>, Bernd Walter writes: > > > > > > >>>>boot dka400 > > > >(boot dka400.4.0.6.0 -flags 0) > > > >block 0 of dka400.4.0.6.0 is not a valid boot block > > > >bootstrap failure > > > > > > > >This one is my biggest problem. > > > >SRM doesn't accept the disklabel. > > > >Once I dd the first 512 bytes from an old disk SRM is happy. > > > >I compared them with hexdump, but wasn't able to find the reason. > > > > > > Is there some place which documents what the requirements for being > > > a valid boot-block is ? > > > > None that I know about. > > Maybe someone else on the alpha list knows? > > I'll try to find out. Might take a while. Thank you. In the meantime here are the details. Working: [54]cicely8# hexdump -v ~/delme 0000000 0000 0000 0000 0000 0000 0000 0000 0000 0000010 0000 0000 0000 0000 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 0000 0000 0000030 0000 0000 0000 0000 0000 0000 0000 0000 0000040 4557 8256 0004 0000 4553 4741 5441 2045 0000050 0000 0000 0000 0000 0000 0000 0000 0000 0000060 0000 0000 0000 0000 0200 0000 0020 0000 0000070 0040 0000 03ed 0000 0800 0000 6b84 001f 0000080 0000 0000 0000 0000 0e10 0001 0000 0000 0000090 0000 0000 0000 0000 0000 0000 0000 0000 00000a0 0000 0000 0000 0000 0000 0000 0000 0000 00000b0 0000 0000 0000 0000 0000 0000 0000 0000 00000c0 0000 0000 4557 8256 1a40 0008 2000 0000 00000d0 2000 0000 6b84 001f 0000 0000 0800 0000 00000e0 0807 005a 0000 0000 0000 0000 0000 0000 00000f0 0000 0000 6b84 001f 0000 0000 0000 0000 0000100 0000 0000 0000 0000 0000 0000 0000 0000 0000110 0000 0000 0000 0000 0000 0000 0000 0000 0000120 0000 0000 0000 0000 0000 0000 0000 0000 0000130 0000 0000 0000 0000 0000 0000 0000 0000 0000140 0000 0000 0000 0000 0000 0000 0000 0000 0000150 0000 0000 0000 0000 0000 0000 0000 0000 0000160 0000 0000 0000 0000 0000 0000 0000 0000 0000170 0000 0000 0000 0000 0000 0000 0000 0000 0000180 0000 0000 0000 0000 0000 0000 0000 0000 0000190 0000 0000 0000 0000 0000 0000 0000 0000 00001a0 0000 0000 0000 0000 0000 0000 0000 0000 00001b0 0000 0000 0000 0000 0000 0000 0000 0000 00001c0 0000 0000 0000 0000 0000 0000 0000 0000 00001d0 0000 0000 0000 0000 0000 0000 0000 0000 00001e0 000e 0000 0000 0000 0001 0000 0000 0000 00001f0 0000 0000 0000 0000 e550 c9fa 0835 a2fa 0000200 Non-working: [51]cicely8# hexdump -v ~/delme2 0000000 0000 0000 0000 0000 0000 0000 0000 0000 0000010 0000 0000 0000 0000 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 0000 0000 0000030 0000 0000 0000 0000 0000 0000 0000 0000 0000040 4557 8256 0004 0000 4553 4741 5441 0045 0000050 0000 0000 0000 0000 0000 0000 0000 0000 0000060 0000 0000 0000 0000 0200 0000 0020 0000 0000070 0040 0000 0248 0000 0800 0000 409e 0012 0000080 0000 0000 0000 0000 0e10 0001 0000 0000 0000090 0000 0000 0000 0000 0000 0000 0000 0000 00000a0 0000 0000 0000 0000 0000 0000 0000 0000 00000b0 0000 0000 0000 0000 0000 0000 0000 0000 00000c0 0000 0000 4557 8256 14b8 0008 2000 0000 00000d0 0000 0000 409e 0012 0000 0000 0800 0000 00000e0 0807 2410 0000 0000 0000 0000 0000 0000 00000f0 0000 0000 409e 0012 0000 0000 0000 0000 0000100 0000 0000 0000 0000 0000 0000 0000 0000 0000110 0000 0000 0000 0000 0000 0000 0000 0000 0000120 0000 0000 0000 0000 0000 0000 0000 0000 0000130 0000 0000 0000 0000 0000 0000 0000 0000 0000140 0000 0000 0000 0000 0000 0000 0000 0000 0000150 0000 0000 0000 0000 0000 0000 0000 0000 0000160 0000 0000 0000 0000 0000 0000 0000 0000 0000170 0000 0000 0000 0000 0000 0000 0000 0000 0000180 0000 0000 0000 0000 0000 0000 0000 0000 0000190 0000 0000 0000 0000 0000 0000 0000 0000 00001a0 0000 0000 0000 0000 0000 0000 0000 0000 00001b0 0000 0000 0000 0000 0000 0000 0000 0000 00001c0 0000 0000 0000 0000 0000 0000 0000 0000 00001d0 0000 0000 0000 0000 0000 0000 0000 0000 00001e0 000e 0000 0000 0000 0001 0000 0000 0000 00001f0 0000 0000 0000 0000 ef43 e7cd 526e e5dc 0000200 struct disklabel starts at 0x40. The only real difference in struct disklabel is d_bbsize, but tests have showed, that this shouldn't be the reason. E.g. if I disklabel -e and don't change anything it's cleared out, but SRM still accepts the boot blocks. struct disklabel is 276 bytes long and the block is padded with some unknown values. Especially the last 8 bytes are interesting for me. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021011114720.GZ17920>