Re: Many processes stuck in zfs
On Mar 11, 2010, at 8:45 AM, Alexander Leidinger wrote: > Quoting Pawel Jakub Dawidek (from Wed, 10 Mar 2010 > 18:31:43 +0100): > > There is a 4th possibility, if you can rule out everything else: bugs in the > CPU. I stumbled upon this with ZFS (but UFS was exposing the problem much > faster). The problem in my case was that the BIOS was not recognizing the CPU > and as such was not uploading microcode updates. > > Borja, can you confirm that the CPU is correctly announced in FreeBSD (just > look at "dmesg | grep CPU:" output, if it tells you it is a AMD or Intel XXX > CPU it is correctly detected by the BIOS)? A CPU bug? Weird. Very. Let me explain the whole history of this. We are using ZFS to maintain a couple of servers in an active/passive arrangement. At 30 second intervals we create a snapshot on the master server and send it to the slave. Actually I prefer this scheme to drbd-style arrangements, but that's another story ;) We started our tests and soon ran into problems: deadlocked filesystem. At one point I remember that the deadlock affected UFS as well, not only ZFS. I mean, having both ZFS and UFS, the system also lost access to the UFS filesystems when this happened. Looking at the hours when it happened, it turned out to be one or two of these events: periodic scripts running (which, among other things, traverse the whole filesystem) and/or a backup being made with Bacula. Either way, there seemed to be a problem: read activity on a dataset on which I was receiving a snapshot at the same time could lead to a deadlock. I am sure I have never tried to receive two snapshots simultaneously, etc. The replicating program guaratees it. As the servers had to be rolled into production, and such tests with real servers can be quite time consuming, I set up a couple of FreeBSD virtual machines, using VMWare Fusion (version 2 then, now version 3) on a Macbook (Macbook 4,1 Intel Core2Duo, 2.1 GHz) and tried to reproduce it. To reproduce it, I set up a "master" machine, with /usr/src and /usr/obj on a dataset (pool/src), replicating it at 30 second intervals to another virtual machine, the slave. On the slave, I launch "tar" in an infinite loop, so that the contents of the replicated dataser (pool/src) is copied to another dataset (pool/thecopy). With that running, and, remember, there are replications at 30 second intervals (longer if a replication takes a long time, of course) I run a make buildworld on the master machine. The destination soon gets deadlocked. I have tried to fiddle with the virtual machine, for example, trying to offer a single or dual core CPU, and there's no difference. With dual cores it *seems* to deadlock earlier, but I'm not sure. For the latest test results I've posted, I was using a single core CPU. The original machines on which I detected the problem (problem I have subsequently reproduced successfully on virtual machines running on VMWare Fusion) are Dell PowerEdge 2950, and this is the CPU description: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2496.25-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff Features2=0x40ce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8250003456 (7867 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 8 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 The virtual machine (VMWare Fusion 3.0.0, Macbook, Mac OS X 10.6.2) reports this: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz (2116.62-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xfebfbff Features2=0x80082201> AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 1153433600 (1100 MB) avail memory = 1090441216 (1039 MB) ACPI APIC Table: MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 In order to compare to Solaris, I installed a virtual machine running Solaris 10 as well, and used it as a target f
Re: Many processes stuck in zfs
Quoting Borja Marcos (from Thu, 11 Mar 2010 09:54:47 +0100): On Mar 11, 2010, at 8:45 AM, Alexander Leidinger wrote: Quoting Pawel Jakub Dawidek (from Wed, 10 Mar 2010 18:31:43 +0100): There is a 4th possibility, if you can rule out everything else: bugs in the CPU. I stumbled upon this with ZFS (but UFS was exposing the problem much faster). The problem in my case was that the BIOS was not recognizing the CPU and as such was not uploading microcode updates. Borja, can you confirm that the CPU is correctly announced in FreeBSD (just look at "dmesg | grep CPU:" output, if it tells you it is a AMD or Intel XXX CPU it is correctly detected by the BIOS)? A CPU bug? Weird. Very. It depends. CPUs have bugs. You do not want to run any modern CPU without an microcode update. The BIOS is doing it for you at system start. I do not want to say that this is the problem you have, I just want to point out that it may be possible (but see below). I got hit by this last december and I was finding the solution (replacing the complete system, as only replacing the CPU was not an option) in January. As the servers had to be rolled into production, and such tests with real servers can be quite time consuming, I set up a couple of FreeBSD virtual machines, using VMWare Fusion (version 2 then, now version 3) on a Macbook (Macbook 4,1 Intel Core2Duo, 2.1 GHz) and tried to reproduce it. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2496.25-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 The virtual machine (VMWare Fusion 3.0.0, Macbook, Mac OS X 10.6.2) reports this: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz (2116.62-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Summary: you confirmed the problem on a different kind of CPU. Because of this it makes it even more unlikely that it is a CPU problem. Bye, Alexander. -- A good plan today is better than a perfect plan tomorrow. -- Patton http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Many processes stuck in zfs
Quoting Ivan Voras (from Thu, 11 Mar 2010 11:59:01 +0100): On 03/11/10 09:54, Borja Marcos wrote: I don't know about the rest but this: CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2496.25-MHz K8-class CPU) does not agree with this: FreeBSD/SMP: 1 package(s) x 8 core(s) The Xeon 54xx series does not come in 8 core packages. Either it is 2xquad-core or a Xeon 55xx. Can also be a problem in the layout detection logic... Bye, Alexander. -- If we can ever make red tape nutritional, we can feed the world. -- R. Schaeberle, "Management Accounting" http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Many processes stuck in zfs
On 03/11/10 15:09, Alexander Leidinger wrote: Quoting Ivan Voras (from Thu, 11 Mar 2010 11:59:01 +0100): On 03/11/10 09:54, Borja Marcos wrote: I don't know about the rest but this: CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2496.25-MHz K8-class CPU) does not agree with this: FreeBSD/SMP: 1 package(s) x 8 core(s) The Xeon 54xx series does not come in 8 core packages. Either it is 2xquad-core or a Xeon 55xx. Can also be a problem in the layout detection logic... Not likely, because the 54xx family is very wide spread and nothing special with regards to its topology. It also has the same topology as 53xx. These are systems limited to two physical sockets, each of which can have a single, dual or a quad core CPU and the 5xxx motherboards accept all CPUs from series 50xx, 51xx, 52xx, 53xx, 54xx. In short - these are very, very common systems. My guess would be that someone, somewhere is lying - I don't know if CPUID can be (wrongly) updated by microcode, for example, or if the mptable can be corrupted in a way to represent two physical (socketed) CPUs as one. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_6 tinderbox] failure on i386/i386
TB --- 2010-02-12 20:33:34 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2010-02-12 20:33:34 - starting RELENG_6 tinderbox run for i386/i386 TB --- 2010-02-12 20:33:34 - cleaning the object tree TB --- 2010-02-12 20:34:04 - cvsupping the source tree TB --- 2010-02-12 20:34:04 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/i386/i386/supfile TB --- 2010-03-11 16:57:46 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-03-11 16:57:46 - ERROR: unable to cvsup the source tree TB --- 2010-03-11 16:57:46 - 4.11 user 4.67 system 2319851.44 real http://tinderbox.freebsd.org/tinderbox-releng_6-RELENG_6-i386-i386.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_6 tinderbox] failure on amd64/amd64
TB --- 2010-02-12 20:14:26 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2010-02-12 20:14:26 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2010-02-12 20:14:26 - cleaning the object tree TB --- 2010-02-12 20:15:02 - cvsupping the source tree TB --- 2010-02-12 20:15:02 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile TB --- 2010-03-11 17:02:06 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-03-11 17:02:06 - ERROR: unable to cvsup the source tree TB --- 2010-03-11 17:02:06 - 3.93 user 4.78 system 2321259.84 real http://tinderbox.freebsd.org/tinderbox-releng_6-RELENG_6-amd64-amd64.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Many processes stuck in zfs
On Mar 11, 2010, at 3:08 PM, Alexander Leidinger wrote: >>> Borja, can you confirm that the CPU is correctly announced in FreeBSD (just >>> look at "dmesg | grep CPU:" output, if it tells you it is a AMD or Intel >>> XXX CPU it is correctly detected by the BIOS)? >> >> A CPU bug? Weird. Very. > > It depends. CPUs have bugs. You do not want to run any modern CPU without an > microcode update. The BIOS is doing it for you at system start. > > I do not want to say that this is the problem you have, I just want to point > out that it may be possible (but see below). I got hit by this last december > and I was finding the solution (replacing the complete system, as only > replacing the CPU was not an option) in January. Of course CPUs have bugs, I don't doubt it. I was just wondering how I coud reproduce the problem with a different hardware :) That's why I said it was unlikely. Besides, such a low level fault should produce many more problems than such a well defined failure mode, as far as I know. >> As the servers had to be rolled into production, and such tests with real >> servers can be quite time consuming, I set up a couple of FreeBSD virtual >> machines, using VMWare Fusion (version 2 then, now version 3) on a Macbook >> (Macbook 4,1 Intel Core2Duo, 2.1 GHz) and tried to reproduce it. > >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2496.25-MHz K8-class >> CPU) >> Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 > >> The virtual machine (VMWare Fusion 3.0.0, Macbook, Mac OS X 10.6.2) reports >> this: >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz (2116.62-MHz K8-class >> CPU) >> Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 > > Summary: you confirmed the problem on a different kind of CPU. > > Because of this it makes it even more unlikely that it is a CPU problem. Indeed :) Borja. > > Bye, > Alexander. > > -- > A good plan today is better than a perfect plan tomorrow. > -- Patton > > http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: proliant server lockups with freebsd-amd64-stable (2010-03-10)
On 03/11/10 04:39, Kai Gallasch wrote: > Hi. > > I have some trouble with an opteron server locking up spontaneously. It looses > all networks connectivity and even through console I can get no shell. > > Lockups occur mostly under disk load (periodic daily, bacula backup > running, make buildworld/buildkernel) and I can provoke them easily. try adding: vm.pmap.pg_ps_enabled="0" to /boot/loader.conf and reboot. Long thread reference: http://thread.gmane.org/gmane.os.freebsd.current/121035/focus=121457 possible AMD "errata 147" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: proliant server lockups with freebsd-amd64-stable (2010-03-10)
on 11/03/2010 20:25 Mark Atkinson said the following: > On 03/11/10 04:39, Kai Gallasch wrote: >> Hi. >> >> I have some trouble with an opteron server locking up spontaneously. It >> looses >> all networks connectivity and even through console I can get no shell. >> >> Lockups occur mostly under disk load (periodic daily, bacula backup >> running, make buildworld/buildkernel) and I can provoke them easily. > > try adding: > > vm.pmap.pg_ps_enabled="0" The lockups happen with this setting too. This is likely a red herring, because Kai already has Alan's workaround from head. > to /boot/loader.conf and reboot. > > Long thread reference: > > http://thread.gmane.org/gmane.os.freebsd.current/121035/focus=121457 > > possible AMD "errata 147" 147? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
make installworld problem
suddenly after a while my FreeBSD 8.0 stable machine always fails make installworld. it has rarely been a problem before and when I appeared I just rebooted into multi user, csup and build it all once again and then success. Now It always fails with an error saying this or that directory is empty...and csup and a new buildworld does not fix this. maybe you need more input to have an opinion...just name it and I`ll provide it. My machine functions perfectly, but I can not finalize upgrades right now...buggerem Blessed be.. Kenneth, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
I broke my SSH to jails after 7.2-8.0 src upgrade
Hi all, please forgive the verbosity, but I wanted to include as much detail as possible (without including config files) up front. Summary: SSH works to the jail box host OS, but not to the jails themselves. On a box that is dedicated to jails, I source upgraded from 7.2 to: FreeBSD jail.eagle.ca 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Mar 11 13:22:59 EST 2010 r...@jail.eagle.ca:/usr/obj/usr/src/sys/JAIL i386 I then proceeded to update each jail by `make installworld DESTDIR=$JAILDIR', followed by (for most, but not quite all jails), a `mergemaster -Uia'. During the upgrade of the host OS, I know I rebooted here: - after the `installkernel' phase of the host OS - after the `installworld' phase of the host OS ...in between the above stages, I performed a `mergemaster -Uia' Now, I can SSH into the host, but not the jails it contains. I have been Googling for hours trying to figure this out. I've honestly exhausted all of the possibilities I could find regarding the issue, even some that dated back to the good ol' 4.x days. It seemingly has something to do with tty/pts, but I just can't figure it out. When trying to SSH to a jail from the resident host OS: %ssh acct.eagle.ca Password: PTY allocation request failed on channel 0 Warning: no access to tty (Bad file descriptor). Thus no job control in this shell. ...and when I attempt SSH to a jail from a remote box, the connection drops immediately after I enter the password. In both cases, the following is logged into /var/log/messages within the jail host: Mar 11 21:35:40 acct sshd[8175]: error: openpty: No such file or directory Mar 11 21:35:40 acct sshd[8178]: error: session_pty_req: session 0 alloc failed A listing of the dev directory on the jail doesn't show pts (but it does on the host OS): %ll /usr/jails/acct/dev total 1 dr-xr-xr-x 2 root wheel 512 Mar 11 17:12 fd lrwxr-xr-x 1 root wheel14 Mar 11 17:12 log -> ../var/run/log crw-rw-rw- 1 root wheel0, 7 Mar 11 21:11 null crw-rw-rw- 1 root wheel0, 12 Mar 11 12:10 random lrwxr-xr-x 1 root wheel 4 Mar 11 17:12 stderr -> fd/2 lrwxr-xr-x 1 root wheel 4 Mar 11 17:12 stdin -> fd/0 lrwxr-xr-x 1 root wheel 4 Mar 11 17:12 stdout -> fd/1 lrwxr-xr-x 1 root wheel 6 Mar 11 17:12 urandom -> random crw-rw-rw- 1 root wheel0, 8 Mar 11 17:10 zero ...and I've tried to make Google-advised changes to the /etc/defaults/devfs.rules file to no avail. ;) All other services within the host OS and the jails are operating perfectly. I'm just missing my tty's. Can someone hit me with the cluebat, because I really feel that I've missed something. Thanks, Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
Sounds like you have something wrong with devfs.rules in jail section? On Mar 11, 2010 6:46 PM, "Steve Bertrand" wrote: Hi all, please forgive the verbosity, but I wanted to include as much detail as possible (without including config files) up front. Summary: SSH works to the jail box host OS, but not to the jails themselves. On a box that is dedicated to jails, I source upgraded from 7.2 to: FreeBSD jail.eagle.ca 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Mar 11 13:22:59 EST 2010 r...@jail.eagle.ca:/usr/obj/usr/src/sys/JAIL i386 I then proceeded to update each jail by `make installworld DESTDIR=$JAILDIR', followed by (for most, but not quite all jails), a `mergemaster -Uia'. During the upgrade of the host OS, I know I rebooted here: - after the `installkernel' phase of the host OS - after the `installworld' phase of the host OS ...in between the above stages, I performed a `mergemaster -Uia' Now, I can SSH into the host, but not the jails it contains. I have been Googling for hours trying to figure this out. I've honestly exhausted all of the possibilities I could find regarding the issue, even some that dated back to the good ol' 4.x days. It seemingly has something to do with tty/pts, but I just can't figure it out. When trying to SSH to a jail from the resident host OS: %ssh acct.eagle.ca Password: PTY allocation request failed on channel 0 Warning: no access to tty (Bad file descriptor). Thus no job control in this shell. ...and when I attempt SSH to a jail from a remote box, the connection drops immediately after I enter the password. In both cases, the following is logged into /var/log/messages within the jail host: Mar 11 21:35:40 acct sshd[8175]: error: openpty: No such file or directory Mar 11 21:35:40 acct sshd[8178]: error: session_pty_req: session 0 alloc failed A listing of the dev directory on the jail doesn't show pts (but it does on the host OS): %ll /usr/jails/acct/dev total 1 dr-xr-xr-x 2 root wheel 512 Mar 11 17:12 fd lrwxr-xr-x 1 root wheel14 Mar 11 17:12 log -> ../var/run/log crw-rw-rw- 1 root wheel0, 7 Mar 11 21:11 null crw-rw-rw- 1 root wheel0, 12 Mar 11 12:10 random lrwxr-xr-x 1 root wheel 4 Mar 11 17:12 stderr -> fd/2 lrwxr-xr-x 1 root wheel 4 Mar 11 17:12 stdin -> fd/0 lrwxr-xr-x 1 root wheel 4 Mar 11 17:12 stdout -> fd/1 lrwxr-xr-x 1 root wheel 6 Mar 11 17:12 urandom -> random crw-rw-rw- 1 root wheel0, 8 Mar 11 17:10 zero ...and I've tried to make Google-advised changes to the /etc/defaults/devfs.rules file to no avail. ;) All other services within the host OS and the jails are operating perfectly. I'm just missing my tty's. Can someone hit me with the cluebat, because I really feel that I've missed something. Thanks, Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
On 2010.03.11 21:49, Xin LI wrote: > Sounds like you have something wrong with devfs.rules in jail section? Did I miss or fsck something up by not reading UPDATING properly? Here is what I have on the host OS: %cat /etc/defaults/devfs.rules | grep -v "^#" [devfsrules_hide_all=1] add hide [devfsrules_unhide_basic=2] add path null unhide add path zero unhide add path crypto unhide add path random unhide add path urandom unhide [devfsrules_unhide_login=3] add path 'ptyp*' unhide add path 'ptyq*' unhide add path 'ptyr*' unhide add path 'ptys*' unhide add path 'ptyP*' unhide add path 'ptyQ*' unhide add path 'ptyR*' unhide add path 'ptyS*' unhide add path 'ttyp*' unhide add path 'ttyq*' unhide add path 'ttyr*' unhide add path 'ttys*' unhide add path 'ttyP*' unhide add path 'ttyQ*' unhide add path 'ttyR*' unhide add path 'ttyS*' unhide add path 'pts/*' unhide add path 'pty/*' unhide add path fd unhide add path 'fd/*' unhide add path stdin unhide add path stdout unhide add path stderr unhide [devfsrules_jail=4] add include $devfsrules_hide_all add include $devfsrules_unhide_basic add include $devfsrules_unhide_login ...and on a jail OS: %cat /usr/jails/devel/etc/defaults/devfs.rules | grep -v "^#" [devfsrules_hide_all=1] add hide [devfsrules_unhide_basic=2] add path null unhide add path zero unhide add path crypto unhide add path random unhide add path urandom unhide [devfsrules_unhide_login=3] add path 'ptyp*' unhide add path 'ptyq*' unhide add path 'ptyr*' unhide add path 'ptys*' unhide add path 'ptyP*' unhide add path 'ptyQ*' unhide add path 'ptyR*' unhide add path 'ptyS*' unhide add path 'ttyp*' unhide add path 'ttyq*' unhide add path 'ttyr*' unhide add path 'ttys*' unhide add path 'ttyP*' unhide add path 'ttyQ*' unhide add path 'ttyR*' unhide add path 'ttyS*' unhide add path 'pts/*' unhide add path 'pty/*' unhide add path fd unhide add path 'fd/*' unhide add path stdin unhide add path stdout unhide add path stderr unhide add path pts unhide [devfsrules_jail=4] add include $devfsrules_hide_all add include $devfsrules_unhide_basic add include $devfsrules_unhide_login Thanks for such a quick response LI, Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: make installworld problem
On 2010.03.11 16:41, Kenneth Hatteland wrote: > suddenly after a while my FreeBSD 8.0 stable machine always fails make > installworld. it has rarely been a problem before and when I appeared I > just rebooted into multi user, csup and build it all once again and then > success. > > Now It always fails with an error saying this or that directory is > empty...and csup and a new buildworld does not fix this. > > maybe you need more input to have an opinion...just name it and I`ll > provide it. - error codes - directory names - did you `rm -rf /usr/obj/*' prior to re-csup'ing > My machine functions perfectly, but I can not finalize > upgrades right now...buggerem Provide a bit more detail with where exactly it is failing ;) Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
Looks like you have a stale configuration. DId you done mergemaster? Cheers, -- Xin LI http://www.delphij.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
On 2010.03.11 22:14, Xin LI wrote: > Looks like you have a stale configuration. DId you done mergemaster? Yes. I performed it as such: # mergemaster -Uia under the host OS, and then subsequently within each jail. I'm not very familiar with mergemaster, so could my use of the args been incorrect? Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
On 2010.03.11 22:14, Steve Bertrand wrote: > I had even used diff(8) earlier, err, diff(1) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
On 2010.03.11 21:49, Xin LI wrote: > Sounds like you have something wrong with devfs.rules in jail section? Heh, Thanks Xin LI, I knew the cluebat would work ;) This line: "add path pts unhide" ...I had added to the jails, but NOT to the host /etc/defaults/devfs.rules. It took me sending a cat of each file to realize I was missing it in the host OS file. I had even used diff(8) earlier, but that must have been after much eye-strain. Although I have no idea what "add path pts unhide" actually does, after adding it into the proper location within the host OS filesystem, I'm all back up and rolling ;) Absolute kudos to Richard Bader who started me down the right path in this thread: http://www.mail-archive.com/freebsd-j...@freebsd.org/msg01061.html The only thing that I didn't get from it was that the "add path pts unhide" is required in /etc/defaults/devfs.rules file on the HOST OS. Thanks much! 7.2-8.0 source upgrade with jails is 100% successful! Good work dev team! Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Jails & 8.0
Sorry for the cross-post, but this is a 'thank-you', not a request for help. I want to express my sincere appreciation for all of those who made FreeBSD jails a viable virtual server solution for us who required multiple IPs, particularly those who demand/require IPv6 support: %jls -v JID Hostname Path Name State CPUSetID IP Address(es) [..snip..] 8 v6only/usr/jails/onlyv6.com 8 ACTIVE 9 208.70.104.90 2607:f118:8c0:800::64 Not only that, FreeBSD 8 is just absolutely fantastic. Although I've only been using FreeBSD since 4.3, I never could have dreamt that the OS would ever have a release that is so close to its core values, but at the same time so feature rich and stable, particularly for those who like to use the OS as a network (L2/L3) platform in many cases. My hats off. Thanks all! What a tremendous job. Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Weird, it seems that RELENG_8_0 do contain the correct file... What does 'ident /etc/defaults/devfs.rules' show? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLmbsOAAoJEATO+BI/yjfBYWwH/jLink3OiDf1Rth8Id+BZL8B P8I2+0jgCny3DjDltRqy0s1+rzF0hjQjpUrUR/T/lPIBRqi2CgQ6RuKe4fHjlZ5c JR2p7AI0BnrU6gpJmVyhoROUZAEEMIrqxXji00N/o+ZuRvuVO+YfVYnuJrMcp78+ vll0bWrHp1xevXf6cH4FcTaurKsexZAZbBvHnrWL6v8WWK1+CtuRmbWjStaNg2tK 6SSOE3P2IEXVW3LNQ9iHV0GycgnbdnsYTTOjsQG2BQTpNRozMvQk3f9oiVMHDn2F a2vBewVkWkzfTX9IBX6o6aYbIInRQo0TYitj5nnP8vI+nF4WI/hnAebv9dO4ymQ= =6LSi -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
On 2010.03.11 22:54, Xin LI wrote: > Weird, it seems that RELENG_8_0 do contain the correct file... What > does 'ident /etc/defaults/devfs.rules' show? ...not necessarily 8_0: %grep tag /etc/supfile *default tag=RELENG_8 fwiw: %ident /etc/defaults/devfs.rules /etc/defaults/devfs.rules: $FreeBSD: src/etc/defaults/devfs.rules,v 1.4.2.1.6.1 2009/04/15 03:14:26 kensmith Exp $ ...again... perhaps my arg list to mergemaster was the issue. If it was, it would be good to know ;) Otherwise, it was a standard src upgrade. Let me know if you need anything further. I can simulate the procedure on other hardware tomorrow to isolate the issue if you feel that this may affect others, or if it can prove that I was just sleeping on the job. Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010/03/11 20:26, Steve Bertrand wrote: > On 2010.03.11 22:54, Xin LI wrote: >> Weird, it seems that RELENG_8_0 do contain the correct file... What >> does 'ident /etc/defaults/devfs.rules' show? > > ...not necessarily 8_0: > > %grep tag /etc/supfile > > *default tag=RELENG_8 Oh that shouldn't a problem :) > fwiw: > > %ident /etc/defaults/devfs.rules > > /etc/defaults/devfs.rules: > $FreeBSD: src/etc/defaults/devfs.rules,v 1.4.2.1.6.1 2009/04/15 > 03:14:26 kensmith Exp $ This is a old version which comes from 7.2, so that's the problem... > ...again... perhaps my arg list to mergemaster was the issue. If it was, > it would be good to know ;) > > Otherwise, it was a standard src upgrade. > > Let me know if you need anything further. I can simulate the procedure > on other hardware tomorrow to isolate the issue if you feel that this > may affect others, or if it can prove that I was just sleeping on the job. Could you please check ident on /usr/src/etc/defaults/devfs.rules? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLmcNoAAoJEATO+BI/yjfBnQwH/jN//MTEruj3TSPOcQBqmEJd ii9wFhqQfZOHboAAkzNeARX+obGpDhJSEtwSpf4MpoK5jq9i5fEhHaE1uIGmlt+4 ZM9oZkN3elTnTrscU4v9CddPgPXrjSfZMavWQUk/gmoksRrXKAmsdSfAubZBqC9m BpcNaR5+V/DmMfLQqvG3Clfh7/yooyb/X+t6zgcEWNZXGXk/xEwglho7njdQF/LS IFNF9aaPqn+kSucQyVPBKGpQXN98dn4aKjDDu9/Vz4CvDVHNoAL7uNuiZgAC0JD9 Jj5UIYOz7xXzDqNx37jgoMPnqQlxAtsUAQDDxerBcKdIgRlSunpyc5i2W+2lA1o= =dr6j -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
On Thu, Mar 11, 2010 at 8:26 PM, Steve Bertrand wrote: > On 2010.03.11 22:54, Xin LI wrote: >> Weird, it seems that RELENG_8_0 do contain the correct file... What >> does 'ident /etc/defaults/devfs.rules' show? > > ...not necessarily 8_0: > > %grep tag /etc/supfile > > *default tag=RELENG_8 > > fwiw: > > %ident /etc/defaults/devfs.rules > > /etc/defaults/devfs.rules: > $FreeBSD: src/etc/defaults/devfs.rules,v 1.4.2.1.6.1 2009/04/15 > 03:14:26 kensmith Exp $ > > ...again... perhaps my arg list to mergemaster was the issue. If it was, > it would be good to know ;) > > Otherwise, it was a standard src upgrade. > > Let me know if you need anything further. I can simulate the procedure > on other hardware tomorrow to isolate the issue if you feel that this > may affect others, or if it can prove that I was just sleeping on the job. I've done a few RELENG_8_0 to STABLE-8 to 9-CURRENT upgrades lately and mergemaster was goofing up the contents a bit based on the RCS versions. I had to hand-edit a crapload of stuff going from 8 to 9, and I still don't trust mergemaster's automatic merging logic because it goofs up on /etc/group // /etc/passwd still (doesn't merge anything, discards my info, etc) for starters. -a doesn't actually do any merging though, FWIW: -a Run automatically. This option will leave all the files that differ from the installed versions in the temporary directory to be dealt with by hand. If the temproot directory exists, it creates a new one in a previously non-existent directory. This option unsets the verbose flag, but other than -U it is compatible with all other options. Setting -a makes -w superfluous. Also, "add path pts unhide" unmasks all psuedo TTY dev nodes so that applications that use openpty(3) and friends (like sshd) can allocate them at login. Thanks, -Garrett ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
On 2010.03.11 23:30, Xin LI wrote: > On 2010/03/11 20:26, Steve Bertrand wrote: >> On 2010.03.11 22:54, Xin LI wrote: >>> Weird, it seems that RELENG_8_0 do contain the correct file... What >>> does 'ident /etc/defaults/devfs.rules' show? > >> ...not necessarily 8_0: > >> %grep tag /etc/supfile > >> *default tag=RELENG_8 > > Oh that shouldn't a problem :) > >> fwiw: > >> %ident /etc/defaults/devfs.rules > >> /etc/defaults/devfs.rules: >> $FreeBSD: src/etc/defaults/devfs.rules,v 1.4.2.1.6.1 2009/04/15 >> 03:14:26 kensmith Exp $ > > This is a old version which comes from 7.2, so that's the problem... > >> ...again... perhaps my arg list to mergemaster was the issue. If it was, >> it would be good to know ;) > >> Otherwise, it was a standard src upgrade. > >> Let me know if you need anything further. I can simulate the procedure >> on other hardware tomorrow to isolate the issue if you feel that this >> may affect others, or if it can prove that I was just sleeping on the job. > > Could you please check ident on /usr/src/etc/defaults/devfs.rules? %uname -a FreeBSD jail.eagle.ca 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Mar 11 13:22:59 EST 2010 r...@jail.eagle.ca:/usr/obj/usr/src/sys/JAIL i386 %ident /usr/src/etc/defaults/devfs.rules /usr/src/etc/defaults/devfs.rules: $FreeBSD: src/etc/defaults/devfs.rules,v 1.6.2.2 2010/01/11 18:42:29 jhb Exp $ Steve ps. I can see that I did something wrong ;) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010/03/11 20:33, Garrett Cooper wrote: > I've done a few RELENG_8_0 to STABLE-8 to 9-CURRENT upgrades lately > and mergemaster was goofing up the contents a bit based on the RCS > versions. I had to hand-edit a crapload of stuff going from 8 to 9, > and I still don't trust mergemaster's automatic merging logic because > it goofs up on /etc/group // /etc/passwd still (doesn't merge > anything, discards my info, etc) for starters. > > -a doesn't actually do any merging though, FWIW: > > -a Run automatically. This option will leave all the files that > differ from the installed versions in the temporary directory > to be dealt with by hand. If the temproot directory exists, > it creates a new one in a previously non-existent directory. > This option unsets the verbose flag, but other than -U it is > compatible with all other options. Setting -a makes -w > superfluous. > > Also, "add path pts unhide" unmasks all psuedo TTY dev nodes so that > applications that use openpty(3) and friends (like sshd) can allocate > them at login. Yes that's right. Thanks for posting, perhaps we can document it in FAQ? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLmcX6AAoJEATO+BI/yjfB4lgIAKF4XMGFSU0VsvmfUD2WIWoE N5UQTKiew4cyytk80SS0ProGemMnWykAfZIDyhovCxp7WRAPJMmrqhulcYXHi+hW DBP4Dx8AsHu/pQ0edauIfnEXYy4gd9g9D6yRIS8407izYTPYs1FvfW0GeftLwEfn Ngm/bYggw1g/Nc5ercqc3AV1vXJJSZ6c3VL8r1ohlsiCRlybMaXBxQrU/KSjDFoz /xI4TOJ5+L+gCpfFB8Tvso8IueZ/YqVSPKnC95bOwGR16sERmACZ7rRUIg7zXyhA VhKttjqfLrHRn6yp905OvS3rkmtCWBfpqIM8Ia34owjSlZbTUK7i0phiDw3uADE= =IXRh -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
On 2010.03.11 23:33, Garrett Cooper wrote: > On Thu, Mar 11, 2010 at 8:26 PM, Steve Bertrand wrote: >> On 2010.03.11 22:54, Xin LI wrote: >>> Weird, it seems that RELENG_8_0 do contain the correct file... What >>> does 'ident /etc/defaults/devfs.rules' show? >> >> ...not necessarily 8_0: >> >> %grep tag /etc/supfile >> >> *default tag=RELENG_8 >> >> fwiw: >> >> %ident /etc/defaults/devfs.rules >> >> /etc/defaults/devfs.rules: >> $FreeBSD: src/etc/defaults/devfs.rules,v 1.4.2.1.6.1 2009/04/15 >> 03:14:26 kensmith Exp $ >> >> ...again... perhaps my arg list to mergemaster was the issue. If it was, >> it would be good to know ;) >> >> Otherwise, it was a standard src upgrade. >> >> Let me know if you need anything further. I can simulate the procedure >> on other hardware tomorrow to isolate the issue if you feel that this >> may affect others, or if it can prove that I was just sleeping on the job. > > I've done a few RELENG_8_0 to STABLE-8 to 9-CURRENT upgrades lately > and mergemaster was goofing up the contents a bit based on the RCS > versions. I had to hand-edit a crapload of stuff going from 8 to 9, > and I still don't trust mergemaster's automatic merging logic because > it goofs up on /etc/group // /etc/passwd still (doesn't merge > anything, discards my info, etc) for starters. > > -a doesn't actually do any merging though, FWIW: heh. Then this explains it. ...at least my own idiocy (or perhaps lack thereof for trying too hard) keeps me at the OS troubleshooting level ;) So long as the OS I'm troubleshooting doesn't have a gui, I'm ok with it. I'm obviously going to get a better understanding of mergemaster. More importantly, I have a colleague who wanted to help this afternoon, but I didn't know how to describe the problem. This thread will help. Thanks! Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
On 2010.03.11 23:41, Xin LI wrote: > On 2010/03/11 20:33, Garrett Cooper wrote: >> I've done a few RELENG_8_0 to STABLE-8 to 9-CURRENT upgrades lately >> and mergemaster was goofing up the contents a bit based on the RCS >> versions. I had to hand-edit a crapload of stuff going from 8 to 9, >> and I still don't trust mergemaster's automatic merging logic because >> it goofs up on /etc/group // /etc/passwd still (doesn't merge >> anything, discards my info, etc) for starters. > >> -a doesn't actually do any merging though, FWIW: > >> -a Run automatically. This option will leave all the files >> that >> differ from the installed versions in the temporary >> directory >> to be dealt with by hand. If the temproot directory exists, >> it creates a new one in a previously non-existent directory. >> This option unsets the verbose flag, but other than -U it is >> compatible with all other options. Setting -a makes -w >> superfluous. > >> Also, "add path pts unhide" unmasks all psuedo TTY dev nodes so that >> applications that use openpty(3) and friends (like sshd) can allocate >> them at login. > > Yes that's right. Thanks for posting, perhaps we can document it in FAQ? Well, if anything, the FAQ should simply say "read the damn handbook and follow it". If I had of followed the same procedure that I've been using for the last 7 years (at least) instead of trying to 'automate' (-a) prior to reading the man page thoroughly, I would have been ok. Sorry for the noise, but thanks for the help ;) Cheers, Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I broke my SSH to jails after 7.2-8.0 src upgrade
On Thu, Mar 11, 2010 at 8:41 PM, Xin LI wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2010/03/11 20:33, Garrett Cooper wrote: >> I've done a few RELENG_8_0 to STABLE-8 to 9-CURRENT upgrades lately >> and mergemaster was goofing up the contents a bit based on the RCS >> versions. I had to hand-edit a crapload of stuff going from 8 to 9, >> and I still don't trust mergemaster's automatic merging logic because >> it goofs up on /etc/group // /etc/passwd still (doesn't merge >> anything, discards my info, etc) for starters. >> >> -a doesn't actually do any merging though, FWIW: >> >> -a Run automatically. This option will leave all the files >> that >> differ from the installed versions in the temporary >> directory >> to be dealt with by hand. If the temproot directory exists, >> it creates a new one in a previously non-existent directory. >> This option unsets the verbose flag, but other than -U it is >> compatible with all other options. Setting -a makes -w >> superfluous. >> >> Also, "add path pts unhide" unmasks all psuedo TTY dev nodes so that >> applications that use openpty(3) and friends (like sshd) can allocate >> them at login. > > Yes that's right. Thanks for posting, perhaps we can document it in FAQ? Unfortunately this doesn't really fit in a FAQ because it could be any of the failures caused by openpty failure: ERRORS The openpty() function may fail and set the global variable errno for any of the errors specified for the grantpt(3), posix_openpt(3), ptsname(3), and unlockpt(3) functions and the revoke(2) system call. In addition to this, forkpty() may set it to any value as described for fork(2). Note how openpty(3) isn't descriptive in terms of _what_ individual failures can be reported by it, but instead point to other manpages :)... I've run into whacky ass issues with /var/run permissions in the past, etc, which is why I don't suggest putting this into a FAQ -- the bucket is way too huge to deal with. Steve's right though -- if you're willing to use an option and the documentation clearly states the exact behavior and caveats, you are responsible for the results of any failure through misuse of the tool (exceptions being IMO NUL pointer exceptions, abort(3) calls not thrown by assert(3)s, etc). You're more than welcome to make suggestions on how things can be improved, but as I've discovered in some areas, some of the suggestions one makes aren't necessarily accepted with open minds. Excessive and/or redundant documentation (as I'm starting to understand after playing the opposite side for a while) is no better than little or no documentation; complete and concise documentation is what's needed more than anything else. Thanks, -Garrett ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
