Re: System randomly not logging complete bi-directional traffic.
Thanks for everyone's patients. In reply to Michael asking about the rule set used; the issue happens without ipfw. We temporarily employed ipfw to help and confirm whether traffic was in fact coming into port 80 and while randomly not being logged or seen by FreeBSD's syslogd, or by the web server. It became more of a concern when both tshark and tcpdump are seen capturing the traffic in both directions, yet the web server nor syslogd (before using ipfw), were found to randomly not log certain incoming traffic to port 80; as can be seen by the sample provided in the beginning of this thread. So, to be perfectly clear, with or without ipfw this logging issue remains. Sorry to have missed your prior post - please include the entire ruleset. Thanks. On Sun, Oct 9, 2011 at 10:28 AM, freebsd_u...@guice.ath.cx wrote: freebsd-questions@freebsd.org # # # FreeBSD_7-4 RELEASE # Our hardware is pristine # # What is described herein are regular, yet random occurrences; we need help. We have already performed a reinstall of FreeBSD_7-4 RELEASE (and the daemons in question); the issue remains. Below, is part of a conversation with an httpd whereby the packets (entire conversations) are randomly 'not' being logged and/or seen by either the httpd nor ipfw (logging enabled), yet both tshark and tcpdump are capturing everything. To be perfectly clear, httpd and ipfw (randomly) will not see/log anything of an 'entire conversation'. It is not like it drops certain packets of a conversation; they (httpd/ipfw) either see and log everything during a conversation, or, 'do not see' and 'do not log' any packet associated with a given conversation; all the while tshark and tcpdump are capturing everything (bidirectional); hence the connection is real. The capture below was witnessed by both tshark and tcpdump, but not logged via the httpd or the following ipfw rule: $cmd 00029 deny log logamount 0 ip from table(1) to me 80 The above ipfw rule functions properly from table(1) which contains -- ip.ip.ip.ip/32 -- one (1) ip per line. The names (below) were changed to protect the innocent; yeah right. Internet Protocol Version 4, Src: ex.ter.nal.ip (ex.ter.nal.ip), Dst: in.ter.nal.ip (in.ter.nal.ip) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 00.. = Differentiated Services Codepoint: Default (0x00) ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 60 Identification: 0x8ce5 (36069) Flags: 0x02 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 251 Protocol: TCP (6) Header checksum: 0x9102 [correct] [Good: True] [Bad: False] Source: ex.ter.nal.ip (ex.ter.nal.ip) Destination: in.ter.nal.ip (in.ter.nal.ip) Transmission Control Protocol, Src Port: 46463 (46463), Dst Port: http (80), Seq: 0, Len: 0 Source port: 46463 (46463) Destination port: http (80) [Stream index: 19] Sequence number: 0 (relative sequence number) Header length: 40 bytes Flags: 0x02 (SYN) 000. = Reserved: Not set ...0 = Nonce: Not set 0... = Congestion Window Reduced (CWR): Not set .0.. = ECN-Echo: Not set ..0. = Urgent: Not set ...0 = Acknowledgement: Not set 0... = Push: Not set .0.. = Reset: Not set ..1. = Syn: Set [Expert Info (Chat/Sequence): Connection establish request (SYN): server port http] [Message: Connection establish request (SYN): server port http] [Severity level: Chat] [Group: Sequence] ...0 = Fin: Not set Window size value: 5840 [Calculated window size: 5840] Checksum: 0xe7f8 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Options: (20 bytes) Maximum segment size: 1460 bytes TCP SACK Permitted Option: True Timestamps: TSval 309029146, TSecr 0 Kind: Timestamp (8) Length: 10 Timestamp value: 309029146 Timestamp echo reply: 0 No-Operation (NOP) Window scale: 7 (multiply by 128) Kind: Window Scale (3) Length: 3 Shift count: 7 [Multiplier: 128] Frame Number: 51 Frame Length: 74 bytes (592 bits) Capture Length: 74 bytes (592 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ip:tcp] Ethernet II, Src: Router_cf:gr:f0 (11:52:c3:fd:dd:f0), Dst: Goe_40:84:21 (00:15:18:40:28:41) Destination: Goe_40:84:21 (00:15:18:40:28:41) Address: Goe_40:84:21
System randomly not logging complete bi-directional traffic.
freebsd-questions@freebsd.org # # # FreeBSD_7-4 RELEASE # Our hardware is pristine # # What is described herein are regular, yet random occurrences; we need help. We have already performed a reinstall of FreeBSD_7-4 RELEASE (and the daemons in question); the issue remains. Below, is part of a conversation with an httpd whereby the packets (entire conversations) are randomly 'not' being logged and/or seen by either the httpd nor ipfw (logging enabled), yet both tshark and tcpdump are capturing everything. To be perfectly clear, httpd and ipfw (randomly) will not see/log anything of an 'entire conversation'. It is not like it drops certain packets of a conversation; they (httpd/ipfw) either see and log everything during a conversation, or, 'do not see' and 'do not log' any packet associated with a given conversation; all the while tshark and tcpdump are capturing everything (bidirectional); hence the connection is real. The capture below was witnessed by both tshark and tcpdump, but not logged via the httpd or the following ipfw rule: $cmd 00029 deny log logamount 0 ip from table(1) to me 80 The above ipfw rule functions properly from table(1) which contains -- ip.ip.ip.ip/32 -- one (1) ip per line. The names (below) were changed to protect the innocent; yeah right. Internet Protocol Version 4, Src: ex.ter.nal.ip (ex.ter.nal.ip), Dst: in.ter.nal.ip (in.ter.nal.ip) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 00.. = Differentiated Services Codepoint: Default (0x00) ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 60 Identification: 0x8ce5 (36069) Flags: 0x02 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 251 Protocol: TCP (6) Header checksum: 0x9102 [correct] [Good: True] [Bad: False] Source: ex.ter.nal.ip (ex.ter.nal.ip) Destination: in.ter.nal.ip (in.ter.nal.ip) Transmission Control Protocol, Src Port: 46463 (46463), Dst Port: http (80), Seq: 0, Len: 0 Source port: 46463 (46463) Destination port: http (80) [Stream index: 19] Sequence number: 0(relative sequence number) Header length: 40 bytes Flags: 0x02 (SYN) 000. = Reserved: Not set ...0 = Nonce: Not set 0... = Congestion Window Reduced (CWR): Not set .0.. = ECN-Echo: Not set ..0. = Urgent: Not set ...0 = Acknowledgement: Not set 0... = Push: Not set .0.. = Reset: Not set ..1. = Syn: Set [Expert Info (Chat/Sequence): Connection establish request (SYN): server port http] [Message: Connection establish request (SYN): server port http] [Severity level: Chat] [Group: Sequence] ...0 = Fin: Not set Window size value: 5840 [Calculated window size: 5840] Checksum: 0xe7f8 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Options: (20 bytes) Maximum segment size: 1460 bytes TCP SACK Permitted Option: True Timestamps: TSval 309029146, TSecr 0 Kind: Timestamp (8) Length: 10 Timestamp value: 309029146 Timestamp echo reply: 0 No-Operation (NOP) Window scale: 7 (multiply by 128) Kind: Window Scale (3) Length: 3 Shift count: 7 [Multiplier: 128] Frame Number: 51 Frame Length: 74 bytes (592 bits) Capture Length: 74 bytes (592 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ip:tcp] Ethernet II, Src: Router_cf:gr:f0 (11:52:c3:fd:dd:f0), Dst: Goe_40:84:21 (00:15:18:40:28:41) Destination: Goe_40:84:21 (00:15:18:40:28:41) Address: Goe_40:84:21 (00:15:18:40:28:41) ...0 = IG bit: Individual address (unicast) ..0. = LG bit: Globally unique address (factory default) Source: Router_cf:gr:f0 (11:52:c3:fd:dd:f0) Address: Router_cf:gr:f0 (11:52:c3:fd:dd:f0) ...0 = IG bit: Individual address (unicast) ..0. = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol Version 4, Src: ex.ter.nal.ip (ex.ter.nal.ip), Dst: in.ter.nal.ip (in.ter.nal.ip) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 00.. = Differentiated Services Codepoint: Default (0x00) ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport)
Re: IDE -- mount partitions for better performance
Annotated below ... Hi, On Tuesday 15 March 2011 07:00:30 freebsd_u...@guice.ath.cx wrote: freebsd-questions@freebsd.org Guidance with the following: We are limited to Support for ATA-100/66/33 IDE and ATAPI compliant devices. With that said, we have our atapi/33 optical on a add in controller (PCI) and are seeking to place four HDDs on the main boards controllers. Our dilemma is where to place /, /tmp, /usr and /var from a performance standpoint. We understand that /var does quite a bit of writing and probably should go on the master hdd, but what about the /usr, /tmp and root? Hell, Im not sure my thinking is sane as to where I think /var should be placed/mounted. did I get it right? You have four hard disks? Yes, four separate HDD's If so, place /, /var /tmp on indiidual drives. Make the fourth disk usr and mount the remaining space of the other three disks inside /usr/home. Are you suggesting something similar to: /dev/ad4s1a for / /dev/ad4s2a for /tmp /dev/ad4s3a for /usr /dev/ad4s4a for /var If so, my initial can current concern is which device (hdd) from the above list/configuration, should be connected to which cable connector (master or slave)? --depending on how much writing to a particular device is taking place; for instance during a 'build world' or while building anything from src. there is quite a bit of writing going on. I would think that making the disk/slice that is being written to a slave would decrease performance when the master to that slave is also being written to simultaneously. In such a case the slave would need to wait until the master is done writing before the slave would be able to write; Is my thinking on this sane? Please enlighten me/us. Thank you. Locate then stuff on the other three disks which you expect to be used in parallel with the /usr disk. I'm lost on the above suggestion; not understanding this. Of course, you can mount it anywhere else if you want. Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
IDE -- mount partitions for better performance
freebsd-questions@freebsd.org Guidance with the following: We are limited to Support for ATA-100/66/33 IDE and ATAPI compliant devices. With that said, we have our atapi/33 optical on a add in controller (PCI) and are seeking to place four HDDs on the main boards controllers. Our dilemma is where to place /, /tmp, /usr and /var from a performance standpoint. We understand that /var does quite a bit of writing and probably should go on the master hdd, but what about the /usr, /tmp and root? Hell, Im not sure my thinking is sane as to where I think /var should be placed/mounted. Thanks for the read of this. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Custom Kernel -- Module exclusion by association
My meaning in the 'subject' is: Currently we want to: 'options QUOTA' in the kernel. We do not want to compile any modules that we don't have to (effort to save time). If adding support for 'QUOTA' doesn't require any module rebuilding, how do we specify/exclude 'all' module building using 'WITHOUT_MODULES' in the /etc/make.conf? In addition, if there are modules that need to be rebuilt in 'association' with the 'options QUOTA', or any other kernel addition, how are we to tell 'what is' needed and/or what 'is not' needed before blindly omitting modules from the kernel build process? 2) The man make.conf shows a listing for 'KERNCONF', the installed (7.3) file: /usr/share/examples/etc/make.conf makes no mention of this. Should we decide to employ the use of 'KERNCONF' within our /etc/make.conf, does this get auto-magically read if we only type: env -i make buildkernel KERNCONF --without typing a configuration filename? Assuming of course we saved the named file in /usr/src/sys/arch/conf. Thanks for taking the time to read my msg. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Upgrading from 6.3-p3 -to- 7.x-p4 -- SENDMAIL -- TECRA
The short version of this: after the entire build and installworld process the base-SENDMAIL appeared to be fully running but was not functioning correctly, no incoming or outgoing mail --not from the local box to the Inet and nothing IN from the Inet until we = cd /etc/mail make all make install make restart. Given that we just did a build, installworld, what would cause SENDMAIL (base install) to be running and not work correctly without us having to issue the above commands? /END SHORT EXPLANATION === Here are the commands we used to build from src: /usr/bin/env -i /usr/bin/make -DALWAYS_CHECK_MAKE buildworld /usr/bin/env -i /usr/bin/make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=GENERIC /usr/bin/env -i /usr/bin/make -DALWAYS_CHECK_MAKE installkernel KERNCONF=GENERIC === with focus on -DALWAYS_CHECK_MAKE Details below ... === After rebooting, post installworld and mergemaster the following took place: WORKSTATION# ps aux |grep -i sendmail root 854 0.0 0.2 7776 4712 ?? Ss1:34AM 0:01.92 sendmail: accepting connections (sendmail) smmsp 858 0.0 0.2 5924 3324 ?? Is1:34AM 0:00.04 sendmail: Queue [EMAIL PROTECTED]:30:00 for /var/spool/client root 4222 0.0 0.2 7904 4988 ?? S 3:10PM 0:00.07 sendmail: ./m8BJA1J7004220 nmlsrvr2.ins.state.ny.us.: root 4250 0.0 0.1 1628 1068 p1 L+3:11PM 0:00.02 grep -i sendmail === Above, SENDMAIL is running however, nothing is INcoming or OUTgoing (Inet) === Below, looking for something obvious; perhaps a typo or change in a config file. WORKSTATION# cat /etc/rc.conf |grep -i sendmail mta_start_script=/etc/rc.sendmail # Settings for /etc/rc.sendmail and /etc/rc.d/sendmail: sendmail_enable=YES # Run the sendmail inbound daemon (YES/NO). WORKSTATION# cat /etc/defaults/rc.conf | grep -i sendmail mta_start_script=/etc/rc.sendmail # Settings for /etc/rc.sendmail and /etc/rc.d/sendmail: sendmail_enable=NO# Run the sendmail inbound daemon (YES/NO). sendmail_pidfile=/var/run/sendmail.pid# sendmail pid file sendmail_procname=/usr/sbin/sendmail # sendmail process name sendmail_flags=-L sm-mta -bd -q30m # Flags to sendmail (as a server) sendmail_submit_enable=YES# Start a localhost-only MTA for mail submission sendmail_submit_flags=-L sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost sendmail_outbound_enable=YES # Dequeue stuck mail (YES/NO). sendmail_outbound_flags=-L sm-queue -q30m # Flags to sendmail (outbound only) sendmail_msp_queue_enable=YES # Dequeue stuck clientmqueue mail (YES/NO). sendmail_msp_queue_flags=-L sm-msp-queue -Ac -q30m # Flags for sendmail_msp_queue daemon. sendmail_rebuild_aliases=NO # Run newaliases if necessary (YES/NO). WORKSTATION# cat /etc/make.conf # added by use.perl 2008-08-04 02:29:43 PERL_VER=5.8.8 PERL_VERSION=5.8.8 SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl2 SENDMAIL_MC=/etc/mail/WORKSTATION.mc SENDMAIL_SUBMIT_MC=/etc/mail/WORKSTATION.submit.mc === Lets try and fix things (SENDMAIL) by doing the following: WORKSTATION# make all /usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/ /usr/share/sendmail/cf/m4/cf.m4 /etc/mail/WORKSTATION.mc /etc/mail/WORKSTATION.cf /usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/ /usr/share/sendmail/cf/m4/cf.m4 /etc/mail/WORKSTATION.submit.mc /etc/mail/WORKSTATION.submit.cf WORKSTATION# make install install -m 444 /etc/mail/WORKSTATION.cf /etc/mail/sendmail.cf install -m 444 /etc/mail/WORKSTATION.submit.cf /etc/mail/submit.cf WORKSTATION# make restart Restarting: sendmail sendmail-clientmqueue. WORKSTATION# ps auxwww | grep -i sendmail smmsp4331 0.0 0.2 5924 3404 ?? Is3:18PM 0:00.01 sendmail: Queue [EMAIL PROTECTED]:30:00 for /var/spool/clientmqueue (sendmail) root 4333 0.0 0.2 7776 4844 ?? Ss3:18PM 0:00.16 sendmail: accepting connections (sendmail) root 4589 0.0 0.2 7776 4976 ?? I 4:18PM 0:00.02 sendmail: ./m8BJA1J7004220 nmlsrvr2.ins.state.ny.us.: user open (sendmail) root 4600 0.0 0.1 1628 1068 p1 R+4:21PM 0:00.00 grep -i sendmail === After looking at the output of ps auxwww | grep -i sendmail == both before and after re_making things within /etc/mail, you'll see that different instances of the same processes are running --nothing more, nothing less. I guess a more focused and/or additional question would be; what command, if any, did we run that wasn't run during the build, installworld procedure in which SENDMAIL was to be included (rebuilt)? Did we shoot ourselves in the foot -or- is there cause for concern in the buildworld process with regards to SENDMAIL while upgrading from 6.3-p3 to 7.x-p4? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kldxref: file isn't dynamically-linked^M -- TECRA
Chris Hill wrote: On Wed, 10 Sep 2008, Polytropon wrote: [snip] I'm sure you noticed the Ctrl-M (^M) at the ends of each line. This seems to be an MS-DOS-like line break (ASCII 0x13 + 0x10). UNIX (and so FreeBSD) use the NL or LF character 0x10. And 0x13 is the CR character which is equivalent to Ctrl-M, if I do remember correctly. Almost correctly. ASCII CR (Ctrl-M) is 0x0d, which is decimal 13; ASCII LF (Ctrl-J or newline) is 0x0a, which is decimal 10. Sorry for the off-topic pedantry. -- Chris Hill [EMAIL PROTECTED] ** [ Busy Expunging | ] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] While I do appreciate your efforts, both of you gentlemen did not address the issue at hand. I have found what was needed to either fix or work around the topic of discussion at this URL: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2007-10/msg00314.html Unfortunately for me, I'm not subscribed to nor did I search the other FreeBSD mail list for this particular issue as I don't run 'stable' or '-Current'. For anyone else reading this thread and/or bumping in to this problem, use the above URL or link to bring closure. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
kldxref: file isn't dynamically-linked^M -- TECRA
# uname -a FreeBSD 6281.domain.net 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Jan 16 04:45:4 5 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386 ##--- cvsup the src # @(#)newvers.sh 8.1 (Berkeley) 4/20/94 # $FreeBSD: src/sys/conf/newvers.sh,v 1.72.2.5.2.8 2008/09/03 19:09:47 simon Exp TYPE=FreeBSD REVISION=7.0 BRANCH=RELEASE-p4 ## ## HERE WE GO ... ## ##-- Contents of /etc/make.conf # cat /etc/make.conf # added by use.perl 2008-09-09 00:29:14 PERL_VER=5.8.8 PERL_VERSION=5.8.8 ## -- END Contents /etc/make.conf cd /usr/src env -i make -DALWAYS_CHECK_MAKE buildworld ## The above appears to work fine. script bk.out env -i make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=GENERIC env -i make -DALWAYS_CHECK_MAKE installkernel KERNCONF=GENERIC bk2.out make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=GENERIC make -DALWAYS_CHECK_MAKE installkernel KERNCONF=GENERIC bk3.out make buildkernel KERNCONF=GENERIC make installkernel KERNCONF=GENERIC ## Using any of the above commands yield: === zyd (install)^M install -o root -g wheel -m 555 if_zyd.ko /boot/kernel^M install -o root -g wheel -m 555 if_zyd.ko.symbols /boot/kernel^M kldxref /boot/kernel^M kldxref: file isn't dynamically-linked^M kldxref: ## We made a slight change to the above commands, instead of 'buildkernel' or 'installkernel' we just used 'kernel' in each and every command line shown above and re_ran the command. Which resulted in the same results shown above. What are we doing incorrectly? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Starting and using services -- Single-user mode -- TECRA_A9-S9017
I have the need to start and use service while in single_user mode. To this point I'm not able to use 'top' or 'ps' respectively. In addition,from the CLI; when I attempt to start services such as 'portmap' and 'sshd' nothing is shown running via 'ps'. All I see are the headers when I issue th 'ps aux' command. I'm sure its possible to do what I'm attempting, but given the crippled situation of this box, I'm stuck in Single-user mode and need to start enough services that will allow the use of 'scp' in order to move some zipped/crucial files from the crippled box to another machine on the same network. There are no other options, I need to do this from single-user mode. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Starting and using services -- Single-user mode -- TECRA_A9-S9017
Ivan Voras wrote: [EMAIL PROTECTED] wrote: I have the need to start and use service while in single_user mode. To this point I'm not able to use 'top' or 'ps' respectively. In ps is in /bin, top is in /usr/bin ; unless you a) have your PATH wrong or b) commonly put /bin on separate file systems, you should be able to use ps and others in /bin and /sbin. addition,from the CLI; when I attempt to start services such as 'portmap' and 'sshd' nothing is shown running via 'ps'. All I see are the headers when I issue th 'ps aux' command. Are your world and kernel matched? This is a failed 4.x to 5.x upgrade which I really don't want to address any further. Currently, as a last effort to save this 'current' install I'm doing a 'make buildworld, buildkernel, installkernel and installworld as we speak. Should this fail I'll continue with the topic of this discussion = while in single-user mode, start enough services to use 'scp' and 'mv' curcial files over to another machine thereafter do a fresh install on the failed box in question. I'm sure its possible to do what I'm attempting, but given the crippled situation of this box, I'm stuck in Single-user mode and need to start enough services that will allow the use of 'scp' in order to move some zipped/crucial files from the crippled box to another machine on the same network. Until now I've tried fsck -p ; mount -u / ; mount -a -t ufs ; swapon -a We will try your suggestions once the building finishes (on it own) to first see if the new build process has fixed everything (multi-user) that was broken and if not, we'll follow your recommendation(s). When you enter single user mode, root file system is mounted read-only so one of the first things you need to do is mount -u -o rw /. Next, you need to mount your other file systems (/usr is usually a separate file system and that's where ssh lives) so do mount -a. At this point you might as well cancel the single-user mode by exiting the shell and go multi-user. If there are file system errors. mount -a will fail and you'll need to mount other file systems by hand. The only errors or warnings we've experienced where listed in the 4.x to 5.x section of the 5.5 /usr/src/UPDATING file with reference to 'userland' The UPDATING said to ignore these errors. Obviously something is seriously wrong with that section on updating from 4.x to 5.x Enough said, we'll post one way or the other once the build is done. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
TECRA_A9-S9017 -- /usr/src/UPDATING -- Machine is down.
The short version is, the machine will not enter multi-user mode after we followed the instructions or directions within /usr/src/UPDATING . the SECTION entitled: To upgrade in-place from 4.x-stable to 5.x - While we are able to enter single-user mode with no apparent issues, attempting to enter multi-user mode yields the following: date init can't exec getty '/usr/libexec/getty' for port /dev/ttyv0: The above line takes place for all the ttyv's listed in /etc/ttys. We've checked the entries in /etc/ttys as-well-as checked to be sure /usr/libexec/getty was in fact in its proper place with correct permissions. Because this upgrade went sideways we are only soliciting help to reboot into multi-user mode to retrieve the data which our level.0/9 dump(s) failed to get .thereafter we'll do a fresh install and return this machine to service. What can we do at this point to accomplish our goal of booting in to multi-user mode? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TECRA_A9-S9017 -- /usr/src/UPDATING -- Machine is down.
On Mon, Aug 25, 2008 at 10:04:09AM -0400, David Gurvich wrote: Are you sure you've updated all of /etc, particularly the login? Initially no we didn't; because the plan was to do: 4.x -- 5.5 -- 6.3. However, once the machine failed to boot in to multi-user mode, we revisited mergemaster and installed all the newer versions of /etc/*; we are still left with only being able to boot in to single-user mode and 'not' multi-user mode. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TECRA_A9-S9017 -- /usr/src/UPDATING -- Machine is down.
On Mon, Aug 25, 2008 at 08:10:24PM +, Christopher Joyner wrote: On Mon, Aug 25, 2008 at 8:09 PM, Christopher Joyner [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 7:27 PM, [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 10:04:09AM -0400, David Gurvich wrote: Are you sure you've updated all of /etc, particularly the login? Initially no we didn't; because the plan was to do: 4.x -- 5.5 -- 6.3. However, once the machine failed to boot in to multi-user mode, we revisited mergemaster and installed all the newer versions of /etc/*; we are still left with only being able to boot in to single-user mode and 'not' multi-user mode. I had a certain problem not to long ago, and running sysinstall in single-user mode, than installing the base installation of the system, that fixed my problem. Do you think installing the base from sysinstall could fix this? Already tried that. We keep getting messages of not being able to find the files for bin even though we type in the direct URL of the ftp:// that houses the archived versions 4.x to 5.x of freebsd, but, it (sysinstall and friends) is able to find the balance of the files; man apges, docs, etc ... We have no interest in save this UPGRADE. We just want to be able to boot in to multi-user mode in order to get some files that dump, for some reason or another, was unable to get on a level 0 or 9. On the other hand, if we can find another network, we'll try and configure the box for LAN access (single-user) and scp what we need, thereafter doing a fresh 'Dangerously Dedicated' install. That is, if we can't get this getty issue temporarily repaired. Your thoughts ... ? I wanted to add, it would probably delete all your configuration files, such as your groups and users. Which is why I did it. For completness, we aren't interested in saving this install, just the files that our dump 0 and 9 failed to get. There is a temp laptop holding on until we can get this machine back online with a fresh install. Thank you for your replies. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
buildworld, buildkernel, installkernel, shutdow now, fsck -p -- NO WRITE ACCESS
I do not code in any way. With that being said, should you be able to help please do so with the knowledge that I can not code. I'm following the freebsd handbook when the following occurs. -- separate fresh 'dangerously dedicated' installs of both 7.0 and 6.3-RELEASE on the same machine, yield the following: In multi-user mode make buildworld, buildkernel and installkernel. Shutdown now -- fsck -p /dev/ad4s1a: NO WRITE ACCESS /dev/ad4s1a: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY This happens each and everytime no matter if I install from iso -or- ftp (passive). After numerous attempts the only way to get past this is 'fsck -y'. Could the fbsd handbook section I'm following need updating or is there another issue taking place here? 23.4.1 The Canonical Way to Update Your System 23.4.5 Drop to Single User Mode ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld, buildkernel, installkernel, shutdow now, fsck -p -- NO WRITE ACCESS
Daniel Bye wrote: On Mon, Aug 04, 2008 at 06:37:28PM -0400, email wrote: I thank you. In addition, I am quite sure the command we are referred to in 23.4.5 Drop to Single User Mode is in fact 'shutdown now' and not 'shutdown -r now'. Yes. But that section relates to dropping to single user mode for the duration of the build, not for the installworld phase. To quote from 23.4.5: You may want to *compile* the system in single user mode. (Emphasis mine) It is merely a possible preparatory step that some people like to take before embarking on the rest of the process. Section 23.4.9 goes on to talk about what to do after the world and kernel build are complete, and you have installed the new kernel: You should reboot into single user mode to test the new kernel works. Do this by following the instructions in Section 23.4.5. This refers specifically to the part of 23.4.5 that talks about rebooting into single user mode, and not the part that talks about dropping to single user mode. (A subtle, but important, distinction.) I would suggest that the simplest approach would be something like: # cd /usr/src # make buildworld make buildkernel # make installkernel (reboot into single user mode) # fsck -p # mount -u / # mount -at ufs # swapon -a # cd /usr/src # make installworld # mergemaster (Just so we're clear - section 23.4.5 talks about going to single user mode for the duration of the *first 3 steps* of the above process. As I mentioned previously, I have never found this step necessary, but there is certainly no harm in it, and it may be the sensible thing to do if your system has a lot of users logged in during normal operations. Note that you must still reboot after installing the new kernel, and before continuing to installworld.) Dan I followed 'your' suggestion/recommendation and did 'shutdown -r now' with great results; -- fsck -p works fine. However allow me to say that the fbsd handbook section 23.4.9, which I was initially following referred me back/up to section 23.4.5. The entire section -- 23.4 Rebuilding “world” only mentioned 'shutdown -r now' one (1) time in section 23.4.12. Had the fbsd handbook mentioned 'shutdown -r now' instead of referring the reader to another section perhaps I wouldn't be discussing this with you. :-) Sorry to make this longer than it needed to be. I thank you once again. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
