loader.conf Error: stack overflow
Using -CURRENT as of a few hours ago: --- FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Sun Aug 10 13:37:08 CEST 2003) Loading /boot/defaults/loader.conf Error: stack overflow \ /boot/kernel/kernel text=0x30ee80 data=0x33f98+0x57160 syms=[0x4+0x3c2d0+0x4+0x4 a11b] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/kernel/acpi.ko --- Might be an ACIP problem. Google didn't show this error, though. Fortunately, the boot process continues after the error. --Lucky ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: options NO_SWAPPING, still wants swap
On Fri, 11 Apr 2003, Bruce Evans wrote: On Thu, 10 Apr 2003, Lucky Green wrote: I compiled a kernel with options NO_SWAPPING, yet CURRENT still attempts to allocate swap space: NO_SWAPPING has nothing to do with not allocating swap space. It prevents swapping of upages and stack pages only. Unfortunately, NOTES' description of NO_SWAPPING says that it disables swapping without explaining what swapping is (it is just swapping of upages and stack, and has nothing to do with generic VM paging). NO_SWAPPING is documented mainlly in the commitlog for the change that added it: Perhaps a kind comitter could modify NOTES to help make users aware that NO_SWAPPING does not disable swapping of memory to disk and to look to man rc.conf for information about the latter? Thanks, --Lucky ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ENOMEM error diagnosis?
Poul-Henning wrote: Make sure you have rev 1.9 of src/sys/geom/bde/g_bde_crypt.c I hadn't done my math and before that rev gbde would request very large lumps of ram from malloc(9). For a few hours, I thought that rev 1.9 may have fixed the problem, but I just received another ENOMEM 0xchanging_digits on 0xc1c7c700(ad4s1c.bde) after remaking the world and recompiling the kernel with a cvsup from last night. g_bde_crypt.c is v 1.9 from 2003/03/07. Seems a bug continues to persist in GBDE. --Lucky To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ENOMEM error diagnosis?
I am seeing a lot of crashes of GBDE, causing ENOMEM errors to scroll rapidly on the console. Whenever this happens, the server becomes unresponsive to keyboard or any other input and has to be power cycled. Is there some debug setting that I can set which would help diagnose the problem further? This is on a minimally-loaded test machine with no other users and no significant load from any services. Thanks, --Lucky To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
GBDE automation scripts?
I am writing a section for the Handbook on how to use gbde. Currently, using gbde is a rather manual process. Each time a host reboots, the admin needs to attach the gbde device(s), enter any required passphrases, manually fsck the partition, and mount it. I suspect some subscribers to this mailing list have scripts in place to at least partially automate the process. If you have such a script, could you please get in touch with me for inclusion of the script in the Handbook? What I am looking for is something along the following lines: At the low end: a script that takes a list of gbde-encrypted file systems stored in an fstab-like file that contains the names of the gbde lock files together with their ultimate mount points. Think of this file as an /etc/fstab.gbde. The script then prompts the admin for the required passphrases, and completes the remainder of the tasks though mounting the attached partitions. For simplicity, the script could assume that the gbde lock files are all stored in /etc/gbde/ and are named with the name of the underlying device. At the not quite so low end: same as above, but the script will try an admin-provided passphrase on all gbde devices, only asking the admin to provide additional passphrases if the decryption does not yield a file system that mount knows about. Rationale: Few will use 4 passphrases to encrypt /aux1 through /aux4 and the user probably doesn't want to be prompted multiple times, once for each device, to enter the same passphrase multiple times. Much better user experience: extend fstab(5) to hold the information that would under the earlier scenarios have been stored in /etc/fstab.gbde. Of course the gbde devices listed in /etc/fstab should not be auto-mounted during boot. Then extend mount with an argument to mount encrypted partitions based on the information stored in /etc/fstab, asking the user for a passphrase as needed. Hey, one can hope. ;) Either way, if you have any scripts that do even part of what I am describing, please get in touch with time. Thanks, --Lucky To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet (xl) will not transmit or receive
Kevin wrote: I updated my 5.0 system built in late January to RELENG_5_0 on Sunday and the Ethernet was not working. I tried again last night with no change in behavior. The system is an AMD K6-2 on an ASUS P5A mobo. I have a 3Com 3c905B Ethernet which had been working fine on a kernel built in late January. The dmesg is not too meaningful, but the system shows no errors. It simply never receives a packet. ARPs are all incomplete and no packets are transmitted although netstat -in indicates that they are. The packets never actually reach the wire, though. I can't believe that no one else has this card, but I didn't find anything in the archives on it. I experienced the exact same behavior with my GF's GigaByte GA-5AN AMD K6-2 motherboard. Both a 3COM and a Realtek (yeah, I know...) card refused to pass packets, staying in hardware loopback. The link light on both cards would remain on until it appears the device was probed. At that point the link was lost permanently. The motherboard and both cards work fine with FreeBSD 4.7, which I even re-tested after the futile 5.0-RELEASE installation. I even flashed in the latest BIOS, but that had no effect. (The hardware has since been re-tasked and is no longer available for testing). --Lucky Green To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
OpenSSL 0.9.6/0.9.7 library version conflicts
I just spent a few days trying to determine why postfix with STARTTLS enabled is instantly dumping core on my new FreeBSD 5.0 machine. The problem was caused by a conflict between OpenSSL library versions 0.9.6 and 0.9.7, both of which are installed on the machine. The former as part of the FreeBSD base distribution, the latter as a Port. Unfortunately, the nature of the conflict, at least on my box, prevented any meaningful gdb back trace. If you are seeing unexplained core dumps with SSL-using applications and have both OpenSSL 0.9.6 and 0.9.7 installed, chances are you ran into this problem. Fix: no idea. Workaround: 1) Remove one of the two conflicting OpenSSL versions. This may be non-trivial; on FreeBSD, a Google search seems to indicate that replacing the OpenSSL version that ships with the OS may lead to other problems and/or unexpected behavior. 2) Convince your OS provider to upgrade to 0.9.7. 3) If you are a Port/Package/RPM maintainer, you may wish to implement a check for conflicting OpenSSL library versions. FYI, FreeBSD is not the only OS on which this problem has been found to exist. Debian Linux is experience the same problem. See a post to debian-devel-announce attached below. Thanks, --Lucky - From: Stephen Frost [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: OpenSSL 0.9.6/0.9.7, LDAP, SSH, friends Hey all, There are quite a few bugs that are probably because of the problem I'm about to describe (177868, 178061, 173821, probably others..) so it was felt that this might be something to make other developers aware of. Currently in Debian there are quite a few packages which still link against OpenSSL 0.9.6 (libldap2-tls, ssh-krb5, others). Newer packages are being linked against OpenSSL 0.9.7 (ssh, etc). The problem happens when these two end up getting linked into the same running program. An example of how this can happen is this: ssh starts up and brings in 0.9.7. A user connects and PAM is configured to use libpam-ldap. libpam-ldap loads and brings in libldap2-tls. libldap2-tls loads and brings in 0.9.6. After this point basically anything involving SSL is questionable at best and very likely to give you a segfault. Methods to detect this include: strace the binary and see if it's loading 0.9.6 and 0.9.7 set LD_DEBUG=3Dfiles and run the binary and watch the output gdb the program, run it and when it segfaults run: info sharedlibrary gdb worked best for me since it gives a nice short list without lots of other information you don't need. The specific library file I've seen is:=20 /usr/lib/i686/cmov/libcrypto.so.0.9.6 /usr/lib/i686/cmov/libcrypto.so.0.9.7 For the record I've heard of similar potential problems with libsasl7 vs. libsasl2 which involves things like sendmail, slapd, etc. I don't have an overall solution to this, though I've heard much about versioned symbols perhaps being an answer. I know that's been discussed on d-d some already though and don't know where that went. Trying to keep this short, just be on alert for these issues when you see bug reports come in about segfaults with these and related packages. Good luck, Stephen --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
L440gx+ serial BIOS needs text mode
I have a dual PIII Intel L440gx+ (VA Linux) server. I am running CURRENT cvsupped a few hours ago. This motherboard provides access to the BIOS via sio1. When booting, the serial BIOS shows everything that's happening until the point of booting the kernel (where it seems to switch video modes to have a bright white character set rather than the dull white/grey characters used initially). 1) Is there a way to prevent the FreeBSD kernel from ever switching into this different video mode, thus allowing me to continue to use the built-in serial terminal? The machine is a headless server, I don't care if video works as long as I can pull out a serial terminal. Furthermore, dmesg shows: sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A While Google shows several other users seeing same output, I have been unable to find a post that clearly explained what the cause of this not in bitmap error is. While sio1 is used by the serial BIOS and therefore reasonably could be expected to cause some error, sio0 should work just fine. 2) Even if the above errors are harmless, how do I make them go away? TIA, --Lucky To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: L440gx+ serial BIOS needs text mode
Attila wrote: The reason that you lost the serial console after the kernel started is that you BIOS from that point is launched to the nearest galaxy's trashcan via hyperspace, I mean is not functional. You have to set up the serial console. A good answer on your average PC. (And perhaps even for this one :) However, the Intel L440gx+ motherboard I have (it came in a VA Linux rackmount) seems to have a separate CPU performing all kinds of monitoring tasks, watchdog, etc, so I was hoping this separate CPU was actually performing the serial console task. As I read it on page 64 of the manual (download from Intel), the second serial port is actually connected through a multiplexer to the Baseboard Management Controller (Dallas 82CH10) in my configuration. ftp://download.intel.com/support/motherboards/server/l440gx/254151-003.p df On page 36, the EMP 'always active mode' I selected suggests that console redirection remains active, and the OS can not see the port (or by extension take control of it). Which would seem to leaves the graphics mode issue. FreeBSD should be oblivious to the fact that this re-direction is even going on, but the kernel seems to do /something/ that impacts the built-in serial console. I guess the idea is to not have to use the FreeBSD software serial console, but use the hardware serial console out that comes with the motherboard. [FYI, there is a FreeBSD project to access the IMPI functions of these motherboards. http://people.freebsd.org/~dwhite/ipmi/, but it seems to address a slightly different question. Thanks in advance, --Lucky Green To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0 without swap
I am about to set up a FreeBSD 5.0 machine without a swap partition. The server has 1GB of RAM. Are there any caveats that I need to consider during installation or configuration? Thanks, --Lucky To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: 5.0 without swap
Miguel wrote: Having no swap will prevent you from getting crashdumps in case of panic which, if you run 5.0, is not that unusual. Besides these days harddrives cost $1/GB, so why not setup the swap partition anyway? I don't want cleartext cryptographic keys to ever touch magnetic media, thus potentially opening the door to future forensic analysis. --Lucky, who thought that he once, many years ago, read that there was a kernel option one should set if you have no swap partition. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
BDE drive encryption practices and techniques?
I plan to deploy GBDE in an environment in which the absolute maximum of the system that can reasonably be kept encrypted on disk will be kept in an encrypted format. The system has the following requirements: 1) It must remain possible to administer the host over ssh. This includes rebooting the host. 2) /home must be encrypted. 3) The machine is not required to permit non-root login or accept mail until root has mounted the encrypted partitions over ssh. Furthermore, performance requirements are not an issue. Assume plenty of CPU and RAM. 4) /var/mail must be encrypted. 5) /var/log/maillog must be encrypted. 6) /var/log/messages should be encrypted, however, syslog must be able to write messages to the log from boot. (These two combined requirements may at first seem mutually exclusive, though this may not actually be the case, perhaps the log could be buffered to a memory device and written to /var/log/messages once /var becomes available). 7) Once the encrypted partitions are mounted, the rest of the services should start up automatically as they would have if all partitions had been mounted initially. 8) It sure would be nice if everything in /usr not required to boot the system were encrypted. Is anybody here working on a similar configuration? Do you have any suggestions how to best accomplish some or all of these requirements? Sample modifications to rc.*? Thanks in advance, --Lucky To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
DRM_LINUX, potential draw backs?
Are there any potential draw backs to enabling DRM_LINUX? Or should DRM_LINUX be enabled whenever one enables COMPAT_LINUX? This has not been clear to me from reading NOTES. Thanks, --Lucky Green To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Request: remove ssh1 fallback
David wrote: Thus spake Steven Ames [EMAIL PROTECTED]: Making SSH 2 the default is one thing. Removing SSH 1 as a fallback altogether is going to break compatibility with other systems like you'd never believe. For example, I regularly need to SSH into Solaris boxen running SSH 1. These machines aren't secure anyway, and since there's nothing I can do about it, I don't want any surprises when I upgrade. I think he was suggesting removing it from the sshd server, not the client. You can always specify the protocol on the command line with the client even if it didn't fall back... and again he's suggesting it for the default configuration, you can always change the configuration. I'm not necessarily for this change I just want to be sure what change is being suggested :) In either case, you break compatibility. Say I wanted to SSH from those Solaris boxen to my home machine, for example. (I don't, but that's not the point.) If my SSH server didn't have the SSH 1 fallback, there's nothing I could do from the command line to allow me to log in. My apologies if I my request was unclear: I am indeed only proposing to remove ssh1 fallback mode from the default configuration file of sshd, not from the default configuration of the ssh client. This change would not impact any users of existing FreeBSD installations as client or server. If somebody installs a fresh installation of FreeBSD 5.0 on a machine it would out-of-the-box support login by ssh2 only. Anybody that wishes to enable ssh1 on this fresh install remains able to do so. An upgrade shouldn't break your ssh settings regardless. Yes, this change would, out of the box, potentially come as a noticeable surprise for a small number of users: a user that needs to be able to log into a 5.0 box from a machine on which ssh2 is not available would manually need to enable ssh1 login in their sshd_config file. But I would argue that permitting ssh1 login into a machine should be a conscious act taken by the administrator by editing the config file, not something that a distribution should enable by default in a new install. Hope that helps somewhat clarify the scope of my request, --Lucky Green To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: 5.0-RUSH: -current install testers wanted!
Poul-Henning Kamp wrote: [requesting 5.0 testers] If you don't have the machine-power to run make release yourself, I hope the japanese snapshot server is producing good snapshots, if that fails, I would appreciate if somebody will produce and put up good releases and/or ISO images somewhere. It would be very helpful if somebody could provide those of us ready to start testing with the precise URL to the floppies/ISOs of a particular build that should be tested. --Lucky Green, who earlier today installed the HD on which 5.0 will live. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Request: remove ssh1 fallback
If I understand correctly, the next opportunity after 5.0R to make a change of such significance is FreeBSD 6.0. Since I suspect that few folks will want to have ssh1 enabled by the time 6.0 is released, I would like to request for the team to please consider disabling ssh1 fallback prior to 5.0R. Ssh1 is fundamentally broken. It uses a CRC where a MAC is required. While the attack detection logic in the code looks good, I don't know of many cryptographers that would be willing to bet that no further attacks exploiting ssh1's design flaws will be found. Ssh1 is a potential security hole with very little utility remaining given that ssh2-capable versions of ssh are readily available for a host of platforms and in fact have been so for some time. I therefore believe that the 5.0 release represents a perfect opportunity to remove ssh1 fallback from the default distribution of FreeBSD and hope the FreeBSD team will consider this change. Thanks, --Lucky Green To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FireWire in 5.0?
I need to plan for some new servers by the end of the year. One of the boxes will require support for FireWire IEEE 1394. While I don't expect 5.0 to ship by November 20, I was wondering what the developers on this list believe the odds are that the FireWire code will make it into a stable 5.0 release by, say, January? I am aware that there is existing FireWire code, I am just wondering by when you think the integration will likely be done. Thanks in advance, --Lucky Green To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Suggestion to disable ssh1 in FreeBSD 5.0
FreeBSD Gurus, I would like to suggest for the FreeBSD team to please consider disabling support for ssh1 in the default configuration of sshd starting with FreeBSD 5.0 for the following reasons: 1) The ssh1 protocol is fundamentally insecure. The protocol uses a CRC where a MAC is needed, permitting the insertion of data in to the connection. While there have been various patches over the years that attempt to detect attacks trying to exploit this security hole, no patch can ever fully fix this security hole. Sure, we may not at present know an exploit that could be successfully launched against the present ssh1, but few security experts feel comfortable another, or even several other, such exploit will not be found. Consequently, many security conscious folks long disabled ssh1 access to their servers. 2) While compatibility was once a problem, by now there are a sufficient number of free ssh2-capable clients available on wide range of platforms. It must be the rare case in which a server truly needs to maintain the use of ssh1 because there are no ssh2 clients for the client platform. (I can't even think of one such client platform, though don't doubt they exist). At any rate, ssh2-capable clients have become sufficiently widely available and will be even more widely available by the time FreeBSD 5.0 is released that compatibility is losing strength as an argument to leave ssh1 enabled by default. If somebody truly needs ssh1 they will know how to edit a config file. 3) Compatibility reducing security is typically not a good thing. I therefore would like to ask the FreeBSD team to please consider to, in the default configuration of FreeBSD 5.0, only enable ssh2 for sshd. Thanks, --Lucky Green To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
