Re: unmounting a filesystem safely that doesn't exist anymore

2006-06-12 Thread Björn König

Peter Jeremy schrieb:

On Sat, 2006-Jun-10 19:40:41 +0200, Bjrn Knig wrote:

I did a mistake: I unplugged my digital camera accidentally before I 
unmounted the filesystem. *doh* This happens very often, because I'm 
very scatterbrained. =)



Your best solution may be to use mtools (ports/emulators/mtools) rather
than mounting the filesystem.


changed ad hoc. I just want to know if somebody knows a workaround or 
small trick that prevents the other filesystems from being unclean on 
next boot-up.



The only way to do this is to have all the other filesystems mounted
read-only.  The filesystem clean flag is part of the superblock and
is cleared when a filesystem is mounted.  It will be set only if the
filesystem is cleanly unmounted.


Thank you very much for these information. They help me a lot.

Björn

P.S. I get the feeling questions@ would had been a better place for my 
question. ;-)

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: kernel panic(?) trying to copy data off failed drive with dd

2006-06-12 Thread Miroslav Lachman

Greg Lane wrote:
[...]
The machine is running 5.5 pre-release.  I can pull the disk and put it 
in a machine running 6-stable if that will help.  I could also install 
current on some box or another. Whatever will get the data back!! 


Advice please?!?

Cheers,
Greg


Maybe you can try /usr/ports/sysutils/cpdup which can skip read errors. 
I used cpdup few years ago on HDD with bad sectors with success - lose 
only few unreadable files from the middle of disk.


Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 6.1-stable hangs and LORs

2006-06-12 Thread Bjoern A. Zeeb

On Mon, 12 Jun 2006, Max Laier wrote:


On Sunday 11 June 2006 23:46, Brad Waite wrote:

Kris Kennaway wrote:

We need to know the LOR before anyone can tell what is going wrong ;-)


Ask and you will receive:

lock order reversal:
  1st 0xc077a440 pf task mtx (pf task mtx) @
/usr/src/sys/contrib/pf/net/pf.c:6331
  2nd 0xc07d3fac tcp (tcp) @ /usr/src/sys/contrib/pf/net/pf.c:2719


From pf.conf(5):
BUGS
Due to a lock order reversal (LOR) with the socket layer, the use of the
group and user filter parameter in conjuction with a Giant-free netstack
can result in a deadlock.  If you have to use group or user you must set
debug.mpsafenet to ``0'' from the loader(8), for the moment.  This work-
around will still produce the LOR, but Giant will protect from the dead-
lock.


though this is known and there are already other similar LORs (like
#17, ...) I added it to the LOR page with ID 191 because it's another
code path in the backtrace. That way people will also find this one.
http://sources.zabbadoz.net/freebsd/lor.html#191

--
Bjoern A. Zeeb  bzeeb at Zabbadoz dot NeT
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: kernel panic(?) trying to copy data off failed drive with dd

2006-06-12 Thread Michael P. Soulier
On 12/06/06 Miroslav Lachman said:

 Greg Lane wrote:
 [...]
 The machine is running 5.5 pre-release.  I can pull the disk and put it 
 in a machine running 6-stable if that will help.  I could also install 
 current on some box or another. Whatever will get the data back!! 
 
 Advice please?!?
 
 Maybe you can try /usr/ports/sysutils/cpdup which can skip read errors. 
 I used cpdup few years ago on HDD with bad sectors with success - lose 
 only few unreadable files from the middle of disk.

Regardless, file a bug report. The box should never hang, or reboot. 

Mike

-- 
Michael P. Soulier [EMAIL PROTECTED]
Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction. --Albert Einstein


pgpB6l2UFLEFu.pgp
Description: PGP signature


Re: kernel panic(?) trying to copy data off failed drive with dd

2006-06-12 Thread Greg Lane
On Mon, Jun 12, 2006 at 11:16:28AM +0200, Miroslav Lachman [EMAIL PROTECTED] 
wrote:
 Advice please?!?
 
 Maybe you can try /usr/ports/sysutils/cpdup which can skip read errors. 
 I used cpdup few years ago on HDD with bad sectors with success - lose 
 only few unreadable files from the middle of disk.

I am installing that right now and will give it a try in the morning 
when I am sitting next to it. I want to keep the machine alive 
overnight while I copy some other stuff over the network to another 
machine, since I may take this opportunity (replacing the disk) to upgrade 
to 6-stable.

Thanks,
Greg

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: kernel panic(?) trying to copy data off failed drive with dd

2006-06-12 Thread Greg Lane
On Mon, Jun 12, 2006 at 06:47:56AM -0400, Michael P. Soulier [EMAIL 
PROTECTED] wrote:
 On 12/06/06 Miroslav Lachman said:
 
 Regardless, file a bug report. The box should never hang, or reboot. 

Is this the case?  I had another box (a piece of crap I played around on) 
that had a failing disk, and this would bring the machine down. So I didn't 
think this was necessarily unusual.  However, on the previous occasion the disk 
was the root file system with swap on it, whereas in this case, the disk is 
only a data disk, not any part of the OS.  

Are you saying that the box should never hang or reboot, but should 
recover from the error, and whatever command was running should fail and 
return an error message?

If that is the case, is there possibly some sysctl or boot setting that 
I might have set that would cause it to fail catastrophically rather than 
properly.  Maybe disabling DMA would help? Something? Anything?

If people think this is abnormal enough to warrant a bug report, I am 
happy to file one. I want to be sure this is unexpected behaviour though. 

Some terse info here, in case it helps:

5.5-PRERELEASE from Wed May 10

Tyan Thunder K8S 2880 UGNR  (onboard vga, mpt scsi, dual bge ethernet)
4 x 1GB DDR400
2 x Opteron 248
1 x 73 GB SCSI (Maxtor)   (/ /usr etc, plus 1 x 6 GB swap on here)
1 x 147 GB SCSI (Maxtor)  (/home,  plus 1 x 6 GB swap on here)
2 x SATA 250GB (WD)  (data disks, it is one of these that has failed)
1 x ATA 250GB (WD)   (scratch disk)
Adaptec 2940 with a DLT and EXABYTE drive

I can send a dmesg directly if anyone has any ideas.

Greg

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: kernel panic(?) trying to copy data off failed drive with dd

2006-06-12 Thread Oliver Fromme
Greg Lane [EMAIL PROTECTED] wrote:
  Michael P. Soulier [EMAIL PROTECTED] wrote:
   
   Regardless, file a bug report. The box should never hang, or reboot. 
  
  Is this the case?  I had another box (a piece of crap I played around on) 
  that had a failing disk, and this would bring the machine down. So I didn't 
  think this was necessarily unusual.  However, on the previous occasion the 
  disk 
  was the root file system with swap on it, whereas in this case, the disk is 
  only a data disk, not any part of the OS.  
  
  Are you saying that the box should never hang or reboot, but should 
  recover from the error, and whatever command was running should fail and 
  return an error message?

It depends.  Usually the system should _not_ panic in case
of software errors.  For example, when running fsck on a
broken file system, it should not cause a panic.  However,
mounting a broken file system might cause a panic or other
misbehaviour, which is clearly documented as a bug in the
mount(8) manpage:  It is possible for a corrupted file
system to cause a crash.

However, in the case of hardware failures (including broken
disk drives), anything bad can happen, ranging from silent
data corruption to panics or cold freezes.  Any many cases
the operating system simply has no chance to deal with it
properly.

So, if your panic is caused purely by software error, and
it's not already known and documented, filing a PR might be
a good idea.  But if faulty hardware is involved, sending
a PR is probably useless.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH  Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

A language that doesn't have everything is actually easier
to program in than some that do.
-- Dennis M. Ritchie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: kernel panic(?) trying to copy data off failed drive with dd

2006-06-12 Thread Michael P. Soulier
On 12/06/06 Oliver Fromme said:

 So, if your panic is caused purely by software error, and
 it's not already known and documented, filing a PR might be
 a good idea.  But if faulty hardware is involved, sending
 a PR is probably useless.

I would think that it would depend on how the hardware is being used. If the
disk with errors happens to hold the swap partition, then it's difficult to
blame the kernel for crashing. If it's simply reading data, I don't think that
a kernel panic is acceptable.

Mike

-- 
Michael P. Soulier [EMAIL PROTECTED]
Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction. --Albert Einstein


pgpbqbFfHSeB5.pgp
Description: PGP signature


Re: kernel panic(?) trying to copy data off failed drive with dd

2006-06-12 Thread Oliver Fromme
Michael P. Soulier [EMAIL PROTECTED] wrote:
  Oliver Fromme said:
   So, if your panic is caused purely by software error, and
   it's not already known and documented, filing a PR might be
   a good idea.  But if faulty hardware is involved, sending
   a PR is probably useless.
  
  I would think that it would depend on how the hardware is being used.

Yes, I agree.

  If the
  disk with errors happens to hold the swap partition, then it's difficult to
  blame the kernel for crashing. If it's simply reading data, I don't think 
  that
  a kernel panic is acceptable.

Simply reading data would be a software error, and in
that case a crash or freeze is not acceptable.  (Although
it may be very difficult to fix, especially without
sacrificing performance significantly, e.g. see mount(8).)

However, if the _hardware_ is broken, i.e. the disk drive
does not respond correctly, for example producing DMA errors,
locking up the bus, or whatever, anything could happen.
I guess Søren could tell interesting stories about such
cases.  :-)

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH  Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

... there are two ways of constructing a software design:  One way
is to make it so simple that there are _obviously_ no deficiencies and
the other way is to make it so complicated that there are no _obvious_
deficiencies.-- C.A.R. Hoare, ACM Turing Award Lecture, 1980
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: unmounting a filesystem safely that doesn't exist anymore

2006-06-12 Thread Ulrich Spoerlein
Björn König wrote:
 Hello,
 
 I did a mistake: I unplugged my digital camera accidentally before I 
 unmounted the 
 filesystem. *doh* This happens very often, because I'm very scatterbrained. 
 =) The kernel 
 will panic and all filesystems remain unclean in any case now. I know that 
 this is a well 
 know issue and in past discussions you stated that this behaviour is intended 
 and won't be 
 changed ad hoc. I just want to know if somebody knows a workaround or small 
 trick that 
 prevents the other filesystems from being unclean on next boot-up.

You might give the automounter (am-utils) a whirl. They are very
confusing to set up, but you can set the unmount-if-unused timeout to
something like 5 seconds. This could narrow the window enough to not
panic you system frequently :)

Ulrich Spoerlein
-- 
 PGP Key ID: 20FEE9DD   Encrypted mail welcome!
Fingerprint: AEC9 AF5E 01AC 4EE1 8F70  6CBD E76E 2227 20FE E9DD
Which is worse: ignorance or apathy?
Don't know. Don't care.


pgptDKFK0qUnN.pgp
Description: PGP signature


Re: How can I know which files a proccess is accessing?

2006-06-12 Thread Ulrich Spoerlein
Dan Nelson wrote:
 In the last episode (Jun 09), Ulrich Spoerlein said:
  Sadly, ktrace(1) seems to be rather useless in RELENG_6 right now.
  Every medium sized app will result in an out of ktrace objects
  error. I remember that some improvements to ktrace(1) went into
  -CURRENT. Time for an MFC?
 
 Just raise the kern.ktrace.request_pool sysctl; 4096 works for me.

Heh, I didn't know that sysctl existed. Why is the default value (100)
so low? I set it to 4096, but it only survives three seconds when
running 'ktrace find ~'

Anyway, next time I need ktrace, I'll remember to bump the pool size.
Thanks!

Ulrich Spoerlein
-- 
 PGP Key ID: 20FEE9DD   Encrypted mail welcome!
Fingerprint: AEC9 AF5E 01AC 4EE1 8F70  6CBD E76E 2227 20FE E9DD
Which is worse: ignorance or apathy?
Don't know. Don't care.


pgpktFWAqYki3.pgp
Description: PGP signature


Intermittent Kernel Panics on Disk Activity/cvsup/make on 6.1-RELEASE

2006-06-12 Thread Anthony Volodkin

Hi,

On my Athlon XP 1800 / Abit KX7-333R system, I've been encountering 
intermittent kernel panics during periods of high disk activity or when 
running cvsup or make buildworld. 

What's notable is that at this point the motherboard, CPU, and power 
supply have been replaced and the system has no difficulties running 
Memtest86 for several hours.  Additionally, this problem does not happen 
EACH time I generate a lot of disk load or run cvsup, but occasionally.  
Per the handbook, I've built a debug kernel and captured crash data.  
Below are my dmesg, and the output of several kgdb, list *instruction 
pointer and backtrace.


What are some of the next steps I can take to help resolve this or find 
the cause of these crashes?


Any help is highly appreciated.  Please CC me when responding as I am 
not subscribed to this list.


Thank you,

Anthony Volodkin


kgdb kernel.debug /var/crash/vmcore.1

[GDB will not be able to debug user-mode threads: 
/usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup]

GNU gdb 6.1.1 [FreeBSD]
... [snip] ...
This GDB was configured as i386-marcel-freebsd.

Unread portion of the kernel message buffer:


Fatal trap 9: general protection fault while in kernel mode
instruction pointer = 0x20:0xc06aacfd
stack pointer   = 0x28:0xe981ac10
frame pointer   = 0x28:0xe981acdc
code segment= base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 18257 (cvsup)
trap number = 9
panic: general protection fault
Uptime: 3d15h50m31s
Dumping 2047 MB (2 chunks)
 chunk 0: 1MB (159 pages) ... ok
 chunk 1: 2047MB (524016 pages) 2031 2015 1999 1983 1967 1951 1935 1919 
1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 
1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 
1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 
1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 
1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 
719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 
431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 
143 127 111 95 79 63 47 31 15


#0  doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));


(kgdb) list *0xc06aacfd

0xc06aacfd is in lseek (/usr/src/sys/kern/vfs_syscalls.c:1788).
1783goto drop;
1784fp-f_offset = offset;
1785*(off_t *)(td-td_retval) = fp-f_offset;
1786drop:
1787fdrop(fp, td);
1788VFS_UNLOCK_GIANT(vfslocked);
1789return (error);
1790}
1791
1792#if defined(COMPAT_43)


(kgdb) bt

#0  doadump () at pcpu.h:165
#1  0xc064dee1 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2  0xc064e178 in panic (fmt=0xc088cb0e %s) at 
/usr/src/sys/kern/kern_shutdown.c:558
#3  0xc0841d94 in trap_fatal (frame=0xe981abd0, eva=0) at 
/usr/src/sys/i386/i386/trap.c:836

#4  0xc08418bc in trap (frame=
 {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -377377532, tf_esi = 
-948068912, tf_ebp = -377377572, tf_isp = -377377796, tf_ebx = 0, tf_edx 
= -969420352, tf_ecx = -911557632, tf_eax = 0, tf_trapno = 9, tf_err = 
48128, tf_eip = -1066750723, tf_cs = 32, tf_eflags = 66050, tf_esp = 
-960093848, tf_ss = -911557632}) at /usr/src/sys/i386/i386/trap.c:631

#5  0xc0830c9a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#6  0xc06aacfd in lseek (td=0xc9aabc00, uap=0xe981ad04) at 
/usr/src/sys/kern/vfs_syscalls.c:1787

#7  0xc08420ab in syscall (frame=
 {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 672019104, tf_esi = 
-1077940896, tf_ebp = 136321580, tf_isp = -377377436, tf_ebx = 
673236232, tf_edx = 0, tf_ecx = 118, tf_eax = 198, tf_trapno = 0, tf_err 
= 2, tf_eip = 673179699, tf_cs = 51, tf_eflags = 514, tf_esp = 
136321536, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:981
#8  0xc0830cef in Xint0x80_syscall () at 
/usr/src/sys/i386/i386/exception.s:200

#9  0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)


dmesg

Copyright (c) 1992-2006 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
   The Regents of the University of California. All rights reserved.
FreeBSD 6.1-RELEASE #0: Fri May 26 03:01:47 EDT 2006
   [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SUPERIOR
mptable_probe: MP Config Table has bad signature: \M^D\^A\^A
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) XP 1800+ (1533.99-MHz 686-class CPU)
 Origin = AuthenticAMD  Id 

nvidia-driver related (?) panic on 5.5-RELEASE

2006-06-12 Thread Michael Nottebrock
I've been trying to run Second Life (http://www.secondlife.com) in WINE and 
get a reproducable kernel panic when I try to quit the application. WINE is 
able to run Second Life quite well otherwise for a while, but will eventually 
crash accompanied by kernel trap 9 with interrupts disabled kernel 
messages.

The kernel panic message is:

pmap_invalidate_range: interrupts disabled


Here's a backtrace of a crash dump I got:

#0  doadump () at pcpu.h:160
160 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) bt
#0  doadump () at pcpu.h:160
#1  0xc04edd29 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:412
#2  0xc04ee04d in panic (fmt=0xc0697a7d %s: interrupts disabled)
at /usr/src/sys/kern/kern_shutdown.c:568
#3  0xc064d6eb in pmap_invalidate_range (pmap=0xc07065a0, sva=3614474240, 
eva=3614490624)
at /usr/src/sys/i386/i386/pmap.c:636
#4  0xc064df0d in pmap_qremove (sva=3614474240, count=0)
at /usr/src/sys/i386/i386/pmap.c:1013
#5  0xc0533530 in vfs_vmio_release (bp=0xd6787680) 
at /usr/src/sys/kern/vfs_bio.c:1600
#6  0xc0532ab1 in brelse (bp=0xd6787680) at /usr/src/sys/kern/vfs_bio.c:1382
#7  0xc0541d9c in vtruncbuf (vp=0xc3f99420, cred=0xc3a8e480, td=0xc41e9d80, 
length=0,
blksize=0) at /usr/src/sys/kern/vfs_subr.c:1150
#8  0xc05e5a36 in ffs_truncate (vp=0xc3f99420, length=0, flags=2048, 
cred=0xc3a8e480,
td=0xc41e9d80) at /usr/src/sys/ufs/ffs/ffs_inode.c:400
#9  0xc0601b47 in ufs_setattr (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:566
#10 0xc0604e73 in ufs_vnoperate (ap=0x0) 
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2827
#11 0xc04f2d65 in coredump (td=0xc41e9d80) at vnode_if.h:364
#12 0xc04f2647 in sigexit (td=0xc41e9d80, sig=10) 
at /usr/src/sys/kern/kern_sig.c:2414
#13 0xc04f0a51 in trapsignal (td=0xc41e9d80, sig=10, code=30)
at /usr/src/sys/kern/kern_sig.c:1531
#14 0xc0652da0 in trap (frame=
  {tf_fs = 2035999, tf_es = 19857455, tf_ds = -1091174353, tf_edi = 
2079350784, tf_esi = 0, tf_ebp = 2079371196, tf_isp = -371511964, tf_ebx 
= -1678306116, tf_edx = 2079343616,---Type return to continue, or q 
return to quit---
# tf_ecx = 0, tf_eax = 0, tf_trapno = 9, tf_err = 0, tf_eip = -1678318765, 
tf_cs = 31, tf_eflags = 2097686, tf_esp = 2079371136, tf_ss = 47}) 
at /usr/src/sys/i386/i386/trap.c:632
#15 0xc0640fea in calltrap () at /usr/src/sys/i386/i386/exception.s:140

... and finally, my kernel config is attached.


Cheers,
-- 
   ,_,   | Michael Nottebrock   | [EMAIL PROTECTED]
 (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
   \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org
#
# GENERIC -- Generic kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the handbook section on
# Kernel Configuration Files:
#
#
http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413.2.6.2.2 2004/10/24 18:02:52 
scottl Exp $

machine i386
cpu I686_CPU
ident   KISTE-SMP

# To statically compile in device wiring instead of /boot/device.hints
#hints  GENERIC.hints # Default places to look for devices.

makeoptions DEBUG=-g

options SMP # Symmetric MultiProcessor Kernel
#optionsSCHED_ULE   # ULE scheduler
options SCHED_4BSD  # 4BSD scheduler
options INET# InterNETworking
options INET6   # IPv6 communications protocols
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
options MD_ROOT # MD is a potential root device
options NFSCLIENT   # Network Filesystem Client
options NFSSERVER   # Network Filesystem Server
options NFS_ROOT# NFS usable as /, requires NFSCLIENT
options MSDOSFS # MSDOS Filesystem
options CD9660  # ISO 9660 Filesystem
options PROCFS  # Process filesystem (requires PSEUDOFS)
options PSEUDOFS# Pseudo-filesystem framework
options GEOM_GPT# GUID Partition Tables.
options COMPAT_43   # Compatible with BSD 4.3 [KEEP 

'make release' questions...

2006-06-12 Thread Peter Losher
I have been mucking about w/ 'make release' for some time now (stripping
out OpenSSH, sendmail, Heimdal, bits oF BIND, etc.) and while I now have
a working .iso image, that will install and update, I have some
questions that 'man release' just won't answer. :)

First, is there any way to instruct 'make release' to just build certain
packages (and their dependencies) for inclusion in the release instead
of a blanket NOPORTS?  There's no need for us spend two/three days
compiling all the various ports when we will only use a small handful of
them on most of our boxes.  (and would speed up the amount of time it
takes to roll out a new release) ;)

Second, is there a way to build/tell sysinstall that if NO_OPENSSH is
set, that it doesn't ask you whether you want to enable SSH logins?

Thanks again in advance for any advice you can provide.

Best Wishes - Peter
-- 
[ http://www.plosh.net/ ] - Earth Halted: Please reboot to continue



signature.asc
Description: OpenPGP digital signature