freebsd-hackers Digest, Vol 366, Issue 5
freebsd-hac...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
or, via email, send a message with subject or body 'help' to
freebsd-hac...@freebsd.org
You can reach the person managing the list at
freebsd-ha...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-hackers digest..."
Today's Topics:
1. Re: Newbie question: kernel image a dynamically linked
binary? (Oliver Fromme)
2. Re: Newbie question: kernel image a dynamically linked
binary? (John Baldwin)
3. Re: Fwd: mkuzip and/or geom_uzip changes? (John Baldwin)
4. Re: Fwd: mkuzip and/or geom_uzip changes? (John Baldwin)
5. Re: Fwd: mkuzip and/or geom_uzip changes? (Tim Judd)
6. Re: Compiling kernel with gcc43 [SOLVED] (Oliver Fromme)
7. Re: Compiling kernel with gcc43 [SOLVED] (Pegasus Mc Cleaft)
8. Re: Fwd: mkuzip and/or geom_uzip changes? (John Baldwin)
9. Re: Fwd: mkuzip and/or geom_uzip changes? (Tim Judd)
10. Re: Compiling kernel with gcc43 [SOLVED] (Vlad Galu)
11. Re: Fwd: mkuzip and/or geom_uzip changes? (John Baldwin)
12. Re: Newbie question: kernel image a dynamically linked
binary? (Dag-Erling Sm?rgrav)
13. Re: Dynamic ticks in FreeBSD (Dag-Erling Sm?rgrav)
14. Re: Newbie question: kernel image a dynamically linked
binary? (Dag-Erling Sm?rgrav)
15. Re: Dynamic ticks in FreeBSD (Dag-Erling Sm?rgrav)
16. Re: Fwd: mkuzip and/or geom_uzip changes? (Tim Judd)
17. Re: Fwd: mkuzip and/or geom_uzip changes? (Tim Judd)
18. Re: Fwd: mkuzip and/or geom_uzip changes? (Tim Judd)
----------------------------------------------------------------------
Message: 1
Date: Thu, 1 Apr 2010 14:01:29 +0200 (CEST)
From: Oliver Fromme <ol...@lurza.secnetix.de>
Subject: Re: Newbie question: kernel image a dynamically linked
binary?
To: freebsd...@FreeBSD.ORG, daniel....@gmail.com,
freebsd...@FreeBSD.ORG, freebs...@FreeBSD.ORG
Message-ID: <201004011201....@lurza.secnetix.de>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
Please don't crosspost to many lists. This topic is probably
suitable for hackers@ but not for the other lists.
Daniel Rodrick <daniel....@gmail.com> wrote:
> I'm a newbie and coming from Linux background, and am trying to learn
> FreeBSD now. The first thing I find a little confusing is that the
> final FreeBSD kernel image is shown as a DYNAMICALLY LINKED binary:
>
> $
> $ pwd
> /boot/kernel
> $
> $ file kernel
> kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),
> dynamically linked (uses shared libs), not stripped
> $
>
> How can the kernel image use shared libraries? And which ones does it
> use, if any?
>
> Also, I cannot find out the libraries the image uses using the
> traditional ldd command:
>
> $ ldd kernel
> kernel:
> kernel: signal 6
> $
ldd works by actually executing the binary with a special
flag for rtld(1). Compare:
$ ldd /bin/sh
/bin/sh:
libedit.so.7 => /lib/libedit.so.7 (0x280a8000)
libncurses.so.8 => /lib/libncurses.so.8 (0x280bd000)
libc.so.7 => /lib/libc.so.7 (0x280fc000)
$ LD_TRACE_LOADED_OBJECTS=1 /bin/sh
libedit.so.7 => /lib/libedit.so.7 (0x280a8000)
libncurses.so.8 => /lib/libncurses.so.8 (0x280bd000)
libc.so.7 => /lib/libc.so.7 (0x280fc000)
Of course you cannot execute the kernel (only the boot loader
knows how to load and boot the kernel), so ldd fails on the
kernel.
But you can use objdump(1) to list dynamic dependencies.
$ objdump -p /bin/sh | grep NEEDED
NEEDED libedit.so.7
NEEDED libncurses.so.8
NEEDED libc.so.7
$ objdump -p /boot/kernel/kernel | grep NEEDED
NEEDED hack.So
As far as I know, the kernel and all kernel modules need to
be dynamic binaries so the kernel linker works, which is
required for dynamically loading kernel modules.
So what is that "hack.So" object? It's just a dummy that's
required for technical reasons. You can see the details in
/sys/conf/kern.post.mk which contains this paragraph:
# This is a hack. BFD "optimizes" away dynamic mode if there are no
# dynamic references. We could probably do a '-Bforcedynamic' mode like
# in the a.out ld. For now, this works.
HACK_EXTRA_FLAGS?= -shared
hack.So: Makefile
:> hack.c
${CC} ${HACK_EXTRA_FLAGS} -nostdlib hack.c -o hack.So
rm -f hack.c
> Can some please throw some light?
I hope I did. :-)
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"Unix gives you just enough rope to hang yourself --
and then a couple of more feet, just to be sure."
-- Eric Allman
------------------------------
Message: 2
Date: Thu, 1 Apr 2010 07:37:53 -0400
From: John Baldwin <j...@freebsd.org>
Subject: Re: Newbie question: kernel image a dynamically linked
binary?
To: freebs...@freebsd.org
Cc: freebsd...@freebsd.org, Daniel Rodrick
<daniel....@gmail.com>
Message-ID: <20100401073...@freebsd.org>
Content-Type: Text/Plain; charset="iso-8859-1"
On Thursday 01 April 2010 6:23:50 am Daniel Rodrick wrote:
> Hello List,
>
> I'm a newbie and coming from Linux background, and am trying to learn
> FreeBSD now. The first thing I find a little confusing is that the
> final FreeBSD kernel image is shown as a DYNAMICALLY LINKED binary:
>
> $
> $ pwd
> /boot/kernel
> $
> $ file kernel
> kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),
> dynamically linked (uses shared libs), not stripped
> $
>
> How can the kernel image use shared libraries? And which ones does it
> use, if any?
>
> Also, I cannot find out the libraries the image uses using the
> traditional ldd command:
>
> $ ldd kernel
> kernel:
> kernel: signal 6
> $
>
> Can some please throw some light?
It's a hack that is used so that the kernel linker is able to link in kernel
modules that are built as shared objects. The kernel is mostly built from
static objects, but a single dynamic object (that is empty) is linked in:
# This is a hack. BFD "optimizes" away dynamic mode if there are no
# dynamic references. We could probably do a '-Bforcedynamic' mode like
# in the a.out ld. For now, this works.
HACK_EXTRA_FLAGS?= -shared
hack.So: Makefile
:> hack.c
${CC} ${HACK_EXTRA_FLAGS} -nostdlib hack.c -o hack.So
rm -f hack.c
--
John Baldwin
------------------------------
Message: 3
Date: Thu, 1 Apr 2010 08:38:38 -0400
From: John Baldwin <j...@freebsd.org>
Subject: Re: Fwd: mkuzip and/or geom_uzip changes?
To: freebsd...@freebsd.org
Cc: Tim Judd <taj...@gmail.com>, sob...@freebsd.org
Message-ID: <20100401083...@freebsd.org>
Content-Type: Text/Plain; charset="iso-8859-15"
On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote:
> Hi All,
>
> Just starting to see if I can find other reports. You all probably
> have had the "more than one pair of eyes looking at a thing is better
> than my eyes alone." This is why I'm writing now, as I'm starting the
> discovery.
>
> Let me background this a little bit. I only started looking into this
> because mkuzip and it's counterpart, geom_uzip are throwing errors on
> FreeBSD8 i386
>
>
> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with knobs):
> make DESTDIR=/home/small8 installworld installkernel distribution
> mv /home/small8/boot /home/small8-boot/
> makefs -t ffs /home/small8/usr.img /home/small8/usr/
> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img [*]
> chflags -R noschg /home/small8/usr/*
> rm -rf /home/small8/usr/* /home/small8/usr.img
> ee /home/small8/etc/rc.d/mountcritlocal
> [**]
> makefs -t ffs /home/small8-boot/mfsroot /home/small8/
> gzip --best /home/small8-boot/mfsroot
> ee /home/small8-boot/boot/loader.conf
> [***]
> rm /home/small8-boot/boot/kernel/*.symbols
> gzip --best /home/small8-boot/boot/kernel/kernel
> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot
> -iso-level 4 -o /home/small8.iso /home/small8-boot/
>
>
> [*]: mkuzip inserts a script header that is broken. module name it's
> searching for may have been renamed?
> [**]: Edited mountcritlocal to mount the usr.uzip file as by using the
> above script header, throws errors
> [***]: added zlib and geom_uzip modules to load to the boot image, to
> satisfy the script header's requirements.
>
> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso.
> Small enough to apparently fit into the undocumented 50 or 100MB size
> limit of mfs_root module
BTW, you can raise this limit by changing NKPT.
> The problem:
> mkuzip generates a few lines as a script in the head of the
> resulting *.uzip file. Two problems...
> 1) the module it queries for is geom_uzip (kldstat -m $m), but
> FreeBSD8 names the geom_uzip module (i guess, internally) as g_uzip.
> mkuzip's generated image will never find the module if they're not
> named the same.
It is g_uzip even in 7:
DECLARE_GEOM_CLASS(g_uzip_class, g_uzip);
MODULE_DEPEND(g_uzip, zlib, 1, 1, 1);
This has probably just been broken from the start. If it used 'kldstat -n'
then it might work. Well, it probably works (modulo a warning) by accident as
it doesn't hurt to kldload an already-loaded module. Note though that it
assumes the raw usr.img is an ISO image, not a UFS filesystem.
> 2) even with geom_uzip module and it's dependency zlib loaded, i don't
> get a mdconfig node '/dev/md?.uzip' to appear.
>
> It's been forever since I touched uzip, so I have to ask.
Do you have a md0 device at all? I think you want to hack the script to do
something like this:
disk=`mdconfig -af /path/to/usr.img`
mount -r /dev/$disk.uzip /usr
--
John Baldwin
------------------------------
Message: 4
Date: Thu, 1 Apr 2010 09:37:42 -0400
From: John Baldwin <j...@freebsd.org>
Subject: Re: Fwd: mkuzip and/or geom_uzip changes?
To: freebsd...@freebsd.org
Cc: Tim Judd <taj...@gmail.com>, sob...@freebsd.org
Message-ID: <20100401093...@freebsd.org>
Content-Type: Text/Plain; charset="iso-8859-15"
On Thursday 01 April 2010 8:38:38 am John Baldwin wrote:
> > 2) even with geom_uzip module and it's dependency zlib loaded, i don't
> > get a mdconfig node '/dev/md?.uzip' to appear.
> >
> > It's been forever since I touched uzip, so I have to ask.
>
> Do you have a md0 device at all? I think you want to hack the script to do
> something like this:
>
> disk=`mdconfig -af /path/to/usr.img`
> mount -r /dev/$disk.uzip /usr
To clarify, I would hack this into an /etc rc script, not in the script
embedded into the uzip image.
--
John Baldwin
------------------------------
Message: 5
Date: Thu, 1 Apr 2010 08:48:07 -0600
From: Tim Judd <taj...@gmail.com>
Subject: Re: Fwd: mkuzip and/or geom_uzip changes?
To: John Baldwin <j...@freebsd.org>
Cc: freebsd...@freebsd.org
Message-ID:
<v2iade45ae91004010748m7...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 4/1/10, John Baldwin <j...@freebsd.org> wrote:
> On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote:
>> Hi All,
>>
>> Just starting to see if I can find other reports. You all probably
>> have had the "more than one pair of eyes looking at a thing is better
>> than my eyes alone." This is why I'm writing now, as I'm starting the
>> discovery.
>>
>> Let me background this a little bit. I only started looking into this
>> because mkuzip and it's counterpart, geom_uzip are throwing errors on
>> FreeBSD8 i386
>>
>>
>> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with knobs):
>> make DESTDIR=/home/small8 installworld installkernel distribution
>> mv /home/small8/boot /home/small8-boot/
>> makefs -t ffs /home/small8/usr.img /home/small8/usr/
>> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img
>> [*]
>> chflags -R noschg /home/small8/usr/*
>> rm -rf /home/small8/usr/* /home/small8/usr.img
>> ee /home/small8/etc/rc.d/mountcritlocal
>> [**]
>> makefs -t ffs /home/small8-boot/mfsroot /home/small8/
>> gzip --best /home/small8-boot/mfsroot
>> ee /home/small8-boot/boot/loader.conf
>> [***]
>> rm /home/small8-boot/boot/kernel/*.symbols
>> gzip --best /home/small8-boot/boot/kernel/kernel
>> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot
>> -iso-level 4 -o /home/small8.iso /home/small8-boot/
>>
>>
>> [*]: mkuzip inserts a script header that is broken. module name it's
>> searching for may have been renamed?
>> [**]: Edited mountcritlocal to mount the usr.uzip file as by using the
>> above script header, throws errors
>> [***]: added zlib and geom_uzip modules to load to the boot image, to
>> satisfy the script header's requirements.
>>
>> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso.
>> Small enough to apparently fit into the undocumented 50 or 100MB size
>> limit of mfs_root module
>
> BTW, you can raise this limit by changing NKPT.
I'm sorry, I'm not sure what you're referring to when you are telling me this.
>
>> The problem:
>> mkuzip generates a few lines as a script in the head of the
>> resulting *.uzip file. Two problems...
>> 1) the module it queries for is geom_uzip (kldstat -m $m), but
>> FreeBSD8 names the geom_uzip module (i guess, internally) as g_uzip.
>> mkuzip's generated image will never find the module if they're not
>> named the same.
>
> It is g_uzip even in 7:
>
> DECLARE_GEOM_CLASS(g_uzip_class, g_uzip);
> MODULE_DEPEND(g_uzip, zlib, 1, 1, 1);
>
> This has probably just been broken from the start. If it used 'kldstat -n'
> then it might work. Well, it probably works (modulo a warning) by accident
> as
> it doesn't hurt to kldload an already-loaded module. Note though that it
> assumes the raw usr.img is an ISO image, not a UFS filesystem.
>
>> 2) even with geom_uzip module and it's dependency zlib loaded, i don't
>> get a mdconfig node '/dev/md?.uzip' to appear.
>>
>> It's been forever since I touched uzip, so I have to ask.
>
> Do you have a md0 device at all? I think you want to hack the script to do
> something like this:
I double check at home tonight, but I don't remember any additional md
devices, since I'm running from an MFS_ROOT, i get md0, but that's
all.
I definately do not get any /dev/md?.uzip files. No .uzips show up.
>
> disk=`mdconfig -af /path/to/usr.img`
> mount -r /dev/$disk.uzip /usr
>
> --
> John Baldwin
>
I noted it defaulted to cd9660 too. I hadn't gotten to debugging that
point, since I never get a devnode of .uzip
I'll follow up tonight.
------------------------------
Message: 6
Date: Thu, 1 Apr 2010 17:27:41 +0200 (CEST)
From: Oliver Fromme <ol...@lurza.secnetix.de>
Subject: Re: Compiling kernel with gcc43 [SOLVED]
To: freebsd...@FreeBSD.ORG, FreeBSD-...@FreeBSD.ORG,
lo...@bsd.com.br
Message-ID: <201004011527....@lurza.secnetix.de>
Content-Type: text/plain; charset=ISO-8859-1
Mario Lobo <lo...@bsd.com.br> wrote:
> [...]
> It's compiling right now.
>
> I'll post my findings and impressions on results and performance right after
> the next reboot.
So, how is it going? Any benchmarks yet? I'm curious
if the new gcc version will really make a significant
difference.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things."
-- Doug Gwyn
------------------------------
Message: 7
Date: Thu, 1 Apr 2010 16:53:36 +0000
From: Pegasus Mc Cleaft <k...@mthelicon.com>
Subject: Re: Compiling kernel with gcc43 [SOLVED]
To: freebsd...@freebsd.org, FreeBSD-...@freebsd.org,
lo...@bsd.com.br
Message-ID: <20100401165...@mthelicon.com>
Content-Type: Text/Plain; charset="iso-8859-1"
On Thursday 01 April 2010 15:27:41 Oliver Fromme wrote:
> Mario Lobo <lo...@bsd.com.br> wrote:
> > [...]
> > It's compiling right now.
> >
> > I'll post my findings and impressions on results and performance right
> > after the next reboot.
>
> So, how is it going? Any benchmarks yet? I'm curious
> if the new gcc version will really make a significant
> difference.
I would love to see the /etc/make.conf, /etc/src.conf and
/etc/libmap.conf files that were used for the build. I have tried compiling in
VBox a current kernel and world, but it usually just bombs out for me. I would
like to give this a go as well.
Peg
------------------------------
Message: 8
Date: Thu, 1 Apr 2010 13:04:38 -0400
From: John Baldwin <j...@freebsd.org>
Subject: Re: Fwd: mkuzip and/or geom_uzip changes?
To: Tim Judd <taj...@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID: <20100401130...@freebsd.org>
Content-Type: Text/Plain; charset="iso-8859-1"
On Thursday 01 April 2010 10:48:07 am Tim Judd wrote:
> On 4/1/10, John Baldwin <j...@freebsd.org> wrote:
> > On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote:
> >> Hi All,
> >>
> >> Just starting to see if I can find other reports. You all probably
> >> have had the "more than one pair of eyes looking at a thing is better
> >> than my eyes alone." This is why I'm writing now, as I'm starting the
> >> discovery.
> >>
> >> Let me background this a little bit. I only started looking into this
> >> because mkuzip and it's counterpart, geom_uzip are throwing errors on
> >> FreeBSD8 i386
> >>
> >>
> >> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with knobs):
> >> make DESTDIR=/home/small8 installworld installkernel distribution
> >> mv /home/small8/boot /home/small8-boot/
> >> makefs -t ffs /home/small8/usr.img /home/small8/usr/
> >> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img
> >> [*]
> >> chflags -R noschg /home/small8/usr/*
> >> rm -rf /home/small8/usr/* /home/small8/usr.img
> >> ee /home/small8/etc/rc.d/mountcritlocal
> >> [**]
> >> makefs -t ffs /home/small8-boot/mfsroot /home/small8/
> >> gzip --best /home/small8-boot/mfsroot
> >> ee /home/small8-boot/boot/loader.conf
> >> [***]
> >> rm /home/small8-boot/boot/kernel/*.symbols
> >> gzip --best /home/small8-boot/boot/kernel/kernel
> >> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot
> >> -iso-level 4 -o /home/small8.iso /home/small8-boot/
> >>
> >>
> >> [*]: mkuzip inserts a script header that is broken. module name it's
> >> searching for may have been renamed?
> >> [**]: Edited mountcritlocal to mount the usr.uzip file as by using the
> >> above script header, throws errors
> >> [***]: added zlib and geom_uzip modules to load to the boot image, to
> >> satisfy the script header's requirements.
> >>
> >> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso.
> >> Small enough to apparently fit into the undocumented 50 or 100MB size
> >> limit of mfs_root module
> >
> > BTW, you can raise this limit by changing NKPT.
>
>
> I'm sorry, I'm not sure what you're referring to when you are telling me this.
If you increase NKPT (look in /sys/i386/conf/NOTES on a recent stable) you
can use a larger mfs root.
> >> 2) even with geom_uzip module and it's dependency zlib loaded, i don't
> >> get a mdconfig node '/dev/md?.uzip' to appear.
> >>
> >> It's been forever since I touched uzip, so I have to ask.
> >
> > Do you have a md0 device at all? I think you want to hack the script to do
> > something like this:
>
> I double check at home tonight, but I don't remember any additional md
> devices, since I'm running from an MFS_ROOT, i get md0, but that's
> all.
>
> I definately do not get any /dev/md?.uzip files. No .uzips show up.
You will not get the uzip device until you create the md device via
mdconfig -af.
> > disk=`mdconfig -af /path/to/usr.img`
> > mount -r /dev/$disk.uzip /usr
That's why I think you need to add this to a script in /etc. You could
perhaps put the mount line in /etc/fstab, but you need to invoke mdconfig
to create md1. At that point you should get the md1.uzip device
automatically.
--
John Baldwin
------------------------------
Message: 9
Date: Thu, 1 Apr 2010 11:14:30 -0600
From: Tim Judd <taj...@gmail.com>
Subject: Re: Fwd: mkuzip and/or geom_uzip changes?
To: John Baldwin <j...@freebsd.org>
Cc: freebsd...@freebsd.org
Message-ID:
<m2zade45ae91004011014w2...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 4/1/10, John Baldwin <j...@freebsd.org> wrote:
> On Thursday 01 April 2010 10:48:07 am Tim Judd wrote:
>> On 4/1/10, John Baldwin <j...@freebsd.org> wrote:
>> > On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote:
>> >> Hi All,
>> >>
>> >> Just starting to see if I can find other reports. You all probably
>> >> have had the "more than one pair of eyes looking at a thing is better
>> >> than my eyes alone." This is why I'm writing now, as I'm starting the
>> >> discovery.
>> >>
>> >> Let me background this a little bit. I only started looking into this
>> >> because mkuzip and it's counterpart, geom_uzip are throwing errors on
>> >> FreeBSD8 i386
>> >>
>> >>
>> >> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with
>> >> knobs):
>> >> make DESTDIR=/home/small8 installworld installkernel distribution
>> >> mv /home/small8/boot /home/small8-boot/
>> >> makefs -t ffs /home/small8/usr.img /home/small8/usr/
>> >> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img
>> >> [*]
>> >> chflags -R noschg /home/small8/usr/*
>> >> rm -rf /home/small8/usr/* /home/small8/usr.img
>> >> ee /home/small8/etc/rc.d/mountcritlocal
>> >> [**]
>> >> makefs -t ffs /home/small8-boot/mfsroot /home/small8/
>> >> gzip --best /home/small8-boot/mfsroot
>> >> ee /home/small8-boot/boot/loader.conf
>> >> [***]
>> >> rm /home/small8-boot/boot/kernel/*.symbols
>> >> gzip --best /home/small8-boot/boot/kernel/kernel
>> >> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot
>> >> -iso-level 4 -o /home/small8.iso /home/small8-boot/
>> >>
>> >>
>> >> [*]: mkuzip inserts a script header that is broken. module name it's
>> >> searching for may have been renamed?
>> >> [**]: Edited mountcritlocal to mount the usr.uzip file as by using the
>> >> above script header, throws errors
>> >> [***]: added zlib and geom_uzip modules to load to the boot image, to
>> >> satisfy the script header's requirements.
>> >>
>> >> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso.
>> >> Small enough to apparently fit into the undocumented 50 or 100MB size
>> >> limit of mfs_root module
>> >
>> > BTW, you can raise this limit by changing NKPT.
>>
>>
>> I'm sorry, I'm not sure what you're referring to when you are telling me
>> this.
>
> If you increase NKPT (look in /sys/i386/conf/NOTES on a recent stable) you
> can use a larger mfs root.
>
>> >> 2) even with geom_uzip module and it's dependency zlib loaded, i don't
>> >> get a mdconfig node '/dev/md?.uzip' to appear.
>> >>
>> >> It's been forever since I touched uzip, so I have to ask.
>> >
>> > Do you have a md0 device at all? I think you want to hack the script to
>> > do
>> > something like this:
>>
>> I double check at home tonight, but I don't remember any additional md
>> devices, since I'm running from an MFS_ROOT, i get md0, but that's
>> all.
>>
>> I definately do not get any /dev/md?.uzip files. No .uzips show up.
>
> You will not get the uzip device until you create the md device via
> mdconfig -af.
And that was one of my troubleshooting attempts the other night.
Instead of relying on a (misdone) embedded script, I tried mdconfig
-at vnode -f; and a mdconfig -af;. If I recall, they create a md?
node, but not a md?.uzip node.
No joy, I have been trying to grep source files seeing what might be
the problem of creating the md?.uzip, but I still haven't found the
code that does it.
Can you duplicate the issue? I haven't gotten into trying to rebuild
world (without the src.conf exclusions). I might be able to attempt
that tonight.
Thanks for your time, Mr. Baldwin.
>
>> > disk=`mdconfig -af /path/to/usr.img`
>> > mount -r /dev/$disk.uzip /usr
>
> That's why I think you need to add this to a script in /etc. You could
> perhaps put the mount line in /etc/fstab, but you need to invoke mdconfig
> to create md1. At that point you should get the md1.uzip device
> automatically.
That above script wouldn't give a devnode /dev/md?.uzip. it's being
run manually at a single-user mode and it doesn't create the
/dev/md?.uzip node. I will be doing all this this evening when I get
home.
>
> --
> John Baldwin
>
------------------------------
Message: 10
Date: Thu, 1 Apr 2010 23:15:13 +0300
From: Vlad Galu <du...@dudu.ro>
Subject: Re: Compiling kernel with gcc43 [SOLVED]
To: freebsd...@freebsd.org, FreeBSD-...@freebsd.org
Message-ID:
<n2pad79ad6b1004011315uf...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 1, 2010 at 6:27 PM, Oliver Fromme <ol...@lurza.secnetix.de> wrote:
> Mario Lobo <lo...@bsd.com.br> wrote:
> > [...]
> > It's compiling right now.
> >
> > I'll post my findings and impressions on results and performance right after
> > the next reboot.
>
> So, how is it going? Any benchmarks yet? I'm curious
> if the new gcc version will really make a significant
> difference.
>
I'm not as worried about performance as I am about compatibilty.
Various software suites have started using newer GCCisms in their
code. One example I can give from the top of my head is Wt
(www.webtoolkit.eu), which compiles with 4.4, but not with 4.2. I
shamefully haven't dug any deeper to check which particular
syntactical construct offended 4.2.
Yes, one might say, after all it's the upstream developers who ought
to make sure their software compiles on FreeBSD, but some aditional
overhead on the shoulders of our port maintainers should be expected.
> Best regards
> Oliver
>
> --
> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
> Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
> secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
> chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
>
> FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
>
> "UNIX was not designed to stop you from doing stupid things,
> because that would also stop you from doing clever things."
> -- Doug Gwyn
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>
--
Good, fast & cheap. Pick any two.
------------------------------
Message: 11
Date: Thu, 1 Apr 2010 16:25:45 -0400
From: John Baldwin <j...@freebsd.org>
Subject: Re: Fwd: mkuzip and/or geom_uzip changes?
To: Tim Judd <taj...@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID: <20100401162...@freebsd.org>
Content-Type: Text/Plain; charset="iso-8859-1"
On Thursday 01 April 2010 1:14:30 pm Tim Judd wrote:
> On 4/1/10, John Baldwin <j...@freebsd.org> wrote:
> > On Thursday 01 April 2010 10:48:07 am Tim Judd wrote:
> >> On 4/1/10, John Baldwin <j...@freebsd.org> wrote:
> >> > On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote:
> >> >> Hi All,
> >> >>
> >> >> Just starting to see if I can find other reports. You all probably
> >> >> have had the "more than one pair of eyes looking at a thing is better
> >> >> than my eyes alone." This is why I'm writing now, as I'm starting the
> >> >> discovery.
> >> >>
> >> >> Let me background this a little bit. I only started looking into this
> >> >> because mkuzip and it's counterpart, geom_uzip are throwing errors on
> >> >> FreeBSD8 i386
> >> >>
> >> >>
> >> >> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with
> >> >> knobs):
> >> >> make DESTDIR=/home/small8 installworld installkernel distribution
> >> >> mv /home/small8/boot /home/small8-boot/
> >> >> makefs -t ffs /home/small8/usr.img /home/small8/usr/
> >> >> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img
> >> >> [*]
> >> >> chflags -R noschg /home/small8/usr/*
> >> >> rm -rf /home/small8/usr/* /home/small8/usr.img
> >> >> ee /home/small8/etc/rc.d/mountcritlocal
> >> >> [**]
> >> >> makefs -t ffs /home/small8-boot/mfsroot /home/small8/
> >> >> gzip --best /home/small8-boot/mfsroot
> >> >> ee /home/small8-boot/boot/loader.conf
> >> >> [***]
> >> >> rm /home/small8-boot/boot/kernel/*.symbols
> >> >> gzip --best /home/small8-boot/boot/kernel/kernel
> >> >> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot
> >> >> -iso-level 4 -o /home/small8.iso /home/small8-boot/
> >> >>
> >> >>
> >> >> [*]: mkuzip inserts a script header that is broken. module name it's
> >> >> searching for may have been renamed?
> >> >> [**]: Edited mountcritlocal to mount the usr.uzip file as by using the
> >> >> above script header, throws errors
> >> >> [***]: added zlib and geom_uzip modules to load to the boot image, to
> >> >> satisfy the script header's requirements.
> >> >>
> >> >> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso.
> >> >> Small enough to apparently fit into the undocumented 50 or 100MB size
> >> >> limit of mfs_root module
> >> >
> >> > BTW, you can raise this limit by changing NKPT.
> >>
> >>
> >> I'm sorry, I'm not sure what you're referring to when you are telling me
> >> this.
> >
> > If you increase NKPT (look in /sys/i386/conf/NOTES on a recent stable) you
> > can use a larger mfs root.
> >
> >> >> 2) even with geom_uzip module and it's dependency zlib loaded, i don't
> >> >> get a mdconfig node '/dev/md?.uzip' to appear.
> >> >>
> >> >> It's been forever since I touched uzip, so I have to ask.
> >> >
> >> > Do you have a md0 device at all? I think you want to hack the script
to
> >> > do
> >> > something like this:
> >>
> >> I double check at home tonight, but I don't remember any additional md
> >> devices, since I'm running from an MFS_ROOT, i get md0, but that's
> >> all.
> >>
> >> I definately do not get any /dev/md?.uzip files. No .uzips show up.
> >
> > You will not get the uzip device until you create the md device via
> > mdconfig -af.
>
> And that was one of my troubleshooting attempts the other night.
> Instead of relying on a (misdone) embedded script, I tried mdconfig
> -at vnode -f; and a mdconfig -af;. If I recall, they create a md?
> node, but not a md?.uzip node.
>
>
> No joy, I have been trying to grep source files seeing what might be
> the problem of creating the md?.uzip, but I still haven't found the
> code that does it.
Does it create a /dev/md1 device?
--
John Baldwin
------------------------------
Message: 12
Date: Thu, 01 Apr 2010 14:05:01 +0200
From: Dag-Erling Sm?rgrav <d...@des.no>
Subject: Re: Newbie question: kernel image a dynamically linked
binary?
To: gary.je...@freenet.de
Cc: freebsd...@freebsd.org, Daniel Rodrick
<daniel....@gmail.com>, freebsd...@freebsd.org,
freebs...@freebsd.org
Message-ID: <86y6h7s...@ds4.des.no>
Content-Type: text/plain; charset=utf-8
Dag-Erling Smørgrav <d...@des.no> writes:
> File is right. The kernel contains relocation entries so kernel modules
> can be linked against it.
"relocation entries" is possibly not the right term, someone with better
knowledge of ELF will have to correct me.
DES
--
Dag-Erling Smørgrav - d...@des.no
------------------------------
Message: 13
Date: Wed, 31 Mar 2010 14:18:38 +0200
From: Dag-Erling Sm?rgrav <d...@des.no>
Subject: Re: Dynamic ticks in FreeBSD
To: Tsuyoshi Ozawa <ozaw...@t-oza.net>
Cc: freebsd-hackers <freebsd...@freebsd.org>, Roman Divacky
<rdiv...@freebsd.org>, Julian Elischer <jul...@elischer.org>
Message-ID: <86iq8cs...@ds4.des.no>
Content-Type: text/plain; charset=utf-8
Tsuyoshi Ozawa <ozaw...@t-oza.net> writes:
> Julian Elischer <jul...@elischer.org> writes:
> > Who are you? and what have you done with DES?
> Sorry [...]
Never mind, Julian was making a joke at my expense.
DES
--
Dag-Erling Smørgrav - d...@des.no
------------------------------
Message: 14
Date: Thu, 01 Apr 2010 14:03:49 +0200
From: Dag-Erling Sm?rgrav <d...@des.no>
Subject: Re: Newbie question: kernel image a dynamically linked
binary?
To: gary.je...@freenet.de
Cc: freebsd...@freebsd.org, Daniel Rodrick
<daniel....@gmail.com>, freebsd...@freebsd.org,
freebs...@freebsd.org
Message-ID: <8639zft...@ds4.des.no>
Content-Type: text/plain; charset=utf-8
Gary Jennejohn <gary.je...@freenet.de> writes:
> Daniel Rodrick <daniel....@gmail.com> writes:
> > $ file kernel
> > kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),
> > dynamically linked (uses shared libs), not stripped
> file is confused. FreeBSD uses a monolithic kernel and no shared
> libraries are involved. However, it is possible to dynamically load
> modules using kldload. See the appropriate man page.
File is right. The kernel contains relocation entries so kernel modules
can be linked against it.
"monolithic" means something else entirely.
DES
--
Dag-Erling Smørgrav - d...@des.no
------------------------------
Message: 15
Date: Tue, 30 Mar 2010 21:15:32 +0200
From: Dag-Erling Sm?rgrav <d...@des.no>
Subject: Re: Dynamic ticks in FreeBSD
To: Julian Elischer <jul...@elischer.org>
Cc: Tsuyoshi Ozawa <ozaw...@t-oza.net>, freebsd-hackers
<freebsd...@freebsd.org>
Message-ID: <86bpe5m...@ds4.des.no>
Content-Type: text/plain; charset=utf-8
Julian Elischer <jul...@elischer.org> writes:
> Who are you? and what have you done with DES?
I gave him a week off...
DES
--
Dag-Erling Smørgrav - d...@des.no
------------------------------
Message: 16
Date: Thu, 1 Apr 2010 15:26:38 -0600
From: Tim Judd <taj...@gmail.com>
Subject: Re: Fwd: mkuzip and/or geom_uzip changes?
To: John Baldwin <j...@freebsd.org>
Cc: freebsd...@freebsd.org
Message-ID:
<v2hade45ae91004011426n3...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 4/1/10, John Baldwin <j...@freebsd.org> wrote:
> On Thursday 01 April 2010 1:14:30 pm Tim Judd wrote:
>> On 4/1/10, John Baldwin <j...@freebsd.org> wrote:
>> > On Thursday 01 April 2010 10:48:07 am Tim Judd wrote:
>> >> On 4/1/10, John Baldwin <j...@freebsd.org> wrote:
>> >> > On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote:
>> >> >> Hi All,
>> >> >>
>> >> >> Just starting to see if I can find other reports. You all probably
>> >> >> have had the "more than one pair of eyes looking at a thing is
>> >> >> better
>> >> >> than my eyes alone." This is why I'm writing now, as I'm starting
>> >> >> the
>> >> >> discovery.
>> >> >>
>> >> >> Let me background this a little bit. I only started looking into
>> >> >> this
>> >> >> because mkuzip and it's counterpart, geom_uzip are throwing errors
>> >> >> on
>> >> >> FreeBSD8 i386
>> >> >>
>> >> >>
>> >> >> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with
>> >> >> knobs):
>> >> >> make DESTDIR=/home/small8 installworld installkernel distribution
>> >> >> mv /home/small8/boot /home/small8-boot/
>> >> >> makefs -t ffs /home/small8/usr.img /home/small8/usr/
>> >> >> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img
>> >> >> [*]
>> >> >> chflags -R noschg /home/small8/usr/*
>> >> >> rm -rf /home/small8/usr/* /home/small8/usr.img
>> >> >> ee /home/small8/etc/rc.d/mountcritlocal
>> >> >> [**]
>> >> >> makefs -t ffs /home/small8-boot/mfsroot /home/small8/
>> >> >> gzip --best /home/small8-boot/mfsroot
>> >> >> ee /home/small8-boot/boot/loader.conf
>> >> >> [***]
>> >> >> rm /home/small8-boot/boot/kernel/*.symbols
>> >> >> gzip --best /home/small8-boot/boot/kernel/kernel
>> >> >> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot
>> >> >> -iso-level 4 -o /home/small8.iso /home/small8-boot/
>> >> >>
>> >> >>
>> >> >> [*]: mkuzip inserts a script header that is broken. module name
>> >> >> it's
>> >> >> searching for may have been renamed?
>> >> >> [**]: Edited mountcritlocal to mount the usr.uzip file as by using
>> >> >> the
>> >> >> above script header, throws errors
>> >> >> [***]: added zlib and geom_uzip modules to load to the boot image,
>> >> >> to
>> >> >> satisfy the script header's requirements.
>> >> >>
>> >> >> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB
>> >> >> iso.
>> >> >> Small enough to apparently fit into the undocumented 50 or 100MB
>> >> >> size
>> >> >> limit of mfs_root module
>> >> >
>> >> > BTW, you can raise this limit by changing NKPT.
>> >>
>> >>
>> >> I'm sorry, I'm not sure what you're referring to when you are telling
>> >> me
>> >> this.
>> >
>> > If you increase NKPT (look in /sys/i386/conf/NOTES on a recent stable)
>> > you
>> > can use a larger mfs root.
>> >
>> >> >> 2) even with geom_uzip module and it's dependency zlib loaded, i
>> >> >> don't
>> >> >> get a mdconfig node '/dev/md?.uzip' to appear.
>> >> >>
>> >> >> It's been forever since I touched uzip, so I have to ask.
>> >> >
>> >> > Do you have a md0 device at all? I think you want to hack the script
>> >> >
> to
>> >> > do
>> >> > something like this:
>> >>
>> >> I double check at home tonight, but I don't remember any additional md
>> >> devices, since I'm running from an MFS_ROOT, i get md0, but that's
>> >> all.
>> >>
>> >> I definately do not get any /dev/md?.uzip files. No .uzips show up.
>> >
>> > You will not get the uzip device until you create the md device via
>> > mdconfig -af.
>>
>> And that was one of my troubleshooting attempts the other night.
>> Instead of relying on a (misdone) embedded script, I tried mdconfig
>> -at vnode -f; and a mdconfig -af;. If I recall, they create a md?
>> node, but not a md?.uzip node.
>>
>>
>> No joy, I have been trying to grep source files seeing what might be
>> the problem of creating the md?.uzip, but I still haven't found the
>> code that does it.
>
> Does it create a /dev/md1 device?
If I remember, it does. I will be double checking these details
tonight. In about 2 hrs or so.
>
> --
> John Baldwin
>
------------------------------
Message: 17
Date: Thu, 1 Apr 2010 19:50:06 -0600
From: Tim Judd <taj...@gmail.com>
Subject: Re: Fwd: mkuzip and/or geom_uzip changes?
To: John Baldwin <j...@freebsd.org>
Cc: freebsd...@freebsd.org, sob...@freebsd.org
Message-ID:
<x2yade45ae91004011850lc...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 4/1/10, John Baldwin <j...@freebsd.org> wrote:
> On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote:
>> Hi All,
>>
>> Just starting to see if I can find other reports. You all probably
>> have had the "more than one pair of eyes looking at a thing is better
>> than my eyes alone." This is why I'm writing now, as I'm starting the
>> discovery.
>>
>> Let me background this a little bit. I only started looking into this
>> because mkuzip and it's counterpart, geom_uzip are throwing errors on
>> FreeBSD8 i386
>>
>>
>> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with knobs):
>> make DESTDIR=/home/small8 installworld installkernel distribution
>> mv /home/small8/boot /home/small8-boot/
>> makefs -t ffs /home/small8/usr.img /home/small8/usr/
>> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img
>> [*]
>> chflags -R noschg /home/small8/usr/*
>> rm -rf /home/small8/usr/* /home/small8/usr.img
>> ee /home/small8/etc/rc.d/mountcritlocal
>> [**]
>> makefs -t ffs /home/small8-boot/mfsroot /home/small8/
>> gzip --best /home/small8-boot/mfsroot
>> ee /home/small8-boot/boot/loader.conf
>> [***]
>> rm /home/small8-boot/boot/kernel/*.symbols
>> gzip --best /home/small8-boot/boot/kernel/kernel
>> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot
>> -iso-level 4 -o /home/small8.iso /home/small8-boot/
>>
>>
>> [*]: mkuzip inserts a script header that is broken. module name it's
>> searching for may have been renamed?
>> [**]: Edited mountcritlocal to mount the usr.uzip file as by using the
>> above script header, throws errors
>> [***]: added zlib and geom_uzip modules to load to the boot image, to
>> satisfy the script header's requirements.
>>
>> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso.
>> Small enough to apparently fit into the undocumented 50 or 100MB size
>> limit of mfs_root module
>
> BTW, you can raise this limit by changing NKPT.
>
>> The problem:
>> mkuzip generates a few lines as a script in the head of the
>> resulting *.uzip file. Two problems...
>> 1) the module it queries for is geom_uzip (kldstat -m $m), but
>> FreeBSD8 names the geom_uzip module (i guess, internally) as g_uzip.
>> mkuzip's generated image will never find the module if they're not
>> named the same.
>
> It is g_uzip even in 7:
>
> DECLARE_GEOM_CLASS(g_uzip_class, g_uzip);
> MODULE_DEPEND(g_uzip, zlib, 1, 1, 1);
>
> This has probably just been broken from the start. If it used 'kldstat -n'
> then it might work. Well, it probably works (modulo a warning) by accident
> as
> it doesn't hurt to kldload an already-loaded module. Note though that it
> assumes the raw usr.img is an ISO image, not a UFS filesystem.
>
>> 2) even with geom_uzip module and it's dependency zlib loaded, i don't
>> get a mdconfig node '/dev/md?.uzip' to appear.
>>
>> It's been forever since I touched uzip, so I have to ask.
>
> Do you have a md0 device at all? I think you want to hack the script to do
> something like this:
>
> disk=`mdconfig -af /path/to/usr.img`
> mount -r /dev/$disk.uzip /usr
>
> --
> John Baldwin
>
booted single-user
md0 is the mfs_root
here is the manual attachment of an mdconfig...
# mdconfig -af /usr.uzip
WARNING: opening backing store: /usr.uzip readonly
md1.uzip: block size (24) should be a multiple of 512.
md1
# ls /dev/md1*
/dev/md1
#
------------------------------
Message: 18
Date: Thu, 1 Apr 2010 19:52:34 -0600
From: Tim Judd <taj...@gmail.com>
Subject: Re: Fwd: mkuzip and/or geom_uzip changes?
To: John Baldwin <j...@freebsd.org>
Cc: freebsd...@freebsd.org
Message-ID:
<p2vade45ae91004011852g5...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 4/1/10, Tim Judd <taj...@gmail.com> wrote:
> On 4/1/10, John Baldwin <j...@freebsd.org> wrote:
>> On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote:
>>> Hi All,
>>>
>>> Just starting to see if I can find other reports. You all probably
>>> have had the "more than one pair of eyes looking at a thing is better
>>> than my eyes alone." This is why I'm writing now, as I'm starting the
>>> discovery.
>>>
>>> Let me background this a little bit. I only started looking into this
>>> because mkuzip and it's counterpart, geom_uzip are throwing errors on
>>> FreeBSD8 i386
>>>
>>>
>>> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with knobs):
>>> make DESTDIR=/home/small8 installworld installkernel distribution
>>> mv /home/small8/boot /home/small8-boot/
>>> makefs -t ffs /home/small8/usr.img /home/small8/usr/
>>> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img
>>> [*]
>>> chflags -R noschg /home/small8/usr/*
>>> rm -rf /home/small8/usr/* /home/small8/usr.img
>>> ee /home/small8/etc/rc.d/mountcritlocal
>>> [**]
>>> makefs -t ffs /home/small8-boot/mfsroot /home/small8/
>>> gzip --best /home/small8-boot/mfsroot
>>> ee /home/small8-boot/boot/loader.conf
>>> [***]
>>> rm /home/small8-boot/boot/kernel/*.symbols
>>> gzip --best /home/small8-boot/boot/kernel/kernel
>>> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot
>>> -iso-level 4 -o /home/small8.iso /home/small8-boot/
>>>
>>>
>>> [*]: mkuzip inserts a script header that is broken. module name it's
>>> searching for may have been renamed?
>>> [**]: Edited mountcritlocal to mount the usr.uzip file as by using the
>>> above script header, throws errors
>>> [***]: added zlib and geom_uzip modules to load to the boot image, to
>>> satisfy the script header's requirements.
>>>
>>> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso.
>>> Small enough to apparently fit into the undocumented 50 or 100MB size
>>> limit of mfs_root module
>>
>> BTW, you can raise this limit by changing NKPT.
>>
>>> The problem:
>>> mkuzip generates a few lines as a script in the head of the
>>> resulting *.uzip file. Two problems...
>>> 1) the module it queries for is geom_uzip (kldstat -m $m), but
>>> FreeBSD8 names the geom_uzip module (i guess, internally) as g_uzip.
>>> mkuzip's generated image will never find the module if they're not
>>> named the same.
>>
>> It is g_uzip even in 7:
>>
>> DECLARE_GEOM_CLASS(g_uzip_class, g_uzip);
>> MODULE_DEPEND(g_uzip, zlib, 1, 1, 1);
>>
>> This has probably just been broken from the start. If it used 'kldstat
>> -n'
>> then it might work. Well, it probably works (modulo a warning) by
>> accident
>> as
>> it doesn't hurt to kldload an already-loaded module. Note though that it
>> assumes the raw usr.img is an ISO image, not a UFS filesystem.
>>
>>> 2) even with geom_uzip module and it's dependency zlib loaded, i don't
>>> get a mdconfig node '/dev/md?.uzip' to appear.
>>>
>>> It's been forever since I touched uzip, so I have to ask.
>>
>> Do you have a md0 device at all? I think you want to hack the script to
>> do
>> something like this:
>>
>> disk=`mdconfig -af /path/to/usr.img`
>> mount -r /dev/$disk.uzip /usr
>>
>> --
>> John Baldwin
>>
>
>
>
> booted single-user
> md0 is the mfs_root
>
> here is the manual attachment of an mdconfig...
> # mdconfig -af /usr.uzip
> WARNING: opening backing store: /usr.uzip readonly
> md1.uzip: block size (24) should be a multiple of 512.
> md1
> # ls /dev/md1*
> /dev/md1
> #
>
Forgot the kldstat, which was obviously omitted
# kldstat
Id Refs Address Size Name
1 5 0xc0400000 b6e060 kernel
2 1 0xc0f6f000 3ffc geom_uzip.ko
3 2 -xc0f73000 ac20 zlib.ko
------------------------------
End of freebsd-hackers Digest, Vol 366, Issue 5
***********************************************