As Konstantin Belousov wrote:
Yes, I think that r238603 missed an update to etc/mtree/BSD.usr.dist.
Oops, thanks, fixed!
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't
As Kevin Oberman wrote:
Can you suspend from within graphics mode?
Have you tried using APMD to put the display into text mode when
suspending?
Tried it, but didn't get that to work. I. e., it seems apmd never
calls /etc/rc.suspend (i can't see any syslog entry from that logger
call
Matthew N. Dodd [EMAIL PROTECTED] wrote:
My only outstanding issue is that I can't suspend if an application
is holding /dev/dsp or /dev/audio open.
Can you suspend from within graphics mode? I can't seem to do that,
neither with APM nor with ACPI. In some case, i've seen four
horizontal
Darren Pilgrim [EMAIL PROTECTED] wrote:
The above practices have worked fine for a long time in 4.x and still do
even in 4.7p4, which is on this same machine.
Get Matthew N. Dodd's patch at:
ftp://ftp.jurai.net/users/winter/patches/geom-foot.patch
(Hint: sysctl
As Greg 'groggy' Lehey wrote:
I guess it's time to dump the old vinum start code from
vinum(8) completely, and use the in-kernel scan now.
This sounds like a good idea.
Not after looking a bit closer. ;-) The only difference ist that the
userland vinum start uses devstat, while the
Michael Reifenberger [EMAIL PROTECTED] wrote:
After reboot, a `vinum start` gives me:
** no drives found: No such file or directory
Do you perchance have a kernel without GEOM?
vinum start has now been changed to use sysctl kern.disks as the list
of devices to scan. Hmm. No, maybe not...
M. Warner Losh [EMAIL PROTECTED] wrote:
devd works for me when I have devices in my machine at boot. It
does run the start script for me.
I've got a related problem. My kernel is a bit modularized, and with
devd, when i insert the card into the running machine, the script
framework properly
As Michael Reifenberger wrote:
What does your sysctl kern.disks say?
(nihil)(root) # sysctl -a kern.disks
kern.disks: da1 da0 ad1 ad0
That's OK.
I guess it's time to dump the old vinum start code from
vinum(8) completely, and use the in-kernel scan now.
--
cheers, Jorg
As Matthew N. Dodd wrote:
On Tue, 21 Jan 2003, Joerg Wunsch wrote:
It already stopped me when accessing /dev/da0, so why try something
more obscure? Sorry, you've lost me.
ftp://ftp.jurai.net/users/winter/patches/geom-foot.patch
Just apply it to your local source tree and get
As [EMAIL PROTECTED] wrote:
If this is not enough, you can try to set
int g_debugflags = G_T_ACCESS | G_T_TOPOLOGY;
But that will result in much more debugging output.
Here's the result. What does it mean to me? (debug flag set from
DDB, and turned off in single-user again.)
--
As Bernd Walter wrote:
Now that you say it - vinum isn't loaded before going multiuser.
Oh, i should add: in my case, it's loaded before mounting the
root (root is on vinum).
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
As [EMAIL PROTECTED] wrote:
You are saying that the close should read?
error = (*devsw(drive-dev)-d_close) (drive-dev, FWRITE | FREAD, 0, NULL);
Yes, d_close should match whatever the corresponding d_open is called with.
Thanks for pointing this out, this indeed seems to fix this case, fix
Ollivier Robert [EMAIL PROTECTED] wrote:
Oh, i should add: in my case, it's loaded before mounting the
root (root is on vinum).
And how did you achieved this ? I thought vinum isn't able to do
that...
Well, the patch for -current is currently only sitting here on my
machine(s). Greg wanted
Alex Deiter [EMAIL PROTECTED] wrote:
Say me please, sometime growfs will learn to work with vinum
volumes?
The growfs maintainers know about the problem, and are working on a
solution. We learned about that problem too late before 5.0R was due,
so since a quick fix couldn't be produced in
Daniel C. Sobral [EMAIL PROTECTED] wrote:
You can turn this debugging off from userland with:
sysctl kern.geom.debugflags=0
Why not make it a loader tunable?
Why should it? It's a debugging flag, so it's IMHO sufficient that it
can be set from DDB (that's what i did).
--
cheers,
[EMAIL PROTECTED] (Joerg Wunsch) wrote:
The biggest problem of all this is, of course, the bootstrapping
step. The bootstrap still needs an `a' partition in order to read
at least /boot/loader etc. from. The solution is to produce a faked
overlay `a' partition that sits at exactly the point
Included an old disk into a running system. Want to install a new
label onto it:
uncle# disklabel -Brw da0 auto
disklabel: ioctl DIOCSDINFO: open partition would move or shrink
Needless to say, there is nothing open at all on it. As i said, an
old disk that incidentally has a BSD label on it.
As [EMAIL PROTECTED] wrote:
Hang on.
If no disk partitions of any kind are open, there is nothing which
prevents you from doing a dd if=/dev/zero of=/dev/da0 bs=64k.
My guess is that vinum scanned the disks when starting, but found
nothing on it.
However, my really concern is what i wrote
As [EMAIL PROTECTED] wrote:
My guess is that vinum scanned the disks when starting, but found
nothing on it.
And forgot to close them again ?
At least from a cursory review of the code, no. It closes them
again unless a valid vinum configuration has been found.
OK, i'll look once again.
As Matthew N. Dodd wrote:
It already stopped me when accessing /dev/da0, so why try something
more obscure? Sorry, you've lost me.
ftp://ftp.jurai.net/users/winter/patches/geom-foot.patch
Oh, nice! Thanks!
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
- Forwarded message from Kris Kennaway [EMAIL PROTECTED] -
One or more ports that you maintain are currently unbuildable under
FreeBSD 5.0-CURRENT/i386 on the FreeBSD package-building cluster.
[...]
- End forwarded message -
...
gmake[2]: Entering directory
As Matthew N. Dodd wrote:
I really /hate/ this CPU feature crap.
So do I.
I've also found that the only way to reliablly disable it is to comment it
out from sys.mk.
Maybe i should do this using a preconfigure script in my port... :-)
--
cheers, Jorg .-.-. --... ...--
As Kris Kennaway wrote:
What am i supposed to do in order to get cross-compilation working
properly?
NO_CPU_CFLAGS=yes
This is documented in make.conf.
At least not in my version of make.conf's man page. Just checked,
neither in the current version.
I (and obviously not only I) wish
As Simon 'corecode' Schubert wrote:
my kernel can't detect fdc anymore when loading acpi. does anybody else
have such issues?
Hmm, not here. However, my fdc driver is modloaded, too (from the
bootloader). I just tried to unload it, then load acpi (which yields
module_register_init:
[EMAIL PROTECTED] (Jan Stocker) wrote:
I cant mount my floppy from time to time.
twoflower# mount -t msdosfs /dev/fd0 /home/jstocker/floppy/
msdosfs: /dev/fd0: Device not configured
ENXIO is something of a `catch-all' error code in the kernel. It
could mean that there's no such driver
David O'Brien [EMAIL PROTECTED] wrote:
I can rlogin to a -CURRENT box as root. However `rsh box id' comes back
with:
Jul 3 00:11:33 box rshd[4916]: root@dragon as rootk: permission denied
(authentication error). cmd='id'
man pam_rhosts should explain that.
--
cheers, Jorg
As Mark Peek wrote:
Can you verify that there are patches in the devel/gdb52/files?
# ls /usr/ports/devel/gdb52/files
CVS patch-gdb_kvm-fbsd.c
patch-gdb_config_alpha_fbsd.mh patch-gdb_symfile.c
patch-gdb_config_i386_fbsd.mh patch-gdb_target.c
David O'Brien [EMAIL PROTECTED] wrote:
Mark Peek and DFR have made patches against GDB 5.2 such that it
should do everything we need it to. It would be most helpful for
people to test this before it goes into /usr/src.
j@uriah 133% gdb52 kernel.debug /cdrom/vmcore.1
GNU gdb 5.2
Copyright
As Mark Peek wrote:
Hmm, so how to debug a kernel coredump?
You need to update your gdb52 port.
I can't find a newer one in CVS:
j@uriah 85% pkg_info -I gdb-\*
gdb-5.2_2 GNU GDB 5.2 developmental snapshot
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
Ruslan Ermilov [EMAIL PROTECTED] wrote:
I'm in the middle of rewriting release/scripts/*.pl scripts.
Is this even necessary? A make release has so many prerequisites
(among them, a locally available CVS tree) that Perl as a prerequisite
would do no harm. Even more, a normal make release
yuri khotyaintsev [EMAIL PROTECTED] wrote:
so now I have
usr.p0 - 1 subdisk (usr.p0.s0)
usr.p1 - 0 subdisk
I have no possibility to get new large disk now.
Should I try to remove plex usr.p1 ?
Yes, I think so. Perhaps you need to detach it before (most likely).
--
cheers, Jorg
As Bruce Evans wrote:
On Wed, 3 Apr 2002, I wrote:
...
This seems to be a bug in the fd driver. ls -F works the first time
exist. fd0a and fd0c may need to exist for compatibility, but shouldn't.
fd0b and fd0[d-h] just shouldn't exist.
Bruce
As Bruce Evans wrote:
This seems
Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote:
lrwxr-xr-x 1 root wheel4 Apr 2 20:34 /dev/fd1c@ - fd0
Uh?
Interesting that you spooted /that/. :-)
OK, gonna fix it...
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
Peter Jeremy [EMAIL PROTECTED] wrote:
I've just finished updating a system to -CURRENT from mid-April
(just before the DP1 branch). When I try to login, login(8) goes
into a loop.
I've seen this occasionally for accounts that have either S/Key or
opie (forgot which one it was) enabled.
As Bruce Evans wrote:
BTW, device cloning seems to work wrong for fd:
%%%
Script started on Wed Apr 3 02:16:43 2002
ttyp1:bde@besplex:/tmp ls /dev/fd0c
ls: /dev/fd0c: No such file or directory
ttyp1:bde@besplex:/tmp ls /dev/fd0c
/dev/fd0c@
ttyp1:bde@besplex:/tmp exit
I can also see
Crist J. Clark [EMAIL PROTECTED] wrote:
Have a crash box handy?
$ disklabel fd0.1440
The patch below should fix that, thanks for the bug report.
fdioctl() historically attempted to determine the raw partition
(`c') of the device in order to read the label. However, the floppy
driver
David O'Brien [EMAIL PROTECTED] wrote:
Slow. Eats memory. Crashes all the time. Does not save state
between sessions. Does not render HTML 4 properly. Does not support
CSS properly. Does not zoom. Does not display PNG properly.
Incorrectly ignores cache-control headers on images. The
Bruce Evans [EMAIL PROTECTED] wrote:
The -current cu is a crock of tip.
It has more missing features, compared to the Taylor version, like the
unability to run an external program with stdin and stdout piped to
the remote end simultaneously (like a local sz Z-modem program),
plus it has this
Martin Blapp [EMAIL PROTECTED] wrote:
Suse's Copyright:
/* Copyright (c) 1999 Thorsten Kukuk
Author: Thorsten Kukuk [EMAIL PROTECTED]
That would at least be a copyright violation.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
Riccardo Torrini [EMAIL PROTECTED] wrote:
May be. Or not. Even with _all_ this lines commented I get the
floppy controller detected (but no floppy drive).
That's strange, because on IA32 architectures, the first two drives
are supposed to be configured from what is recorded in the CMOS
Robert Watson [EMAIL PROTECTED] wrote:
Most people I know of that netboot boxes on Intel platforms now use
PXE.
But well, there are only two NICs that support PXE, aren't there? In
particular, there's nothing cheap (i. e. = USD 10) you could use in
conjunction with an old junk ISA NIC people
Mike Brancato [EMAIL PROTECTED] wrote:
oh, well. They say something along the lines of
Disk error: lba is 0x9 (should be 0x10)
or similar. then it trys to boot the kernel twice using the loader,
but fails with the path 0:fd(0,a)/kernel
I have to confirm this, for a self-made make release
Bakul Shah [EMAIL PROTECTED] wrote:
On a -CURRENT:
$ du -s /usr/src
389637/usr/src
FFS likes to have about 10% free space + add a few more (may
be 4%) for the inodes space. So you need a partition of at
least 450MB.
j@uriah 57% df -k /usr/src
Filesystem 1K-blocks Used
[EMAIL PROTECTED] (Joerg Wunsch) wrote:
j@uriah 57% df -k /usr/src
Filesystem 1K-blocks UsedAvail Capacity Mounted on
/dev/vinum/src 595455 434778 11304179%/usr/src
That is -current as of around christmas.
Bakul got back to me and questioned that number -- he
Maksim Yevmenkin [EMAIL PROTECTED] wrote:
it looks like if_ar and if_sr modules will not compile
unless you have enabled NETGRAPH. patches are simple and
attached.
Sorry for the breakage, yes.
#include sys/syslog.h
#include dev/ar/if_ar.h
#else /* NETGRAPH */
+#include netinet/in.h
Ruslan Ermilov [EMAIL PROTECTED] wrote:
Oops sorry, that was Joerg.
It's fixed now, although i'm still not convinces that using __i386__
is the right thing. If our machine/param.h defines several
constants for _MACHINE_ARCH, they should all be distint for the
various machines. As it seems
David O'Brien [EMAIL PROTECTED] wrote:
Anyone know how to get this on -CURRENT now days?
No problem for me.
.. enable it in /etc/pam.conf:
login authsufficient pam_opie.so no_warn
.. initialize the key with opiepasswd
.. use telnet -K to prevent automatic (SRA) login
(Well,
Well, everybody can read the commit message, it basically contains all
that is to say. I've offered the patch for review quite some time
ago, but nobody seemed to be interested (or at least nobody had some
feedback to me). So i've been running the patched system here for too
long now, it's time
Hiten Pandya [EMAIL PROTECTED] wrote:
i wanted to ask if there were any _plans_ to port
JFS (Journaled File System) to FreeBSD...
As long as nobody gets the idea to import VxFS... It's dog slow
compared to UFS+softupdates. :-) Dog slow even compared to
Solaris 8 UFS+logging. Of course, i
As Peter Wemm wrote:
No, it isn't ignored, BIOS'es know that fdisk partitions end on
cylinder boundaries, and therefore can intuit what the expected
geometry is for the disk in question.
And you call that a design? I call it a poor hack, nothing else.
The restriction to whatever the BIOS
As Peter Wemm wrote:
Can you please clarify for me what specifically you do not like.. Is it:
- the cost of 32K of disk space on an average disk these days?
(and if so, is reducing that to one sector instead of 62 sufficient?)
The idea of a geometry that does not even remotely resembles
As Terry Lambert wrote:
Joerg Wunsch wrote:
/The/ major advantage of DD mode was that all BIOSes (so far :) at
least agree on how to access block 0 and the adjacent blocks, so
starting our own system there makes those disks portable.
I guarantee you that there are a number
As Peter Wemm wrote:
Yes, that is much safer, however there are certain bioses that have
interesting quirks that the MBR has to work around. The problem
when overlapping mbr and boot1 into the same block is that we no
longer have the space to do that. boot1.s has got *3* bytes free.
Too
As Peter Wemm wrote:
There shouldn't *be* bootblocks on non-boot disks.
dd if=/dev/zero of=/dev/da$n count=1
Dont use disklabel -B -rw da$n auto. Use disklabel -rw da$n auto.
All my disks have bootblocks and (spare) boot partitions. All the
bootblocks are DD mode. I don't see any
As Daniel O'Connor wrote:
I don't understand the need some people have for using something
that is labelled as DANGEROUS.
Historically, it hasn't been labelled that, it only later became
common terminology for it -- in the typical half-joking manner.
No, it won't hurt your cats but you may
As [EMAIL PROTECTED] wrote:
There are very good reasons NOT to use DD mode if you use certain
types of Adaptec SCSI controllers - they simply won't boot from DD.
Never seen. All my SCSI controllers so far booted from my disks
(obviously :).
I figure from Peter's comment in that piece of
Mike Smith [EMAIL PROTECTED] wrote:
- The MBR partition table is not obsolete, it's a part of the PC
architecture specification.
Its design is antique. Or rather: it's missing a design. See other
mail for the reasons. For FreeBSD, it's obsolete since we don't need
to rely on fdisk
As Ruslan Ermilov wrote:
You need to configure /some/ interface address for the remote end
anyway, and it must not clash with any other routing table entry,
since ifconfig ... up always adds an entry for the remote IP address
for p2p interfaces.
Only if you have INET address configured
Bernd Walter [EMAIL PROTECTED] wrote:
32 times for each disk on booting with most of 30 disks.
Possibly it's triggered by vinums drive scanning.
Yep, same here (and it is triggered by vinum).
What can I do about these messages?
Remove it. It should not have been there in the first place,
As Ruslan Ermilov wrote:
phk has chosen 0.0.0.1 since it obviously cannot be a meaningful
statically configured address.
OK, but is it really necessary? It's much simpler to add routes
over P2P interfaces using the interface name ...
You need to configure /some/ interface address for
Ruslan Ermilov [EMAIL PROTECTED] wrote:
ISTR that I4B uses some special magical destination address for some
purpose (0.0.0.0 or something).
The magical destination address is 0.0.0.1. It is used as a
`placeholder' address for the remote side, so you can add a route to
it.
Should probably
Galen Sampson [EMAIL PROTECTED] wrote:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1
fault code= supervisor read, page not present
instruction pointer = 0x8:0xc02b5baf
stack pointer = 0x10:0xcadc3d48
frame pointer = 0x10:0xbfbfadb4
As Maxime Henrion wrote:
Seems to work. mount(8) has still the problem though:
Great, I'll file a PR for it. Thanks for the feedback !
I can commit it if you want.
I fail to see why should ``mount -t local'' work.
ISTR that it used to work, at least in the context of
mount -a -t
Maxime Henrion [EMAIL PROTECTED] wrote:
I looked at the code a bit more closely and you're entirely right. I
think I figured out why my patch caused a core dump. Here is a more
correct patch that should fix the problem without causing core dumps.
Seems to work. mount(8) has still the
As Christoph Herrmann wrote:
Maybe there are other problems. But I had no problems (burning CDs
on -CURRENT) until the beginning of october. (I run make world about
once a week). And with -STABLE everything is fine until now. It is
the same box, I (try to) burn the same image, the only
Kenneth D. Merry [EMAIL PROTECTED] wrote:
Are there any areas with good data on the CD? i.e. can you see any
pattern to the corruption? If you compare the same CD burned from
-current and -stable you might begin to see a patern.
I tried a test-burn with a FreeBSD-current from yesterday, on
Bob Vaughan [EMAIL PROTECTED] wrote:
sources from yesterday evening. rebuild with kernel sources from tonight.
same results.
vt0: unknown trident VGA, 80 columns, color, 8 screens, unknown keyboard
Warning: Driver mistake: repeat make_dev (ttyv0)
Does this only happen with a recent
Luigi Rizzo [EMAIL PROTECTED] wrote:
I have been experiencing this problem for sometimes on CURRENT-based
picobsd images: the shell coredumps if it does not find an
entry for its terminal type in /etc/termcap.
Seems to be a »feature« of the new libedit.
(gdb) run
Starting program:
Maksim Yevmenkin [EMAIL PROTECTED] wrote:
i have some weird problem.
Well, it would have been nice if you had told what you deemed to
be the problem. ;-) I can't find any problem at all...
Breakpoint 1, main () at prog1.c:8
8 return (foo(1, 2, '3', test));
(gdb) s
foo (i=1,
As Maksim Yevmenkin wrote:
first of all i want to apoligize. i sent the wrong output. yes, it
does the right thing if you use -g switch, however it does not
work for me if i use -ggdb switch.
Indeed, the output generated with -ggdb looks weird. But then, it
never occurred to me to use -ggdb
Joel Wilsson [EMAIL PROTECTED] wrote:
fd0: hard error reading fsbn 0 (ST0 40abnrml ST1 1no_am
ST2 0 cyl 0 hd 0 sec 1)
So, I thought I'd try using a raw device configured for
higher density disks.
That wouldn't help you. It's already failing at the very first
sector, by not finding
As Philipp Mergenthaler wrote:
I saw something like this some time ago, too. In my case it was
because in kern_sysctl:ogetkerninfo(), in case KINFO_BSDI_SYSINFO:,
the variable size is not always given a value. Maybe the patch in
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25476
fixes it
As Philipp Mergenthaler wrote:
I saw something like this some time ago, too. In my case it was
because in kern_sysctl:ogetkerninfo(), in case KINFO_BSDI_SYSINFO:,
the variable size is not always given a value. Maybe the patch in
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25476
fixes it
After upgrading to current-2001-08-28, my old BSD/OS Netscape 3 binary
no longer works. It coredumps right away at startup, before opening
any window. (Running it as netscape3 -help, where it only produces
a usage message, isn't affected.)
Now the interesting part: i wanted to get an idea why
Hello all,
before leaving for vacation next week, i thought i'd put up the result
of my work of the last couple of weeks for a review for those who are
interested.
The patch itself is available at
http://people.freebsd.org/~joerg/fdpatch.txt.gz
The following README file (see below) is also
David O'Brien [EMAIL PROTECTED] wrote:
-cn: No such file or directory
*** Error code 1
I would run ``type gzip'' or ``which gzip''. It seems either you've
done something to your gzip binary, or there is a commit that broke
it that I've missed.
That's typical behaviour for the mini-gzip
Anton Berezin [EMAIL PROTECTED] wrote:
if (fork() == 0) {
- signal(SIGCHLD, SIG_IGN);
+ signal(SIGCHLD, SIG_DFL);
This is unportable.
If you want automatic zombie reaping, better don't use the simplified
signal(3) handling, but instead
As Anton Berezin wrote:
- signal(SIGCHLD, SIG_IGN);
+ signal(SIGCHLD, SIG_DFL);
Umm, I don't understand. I do not want automatic zombie reaping, I want
exactly the opposite, and my patch does just that.
Ah sorry, i was confused.
--
cheers, Jorg
Bruce Evans [EMAIL PROTECTED] wrote:
I think diskcheckd.conf should check no disks by default.
My opinion, too. (After i suddenly noticed it checks anything by
default...)
Checking is bad for many types of disks. It's bad for all disks on
laptops running off batteries.
And for many
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote:
After Joerg's late-June round of brea^H^H^H^Hcommits to the floppy
driver, I can no longer use my floppy drive. Any attempt to access
the drive (with a known-good writeable floppy in it) simply hangs in
physst state until I eject the disk, at
Crist J. Clark [EMAIL PROTECTED] wrote:
mount: /dev/fd0c: No such file or directory
It seems there is some type of race to get the fd0c symlink in place
and I am not winning it.
The symlink DEVFS nodes are going to be created first time they
are referenced. Your mount attempt thus does
Alfred Perlstein [EMAIL PROTECTED] wrote:
..., I saw a message saying that Vinum was
not yet ready for use with DEVFS. Is that still the case?
I fixed that. :) Let me and Grog know if you have problems.
It basically works for me. Of course, vinum still has a dozen
of bugs that get
Peter Wemm [EMAIL PROTECTED] wrote:
Definately a bug. :-( The scanner is effectively concatenating
the device.hints and the config hints together when enumerating them.
Speaking about bugs in the hints processing:
Triggered by Michael Reifenberger [EMAIL PROTECTED], i started
experimenting
As Robert Watson wrote:
Thomas Moestl recently committed some fixes to the EA code, and may
have a couple more in the pipeline that address these problems.
I've seen the commits, however, since my system was grossly unstable,
i by now took out the EA options again. I'll see whether i can
Maxim Sobolev [EMAIL PROTECTED] wrote:
Please post a HEADS UP when you are done, so we all be
notified that the world is in the safe state again.
And, please also post a list of old vs. new names. Not all of us
follow the i18n list.
Anyway, nice to see that we're going to be compatible to
Joerg Wunsch [EMAIL PROTECTED] wrote:
It /only/ happens after a mount -a, not after just mounting /tmp
only. No idea why, the only `obscure' filesystems i've got are procfs
and portalfs.
portalfs indeed seems to be the culprit for leaving an unreferenced
file in /tmp. However, the panic
subject consistently happens for me when i try to umount /tmp. A
normal umount doesn't work, not even in single-user mode (device
busy), and a forcible umount causes the panic. fstat doesn't show any
open descriptors on it though. It happens on a newfs'd /tmp, too.
It /only/ happens after a
Poul-Henning Kamp [EMAIL PROTECTED] wrote:
=== usr.bin/fetch
/flat/src/usr.bin/fetch/fetch.c: In function `main':
/flat/src/usr.bin/fetch/fetch.c:757: `vtty' undeclared (first use in this function)
Noticed this in my `make release' attempt yesterday, too.
--
cheers, Jorg
Peter Wemm [EMAIL PROTECTED] wrote:
For some reason, sysinstall or the kernel decided to += 64k on the
start address of the swap partition (to avoid swap clobbering the
fdisk, bootblocks, etc at the start of the disk), but neglected to
remove 64k from the size.
This could be undone.
89 matches
Mail list logo
