kgzip(8) regression in RELENG_9 GENERIC

[Devin Teske]

On Jan 23, 2012, at 12:56 AM, CyberLeo Kitsana wrote:

> On 01/23/2012 12:30 AM, Devin Teske wrote:
>> 
>> On Jan 21, 2012, at 1:41 AM, CyberLeo Kitsana wrote:
>> 
>>> On 01/20/2012 09:02 PM, Devin Teske wrote:
>>>> Taking a GENERIC 9.0-RELEASE kernel and running kgzip(8) on it produces an
>>>> unusable kernel which causes immediate BTX halt in loader(8).
>>>> 
>>>> ...
>>>> 
>>>> 4. Say: kgzip kernel
>>> 
>>> Curious, it doesn't even look like that binary is hooked into the build
>>> process at all on 9.0-RELEASE.
>>> 
>> 
>> Can you clarify what you mean by the above?
> 
> On a brand new GENERIC box running 9.0-RELEASE with no special knobs:
> 
> ----8<----
> (4b18d544)[cyberleo at jenga ~]$ which kgzip

On my box:

push900# uname -a
FreeBSD push900.vicor.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:15:25 UTC 2012     root at obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

push900# which kgzip
/usr/sbin/kgzip



> (4b18d544)[cyberleo at jenga ~]$ apropos kgzip

push900# whereis kgzip
kgzip: /usr/sbin/kgzip /usr/share/man/man8/kgzip.8.gz /usr/src/usr.sbin/kgzip


> (4b18d544)[cyberleo at jenga ~]$ cd /usr/src/usr.sbin
> (4b18d544)[cyberleo at jenga /usr/src/usr.sbin]$ ls | grep kgzip
> kgzip
> (4b18d544)[cyberleo at jenga /usr/src/usr.sbin]$ grep kgzip Makefile
> (4b18d544)[cyberleo at jenga /usr/src/usr.sbin]$
> ----8<----

push900# grep kgzip Makefile
# $FreeBSD: release/9.0.0/usr.sbin/kgzip/Makefile 116221 2003-06-11 21:36:06Z obrien $
PROG=	kgzip
MAN=	kgzip.8
SRCS=	kgzip.c aouthdr.c elfhdr.c kgzcmp.c kgzld.c xio.c


> 
> So it's there,

Yes, there it is. How is it that my GENERIC 9.0-RELEASE build has it, source included, manual included, Makefile included, binary included,... but yours does not?



> but the SUBDIR entry in the usr.sbin Makefile that hooks
> it into the build process seems to be missing, whereas things that do
> exist (freebsd-update, &c) are present.
> 
>>> It's manpage indicates that it is unsuitable for loader(8) use,
>> 
>> Likewise, can you clarify the above?
> 
>> From kgzip.8 in the aforementioned directory:
> 
> ----8<----
> BUGS
> As symbols are lost, the usefulness of this utility for compressing ker-
> nels is limited to situations where loader(8) cannot be used; otherwise
> the preferred method of compressing a kernel is simply to gzip(1) it.
> ----8<----
> 

That's an odd sort of message. I've been using kgzip(1) since the days of RELENG_4 ... with loader(8) mind you, and have never had a problem until now with RELENG_9.




>>> and that
>>> just running gzip(1) on the kernel file is sufficient;
>> 
>> I'm getting an error when loading a gzip(1)'d kernel...
>> 
>> 	don't know how to load module '/kernels/GENERIC-i386-9.0.gz'
>> 
>> So I figure, maybe it doesn't like the '.gz' suffix. No go, same error.
> 
> I think we'll need more information on how your system is set up to
> boot:

First, it's not my system, it's my installer.

I'm taking on the task of creating a dual-installer (pictures linked-to below):

http://www.twitpic.com/89l2ub/full
http://www.twitpic.com/89l4n6/full

I usually use kgzip'd kernels on my installer. It's always worked in the past (period).

The reason for doing so is that it takes a 14MB GENERIC kernel and reduces it to 4.6MB (pretty obvious incentive there).



> partition layout,

None to speak of. All I'm really doing to replicate the BTX halt is loading up an ISO with the following contents:

1. loader(8) from unmodified RELENG_9
2. kgzip(1)'d kernel -- again, unmodified RELENG_9 (GENERIC)
3. load kernel with FICL ``load''
4. boot
5. BTX halted immediately



> what boot blocks and loaders are in use, etc.

All from 9.0-RELEASE


> How are you instructing it to load that particular kernel, for example?

Here's the FICL syntax used which replicates the BTX halt:

load /kernels/GENERIC-i386-9.0.kgz
load -t mfs_root /boot/fis_mfsroot9.gz
set vfs.root.mountfrom="ufs:/dev/md0"
set vfs.root.mountfrom.options="rw"
boot

This leads to BTX halt. Simply going in and swapping kgzip(1)'d kernel for non-kgzip(1)'d kernel fixes the problem.
-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.