Subject: Re: 4.99.23 fails to boot on sparc64
To: Martin Husemann <martin@duskware.de>
From: Erik Bertelsen <bertelsen.erik@gmail.com>
List: current-users
Date: 07/15/2007 06:54:07
2007/7/15, Martin Husemann <martin@duskware.de>:
> On Sat, Jul 14, 2007 at 03:27:47PM -0500, David Young wrote:
> > I believe I have seen a similar failure on i386 when the disklabel and the
> > FFS superblock disagreed about the size of blocks and fragments, and/or
> > when the kernel grew big enough to require a 2nd or 3rd level of inode
> > indirection.
>
> This is probably a good direction to investigate - all kernels boot fine
> for me.
>
> Erik, could you try netbooting the non-working kernels?
>
> >  Are the kernels both on a FFS filesystem?  How big are they?
> > What does disklabel(8) say about the disk where the kernels reside?
>
> The sizes or my copies are:
>
> -rw-r--r--  1 martin  wheel  7137044 Jul 12 16:12 netbsd.u2
> -rw-r--r--  1 martin  wheel  7133780 Jul 12 16:12 netbsd.u3
> -rw-r--r--  1 martin  wheel  6909426 Jul 12 16:13 netbsd.u4
>
> Since ofwboot only supports FFSv1 and NFS, I guess they live on a FFSv1
> partition in Erik's case.
>
> Erik, can you "ls -lisa" the kernels, in addition to the info David asked
> for? I wonder if this is an OFW bug and some kernels live beyound some
> magic sector number.
>
> Martin
>

I think that we're closing in now:

 ls -lisa netbsd.*
353468 2544 -rwxr-xr-x  1 root  wheel  2584633 Mar  6 00:44 netbsd.030
353013 2560 -rwxr-xr-x  1 root  wheel  2589578 Mar 21 21:47 netbsd.031
352959 2560 -rwxr-xr-x  1 root  wheel  2590610 Mar 24 12:13 netbsd.032
352900 2560 -rwxr-xr-x  1 root  wheel  2601703 May 21 18:23 netbsd.033
352879 2576 -rwxr-xr-x  1 root  wheel  2617243 May 22 22:25 netbsd.034
352827 2576 -rwxr-xr-x  1 root  wheel  2618896 May 30 19:16 netbsd.035
352807 2576 -rwxr-xr-x  1 root  wheel  2618734 May 31 21:20 netbsd.036
352803 2592 -rwxr-xr-x  1 root  wheel  2625001 Jul  7 15:05 netbsd.037
499550 7648 -rwxr-xr-x  1 root  wheel  7810373 Jul 14 17:29 netbsd.generic
406929 6992 -rwxr-xr-x  1 root  wheel  7137645 Jul 13 11:27 netbsd.u2
406937 6992 -rwxr-xr-x  1 root  wheel  7137044 Jul 12 03:47 netbsd.u2.001
636152 6992 -rwxr-xr-x  1 root  wheel  7134381 Jul 13 13:07 netbsd.u3
636188 6992 -rwxr-xr-x  1 root  wheel  7133780 Jul 12 15:11 netbsd.u3.001
545785 6768 -rwxr-xr-x  2 root  wheel  6909426 Jul 12 13:18 netbsd.u4
656247 6752 -rwxr-xr-x  1 root  wheel  6882774 Jul 13 14:55 netbsd.u6
523027 7472 -rwxr-xr-x  1 root  wheel  7619973 Jul 13 22:38 netbsd.u7
675829 7632 -rwxr-xr-x  1 root  wheel  7791191 Jul 14 15:38 netbsd.u8
679577 7520 -rwxr-xr-x  1 root  wheel  7679388 Jul 14 22:00 netbsd.u9
     4 7520 -rwxr-xr-x  1 root  wheel  7679388 Jul 15 05:58 netbsd.xx


netbsd.generic and netbsd.u2{.001} do boot, the remainder of the
netbsd.u? kernels don't.
netbsd.xx was made by cp /netbsd.u9 /netbsd.xx. netbsd.u9 does not
boot, but netbsd.xx does.
The netbsd.03? kernels are pre-4.99.23 and did all boot.

Is there something magical about loading kernels with inodes being
before or after 512K ?

My next experiment was to rebuild a kernel from my original custom
kernel definition.
As usual i moved the kernel to / using mv. This kernel did not boot.
Then I made a
copy within / and now it boots. The kernel mv'ed from the build area
has inode 631967
and the (booting) copy has inode 5.


The disklabel output is below:

 disklabel sd0
# /dev/rsd0c:
type: unknown
disk: unidata18
label:
flags:
bytes/sector: 512
sectors/track: 399
tracks/cylinder: 6
sectors/cylinder: 2394
cylinders: 14970
total sectors: 35838180
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0

8 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 a:  33788916         0     4.2BSD   2048 16384     0  # (Cyl.      0 -  14113)
 b:   2049264  33788916       swap                     # (Cyl.  14114 -  14969)
 c:  35838180         0     unused      0     0        # (Cyl.      0 -  14969)
#  df -hi
Filesystem        Size       Used      Avail %Cap    iUsed   iAvail
%iCap Mounted on
/dev/sd0a          16G       6.4G       8.6G  42%   471789  1613329  22% /
kernfs            1.0K       1.0K         0B 100%      896      128  87% /kern

- Erik