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