Re: bootloader issue

> sdboot binaries in 1.6.1 and 4.0 look identical
> (since it's written in assembler), so there is
> some problem around bootxx binary in 4.0, I guess.
I thought it would be a bug in the first stage because I don't even see the 
banner from the second stage.  But I guess it must be something that's 
happening in the second stage before the banner gets printed.

> Hmm, in this case, what combination?
> sdboot: 1.6.1
> bootxx: 1.6.1
> boot.atari: 4.0
> installboot: 1.6.1
> Is this right? If so, we have to check the bootxx binary.
No, it is:
sdboot: 1.6.1
bootxx: 1.6.1
boot.atari: 1.6.1
installboot: 1.6.1
And with the version of installboot, I assume you mean the last version that 
was run.  I had to manually replace boot.atari to be the old one from 1.6.1 
and then the boot would work.  Before doing that, I'd get a crash (the one 
you wanted more info on) -- I didn't yet go back to get details on this 
crash because I assumed that the mismatch between xdboot/bootxx vs. 
boot.atari explains it entirely.

> So if you'll try to use different installboot version,
> you have to move bootxx and sdboot binaries into
> an appropriate directory.
When I say I ran the 1.6.1 installboot, what I mean is that I actually 
booted up the 1.6.1 sysinst on a 1.6.1 kernel and ran through the first part 
of the install procedure (being careful to preserve the filesystem).

> BTW, the superblock for root file system is located
> at right after first 8KB blocks (where bootxx is written).
> I'm afraid installboot writes something too much..
Ok, that makes sense.  For now I'll just assume it's an artifact of running 
the 1.6.1 installboot on top of a HEAD install.

You had mentioned adding printfs to the bootloader to try to pinpoint the 
error.  If you build it, I'll test it, as many times as it takes.  =)

David Ross
[email protected]


----- Original Message ----- 
From: "Izumi Tsutsui" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>; <[email protected]>; <[email protected]>; 
<[email protected]>
Sent: Sunday, January 04, 2009 1:09 AM
Subject: Re: bootloader issue


> David Ross wrote:
>
>> Sysinst from HEAD runs installboot.  Here's the command line:
>> /usr/mdec/installboot -v /dev/rsd0c
>>
>> And the output:
>> installboot: Cannot stat /netbsd, no bootversion check done
>> Primary   boot loader: /usr/mdec/std/sdboot
>> Secondary boot loader: /usr/mdec/std/bootxx
>> Boot block installed on /dev/rsd0c (sector 0)
>> Boot preference set to NetBSD.
>
> Ok, then it looks worked as expected.
>
> I've also checked your disk image in the PR.
> It looks sdboot and bootxx are written into
> the first 8KB space properly.
>
> sdboot binaries in 1.6.1 and 4.0 look identical
> (since it's written in assembler), so there is
> some problem around bootxx binary in 4.0, I guess.
>
>> Now, after this is installed of course I get the "Halting..." message, so 
>> I
>> now have gone back to run installboot from 1.6.1.  /boot.atari is still 
>> the
>> one from HEAD so we have the mismatch.  I just tried fixing the mismatch 
>> by
>> dropping the boot.atari from 1.6.1 onto the root of the drive.  And... 
>> it
>> worked!  Well, sort of...
>>
>> The HEAD kernel boots up off the drive and here's what I get:
>> http://i39.tinypic.com/2cdki8x.jpg
>
> Hmm, in this case, what combination?
> sdboot: 1.6.1
> bootxx: 1.6.1
> boot.atari: 4.0
> installboot: 1.6.1
> Is this right? If so, we have to check the bootxx binary.
>
> As per cvs log, there is no particular change between 1.6 and 4.0
> around bootxx, so we have to check other possible changes,
> i.e. gcc4 or machine independent standalone libraries etc.
> (one possible problem is it's too large)
>
>> Two possibilities immediately come to mind:
>>   - Running the 1.6.1 installer slightly corrupted the drive.  In truth, 
>> I
>> didn't _just_ run the 1.6.1 installboot.  That alone fails.
>
> According to cvs log, milan support was added after 1.6
> and directories for boot binaries were changed
> from /usr/mdec/ to /usr/mdec/{std,milan}/ and
> installboot was also changed to search an appropriate dir
> per "-m" (milan) option.
>
> So if you'll try to use different installboot version,
> you have to move bootxx and sdboot binaries into
> an appropriate directory.
>
>> A simple fsck_ffs:
>> fsck_ffs /dev/rsd0a
>> ..does not fix the super block issue.  fsck_ffs complains about the same
>> issue but doesn't repair it.  Not sure how to correct this.  The -b 
>> option
>> looks intriguing but I'm not sure what block number I would need to 
>> supply:
>> http://netbsd.gw.com/cgi-bin/man-cgi?fsck_ffs+.atari+NetBSD-current
>
> "fsck_ffs -b 32" will work, as fsck_ffs(8) says:
>>>          -b block        Use the block number block as the super block 
>>> for
>>>                          the file system.  Block 32 is usually an 
>>> alterna-
>>>                          tive super block.
>
> BTW, the superblock for root file system is located
> at right after first 8KB blocks (where bootxx is written).
> I'm afraid installboot writes something too much..
>
> ---
> Izumi Tsutsui
>