Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On 5/06/2010, at 5:51 PM, Theo de Raadt wrote: >> On Fri, Jun 4, 2010 at 7:49 PM, Jacob Meuser >> wrote: >>> I'm still curious how anything left in /usr/obj can be anything >>> but a possible problem after updating system binaries and sources >>> to a new release. especially for people who are just "following >>> the directions as they are written." >> >> Do you not agree barring broken makefiles and unreliable system clock >> (as someone pointed out), object files and binaries (in obj/) should >> have been rebuilt? > > It's a source tree with nearly 40,000 .[chyl] source code files, and > probably another 40,000 further "source code" dependencies if you > include manual pages and the perl parts. > > We try very hard, and the bsd.*.mk macro package helps a lot > (enforcing consistancy-because-of-simplicity), but if you think we can > get all the dependencies right every single time, it is a tough call. > But this case is worse -- when the trash in the obj tree totally > mis-matches the src tree since it is so far in the past... that is > totally impossible. > > Dependencies don't help when they don't know about the files. Even > make clean or cleandir won't help you then. > > This was not an installer bug. It had nothing to do with upgrades. > We've said it before, and I guess we get to say it again: > > If don't know what you are doing, install a new snapshot. > > How many more times do we have to say that? > > Why are people defending a person who thinks they are smart enough, > and has just proved that they're not? > > Miod, Dale, Kurt, Kettenis and I am quite often the first people to > deal with bumping systems forward over bumps. Some bumps are so > difficult that after they are done the rest of us jump over them using > snapshots. When they happen, WE -- THE DEVELOPERS -- USE THE > SNAPSHOTS! They happen in lots of releases. Why would we use > snapshots, because we are stupid? Or are we smart enough to not waste > our time doing things the hard way? > > Uwe thinks he's being really clever, but he's not clever at all. He's > got a record of choosing the hardest paths. That's his problem. I > just wish he wouldn't be such a loud whiner when he screws his system > up. > But I don't understand what he's doing differently to me. A new release is out, you want to upgrade from the previous release to the new one, and then you want to apply the errata patches. Not saying I'm doing it perfectly, but I'd like to understand where he's going wrong because I do something similar - and wrong, from the sound of it. I don't want to follow current, I just follow the release & apply errata patches. (But it looks like Uwe, I am NOT doing it 100% right.) So I was on 4.5, 4.6 came out. I got the 4.6 CD, followed the upgrade process. I replaced /usr/src with the 4.6 code off the CD, downloaded the errata patches, built. 4.7 comes out, I upgrade from CD, copied the 4.7 source over, downloaded errata, built. Seems to work most of the time apart from a patch requiring a userland build (like openssl) so this is where I am obviously going wrong. A snapshot is a point-in-time, may-have-issues, best way to follow current build, isn't it? But I'd rather follow release. I appreciate you've got better things to do than hand-holding, so I'll work my way through it, but any cluesticks appreciated. Thanks.
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
IF YOU DON'T KNOW WHAT YOUR ARE DOING, INSTALL A NEW SNAPSHOT Theo de Raadt wrote: > > Miod, Dale, Kurt, Kettenis and I am quite often the first people to > deal with bumping systems forward over bumps. Some bumps are so > difficult that after they are done the rest of us jump over them using > snapshots. When they happen, WE -- THE DEVELOPERS -- USE THE > SNAPSHOTS! They happen in lots of releases. Why would we use > snapshots, because we are stupid? Or are we smart enough to not waste > our time doing things the hard way? > IF YOU DON'T KNOW WHAT YOUR ARE DOING, INSTALL A NEW SNAPSHOT (Me, I never know what I am doing, but he KNOWS what he's talking about)
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
Jacob Meuser wrote: ... > > On 5/06/2010, at 7:31 AM, Nick Holland wrote: a patch to the upgrade guide would be wrong. The problem is the patching process (a special case of the userland build process) assumes a clean obj dir. This has nothing to do with upgrades. If you try to rebuild the same userland utility more than once for /any/ reason without clearing the obj dir, you can run into problems. Clearing the obj directory as part of the upgrade is like flushing your toilet based on the date -- may help, but after a while, things start to stink. It isn't the general (or proper) solution. > I'm still curious how anything left in /usr/obj can be anything > but a possible problem after updating system binaries and sources > to a new release. especially for people who are just "following > the directions as they are written." > > -- > jake...@sdf.lonestar.org > SDF Public Access UNIX System - http://sdf.lonestar.org ANYTHING left in /usr/obj will be a possible problem. ANYTHING left ANYWHERE will be a possible problem anytime anything assumes (or has/likes to assume) that it is working with a clean slate. "Fixing" minor problems (and bending everything else out of shape) does NOT make for better systems. For me, I prefer things (upgrade/update/whatever) that do as little collateral damage as possible. (And anytime you want/need to find out what went wrong you do NOT clean up everything first.)
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
patrick keshishian wrote: > > On Fri, Jun 4, 2010 at 7:49 PM, Jacob Meuser > wrote: > > I'm still curious how anything left in /usr/obj can be anything > > but a possible problem after updating system binaries and sources > > to a new release. especially for people who are just "following > > the directions as they are written." > > Do you not agree barring broken makefiles and unreliable system clock > (as someone pointed out), object files and binaries (in obj/) should > have been rebuilt? > > --patrick ?? odds that OP found a bad date and "fixed" it (silently) ??
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
> On Fri, Jun 4, 2010 at 7:49 PM, Jacob Meuser > wrote: > > I'm still curious how anything left in /usr/obj can be anything > > but a possible problem after updating system binaries and sources > > to a new release. especially for people who are just "following > > the directions as they are written." > > Do you not agree barring broken makefiles and unreliable system clock > (as someone pointed out), object files and binaries (in obj/) should > have been rebuilt? It's a source tree with nearly 40,000 .[chyl] source code files, and probably another 40,000 further "source code" dependencies if you include manual pages and the perl parts. We try very hard, and the bsd.*.mk macro package helps a lot (enforcing consistancy-because-of-simplicity), but if you think we can get all the dependencies right every single time, it is a tough call. But this case is worse -- when the trash in the obj tree totally mis-matches the src tree since it is so far in the past... that is totally impossible. Dependencies don't help when they don't know about the files. Even make clean or cleandir won't help you then. This was not an installer bug. It had nothing to do with upgrades. We've said it before, and I guess we get to say it again: If don't know what you are doing, install a new snapshot. How many more times do we have to say that? Why are people defending a person who thinks they are smart enough, and has just proved that they're not? Miod, Dale, Kurt, Kettenis and I am quite often the first people to deal with bumping systems forward over bumps. Some bumps are so difficult that after they are done the rest of us jump over them using snapshots. When they happen, WE -- THE DEVELOPERS -- USE THE SNAPSHOTS! They happen in lots of releases. Why would we use snapshots, because we are stupid? Or are we smart enough to not waste our time doing things the hard way? Uwe thinks he's being really clever, but he's not clever at all. He's got a record of choosing the hardest paths. That's his problem. I just wish he wouldn't be such a loud whiner when he screws his system up.
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On Fri, Jun 04, 2010 at 10:31:22PM -0700, patrick keshishian wrote: > On Fri, Jun 4, 2010 at 7:49 PM, Jacob Meuser > wrote: > > I'm still curious how anything left in /usr/obj can be anything > > but a possible problem after updating system binaries and sources > > to a new release. especially for people who are just "following > > the directions as they are written." > > Do you not agree barring broken makefiles and unreliable system clock > (as someone pointed out), object files and binaries (in obj/) should > have been rebuilt? > > --patrick Consider the follwoing scenario: I have a release n system, last built on May 1. So the obj files have a time stamp of May 1. The files of the tarbal of the new release n+1 have timestamps of Apr 1 or earlier, since it was made at that time. If I then install the tarball by extracting, according to makethe object files are still fresh, since the sources will be older than the object files. By default the files extracted form a tartball get the timestamps from the tarbal. There are some variations on this scenario. -Otto
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On Fri, Jun 4, 2010 at 7:49 PM, Jacob Meuser wrote: > I'm still curious how anything left in /usr/obj can be anything > but a possible problem after updating system binaries and sources > to a new release. especially for people who are just "following > the directions as they are written." Do you not agree barring broken makefiles and unreliable system clock (as someone pointed out), object files and binaries (in obj/) should have been rebuilt? --patrick
TECNICAS DE COBRANZAS. Evento el 15/6/2010, Montevideo - FALTAN POCOS DÍAS, NO QUEDE SIN LUGAR
RECORDATORIO CICLO DE EVENTOS 2010 FALTAN POCOS DMAS, CUPOS LIMITADOS, NO QUEDE SIN LUGAR. TICNICAS EFECTIVAS DE COBRANZAS Instrumentos tesricos y practicos para cobranzas en el mercado uruguayo 15/6/2010 - Hotel Ibis Montevideo - 18:30 a 22:00 hs Dirigido a: Ejecutivos de Cobranza, Supervisores de Cobranza, ejecutivos de cridito, Team leaders, Agentes de Riesgo, Microempresarios, abogados, procuradores, y todo aquel interesado en la tematica. Objetivos: Compartir herramientas practicas y tesricas que fortalezcan a los participantes en sus competencias y habilidades para la negociacisn en cobranzas, siendo totalmente aplicables en nuestro medio. Contenido: 1 - Cultura de Cobranzas - Las Cobranzas en la historia. - Evolucisn en el escenario de la cobranza. 2 Actores - Deudor: - Psicologma del Deudor. - Tipologma de deudores. - Qui camino tomar frente a cada uno de ellos. - Cobrador: - Caractermsticas. - Lenguaje a utilizar y/o evitar. - Su motivacisn.3 Cobranzas Telefsnicas. - Los 5 pasos en las Cobranzas telefsnicas. 4 Negociacisn en Cobranzas - Modelos aplicables. - Cuando utilizar cada modelo. 5 Cierres de Cobranza. 6 Manejo de Objeciones. Especialista uruguayo: Martmn Lima. Actualmente se desempeqa en una de las mas prestigiosas cooperativas financieras del mercado, responsable de la estrategia, analisis cualitativo de la cartera, capacitador institucional y coordinador del equipo de cobranzas. Anteriormente se desempeqs como negociador de la Multinacional Mo&Pc Collections, representando empresas tales como Credit Agricole, Citibank, Itau, Bandes, Surinvest, Oca, Creditel, Pronto, Italcred, Fucac, Tcc, Multicanal, Montecable, Nuevo Siglo y Porto Seguro. Coach (entrenador) empresarial/personal, avalado por la AIP (Association for Integrative Psychology), Hawai, USA. Estudios actuales en Marketing en la UDE y Relaciones Laborales en la UDELAR Inversion: $900 (inscribiindose hasta el 11/6/2010: $700 pesos ). Grupos pagan 2 entran 3, consulte por descuentos para asistentes del interior. - Se incluye material y certificado. - Puede abonar por Abitab, BROU o cobrador. Reserve su lugar: Telifono 315-33-30, Montevideo. Msvil: 093.753319 de lunes a sabados de 10 a 22 hs. E-mail: RESERVE HOY MAPA DE COMO LLEGAR AL HOTEL Gracias por recibir esta propuesta por e-mail y no deseamos ser molestia para usted por dicha vma intentando las mmnimas comunicaciones. Si no desea recibir mas mensajes envmenos un correo con la palabra remover o baja en el asunto, y el sistema automaticamente lo realiza.
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On Sat, Jun 05, 2010 at 10:29:57AM +1200, Richard Toohey wrote: > On 5/06/2010, at 7:31 AM, Nick Holland wrote: > > > Jacob Meuser wrote: > >> On Fri, Jun 04, 2010 at 04:22:35PM +, Uwe Dippel wrote: > >>> Still, may I suggest, that the next Upgrade Guide gets an extra line, with > a > >>> remark pointing out the existence of /usr/obj; and the suggestion to clean > it? > >> you can't supply a patch? can't even attempt one? all these posts and > >> time wasted and you can't try to make a patch to maybe save someone else > >> from the same fate? > > > > a patch to the upgrade guide would be wrong. > > > > The problem is the patching process (a special case of the userland build > process) assumes a clean obj dir. This has nothing to do with upgrades. If > you try to rebuild the same userland utility more than once for /any/ reason > without clearing the obj dir, you can run into problems. Clearing the obj > directory as part of the upgrade is like flushing your toilet based on the > date -- may help, but after a while, things start to stink. It isn't the > general (or proper) solution. > > > > faq10.html, section 10.15 would be more appropriate, I think. It will > probably require more than a couple line diff to work it in clearly. > > > > Nick. > > > > So something in or around here ... > > "Not all patches are for the kernel. In some cases, you will have to rebuild > individual utilities. At other times, will require recompiling all utilities > statically linked to a patched library. Follow the guidance in the header of > the patch, and if uncertain, rebuild the entire system." > > Along the lines of: > > "In some cases (you'll know you have do this because x) you need to clean > /usr/obj first, you do this by y." > > Let me learn what x and y are. > > Thanks. I'm still curious how anything left in /usr/obj can be anything but a possible problem after updating system binaries and sources to a new release. especially for people who are just "following the directions as they are written." -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: No SSH on External Interfaces After pf.conf Rewrite for Load Balancing Outgoing Traffic
dontek wrote: > In rewriting the ruleset I've > had no problems with connectivity with the exception of getting an SSH > connection to the firewall to work on either of the two external > interfaces. [...] > pass log quick on $EXT_IF_1 inet proto tcp from any to ($EXT_IF_1) > port ssh keep state > pass log quick on $EXT_IF_2 inet proto tcp from any to ($EXT_IF_2) > port ssh keep state Use reply-to for your ssh rules: pass log quick on $EXT_IF_1 inet proto tcp from any to ($EXT_IF_1) port ssh keep state reply-to ($EXT_IF_1 $EXT_GATE_1) (And for the 2nd one, too) Devin
Account Information
GE Money Dear CareCredit Healthcare Provider customer, You have 1 new ALERT message Please login to your CareCredit account and visit our brand new Message Center section in order to read the message. Please click the link below to access your CareCredit's Healthcare Provider account: Sign in to access your account ) 2010 CareCredit. All Rights Reserved.
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On 5/06/2010, at 7:31 AM, Nick Holland wrote: > Jacob Meuser wrote: >> On Fri, Jun 04, 2010 at 04:22:35PM +, Uwe Dippel wrote: >>> Still, may I suggest, that the next Upgrade Guide gets an extra line, with a >>> remark pointing out the existence of /usr/obj; and the suggestion to clean it? >> you can't supply a patch? can't even attempt one? all these posts and >> time wasted and you can't try to make a patch to maybe save someone else >> from the same fate? > > a patch to the upgrade guide would be wrong. > > The problem is the patching process (a special case of the userland build process) assumes a clean obj dir. This has nothing to do with upgrades. If you try to rebuild the same userland utility more than once for /any/ reason without clearing the obj dir, you can run into problems. Clearing the obj directory as part of the upgrade is like flushing your toilet based on the date -- may help, but after a while, things start to stink. It isn't the general (or proper) solution. > > faq10.html, section 10.15 would be more appropriate, I think. It will probably require more than a couple line diff to work it in clearly. > > Nick. > So something in or around here ... "Not all patches are for the kernel. In some cases, you will have to rebuild individual utilities. At other times, will require recompiling all utilities statically linked to a patched library. Follow the guidance in the header of the patch, and if uncertain, rebuild the entire system." Along the lines of: "In some cases (you'll know you have do this because x) you need to clean /usr/obj first, you do this by y." Let me learn what x and y are. Thanks.
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On Fri, Jun 4, 2010 at 9:22 AM, Uwe Dippel wrote: ... > Still, may I suggest, that the next Upgrade Guide gets an extra line, with a > remark pointing out the existence of /usr/obj; and the suggestion to clean it? Please point to the part of the Upgrade Guide which talks about building from source, untarring the src tar file, or applying errata. I can't seem to find any such reference, but I'm sure it's in there somewhere, because you originally said that you did the upgrade exactly following the upgrade guide and, as we found out later, your steps included building from source. The other possibility is that you did stuff that was *not* in the upgrade guide, in which case adding text to the upgrade guide saying "if you do this other stuff that's described elsewhere then you should read those other directions and follow them completely" seems kinda bizarre. > Also, with respect to the 'errata', the patches, they describe in detail what > needs to be done. Maybe here, it could as well be suggested, that before > applying the first patch of a new version of OpenBSD, /usr/obj should be > cleaned, or be verified to be clean? It already is the first bullet in the directions for building userland from source: http://www.openbsd.org/faq/faq5.html#BldUserland Philip Guenther
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
> Clearing the obj > directory as part of the upgrade is like flushing your toilet based on the > date -- may help, but after a while, things start to stink. It isn't the > general (or proper) solution. oops. What's the recommended procedure for this? -B
Re: unknown i686 model 0x1e, can't get bus clock (0x0)
On Fri, Jun 04, 2010 at 07:44:21PM +0300, Dexter Tomisson wrote: > On 4 June 2010 14:25, Andreas Gerdd wrote: > > > And should we expect having a better support for Intel Core i5/i7 CPUs > > in the near future, maybe for the next release cycle? > > > > > > > Sounds no; > > Changes by: > > j...@cvs.openbsd.org > > 2010/06/04 09:03:35 > Modified files: > > sys/arch/amd64/amd64: est.c > > sys/arch/i386/i386: machdep.c > Log message: > Don't warn about not knowing what the bus clock is on core i7/i5/i3 > as the high/low guessing won't be done on these processors due to MSR > differences. > > Just 'hide' them. Such a great solution! Look at the code, look at the MSRs, take FSB_FREQ for example, this is not valid on nehalem (no FSB). Take the interpretation of PERF_STATUS using bits that Intel claims are reserved. The ACPI and non ACPI codepaths need to be more isolated from each other and this then needs to be heavily tested. If you were to invest just the smallest of amounts of time looking at how it actually works and the history of the speedstep code you'd understand.
Re: unknown i686 model 0x1e, can't get bus clock (0x0)
* Dexter Tomisson [2010-06-04 18:48]: > On 4 June 2010 14:25, Andreas Gerdd wrote: > > And should we expect having a better support for Intel Core i5/i7 CPUs > > in the near future, maybe for the next release cycle? just check our ever famous public roadmap > Sounds no; > > Changes by: > > j...@cvs.openbsd.org > > 2010/06/04 09:03:35 > Modified files: > > sys/arch/amd64/amd64: est.c > > sys/arch/i386/i386: machdep.c > Log message: > Don't warn about not knowing what the bus clock is on core i7/i5/i3 > as the high/low guessing won't be done on these processors due to MSR > differences. > > Just 'hide' them. Such a great solution! that doesn't mean anything. the info just isn't in the same place as it used to be, so it is pointless for this part of the code to try to figure it out. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
Jacob Meuser wrote: On Fri, Jun 04, 2010 at 04:22:35PM +, Uwe Dippel wrote: Still, may I suggest, that the next Upgrade Guide gets an extra line, with a remark pointing out the existence of /usr/obj; and the suggestion to clean it? you can't supply a patch? can't even attempt one? all these posts and time wasted and you can't try to make a patch to maybe save someone else from the same fate? a patch to the upgrade guide would be wrong. The problem is the patching process (a special case of the userland build process) assumes a clean obj dir. This has nothing to do with upgrades. If you try to rebuild the same userland utility more than once for /any/ reason without clearing the obj dir, you can run into problems. Clearing the obj directory as part of the upgrade is like flushing your toilet based on the date -- may help, but after a while, things start to stink. It isn't the general (or proper) solution. faq10.html, section 10.15 would be more appropriate, I think. It will probably require more than a couple line diff to work it in clearly. Nick.
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
* Uwe Dippel [2010-06-04 18:26]: > I didn't know that the object directories need to be cleaned manually. this should not be needed assuming system time didn't jump. it is still good practice tho. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On Fri, Jun 04, 2010 at 04:22:35PM +, Uwe Dippel wrote: > Still, may I suggest, that the next Upgrade Guide gets an extra line, with a > remark pointing out the existence of /usr/obj; and the suggestion to clean it? you can't supply a patch? can't even attempt one? all these posts and time wasted and you can't try to make a patch to maybe save someone else from the same fate? -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Curso de Analise Bolsista e Produtos Financeiros mude o rumo da sua vida!!!!!
Curso de Analise Bolsista e Produtos Financeiros Assessorar financeiramente empresas e particulares Trabalhar num banco, numa agjncia de valores ou de investimento Compreender qualquer texto financeiro, interpretar graficos... Investir o seu dinheiro para conseguir a maxima rentabilidade UM CERTIFICADO QUE AVALIZA OS SEUS CONHECIMENTOS Clique ja! NOTA INFORMATIVA: O presente email destina-se znica e exclusivamente a informar potenciais utilizadores e nco pode ser considerado SPAM. De acordo com a legislagco internacional que regulamenta o correio electrsnico, "o email nco pode sera ser considerado SPAM quando incluir uma forma do receptor ser removido da lista do emissor". Para deixar de receber estas ofertas no seu e-mail clicar aqui
Re: softraid
Bambero wrote: My qastion is - is it possible to setup bootable software raid 1 (mirroring) during system install ? [...] What I missed ? man softraid "There is no boot support at this time for any disciplines."
softraid
Hello, My qastion is - is it possible to setup bootable software raid 1 (mirroring) during system install ? After boot from a install cd I choose Shell, than I made one partition on whole disk wd0 and wd1 and made a raid volume: bioctl -c 1 -l /dev/wd1a,/dev/wd0a,/dev/wd1a softraid0 then I installed the system on newly created sd0 device Everything went OK but system doesn't boot after reboot. What I missed ? Regards, Bambero
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
Might be better to read and comprehend ``man patch'' before assuming limitations on the scope of patch's reach. > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Uwe Dippel > Sent: Friday, June 04, 2010 11:23 AM > To: misc@openbsd.org > Subject: Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade > base47, on i386 and amd64 > > Jacob Meuser sdf.lonestar.org> writes: > > > oh good grief. you had a dirty /usr/obj. > > > > just look at the pfctl snippet of the log you posted. do you see > pfctl > > being built? do you see pfctl being installed from /usr/obj? > > Oh, yes. So the blame is on my side, I guess. Mea culpa maxima! > I didn't know that the object directories need to be cleaned manually. > Until > yesterday, I would have taken a bet that the object directories lie > within the > source trees (/usr/xenocaram /usr/src), and be cleaned when cleaning > the > sources. Now I am aware that I need to know the location of the object > directories and clean them manually. > I was totally unaware that, in case of a patch, the installer would > take the > next best file of the correct name from there; irrespective of the > underlying > version. > Though I feel in good company. I guess, a great number of people on > this list > were in a similar situation. Knowing the 'social contract' of OpenBSD, > I only > have to blame myself for ignorance. > Still, may I suggest, that the next Upgrade Guide gets an extra line, > with a > remark pointing out the existence of /usr/obj; and the suggestion to > clean it? > Also, with respect to the 'errata', the patches, they describe in > detail what > needs to be done. Maybe here, it could as well be suggested, that > before > applying the first patch of a new version of OpenBSD, /usr/obj should > be > cleaned, or be verified to be clean? > > Thanks for the various people who helped me patiently at analysing this > problem > to the very end! > > Uwe
Re: Intel PRO/1000 QP on Dell R610 and OpenBSD 4.7
On 4 June 2010 16:57, Joerg Streckfuss wrote: > Okey, we tested the newest snapshot but the issue remains. > > Any other clue? > > Joerg fire up sendbug
Re: unknown i686 model 0x1e, can't get bus clock (0x0)
On 4 June 2010 14:25, Andreas Gerdd wrote: > And should we expect having a better support for Intel Core i5/i7 CPUs > in the near future, maybe for the next release cycle? > > > Sounds no; Changes by: j...@cvs.openbsd.org 2010/06/04 09:03:35 Modified files: sys/arch/amd64/amd64: est.c sys/arch/i386/i386: machdep.c Log message: Don't warn about not knowing what the bus clock is on core i7/i5/i3 as the high/low guessing won't be done on these processors due to MSR differences. Just 'hide' them. Such a great solution!
No SSH on External Interfaces After pf.conf Rewrite for Load Balancing Outgoing Traffic
Hey guys:
Today I have used outbound load balancing in pf for the first time for
a client with 2 Internet connections. In rewriting the ruleset I've
had no problems with connectivity with the exception of getting an SSH
connection to the firewall to work on either of the two external
interfaces. (internal works fine)
If I look at the pflog, I can see the connection being passed in (as
well as two retries), but I never see anything being passed back out,
nor blocked. The three tries get passed in from the client and then
the client times out.
What am I missing?
pf.conf
---
EXT_IF_1="em0"
EXT_GATE_1="###.###.###.###"
EXT_IF_2="em1"
EXT_GATE_2="###.###.###.###"
INT_IF="re0"
NETWORK="10.0.0.0/24"
icmp_types="echoreq"
set block-policy return
set loginterface none
set skip on lo
match out on $EXT_IF_1 from $NETWORK nat-to ($EXT_IF_1)
match out on $EXT_IF_2 from $NETWORK nat-to ($EXT_IF_2)
block log all
match in all scrub (no-df max-mss 1440)
antispoof quick for { lo $INT_IF }
pass log quick on $EXT_IF_1 inet proto tcp from any to ($EXT_IF_1)
port ssh keep state
pass log quick on $EXT_IF_2 inet proto tcp from any to ($EXT_IF_2)
port ssh keep state
anchor "ftp-proxy/*"
pass in on $EXT_IF_1 inet proto tcp to port ftp rdr-to 127.0.0.1 port 21
pass in on $EXT_IF_2 inet proto tcp to port ftp rdr-to 127.0.0.1 port 21
pass in on $INT_IF proto tcp to port ftp rdr-to 127.0.0.1 port 8021
pass out on $INT_IF to $NETWORK
pass in quick on $INT_IF from $NETWORK to $INT_IF
pass in inet proto icmp all icmp-type $icmp_types
pass in on $INT_IF from $NETWORK route-to {($EXT_IF_1 $EXT_GATE_1),
($EXT_IF_2 $EXT_GATE_2)} round-robin
pass out log on $EXT_IF_1
pass out log on $EXT_IF_2
pass out log on $EXT_IF_1 from $EXT_IF_2 route-to ($EXT_IF_2 $EXT_GATE_2)
pass out log on $EXT_IF_2 from $EXT_IF_1 route-to ($EXT_IF_1 $EXT_GATE_1)
---
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
Jacob Meuser sdf.lonestar.org> writes: > oh good grief. you had a dirty /usr/obj. > > just look at the pfctl snippet of the log you posted. do you see pfctl > being built? do you see pfctl being installed from /usr/obj? Oh, yes. So the blame is on my side, I guess. Mea culpa maxima! I didn't know that the object directories need to be cleaned manually. Until yesterday, I would have taken a bet that the object directories lie within the source trees (/usr/xenocaram /usr/src), and be cleaned when cleaning the sources. Now I am aware that I need to know the location of the object directories and clean them manually. I was totally unaware that, in case of a patch, the installer would take the next best file of the correct name from there; irrespective of the underlying version. Though I feel in good company. I guess, a great number of people on this list were in a similar situation. Knowing the 'social contract' of OpenBSD, I only have to blame myself for ignorance. Still, may I suggest, that the next Upgrade Guide gets an extra line, with a remark pointing out the existence of /usr/obj; and the suggestion to clean it? Also, with respect to the 'errata', the patches, they describe in detail what needs to be done. Maybe here, it could as well be suggested, that before applying the first patch of a new version of OpenBSD, /usr/obj should be cleaned, or be verified to be clean? Thanks for the various people who helped me patiently at analysing this problem to the very end! Uwe
Re: Intel PRO/1000 QP on Dell R610 and OpenBSD 4.7
Am 04.06.2010 13:18, schrieb Sevan / Venture37: > Test a snapshot to see if the issue still exists > > > Sevan / Venture37 Okey, we tested the newest snapshot but the issue remains. Any other clue? Joerg [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On Fri, 4 Jun 2010, Jan Stary wrote: 'rm -rf /usr/obj/*' is not your arbitrary choice, it's a documented step when building the system. http://www.openbsd.org/faq/faq5.html#BldUserland Also documented there is keeping /usr/obj/ in its own partition and using 'newfs' to zap everything more quickly. /Lars
Re: wrong sshd log alert
Yes, my bad.. Using Putty. I've no idea what it does while trying to log in.. On 4 June 2010 16:15, Kenneth Gober wrote: > I wouldn't call it "wrong", necessarily. what ssh client are you using? > does it attempt to use authentication-type "none" in order to get a list of > supported authentication types from the server? or because it only wants to > prompt you for a password if authentication is required? > > perhaps "confusing" or "misleading" would be a better description for this > entry. > > -ken > > > On Fri, Jun 4, 2010 at 7:11 AM, Dexter Tomisson wrote: > >> my steps: >> >> login as: root >> t...@xx.xx.xx.xx's password: [valid password entered] >> [logged in] >> # exit >> >> sshd log output: >> >> Jun 4 12:03:12 sys sshd[1235]: Connection from MY.IP.AD.DR port 3894 >> Jun 4 12:03:15 sys sshd[1235]: Failed none for root from MY.IP.AD.DR port >> 3894 ssh2 >> Jun 4 12:03:17 sys sshd[1235]: Accepted password for root from >> MY.IP.AD.DR >> port 3894 ssh2 >> Jun 4 12:03:19 sys sshd[1235]: Connection closed by MY.IP.AD.DR >> Jun 4 12:03:19 sys sshd[1235]: Transferred: sent 3784, received 1928 >> bytes >> Jun 4 12:03:19 sys sshd[1235]: Closing connection to MY.IP.AD.DR port >> 3894 >> >> I don't see any reason why i get "Failed none for root from" alert. I >> didn't >> enter any wrong user/password. >> >> OpenBSD 4.7-stable.
Re: wrong sshd log alert
I wouldn't call it "wrong", necessarily. what ssh client are you using? does it attempt to use authentication-type "none" in order to get a list of supported authentication types from the server? or because it only wants to prompt you for a password if authentication is required? perhaps "confusing" or "misleading" would be a better description for this entry. -ken On Fri, Jun 4, 2010 at 7:11 AM, Dexter Tomisson wrote: > my steps: > > login as: root > t...@xx.xx.xx.xx's password: [valid password entered] > [logged in] > # exit > > sshd log output: > > Jun 4 12:03:12 sys sshd[1235]: Connection from MY.IP.AD.DR port 3894 > Jun 4 12:03:15 sys sshd[1235]: Failed none for root from MY.IP.AD.DR port > 3894 ssh2 > Jun 4 12:03:17 sys sshd[1235]: Accepted password for root from MY.IP.AD.DR > port 3894 ssh2 > Jun 4 12:03:19 sys sshd[1235]: Connection closed by MY.IP.AD.DR > Jun 4 12:03:19 sys sshd[1235]: Transferred: sent 3784, received 1928 bytes > Jun 4 12:03:19 sys sshd[1235]: Closing connection to MY.IP.AD.DR port 3894 > > I don't see any reason why i get "Failed none for root from" alert. I > didn't > enter any wrong user/password. > > OpenBSD 4.7-stable.
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
> On Fri, Jun 04, 2010 at 04:33:34PM +0800, Uwe Dippel wrote: > > When you are under 'quality control', and responsible for the > > uptime of a system, you would never do anything out of the scope of > > instructions, naturally. especially not some rm -Rf * in a directory > > of your arbitrary choice. ;) 'rm -rf /usr/obj/*' is not your arbitrary choice, it's a documented step when building the system. http://www.openbsd.org/faq/faq5.html#BldUserland
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On Fri, Jun 04, 2010 at 04:33:34PM +0800, Uwe Dippel wrote: > When you are under 'quality control', and responsible for the > uptime of a system, you would never do anything out of the scope of > instructions, naturally. especially not some rm -Rf * in a directory > of your arbitrary choice. ;) if this is so important: a) reinstall, don't upgrade b) learn to read logs and understand what you are doing > And don't point me to man release, please. I am not doing releases, but, actually, you are. you're just skipping lots of it. > have been making this mistake for 5 years. So, rm -Rf * in /usr/obj is > necessary? learn the system and tools you use. is it necessary? depends on the history of the machine in question. I bet you built pfctl at least once before, no? -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: GPT & OpenBSD
On Fri, Jun 04, 2010 at 01:35:04PM +0400, Mikle Krutov wrote: > Hello, list! > I've lurked arround about subject and found only > http://kerneltrap.org/mailarchive/openbsd-misc/2009/11/20/6298023 > thread, that tells 'no support, but patches are > welcome'. It's not too old thread, but still... > Is there any work ongoing? I'm kind of interested > in gpt support, and wanted to start trying writing > the patches, but i don't want to do the work twice. > > Wbr, No active development that I know of. And even if there is, an independant stab at it could show up problems and improvements! Ken
Take Advantage of The Market Volatility Today
Take advantage of this volatility today!! How have the markets been treating you lately? Are you finding ways to make money in these volatile times or are you just sitting around and employing the buy and hold strategy? Well, if you are waiting for the good times to return you areout of luck! The good times are not coming back. You need a system to take advantage of these market swings and at exactstockpicks we do it all for you. We scan the charts and find opportunities both long and short in this market. It doesn't matter what the market does. We are poised to take advantage of both sides and deliver consistent profits to our members! We send you pre-market selections, as well as alerts throughout the day on which moves to make. You can even have your account auto traded with select brokers. The only thing you will have to do is see the profits build up in your account. Our goal is to generate $1000 per month in profits based on a portfolio size of $25,000. Thats 4% per month or 48% annual. How do we do this? All of our trades are set up using an option position within the play. By doing this we limit our loss potential to around 5%. By utilizing this strategy we allow ourselves nearly unlimited gain potential. As you can see, having this tremendous leverage allows us to get out of plays early with profits, while letting the others stay active until the option expires. At that point, we take our small loss and move on. Its all about making many small gains throughout the month! Do you have a service now that is handing this for you? If not, how are you protecting yourself in these markets? Try ExactStockPicks free for 7 days to find out what we are doing for other investors in your situation. Also, if you take advantage of our service in the next 48 hours we will discount our annual subscription from $469 to $299. Thats less than $25 per month!! Our analysts and support team are here to help you and answer any questions you may have. Send us an e-mail at supp...@exactstockpicks.com. Its time for a change. You need profits. You need protection. Sign up today and let us show you the difference! This message from The Kolo Media Group Llc is being sent in full accordance with the CAN-SPAM Act. We respect your privacy. If you no longer wish to receive emails from The Kolo Media Group Llc, please unsubscribe now. Please reply to this e-mail with any comments or questions about this mailing. All information contained herein is copyright 2010, The Kolo Media Group Llc. The Kolo Media Group Llc | PO Box 190765 | Miami Beach, FL 33119 [demime 1.01d removed an attachment of type image/jpeg which had a name of =?windows-1252?Q?esplogo=5Fsml_(2).jpg?=]
Re: Intel PRO/1000 QP on Dell R610 and OpenBSD 4.7
Test a snapshot to see if the issue still exists Sevan / Venture37
wrong sshd log alert
my steps: login as: root t...@xx.xx.xx.xx's password: [valid password entered] [logged in] # exit sshd log output: Jun 4 12:03:12 sys sshd[1235]: Connection from MY.IP.AD.DR port 3894 Jun 4 12:03:15 sys sshd[1235]: Failed none for root from MY.IP.AD.DR port 3894 ssh2 Jun 4 12:03:17 sys sshd[1235]: Accepted password for root from MY.IP.AD.DR port 3894 ssh2 Jun 4 12:03:19 sys sshd[1235]: Connection closed by MY.IP.AD.DR Jun 4 12:03:19 sys sshd[1235]: Transferred: sent 3784, received 1928 bytes Jun 4 12:03:19 sys sshd[1235]: Closing connection to MY.IP.AD.DR port 3894 I don't see any reason why i get "Failed none for root from" alert. I didn't enter any wrong user/password. OpenBSD 4.7-stable.
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On Fri, Jun 04, 2010 at 04:40:28PM +0800, Uwe Dippel wrote: > On Fri, Jun 4, 2010 at 4:32 PM, patrick keshishian wrote: > > > Where did you get those tar-balls from? Those are most likely not 4.7 > > sources. > > I gave the potential link and their md5 sums further up. Our link here > is sooo slooow; I *am* currently downloading the archives from > ftp://ftp.openbsd.org/pub/OpenBSD/4.7 to compare the checksums. That > would explain a lot (though not everything, since the kernel looks > pretty correct: 4.7). > Maybe someone is faster and can confirm or refute the authenticity of > the archives? > > Uwe oh good grief. you had a dirty /usr/obj. just look at the pfctl snippet of the log you posted. do you see pfctl being built? do you see pfctl being installed from /usr/obj? -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
=?windows-1252?Q?LICITACIONES_P=DABLICAS_EN_M=C9XICO_D.F._PRESENTADAS_POR_PMS_CAPACITACION_EFECTIVA_DE_M=C9XICO??=
[IMAGE] !Promociones Especiales para Grupos! Copyright (C) 2010, PMS Capacitacisn Efectiva de Mixico S.C. Derechos Reservados. PMS de Mixico, El logo de PMS de Mixico son marcas registradas. ADVERTENCIA PMS de Mixico no cuenta con alianzas estratigicas de ningzn tipo dentro de la Republica Mexicana. NO SE DEJE ENGAQAR - DIGA NO A LA PIRATERIA. Todos los logotipos, marcas comerciales e imagenes son propiedad de sus respectivas corporaciones y se utilizan con fines informativos solamente. Este Mensaje ha sido enviado a misc@openbsd.org como usuario de Pms de Mixico o bien un usuario le refiris para recibir este boletmn. Como usuario de Pms de Mixico, en este acto autoriza de manera expresa que Pms de Mixico le puede contactar vma correo electrsnico u otros medios. Si usted ha recibido este mensaje por error, haga caso omiso de el y reporte su cuenta respondiendo este correo con el subject BAJALICITACION Unsubscribe to this mailing list, reply a blank message with the subject UNSUBSCRIBE LICITACION Tenga en cuenta que la gestisn de nuestras bases de datos es de suma importancia y no es intencisn de la empresa la inconformidad del receptor. [demime 1.01d removed an attachment of type image/jpeg which had a name of image001.jpg]
Re: iked(8) and ikectl(8)
On Fri, Jun 04, 2010 at 12:27:12PM +0200, Massimo Lusetti wrote: > On Thu, 3 Jun 2010 23:06:58 +0200 > Reyk Floeter wrote: > > > This is a very brief summary, more information will follow. > > > > reyk > > > > That's great! ... 4.7 is just behind the door and is already time to > move on -current! > > I got 48 IPsec gateways which just await to be upgraded! > but please a little bit before using it in production networks, iked(8) is not fully ready yet ;-). reyk
Re: iked(8) and ikectl(8)
On Thu, 3 Jun 2010 23:06:58 +0200 Reyk Floeter wrote: > This is a very brief summary, more information will follow. > > reyk > That's great! ... 4.7 is just behind the door and is already time to move on -current! I got 48 IPsec gateways which just await to be upgraded! Pretty nice! -- Massimo
Intel PRO/1000 QP on Dell R610 and OpenBSD 4.7
Hi list,
we bought two Dell R610 Servers with four built-in Broadcom BCM5709 nics.
Additionally we installed one Intel PRO/1000 QP quad port nic. There are no
problems with the Broadcoms but something strange happens to the Intel nic.
Sometimes, almost always one to two ports of the intel card couldn't
initialized. The OS comments this with the following message
em1 at pci5 dev 0 function 1 "Intel PRO/1000 QP (82576)" rev 0x01: apic 1 int
14
(irq 10)em1: Hardware Initialization Failed
em1: Unable to initialize the hardware
We are runnig OpenBSD 4.7 stable and dmesg says:
OpenBSD 4.7 (GENERIC) #558: Wed Mar 17 20:46:15 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Xeon(R) CPU L5506 @ 2.13GHz ("GenuineIntel" 686-class) 2.13
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,
xTPR
real mem = 3479244800 (3318MB)
avail mem = 3383246848 (3226MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 04/06/10, BIOS32 rev. 0 @ 0xfa040,
SMBIOS
rev. 2.6 @ 0xcf79c000 (83 entries)
bios0: vendor Dell Inc. version "2.0.13" date 04/06/2010
bios0: Dell Inc. PowerEdge R610
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC SPCR HPET DM__ MCFG WD__ SLIC ERST HEST BERT
EINJ
SRAT TCPA SSDT
acpi0: wakeup devices PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 16 (boot processor)
cpu0: unknown i686 model 0x1a, can't get bus clock (0x0)
cpu0: apic clock running at 133MHz
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
ioapic1 at mainbus0: apid 1 pa 0xfec8, version 20, 24 pins
ioapic1: misconfigured as apic 0, remapped to apid 1
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEX1)
acpiprt2 at acpi0: bus 2 (PEX3)
acpiprt3 at acpi0: bus -1 (PEX4)
acpiprt4 at acpi0: bus -1 (PEX5)
acpiprt5 at acpi0: bus -1 (PEX6)
acpiprt6 at acpi0: bus 4 (PEX7)
acpiprt7 at acpi0: bus 8 (PEX9)
acpiprt8 at acpi0: bus -1 (PEXA)
acpiprt9 at acpi0: bus 3 (SBEX)
acpiprt10 at acpi0: bus 9 (COMP)
acpicpu0 at acpi0: C3, C1, PSS
bios0: ROM list: 0xc/0x8000 0xc8000/0x5c00 0xec000/0x4000!
ipmi at mainbus0 not configured
cpu0: EST: PSS not yet available for this processor
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 5500 Host" rev 0x13
ppb0 at pci0 dev 1 function 0 "Intel X58 PCIE" rev 0x13
pci1 at ppb0 bus 1
bnx0 at pci1 dev 0 function 0 "Broadcom BCM5709" rev 0x20: apic 1 int 4 (irq
15)
bnx1 at pci1 dev 0 function 1 "Broadcom BCM5709" rev 0x20: apic 1 int 16 (irq
14)
ppb1 at pci0 dev 3 function 0 "Intel X58 PCIE" rev 0x13
pci2 at ppb1 bus 2
bnx2 at pci2 dev 0 function 0 "Broadcom BCM5709" rev 0x20: apic 1 int 0 (irq
15)
bnx3 at pci2 dev 0 function 1 "Broadcom BCM5709" rev 0x20: apic 1 int 10 (irq
14)
ppb2 at pci0 dev 7 function 0 "Intel X58 PCIE" rev 0x13: apic 1 int 21 (irq
0)
pci3 at ppb2 bus 4
ppb3 at pci3 dev 0 function 0 "IDT 89HPES12N3A" rev 0x0e
pci4 at ppb3 bus 5
ppb4 at pci4 dev 2 function 0 "IDT 89HPES12N3A" rev 0x0e
pci5 at ppb4 bus 6
em0 at pci5 dev 0 function 0 "Intel PRO/1000 QP (82576)" rev 0x01: apic 1 int
15
(irq 11), address 00:1b:21:61:58:b0
em1 at pci5 dev 0 function 1 "Intel PRO/1000 QP (82576)" rev 0x01: apic 1 int
14
(irq 10)em1: Hardware Initialization Failedem1: Unable to initialize the
hardware
ppb5 at pci4 dev 4 function 0 "IDT 89HPES12N3A" rev 0x0e
pci6 at ppb5 bus 7
em2 at pci6 dev 0 function 0 "Intel PRO/1000 QP (82576)" rev 0x01: apic 1 int
6
(irq 15), address 00:1b:21:61:58:b4
em3 at pci6 dev 0 function 1 "Intel PRO/1000 QP (82576)" rev 0x01: apic 1 int
13
(irq 14)em3: Hardware Initialization Failedem3: Unable to initialize the
hardware
ppb6 at pci0 dev 9 function 0 "Intel X58 PCIE" rev 0x13: apic 1 int 21 (irq
0)
pci7 at ppb6 bus 8
"Intel X58 Misc" rev 0x13 at pci0 dev 20 function 0 not configured
"Intel X58 GPIO" rev 0x13 at pci0 dev 20 function 1 not configured
"Intel X58 RAS" rev 0x13 at pci0 dev 20 function 2 not configured
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 0 int 17
(irq 14)
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 0 int 18
(irq 11)
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 0 int 19
(irq 10)
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb7 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02
pci8 at ppb7 bus 3
mpi0 at pci8 dev 0 function 0 "Symbios Logic SAS1068E" rev 0x08: apic 0 int
16
(irq 15)
scsibus0 at mpi0: 112 targets
sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed
sd0: 237952MB, 512 bytes/sec, 487325696 sec total
ses0 at scsibus0 targ 8 lun 0: SCSI3 13/enclosure
services
fixed
uhci2 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 0 i
Are you a ***Canadian*** Linux user? You're about to become a criminal.
Hi, Is this applicable to OpenBSD also? ( I guess yes ) http://www.reddit.com/comments/cb3n0/are_you_a_canadian_linux_user_youre_about_to/ thanks --Siju
GPT & OpenBSD
Hello, list! I've lurked arround about subject and found only http://kerneltrap.org/mailarchive/openbsd-misc/2009/11/20/6298023 thread, that tells 'no support, but patches are welcome'. It's not too old thread, but still... Is there any work ongoing? I'm kind of interested in gpt support, and wanted to start trying writing the patches, but i don't want to do the work twice. Wbr,
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On 4/06/2010, at 8:33 PM, Uwe Dippel wrote: > On Fri, Jun 4, 2010 at 4:22 PM, Eric Faurot wrote: > >> Don't you have old stuff lying around in /usr/obj that gets installed >> over your new binaries? > > That's probably the critical question now. Though, sorry to say, there > is nowhere written that you have to rm -Rf it, when you > - upgrade > - patch > Actually, I wasn't even aware of the existence of this directory until > several minutes ago. (I expected it to be cleaned with wiping the > source directories.) [cut] > I do, like many others, 'Upgrade Guide X.Y to > X.Z', and then get and apply the errata from > http://openbsd.org/errataXZ.html; according to their instructions. > > If this happens to be wrong, by all means, then I make a mistake, and > have been making this mistake for 5 years. So, rm -Rf * in /usr/obj is > necessary? > > Uwe > I've been doing upgrades from *around* the 4.2 release, but always from the release CDs. And then I've patched as per the errata instructions. And I've not (so far as I can recall) can to clear /usr/obj before applying patches. And as I type that I remembered! Hang on, there *was* once a patch that didn't apply cleanly ... think it was this one (but then I must have started with 3.9) - definitely an SSL one that wouldn't build without clearing /usr/obj first: http://marc.info/?l=openbsd-misc&m=116335647308807&w=2 So something for the upgrade docs or the patch file(s)? Maybe patch 3 for 4.7 might be responsible this time around? If you try the make clean step when applying patch 3 (something like in the link above - it might fix your problems.) Anyway, absolutely nothing to do with the installer or the 4.6 to 4.7 upgrade, so enough from me. Thanks.
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On Fri, Jun 4, 2010 at 4:22 PM, Eric Faurot wrote: > Don't you have old stuff lying around in /usr/obj that gets installed > over your new binaries? That's probably the critical question now. Though, sorry to say, there is nowhere written that you have to rm -Rf it, when you - upgrade - patch Actually, I wasn't even aware of the existence of this directory until several minutes ago. (I expected it to be cleaned with wiping the source directories.) Then, according to what is written by a number of people further up, an number of people could be hit by this. I for one would expect the time stamps to take care for that. And, to stress it again: When you are under 'quality control', and responsible for the uptime of a system, you would never do anything out of the scope of instructions, naturally. especially not some rm -Rf * in a directory of your arbitrary choice. ;) And don't point me to man release, please. I am not doing releases, I am not doing stable, I do, like many others, 'Upgrade Guide X.Y to X.Z', and then get and apply the errata from http://openbsd.org/errataXZ.html; according to their instructions. If this happens to be wrong, by all means, then I make a mistake, and have been making this mistake for 5 years. So, rm -Rf * in /usr/obj is necessary? Uwe
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On Fri, Jun 4, 2010 at 4:32 PM, patrick keshishian wrote: > Where did you get those tar-balls from? Those are most likely not 4.7 sources. I gave the potential link and their md5 sums further up. Our link here is sooo slooow; I *am* currently downloading the archives from ftp://ftp.openbsd.org/pub/OpenBSD/4.7 to compare the checksums. That would explain a lot (though not everything, since the kernel looks pretty correct: 4.7). Maybe someone is faster and can confirm or refute the authenticity of the archives? Uwe
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On Fri, Jun 4, 2010 at 12:55 AM, Uwe Dippel wrote: > On Fri, Jun 4, 2010 at 2:41 PM, patrick keshishian wrote: > >> you mean applying the errata47.html patches? If so, are you certain >> your source tree is tagged OPENBSD_4_7 and not anything else? > > Do I understand you correctly? I am not building releases. I am > installing/downloading the sets; then I do all the stuff in 'Upgrade > guide', then > > rm -Rf * in /usr/src > rm -Rf * in /usr/xenocara > rm -Rf * in /usr/ports, > and then tar ... the source files meticulously as pointed out in the guide: > # cd /usr/src > # tar xzf ../sys.tar.gz > # tar xzf ../src.tar.gz Where did you get those tar-balls from? Those are most likely not 4.7 sources. --patrick
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On Fri, Jun 04, 2010 at 03:55:53PM +0800, Uwe Dippel wrote: > On Fri, Jun 4, 2010 at 2:41 PM, patrick keshishian wrote: > > > you mean applying the errata47.html patches? If so, are you certain > > your source tree is tagged OPENBSD_4_7 and not anything else? > > Do I understand you correctly? I am not building releases. I am > installing/downloading the sets; then I do all the stuff in 'Upgrade > guide', then > > rm -Rf * in /usr/src > rm -Rf * in /usr/xenocara > rm -Rf * in /usr/ports, > and then tar ... the source files meticulously as pointed out in the guide: > # cd /usr/src > # tar xzf ../sys.tar.gz > # tar xzf ../src.tar.gz > # cd /usr > # tar xzf xenocara.tar.gz > # tar xzf ports.tar.gz > and then download the patches into /usr/src, then applying them > and this is what you would see in the serial log. > So I don't tag, because I don't cvs; what i do is just download the 4 > files. (Also see my other post, it points clearly to the sequence and > the reboots done, with always checking pfctl after each reboot.) > > Uwe Don't you have old stuff lying around in /usr/obj that gets installed over your new binaries?
Re: mouse cursor keeps jumping up and left in latest snapshot
On Fri, Jun 04, 2010 at 09:51:16AM +0200, Markus Hennecke wrote: > Am 03.06.2010 23:52, schrieb Ted Unangst: > >On Thu, Jun 3, 2010 at 5:21 PM, Christopher Zimmermann > > wrote: > >>Are you sure this is a problem in kernel? Christopher Linn and I only > >>experience this problem with gtk2 apps. How could the kernel know wether the > >>current focus is on a gtk2 window? > >Because the kernel is responsible for saving and restoring FPU state, > >which is pretty high on the list of suspected trouble makers. > Which would explain why the problem goes away if mouse acceleration > is disabled via xset. > > Kind regards, > Markus The problem only becomes less frequent with xset m 1. -Otto
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On Fri, Jun 4, 2010 at 3:00 PM, Richard Toohey wrote: > I think we are getting closer, aren't we? > > So, NOTHING to do with the actual upgrade, is it? No absolutely nothing. I withdraw the subject with regret. At least the 'base47'-part thereof. > Or the ports/packages. I guess, not. > It is something to do with how you are PATCHING after an upgrade. > > You don't mention where/when you get the source you patch? > > Because that would be a separate step, wouldn't it? > > (I usually install from CD, so I scrub /usr/src & load from src.tar.gz on the > CD.) Exactly. Just explained it in the previous post, and don't want to repeat myself. Except that I download, and then the actual files used were: # md5 /usr/src.tar.gz MD5 (/usr/src.tar.gz) = 5214cd951cac5b7fbd89c968d1b5f859 # md5 /usr/sys.tar.gz MD5 (/usr/sys.tar.gz) = 566c0cd7c3d2f28b17a9795324ead6ff (Here, contrary to the earlier post, at the actual location in /usr of the target machine before extraction: # ls -l /usr/s* -rw-r--r-- 1 root wheel 131759003 Mar 21 19:17 /usr/src.tar.gz -rw-r--r-- 1 root wheel 20668814 Mar 21 19:17 /usr/sys.tar.gz) Uwe
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On Fri, Jun 4, 2010 at 2:41 PM, patrick keshishian wrote: > you mean applying the errata47.html patches? If so, are you certain > your source tree is tagged OPENBSD_4_7 and not anything else? Do I understand you correctly? I am not building releases. I am installing/downloading the sets; then I do all the stuff in 'Upgrade guide', then rm -Rf * in /usr/src rm -Rf * in /usr/xenocara rm -Rf * in /usr/ports, and then tar ... the source files meticulously as pointed out in the guide: # cd /usr/src # tar xzf ../sys.tar.gz # tar xzf ../src.tar.gz # cd /usr # tar xzf xenocara.tar.gz # tar xzf ports.tar.gz and then download the patches into /usr/src, then applying them and this is what you would see in the serial log. So I don't tag, because I don't cvs; what i do is just download the 4 files. (Also see my other post, it points clearly to the sequence and the reboots done, with always checking pfctl after each reboot.) Uwe
Re: mouse cursor keeps jumping up and left in latest snapshot
Am 03.06.2010 23:52, schrieb Ted Unangst: On Thu, Jun 3, 2010 at 5:21 PM, Christopher Zimmermann wrote: Are you sure this is a problem in kernel? Christopher Linn and I only experience this problem with gtk2 apps. How could the kernel know wether the current focus is on a gtk2 window? Because the kernel is responsible for saving and restoring FPU state, which is pretty high on the list of suspected trouble makers. Which would explain why the problem goes away if mouse acceleration is disabled via xset. Kind regards, Markus
Re: i7-720QM one more time
On Thu, 3 Jun 2010 18:31:05 -0400 (EDT) Charlie Root wrote: > > Thanks for your looking at my post. > Come to think about the wsmouse, I believe that Xorg -configure set > it to wsmouse0, so I tried wsmouse1 (no joy, niether the trackpad or > the wireless mouse worrked. I don't believe is has ever been set to > simply wsmouse. I'll give that a try. Kyle, It seems you misread tedu@'s post. He asked you to check to see if your X is using '/dev/wsmouse0' or '/dev/wsmouse' ? Though your /etc/X11/xorg.conf file might designate something, the way to figure out what you're actually using is look at /var/log/Xorg.0.log When X doesn't get what it wants, it can sometimes fall back to something else (e.g. intenral default config), so what you're actually using could be different from what you've defined in /etc/X11/xorg.conf via `Xorg -configure` or manually. As for whether or not you even need to have an xorg.conf file, that's a somewhat different matter. Often (as is the goal), you can run without a configuration and let X set itself up automatically. This doesn't always work, but works most of the time. Also, I remember seeing the evil word "nvidia" in your dmesg: vga1 at pci1 dev 0 function 0 vendor "NVIDIA", \ unknown product 0x0a75 rev 0xa2 Sadly, I don't have total recal, so I'm not sure which nvidia graphics chip that is. The thing you need to know is support for the newer nvidia crap namely GeForce 8xxx, GeForce 9xxx and GeForce GTX (G80, G84, G86, G92, G94, G96, G98, GT200) is only available in -current. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
On 4/06/2010, at 6:41 PM, patrick keshishian wrote: > On Thu, Jun 3, 2010 at 11:18 PM, Uwe Dippel wrote: >> On Thu, Jun 3, 2010 at 7:18 PM, Richard Toohey >> wrote: >> >>> OK, I've tried it and cannot reproduce what you see. I've never done >>> an upgrade from bsd.rd before, so wanted to give it a go. >>> >>> Obviously something different with your set-up, or where you got the files >>> from, or factor X - but as other people have said, they can't guess what. >>> >>> In short - the basic bsd.rd "follow these instructions" worked for me > here. >>> >>> OK, I start with 4.6 amd64 (either 4.6 or just pre-4.6 release) >>> >>> uname -a >>> OpenBSD dellamd64.home 4.6 GENERIC#0 amd64 >>> >>> But before I upgrade, what's /sbin/pfctl? >>> >>> $ ls -l /sbin/pfctl >>> -r-xr-xr-x 1 root bin 492664 Dec 3 23:12 /sbin/pfctl >>> $ md5 /sbin/pfctl >>> MD5 (/sbin/pfctl) = 3e1fa4f69809adff432f9da62010a6a7 >>> >>> http://openbsd.org/faq/upgrade47.html >>> >>> "One easy way to boot from the install kernel is to place the 4.7 version > of >> bsd.rd in the root of your boot drive, then instruct the >>> boot loader to boot using this new bsd.rd file. On amd64 and i386, you do >> this by entering "boot bsd.rd" at the initial boot> prompt." >>> >>> OK, I'll get the bsd.rd from the 4.7 release CD (but could have used FTP.) >>> >>> /usr/bin/su root >>> mv /bsd.rd /bsd46.rd >>> mount /dev/cd0a /mnt/ >>> cp /mnt/4.7/amd64/bsd.rd /bsd.rd >>> umount /mnt >>> eject /dev/cd0a >>> reboot >>> ... boot > boot bsd.rd >>> ... Welcome to the OpenBSD/amd64 4.7 installation program. >>> ... I choose upgrade ... take defaults all the way until ... >>> Location of sets? [What do I do here? I'll try http, and take the >> defaults. What did YOU do here?] >>> bsd, bsd.rd, base47.tgz, misc47.tgz, comp47.tgz, man47.tgz, game47.tgz, >> xbase47.tgz >>> xshare47.tgz, xfont47.tgz, xserv47.tgz ... all get to 100% no errors. >>> ... rest of install, reboot ... >>> $ uname -a >>> OpenBSD dellamd64.home 4.7 GENERIC#112 amd64 >>> $ ls -l /sbin/pfctl >>> -r-xr-xr-x 1 root bin 500856 Mar 18 15:36 /sbin/pfctl >>> $ md5 /sbin/pfctl >>> MD5 (/sbin/pfctl) = 7720c9a4dc100fe29d2d3c4a16954eb4 >> >> Thanks, Richard. >> >> No, you couldn't encounter it. >> It comes in later. >> I have now the whole upgrade session of my third machine, the log is > 2 > MB. >> Whenever I rebooted, it was okay: >> 1. reboot to start bsd.rd - okay >> 2. reboot directly after bsd.rd upgrade - okay >> 3. reboot after 'Final steps', before pkg_add - okay >> 4. reboot after 'Upgrading packages' - okay >> 5. reboot after patching - old files and wrong timestamps - bummer, as >> Theo might say. > > you mean applying the errata47.html patches? If so, are you certain > your source tree is tagged OPENBSD_4_7 and not anything else? > > --patrick I think we are getting closer, aren't we? So, NOTHING to do with the actual upgrade, is it? Or the ports/packages. It is something to do with how you are PATCHING after an upgrade. You don't mention where/when you get the source you patch? Because that would be a separate step, wouldn't it? (I usually install from CD, so I scrub /usr/src & load from src.tar.gz on the CD.) > > > >> I wonder if I can put the file up into the open, or if it contains >> security-related matter.?? >> As bz2 it is just 91 k; I will of course make it available to >> individuals on request. >> >> Uwe
