matusita> super-block backups (for fsck -b #) at:
matusita> <<>>
matusita> Yes, during a newfs. Console shows following messages:
Maybe I'm wrong. Attached "ps" output says no 'newfs' is running but "cp".
So, copying "mfsroot.gz" to a directory of floppy image causes kernel hungup...
jhay> It looks like I spoke too soon. My 2000-10-05 kernel that previously
jhay> worked also now panics. It must be somewhere when the floppies are
jhay> made.
Maybe there is a problem in newfs(8).
peter 2000/10/16 17:41:37 PDT
Modified files:
sbin/newfs mkfs.c
Log:
I
matusita> When I backout this change, the problem seems disappeared...
This is sample shell script to reproduce recent kernel hungup:
#!/bin/sh
dd of=/tmp/image if=/dev/zero count=1440 bs=1k
awk 'BEGIN {printf "%c%c", 85, 170}' | \
dd of=/tmp/image obs=1 seek=510 conv=notrunc
vnconfig -s la
> I also wonder if this is related to the 'make release' problems.
During "make release", src/release/Makefile does create floppies for
installation. Copying 'mfsroot.gz' (mfsroot imagefile) to a newly
newfs-ed floppy image (mfsroot.flp, 1.44MB size) causes kernel hungup.
-- -
Makoto `MAR' MATS
leifn> My hangs at loading ldconf. I can continue with ^C.
Are you using MFS ? I suppose you are not.
I've found that:
- if /etc/fstab has 'mfs' line, system stops during mounting
filesystem. Interrupting with CTRL-C works (and system goes to
single user mode).
- if /etc/fstab does not ha
jwd> 5. At this time, remove ALL MFS filesystems from /etc/fstab.
jwd>They can be hand mounted after bootup or via a local rc
jwd>startup script.
Is there any chance to mount MFS filesystem listed in /etc/fstab just
after the /dev/random reseeding is done ? I cannot put up with that we
c
Maybe kernel image for kern.flp is a little bit larger than a 1.44MB floppy.
***
linking BOOTMFS
textdata bss dec hex filename
2613503 196388 130744 2940635 2cdedb BOOTMFS
install -c -m 555 -o root -g wheel -fschg BOOTMFS /R/stage/kernels
mv /R/stage/kernels/BOOTMFS /R/st
jwd> Also, I don't know how useful INET6 is to a GENERIC kernel on
jwd> todays' networks (faith & gif are already removed).
It is mandatory for FreeBSD installation via IPv6 network (via network
devices; using gif(4) pseudo interface is a rare case, so it should be
removed). Please keep INET6 o
will> I'm sure there are better things to disable, like MFS, SYSV*,
will> P1003_P1B and friends, and ICMP_BANDLIM.
MFS is required; don't forget we have mfsroot.flp :-)
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body o
will> I'm sure there are better things to disable,
How about removing /boot/boot[12] from floppies ?
--- src/release/Makefile.oldMon Oct 23 23:53:50 2000
+++ src/release/MakefileTue Oct 24 22:38:15 2000
@@ -821,7 +821,7 @@
mv ${RD}/kernels/BOOTMFS ${RD}/image.${FSIMAGE}/ker
msmith> The name is historical; we use md(4) not MFS.
I should read md(4) manpage... sorry.
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
obrien> I just diked out more bits. Lets see if that will give us
obrien> enough space on tonights snapshot build.
Whole release procedures are works fine. Thank you. Here's summary of
current size of floppies (i386 architecture):
* boot.flp (639k left)
Filesystem 1K-blocks UsedAvail
hosokawa> Maybe it's current.jp.freebsd.org's problem
I don't think so. It's a mismatch that all object files are created
under /usr/src/modules but make install assumes that these are under
(maybe) /usr/obj. Maybe it's a fault of some Makefiles (sorry I dunno
who change the policy of module co
hosokawa> Last night, I tested "make release" on my machine, and
hosokawa> failed twice because of unloaded vn driver (this causes last
hosokawa> trouble). It successfly finished this morning. I'm Sorry.
'vn' device is a great pitfall of "make release" :-)
hosokawa> I understood the situation
matusita> However, this problem (use /usr/src/sys/modules for compilation) is
matusita> disappeared already according to the logfile of Nov/02/2000.
Hmm, sorry, it is not yet fixed.
cd ../../modules && env MAKEOBJDIRPREFIX=/usr/src/sys/compile/BOOTMFS/modules KMODIR=
make obj all
===> 3dfx
===
Forget to note:
matusita> Warning: Object directory not changed from original /usr/src/sys/modules/3dfx
dinosaur % pwd
${CHROOT_DIRECTORY_FOR_CURRENT}/usr/src/sys/modules
dinosaur % ls */*.o
3dfx/setdef0.o 3dfx/setdef1.o 3dfx/tdfx_pci.o
Only 3dfx module uses /usr/src/sys/modules for compilat
matusita> I've found that current src/sys/modules/linux for RELENG_4
matusita> is not 'make -j' safe. It maybe causes a problem if you want
matusita> to make a module.
Long time has past and, but problem is still there.
OK, we all FreeBSD users should forget the fact that there is an
option '-j
dcs> Err, we have been supporting -j for kernel building for a LONG
dcs> time. The "depend" and "install" targets did not support it, but
dcs> support on the "all" target is about as old as support on the
dcs> "buildworld" target.
AFAIK, that's right.
Obrien, please check src/release/Makeefile
(Strip down To: address, maybe it's only -current problem so I send
this email to [EMAIL PROTECTED] also. Set appropriate Subject:. -- MAR)
marcel> Makoto-san mentioned there's a problem with 3dfx. Is this
marcel> still the case or has it been resolved?
Unfortunately, no. It seems that nobody u
marcel> The net effect is that these targets are built in parallel,
marcel> which obviously isn't right.
Agreed. If there is no reason to do "make obj all" (specify both 'obj'
and 'all' target at once), it's maybe a better solution.
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [E
bde> (In the above example, the targets are built concurrently and race
bde> each other. This is bad when the `all' target wins the race. The
bde> `obj' target runs faster, so it usually wins the race except in the
bde> first directory (3dfx)). More .ORDER statements in *.mk are required.
Tha
marcel> No you can't. $S expands to "../.." which only works for the
marcel> first cd in the -jX case. The second cd will fail.
Ouch... give me one more chance to submit a patch. Here's summary:
* src/release/Makefile should use 'module-depend' while
checking dependancy of mod
obrien> [its easier to read patches when they aren't quoted in their entirety ;-)]
Attached below is a patch which I've made before. If nothing is going
wrong, please commit this change current.jp.FreeBSD.org which
employs 'make -j' option have missed -current release since the
beginning of
(forward to stable/current also, to open this problem widely)
matusita> * CHECKSUM.MD5 is still broken. It also affected to 4.1.1-RELEASE
I cannot believe that this problem is still there, and CHECKSUM.MD5s
of 4.2-RELEASE/{src,crypto} are also broken.
However, it's easy to fix just like this (
Recently, we have a module of 'lnc' ethernet. Maybe it's the last
ethernet driver converted to newbus framework IIRC. Very thank you.
However, this kernel module is named as 'lnc.ko'. Other ethernet
driver modules are named as 'if_XXX.ko'; why lnc doesn't obey this
name convension? Typo, or a ne
imp> Typo, I think. The module needs to be named if_XXX.ko for the
imp> automatic kldload in ifconfig to work.
OK, attached below is a (trivial) patch to fix this.
-- -
Makoto `MAR' MATSUSHITA
Index: Makefile
===
RCS file: /lab/F
imp> This is a good start at a fix. However, all the attachments for the
imp> lnc device also need to be called if_lnc. And they need to share the
imp> same devclass_t so that unit numbers don't go wonky on you (eg, if you
imp> have a isa and a pci lnc card in the same system, you might get two
few weeks before.
Can we temporary disable these devices from src/sys/i386/conf/NOTES ?
-- -
Makoto MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
bde> No. This would defeat the main points of NOTES, which are to
bde> test everything and generate mail for people who break something.
Ah, sorry. I just forget why we have NOTES.
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current"
Just a note.
phk> March 1st I will remove the functionality from mount_mfs and
phk> vnconfig, leaving only the message which will be an error obviously.
Before March 1st, src/release/Makefile, src/release/scripts/doFS.sh,
src/release/texts/FLOPPIES.TXT, and some PicoBSD stuffs need some work
to
src/release/scripts/doFS.sh rev. 1.6 doesn't consider MDDEVICE variable
(formaly, VNDEVICE). Here is a sample fix to use MDDEVICE variable to
configure md -- trivial, add '-u' option if MDDEVICE is already defined.
-- -
Makoto `MAR' MATSUSHITA
Index: doFS.sh
many md devices can we configure at the same time? What's
happen if a file of md's backing store is removed?
-- -
Makoto MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Oops, sorry that From: address was different from the first email...
jhb> Instead, it shouldn't be hard to get a list of configured devices
jhb> out of mdconfig via an ioctl on /dev/mdctl. This would be the
jhb> right fix, as it would fix the general case problem you describe,
jhb> not just one
I've found that current 5-current is broken, since krb5 cannot compile.
Here is a typical compiler message:
In file included from
/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/krb5/krb5_locl.h:142,
from
/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/li
grog> I'll think out another way and test more thoroughly. How does this
grog> look?
g...@itga.com.au already pointed out that "vinum read" command in such
an early stage of /etc/rc causes much much warnings about /dev/ is
read-only filesystem. And, a typo around reading from /etc/vinumslices
(I
scrappy> I found the release man page this evening, after more searching, and
scrappy> understand from it that a simple:
>From release(7):
floppies Generate a new set of boot floppies. This will call the
release.5, release.9, and release.10 targets to re-generate
I'd like to commit following patch to src/release/Makefile. Here's
background:
A user may want to build their own FreeBSD distribution. During the
release build, pkg_add(1) runs within chroot sandbox to install
mkisofs(8) iff MAKE_ISOS=YES. Imagine what's happen if the user is
living behind th
I've tried to do "make release" of FreeBSD/alpha on FreeBSD/i386 box
last night, and found that follow error while generating drivers.flp:
+ export BLOCKSIZE=512
+ [ /R/stage/floppies/drivers.flp = -s ]
+ do_size=
+ FSIMG=/R/stage/floppies/drivers.flp
+ shift
+ RD=/R/stage
+ shift
+ MNT=/mnt
+ sh
phk> Not yet. I think adding a "-m architecture" flag to disklabel is the
phk> way around this problem, but have not had time to do so.
Thanks, I'm waiting until you have enough time to do since I have
little knowledge about this issue:)
BTW, what's changes do you imagine? Make a table which h
It seems that our kenrel for kern.flp does not fit again :-(
(Quote from "make release" logfile)
+ mdconfig -a -t vnode -f /R/stage/floppies/kern.flp
+ MDDEVICE=md1
+ [ ! -c /dev/md1 ]
+ disklabel -w -B -b /R/stage/trees/base/boot/boot md1 fd1440
+ newfs -i 8 -o space -m 0 /dev/md1c
fstab: /e
Ouch..
matusita> % gzip loader
I've forgotten that this loader is already kgzip(8)ed, ignore me. Sorry.
Ok, we have to shrink at least 7kbytes of kernel on kern.flp.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of
Sorry for spamming again.
matusita> Ok, we have to shrink at least 7kbytes of kernel on kern.flp.
If you are serious about this, attached below is a current kernel
configuration file for kern.flp kernel named BOOTMFS (attention: it is
only just for boot floppy, not GENERIC nor default installed
riccardo> Is this stuff really needed on a boot floppy? Maybe we can leave
riccardo> only I486_CPU? What about removing also device eisa and/or bpf?
riccardo> (I'm just curious, don't expect to be an expert :-)
The bpf is required for DHCP client. We cannot remove it, or cannot
network instal
ticso> What about some uncommon ISA scsi controllers like stg and ncv?
ticso> Both are available as a module.
Maybe it's ok, do you know whether stg/ncv kernel modules work as they
should be?
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-c
We (at least, I) don't know exactly that which options and/or drivers
can be picked out from the kernel for kern.flp... maybe it's chance to
find out all of them.
jhay> What about moving the slip driver (sl) to the drivers floppy? I know its
jhay> not much, but it is enough to make things fit on
> Maybe it's ok, do you know whether stg/ncv kernel modules work as they
> should be?
ticso> No - I just can say that they got build on my system.
ticso> I can't test either, because I don't have such cards.
Ah, ok, thank you. Anybody in this list knows?
-- -
Makoto `MAR' Matsushita
To Unsubs
keramida> Just in case anyone tries to build today's current and sees
keramida> it fail because of boot2, you can always set BOOT2_UFS=UFS1_ONLY
keramida> or BOOT2_UFS=UFS2_ONLY in your make.conf and rebuild.
It should work, but it can't be used for a release distribution:)
-- -
Makoto `MAR' Mat
kuku> Can this be switched off with a single switch in the Makefile?
No, or you misunderstand what FreeBSD-current is.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
drosih> GENERIC +VMWARE-friendly settings
It'll be unneeded for further VMware releases. At least, very recent
5-current runs quite fine on my VMware 4 beta.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the m
asmodai> You cannot set the root password as passwd dumps core on a signal 12.
% pwd
/usr/src
% echo **/*(.)|xargs grep 'You cannot set the root password'
%
It should not be an message of passwd(1) or other sources, so it would
be hard to reproduce (if we can) what you've seen.
What you've tri
toha> Release build fails:
toha> drivers.flp: file system if full.
Since yesterday.
toha> Can somebody remove some driver from drivers.conf?
No, don't do that. Since we have only 3 floppies, simply removing
some modules may mean "it cannot use it while installing FreeBSD."
Fortunately w
I'd like to try to bulid FreeBSD/sparc64 on i386 box, but due to the
lack of bsdlabel(8)'s '-m' option (set machine archtecture) on
sunlabel(8), newfs(8) cannot work.
Question: Anybody working on teaching '-m' option to sunlabel(8)?
-- -
Makoto `MAR' Matsushita
__
Self followup...
matusita> I'd like to try to bulid FreeBSD/sparc64 on i386 box, but
matusita> due to the lack of bsdlabel(8)'s '-m' option (set machine
matusita> archtecture) on sunlabel(8), newfs(8) cannot work.
I'm confused something. The fact that newfs(8) on i386 cannot newfs a
filesystem
brooks> I don't think you can because our UFS on disk format is byte
brooks> order dependent. Someone probalby needs to import the NetBSD
brooks> endien-independence stuff.
My friends told me that I can do with a help of geom_sunlabel, and
it's right.
-- -
Makoto `MAR' Matsushita
__
Just FYI for people who run FreeBSD on VMware 4:
Several days before, VMware releases new beta version of VMware
Workstation 4 (actually 4.1 beta), bulid-6568, to alpha testers
including myself.
I've fetched Windows host version, runs on my PC, start my FreeBSD
5-current guest, and found that fi
I can remember that somebody already reports somewhere, but this
bug(?) is still standing there, so here's again:
I failed to install recent 5-current (5.2-BETA as of Nov/29/2003) to VMware
Workstation 4.x (tested with 4.0.5 and 4.1 beta). I've observed that:
* It seems that FreeBSD misundersta
It seems that kern.flp for FreeBSD/alpha is flooded (tested on FreeBSD/i386).
Maybe several kbytes should be removed from the kernel:
% du -s image.kern
1420image.kern
% ls -lR image.kern
total 1209
drwxr-xr-x 2 root wheel 512 Mar 28 00:57 boot
-r-xr-xr-x 1 root wheel 1223388 Mar 28
jmallett> Anyone with insight into this?
"Me Too" with zsh 4.0.6 on 5-current as of early June/2003.
-- -
Makoto `MAR' Matsushita
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail
gmh003532> the fix is (yet again) to rebuild sed.
Is this mean that src/usr.bin/sed should be a build-tool?
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Alex.Wilkinson> Is it because no one has got a working world/kernel
Alex.Wilkinson> for -CURRENT since March 2002 that a newer SNAPSHOT
Alex.Wilkinson> has not been made ?
I don't know it works or not (sorry), latest 5-current FreeBSD/alpha is
available at ftp://snapshots.jp.FreeBSD.org/pub/F
mark> /usr/sbin/sysinstall * - fix - *
What should we do about sysinstall and perl5 package? Options for the
solution may include:
1) Install perl5 package also if 'base' distribution is selected.
pros: Nobody forget to install perl5 package. /usr/bin/perl
should w
chuckr> Ohhhkay. The .jp site I found stopped making snaps on 6/21.
Mainly because kern.flp was flood. Any tiny breakages refuse to make
a distribution.
chuckr> Manfred Antar told me about ftp.kddlabs.co.jp, which is the
chuckr> "good" site.
It mirrors snapshots.jp.FreeBSD.org daily, if my l
ru> This was "broken" again. I don't have any ideas of what to move
ru> out.
There are some ideas to do around boot floppies in my mind:
1) More drivers to move kernel modules, including other network
drivers, pccard and friends, filesystems, etc. Apparantly it
reduces kernel size so ke
jhay> nfsclient.ko and msdosfs.ko exists nowadays, so in theory it can
jhay> reside somewhere else.
It seems that it's time to make the 3rd floppy for kernel modules...
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of
brooks> It does work though.
It should work, but I wonder if 5-current kernel can mount CD-ROM as
the root filesystem. I've tried before (March/2002 or something), but
it doesn't work, kernel refused to mount CD-ROM (see email archive for
more detail). Sorry if it was already fixed.
-- -
Mako
mb> The situation is very unpleasant.
IIRC, we have no active GCC maintainer, no matter you feel unpleasant or not...
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
jhay> md5 died on zero length files. You will have to upgrade the machine or
jhay> at least do a buildworld with new source before you try a release again.
Ya, that's exactly the problem on my buildbox... Thank you for the info.
But if new md5(1) doesn't used by during a release, it's yet anot
elitetek> boot -c on DP1, and the latest snapshots doesnt seem to do
elitetek> anything, I have been unable to find any info regarding a
elitetek> change to the command or what other switches it supports.
Userconfig was gone away in 5-current. Tweak /boot/device.hints
instead, or set appropriat
kuku> So there is no more /kernel file?
Yes.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
culverk> This seems a lot like personal preferance to me, I for one
culverk> don't like a lot of tty's, because running getty on a bunch
culverk> of ttys that I'm not going to use is a waste of ram
Seconded. Two ttys are enough for me. Many getty(8) processes usually
waste our process table
attila> If it reaches this far, both the 'livetree' and 'obj'
attila> trees would be available.
Good idea, I'll try it later.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
tlambert2> That's 3.4 hours saved on a 28.8K modem download time,
tlambert2> overall... a 14% reduction in size.
The percentage doesn't matter. If ISO image is compressed, user who
downloads the image may de-compress that image to burn (I don't know
any about the burner softwares which support
tlambert2> fetch -o - URL | gunzip > unzipped_image
You fully forgot that all users use FreeBSD.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
carl> 3.4 hours is a lot of time on a dial-up connection (granted it
carl> is not a one size fits all period of time).
You forget that you still compressed image with about 30 hours (at
least, full 1 day or more), and it is not helpful for ordinal users,
not you.
Again, reducing hours/percentag
carl> I fail to see how a reduction of hours (even just one) is
carl> insignificant to someone on a dial-up connection. Time is money
carl> for some people; even a meager three hours.
Don't you think "30+ hours of time to fetch an ISO image" is _not_
wasting of money?
carl> Again, I fail to se
After upgrading my 5-current box (as of late September 2002), the
kernel panics periodically with following message:
panic: kmem_malloc(4096): kmem_map too small: 107651072 total allocated
The number '4096' and '107651072' is always the same. What am I
missing something?
-- -
Makoto `MAR'
I'm now trying Terry's patch (just rebuilding a kernel).
jroberson> You are using 100mb of KVA for malloc(9)? Are you certain
jroberson> that you don't have a memory leak?
Maybe there's a chance of a memory leakage by GLOBAL, but I don't sure.
jroberson> How much memory is in this machine? W
tlambert2> This was recently discussed on -current. I posted a dumb
tlambert2> patch that "fixes" the problem.
(stuff deleted)
tlambert2> See the archive of the posting, for more details:
Thank you, I'll try it right now.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTEC
matusita> Thank you, I'll try it right now.
Unfortunately, kernel panics soon after it wakes up... maybe I've
still missed something.
-- -
Makoto `MAR' Matsushita
Booting [/boot/kernel/kernel]...
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 199
jroberson> I suspect that there is some other bug then. 1/2 of your
jroberson> memory should not be consumed by kernel malloc. Do you
jroberson> have an abnormally large MD or something?
MD devices are used to create installation floppies but no, it should
be 1.44MB/2.88MB size, relatively sma
tlambert2> The worst case failure with my "Ugly patch" should be that
tlambert2> things hang, and quit running completey.
I've emailed to the list that I've tried your patch but it cannot boot
(actually it boots, but panics immediately.) Maybe I'm using
different time of source code. Which 5-c
jwd> A new 5.0-20021025-CURRENT snapshot is available
jwd> via anonymous ftp at usw2.freebsd.org:
Wonderful! Is it a time to switch back 'current.FreeBSD.org' name to
that machine?
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in
attila> only problem with snapshot.jp at this point is that
attila> release does not build: md0 problems
That should be a local problem IMO, and I believe it was fixed several
hours before (ya, sorry for being lazy.)
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROT
jwd>The iso(s) boot correctly and sysinstall works fine. The disks
jwd> are formated and newfs'd correctly. However, when sysinstall
jwd> tries to mount the cdrom, the following error is received:
jwd> Error mounting /dev/acd0c on /dist: Operation not supported by device (19).
Which type of
Current 5-current fails 'make release' when processing release.4
target (making a crunch binary). Here's sample session:
===> doc
rm -f cpio.info cpio.info.gz
rm -f .depend /usr/obj/usr/src/gnu/usr.bin/cpio/GPATH
/usr/obj/usr/src/gnu/usr.bin/cpio/GRTAGS
/
Ouch.
matusita> src/sbin/dhclient/Makefile doesn't know 'dhclient_clean' target.
Of course that's normal, dhclient_clean target should be created by crunchgen.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the mes
null> After the cvs checkout completes:
Ah, big sorry... I just fixed in src/release/Makefile rev 1.658.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
matusita> Current 5-current fails 'make release' when processing release.4
matusita> target (making a crunch binary). Here's sample session:
matusita> ===> doc
matusita> rm -f cpio.info cpio.info.gz
matusita> rm -f .depend /usr/obj/usr/src/gnu/usr.bin/cpio/GPATH
matusita>
murray> I'm currently looking into #2 and #3, as well as working with Ted
murray> Lemon from the ISC to fix some symbol pollution that this whole mess
murray> has exposed. Any other ideas?
Currently nothing, it seems that #3 (or its variant) is better IMHO.
-- -
Makoto `MAR' Matsushita
To Uns
gnn> They're needed for the tags: target in the kernel makefiles and
gnn> since I'd like to be able to browse code...
Feel free to check http://snapshots.jp.FreeBSD.org/tour/>. Both
5-current and 4-stable code are HTMLed with GLOBAL daily.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mai
julian> It might be an idea if the kernel were kept separate because
julian> I find that the cross-reference is good but having kernel and userspace
julian> mixed up is a bit confusing..
Hmm, maybe it's a good idea about userland/kernel separation. I'll
try it later (maybe this evening or this
julian> It might be an idea if the kernel were kept separate because I
julian> find that the cross-reference is good but having kernel and
julian> userspace mixed up is a bit confusing..
Ok, I've separated the tour into 'kernel' part and 'userland' part
(5-current kernel is now processing).
Tou
jstocker> kldxref /boot/kernel
jstocker> kldxref:No such file or directory
jstocker> *** Error code 1 (ignored)
See the message "(ignored)". It is the intentional behavior.
If you don't like this, make NO_XREF=YES installkernel will help you.
Check src/sys/conf/kmod.mk for more details.
-- -
rwatson> Certainly we can MFC eaccess(), but that's not going to make
rwatson> the problem go away. Fundamentally our model is backward
rwatson> compatibility, not forward compatibility. We need to build
rwatson> 5.0 packages on 5.0.
That's why I build FreeBSD 5-current snapshots on a 5-curren
rwatson> It seems to me the kernel entry point should be mi_start()
rwatson> rather than main(), however.
Good point. I just did a small hack to do that:
http://snapshots.jp.freebsd.org/tour/current/kernel/>
4-stable kernel tour will be changed also tomorrow.
-- -
Makoto `MAR' Matsushita
To
never> Maybe it's better to make two different ports vmware-tools and
never> vmware-tools3, first of which is for vmware2?
Ancient ports/emulators/vmware-tools (FreeBSD native vmware-tools for
VMware _1.x_) is outdated for VMware 2.x; it doesn't have time sync
feature.
If you're VMware 2.x user
wosch> there are no up to date current snapshots available.
Yes, current 5-current's fixit.flp is flooded. I have an idea how to
fix it (see current@), but sorry I have no time to check that my idea
is good or bad...
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
jhay> I'm building the fixit floppy without a populated /dev. That leaves
jhay> enough space open to fit all the rest of the stuff and it shouldn't
jhay> be needed on -current because of devfs. But I haven't tried it. :-)
That is all I want to check it ASAP :-)
-- -
Makoto `MAR' Matsushita
To
matusita> But I don't checked that we can safely remove /dev/* files from
matusita> fixit.flp (sorry, if no one try to do, I'll do it later).
I've confirmed that it makes no problem, so commit it. We get about
40kbytes of free fixit.flp space again.
-- -
Makoto `MAR' Matsushita
To Unsubscribe
'BTX halted' on floppy boot is still a problem on 5-current. Nobody
can install latest 5-current (not 5.0-DP1 :-) to a fresh PC at this time.
debolaz> Well, here's a dump from me too, it's
debolaz> 5.0-CURRENT-20020313-JPSNAP, the first snap from
debolaz> snapshots.jp.freebsd.org which has the
101 - 200 of 218 matches
Mail list logo
