Port-atari archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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
dross%pobox.com@localhost


----- Original Message ----- From: "Izumi Tsutsui" <tsutsui%ceres.dti.ne.jp@localhost>
To: <dross%pobox.com@localhost>
Cc: <tjamaloo%gmail.com@localhost>; <abs%NetBSD.org@localhost>; <port-atari%NetBSD.org@localhost>; <tsutsui%ceres.dti.ne.jp@localhost>
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




Home | Main Index | Thread Index | Old Index