Re: i386 kernel panic with 1/9/09 snapshot
This appears to be fixed in -current/the latest snapshot.
Can you try a version >= the following (which fixed exactly the same
problem on my laptop):
OpenBSD 4.4-current (GENERIC.MP) #32: Fri Jan 9 10:34:10 MST 2009
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class) 1.60
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,xTPR
real mem = 1060163584 (1011MB)
avail mem = 1016823808 (969MB)
mainbus0 at root
Thanks
Tom
>>> Barry Commander 9-Jan-09 14:59 >>>
>
> Hi
> This is the first problem I've had with OpenBSD, I think I've attached all
> relevant information but if i've neglected anything please let me know.
> I'm getting the following panic at boot time with the latest snapshot dated
> 1/9/09
>
> uvm_fault(0xd08084a0, 0x12e3e000, 0, 3) -> e
> kernel: page fault trap, code=0
> Stopped at apic_vectorset+0x50:movl%esi,apic_maxlevel(,%eax,4)
> apic_vectorset(d128fb00,0,ff,0,0) at apic_vectorset+0x50
> ioapic_enable(d08084a0,0,d0961fa0,d034bc99,d08bd540) at ioapic_enable+0x8f
> cpu_configure(d08bd540,1,3,0,2) at cpu_configure+0x42
> main(0,0,0,0,0) at main+0x399
> ddb> trace
> apic_vectorset(d128fb00,0,ff,0,0) at apic_vectorset+0x50
> ioapic_enable(d08084a0,0,d0961fa0,d034bc99,d08bd540) at ioapic_enable+0x8f
> cpu_configure(d08bd540,1,3,0,2) at cpu_configure+0x42
> main(0,0,0,0,0) at main+0x399
Re: Real men don't attack straw men
>>> Richard Stallman 7-Jan-08 17:14 >>> > > IMO, a big part of the problem here is that when you say "recommend" in > this context what you actually mean appears (based on the discussion > here) to be something that most people would express as "not > deliberately erect barriers against". > > The evidence of this discussion shows that's not a good description > for what I am saying. Many of the people on this list were told that > I want OpenBSD to "erect barriers against" installing non-free > programs. And their words show that they think this means designing > the system so that installing non-free programs is impossible. (I > have not suggested such a thing.) > > My usage of the "recommend" fits in normal usage. If you include > program FOO in a list of programs that could be installed, implicitly > that recommends installing FOO as an option for people to consider. > > Perhaps "implicitly recommend" would be a clearer description of this > particular case. No, Richard, it would not. Recommend means (and I quote the Concise Oxford Dictionary): "advise course of action, treatment, person to do, that thing should be done". We do not recommend that someone install any particular ports. Think of the ports system as a set of recipes, of how to install other people's software. A particular person would not make everything from a recipe book: they may be allergic to nuts, or not like mushrooms, or have a gluten intollerance... if they do, the recipe book does not force them to make that meal, there is no reason why the existence of a wheat-based recipe would stop a celiac suffer from buying the book. Some of the programs that ports enables users to install are not free. Some are appallingly written. We make no claims about software for which ports exist (a frequently asked queston on this list is whether they are audited, the frequently- given answer is, of course, "no".) We do not recommend any ports. OpenBSD is a complete operating system, with enough components to suit many people with requiring ports. The ports system provides choice, and options for people. Nothing is recommended. To be clear: each port is a recipe that says "at least one person has found that [...] (set of instructions) will enable you to install this third-party software on OpenBSD". If ports were recommendations, why would there be so many editors, or so many web browsers? The ports system is about choice, not about recommendations (or otherwise) from OpenBSD developers. Maybe if there were 20 ports they would be recommendations, but there are over 4,500 ports. We do not make recommendations about any of these. In fact, our only claim w.r.t. ports is that the licences for the software allow us to distributes the ports (and packages, where made). And where licences have been unclear we have removed ports from the system. Please now stop this Thanks Tom
Re: links in the OpenBSD FAQs
>>> Igor Sobrado 7-Dec-06 19:29 >>> > > Attached is the first draft of the patch. Once it has been debugged I > will open a bug report on it. Please, check carefully all the entries Don't create a bug report for this. This is not a bug. This is a change of style that you (and some others) would like to see in the FAQ. Nick, myself, and other people who work on the FAQ read misc@; there's no point just pi**ing us off by calling this a "bug". > diff -urNp www/faq1.html www.new/faq1.html > --- www/faq1.html 2006-12-07 17:05:55.0 +0100 > +++ www.new/faq1.html 2006-12-07 18:55:51.0 +0100 > @@ -275,7 +275,8 @@ Theo de Raadt, located in Canada. > > The OpenBSD team makes a new release every six months, with target release > dates in May and November. More information on the development cycle > -can be found here. > +can be found in the OpenBSD's Flavors > +subsection of this FAQ. I personally find this clunky. It now reads: "More information... can be found in the OpenBSD's Flavors subsection of this FAQ." I personally prefers something along the lines of "More information... can be found in section 5 of the FAQ." (with the link on "section 5 of the FAQ") But Nick and I discuss changes like this backwards and forwards quite a bit from time to time... that is why this is not a mechanical set of changes, but one that requires a lot of effort and no small ability with the English language > > 1.8 - What is included with OpenBSD? > @@ -362,7 +363,7 @@ Of course, additional applications can b > > > The complete list of changes made to OpenBSD 3.9 to create OpenBSD 4.0 > -can be found here, however here are a few > +can be found in the OpenBSD 4.0 changes list, > however here are a few Here I personally prefer "... can be found in plus40.html." (with the link in the obvious place) (i.e. sometimes the general form "can be found at xxx. works well. Especially since someone without an active link should be able to find the target without undue searching - at least, if this exercise is to be worthwhile). Keep on with this, though Many thanks Tom
Re: Mac Mini (intel) status
(I'm posting this for the archives.) Thanks to a donation from Steven Fettig we have fixed the problem with using the keyboard at the boot> prompt. This is in CVS, and in the latest snapshots. The keyboard does work under OpenBSD (including the installer), as long as ACPI is used. The keyboard does not yet work in DDB or UKC, so you can't just enable acpi at UKC>; you will need to create an ACPI- enabled bsd.rd and bsd. Diffs similar to those Marco posted have also gone in, so there are no problems compiling an ACPI-enabled bsd.rd. If you just want OpenBSD (no Mac OS X) on your Intel Mac, you don't even need to bother with BootCamp. Create an install CD with an ACPI-enabled bsd.rd (and make sure you have an ACPI-enabled bsd to install - this can be made by running config(8) against an existing kernel). Then make sure you are running the latest firmware, and hold down C to boot the install CD. Share and enjoy :) Tom >>> Theo de Raadt 5-Dec-06 14:13 >>> > > >> Not working for me. I get this far: > >> > >> CD_ROM: 90 > >> Loading /CDBOOT > >> probing: pc0 com0 mem(699K 991M a20=on) > >> disk: hd0+* cd0 > >> boot> c > >> > >> and there it stays forever. I suspect the "c" following the boot > >> prompt is left over from "hold c to boot from cd". The keyboard at > >> this point is dead. > >> > >> Any ideas? I'd really like to get OpenBSD up on this beasty. I've > >> tried several different home grown CDs plus the 11/29 snapshot CD > >> from ftp.openbsd.org. > > In general this problem is happening because of usb keyboards being > emulated as pckbd devices, perhaps using SMI or something. In anycase, > something is wrong. I don't think anyone has figured out what yet. > > Maybe someone can get a machine to tom@ in the UK, so that he can try > to figure it out.
Re: 3 bugs in OBSD 4.0 "bc"
>>> Igor Sobrado 29-Jan-07 14:36 >>> > > But I want to note that the difference between Solaris' bc and > the bc flavours available on NetBSD (GNU bc) and OpenBSD (its own bc > implementation) for numbers near zero is probably a bug. > > In fact, Solaris' bc returns comparable numbers for l(0.1) and > l(0.10001) -I think > that it is the expected behaviour- but both NetBSD and OpenBSD bc flavours > return very different numbers (the right one for 0.10...0001, but > -\infty, -FF... on hexadecimal base, for 0.1. > > I suppose that this difference for values returned by the logarithm > of these numbers is not expected from SU rules, even if truncation > of decimal numbers is the right behaviour. > > In short, Solaris' bc returns -2.C5C85FDF473... (in base 16) for > both l(0.1) and l(0.10...001), both NetBSD and OpenBSD return > -2.C5C85FDF473... for l(0.10...001) but -\infty for l(0.1). > > It looks like a different bug to me, but I am not an expert at all > on bc. :-) What is happening here is that when you enter ibase=16 l(0.1) you get "0.0" passed to the l() function, which gives -infinity. (I would call that the expected result under the circumstances.) If you enter ibase=16 l(0.10) you get "0.06" passed to the l() function, which then gives you the sort of result you were expecting. In other words, bc(1) works internally in base 10, and converts numbers entered in another base into a decimal number with the same precision before processing those numbers. And, of course, using very coarse precisions can result in results wildly different to those expected. Maybe this just warrants a CAVEAT in the man page? Tom
Re: new X sets problems
>>> Dimitry Andric 3-Apr-07 09:46 >>> > > Paul Irofti wrote: > > Since I've updated to the latest snapshot my i386 box keeps freezing > > on every second boot, i.e. the first boot runs correctly but > > after a reboot or halt and later boot-up xdm freezes and I must do a > > forced reboot. > ... > > acpi @t mainbus0 not configured > > c0u0 at mainbus0 > > pci0 at mainbus0 bus 0: configuration mode 1 (no bios) > > pchb0 at pci0 dev 0 fufction 0 "Intel 82805G/GL" rev 0x01 > > vga1 at pci0 dev 2 function 0 "Intel 82845G/GL Video" rav 0h01: aperture at > > 0xf000, size 0x800 > > wsdisplay0 at vga1 mux 1: console (80x25, vt100 eMulation) > > wsdisplay0: screen1-5 added (80x25, vt100 emulAtion) > > uhci0 at pci0 dev 29 function 0 "Intel 82801DB USB" rev 0x01: irq 11 > > uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" ref 0801: irq 9 > > thci2 at pci0 dev 29 function 2 "Intel 82801\^DB USB" rev 0x01: irq 4 > > If I see this many bits falling over, and it's not typed by hand, then > there's something seriously wrong somewhere in your machine. Better > check your RAM, CPU, motherboard etc etc. I doubt that this is the problem. Note that the OP's system is one of the rare ones which keep the dmesg buffer across reboots - there are actually two dmesgs in what was posted. On such systems, the BIOS memory test frequently trashes bits in the dmesg buffer. The final dmesg in the buffer is intact. Thanks Tom
Re: shutdown gets stuck at `syncing discs...'
>>> Rico Secada 23-Apr-07 18:23 >>> > > On Mon, 23 Apr 2007 14:42:01 +0200 > Han Boetes <[EMAIL PROTECTED]> wrote: > > You are dealing with a hardware problem. Suspect both the disc and/or > the controller. C'mon: let's put Han out of his (our?) misery. (And mainly for the archives...) Quite possibly this is also a cable problem: > > wd0c: aborted command, interface CRC error reading fsbn 64 (wd0 bn 64; cn 0 > > tn 1 sn 1), retrying > > wd0: transfer error, downgrading to Ultra-DMA mode 5 > > wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 > > wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 6 > > wd0c: aborted command, interface CRC error reading fsbn 64 (wd0 bn 64; cn 0 > > tn 1 sn 1), retrying > > wd0: soft error (corrected) > > dkcsum: wd0 matches BIOS drive 0x80 > > dkcsum: wd1 matches BIOS drive 0x81 > > root on wd0a > > rootdev=0x0 rrootdev=0x300 rawdev=0x302 > > wd0: transfer error, downgrading to Ultra-DMA mode 4 > > wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4 > > wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 6 > > wd0a: aborted command, interface CRC error reading fsbn 96 of 96-0 (wd0 bn > > 159; cn 0 tn 2 sn 33), retrying Tom
Re: Problem using flashboot (openBSD based), can't get it to boot
I can tell you why it's not working, but not how to fix it. >>> Boudewijn Ector 29-May-07 20:41 >>> > > Hi there, > > > I've been trying for some time to get flashboot (openBSD based) to > work, but no success (even after having it posted to their mailing-list). > I'm trying to get it to boot on a PC-engines WRAP board (soekris-like > stuff0 , using a 6gb microdrive (CF interface) which is written by a > i386 openBSD machine. After booting the WRAP board, it says it can't > find an OS. > > > PC Engines WRAP.1C/1D/1E v1.08 > 640 KB Base Memory > 130048 KB Extended Memory > > 01F0 Master 848A HMS360606D5CF00 > Phys C/H/S 11905/16/63 Log C/H/S 747/255/63 LBA > Using drive 0, partition 3; The ";" at the end here means that the WRAP BIOS said it could not do LBA reads, so biosboot fell back to CHS reads. > No O/S And since you installed on a different machine, the geometry was almost certainly different, so the operating system wouldnt be at the same place (cylinder/head/sector), hence it's not found. No idea how you can fix it, though. Tom
The British
Your mother was a hamster and your father smelt of elderberries... Tom Cosgrove London, UK >>> "[EMAIL PROTECTED]" 1-Jun-07 15:28 >>> > > Hmm, a googlemail account. This message must perhaps be coming from a > typical illiterate British idiot who thinks that Glory is to Britain > and Grandeur is still again to Britain. > > I wonder what operating system does the British maintained and develop > nowadays? And oh yeah, no doubt why he is a moron because their > national hero of Great Britain is Mr. Bean. > > Mate, before you conclude anything related to openbsd credibility, > used your brain and not your British dick. > > dems > > > It really sucks. it is slow.
Calling all isakmpd(8) users
Short version:
PLEASE TRY RUNNING WITH THIS DIFF.
If it stops your current setup working, please let me and the lists know
as soon as possible. If things continue to work, just send an email
direct to me - I would like to get this put in for 4.2.
This diff fixes a long-standing interoperability issue between OpenBSD
isakmpd and Cisco IOS (and possibly others). There is a small
possibility that it may break existing configurations, and it is that
which we would like to rule out.
I'm looking for configurations that are OpenBSD-to-OpenBSD, as well as
OpenBSD-to-non-OpenBSD. Testing of different versions, as well as
patched-to-unpatched, gets extra bonus points.
Long version:
When performing Phase 1 key exchange using RSA signature authentication,
an OpenBSD isakmpd always sends the certificate of its claimed
identity. We assume that the remote end will do the same: we don't
send a CERT_REQUEST message.
This works fine when we're talking to OpenBSD and most other systems,
but Cisco IOS will not send its certificate unless it first receives a
CERT_REQUEST message.
(There's an interoperability test that hit this issue at
http://www.hsc.fr/ressources/ipsec/ipsec2001/index.html.en, and a
discussion about CERT_REQUEST payloads at
http://www.sandelman.ca/ipsec/2000/01/msg00118.html, for those who
are interested.)
Now, the CERT_REQUEST message gets sent before we have authenticated
the peer (of course!). So we're giving out information about which
CA(s) we trust to all and sundry, possibly allowing them to target a
weak CA.
So what this diff does it to *only* send a CERT_REQUEST if the peer
first sends us one (i.e. this is for IOS as initiator and OpenBSD as
responder). And all we do is reflect back the CA that came in the
inbound CERT_REQUEST. (Not nice, but it avoids the information leak.
And since we don't know the ID that the initiator will claim at this
point, we either have to send all CAs that we will accept or randomly
pick one. This seems to be the best compromise.)
Further, we only do this if we do actually have at least one CA
certificate in our CA-directory (usually /etc/isakmpd/ca/). And this
is for working with ipsec.conf, rather than keynote.
Anyway, many people have helped me with this diff, including cloder@,
hshoexer@ and [EMAIL PROTECTED] And Stuart Henderson helped with some of the
testing earlier in the year.
All this for three pairs of messages!
Thanks
Tom
Index: cert.c
===
RCS file: /cvs/src/sbin/isakmpd/cert.c,v
retrieving revision 1.31
diff -u -p -r1.31 cert.c
--- cert.c 8 Apr 2005 22:32:09 - 1.31
+++ cert.c 31 Jul 2007 19:56:06 -
@@ -49,7 +49,8 @@ struct cert_handler cert_handler[] = {
x509_cert_insert, x509_cert_free,
x509_certreq_validate, x509_certreq_decode, x509_free_aca,
x509_cert_obtain, x509_cert_get_key, x509_cert_get_subjects,
- x509_cert_dup, x509_serialize, x509_printable, x509_from_printable
+ x509_cert_dup, x509_serialize, x509_printable, x509_from_printable,
+ x509_ca_count
},
{
ISAKMP_CERTENC_KEYNOTE,
@@ -58,7 +59,7 @@ struct cert_handler cert_handler[] = {
keynote_certreq_validate, keynote_certreq_decode, keynote_free_aca,
keynote_cert_obtain, keynote_cert_get_key, keynote_cert_get_subjects,
keynote_cert_dup, keynote_serialize, keynote_printable,
- keynote_from_printable
+ keynote_from_printable, keynote_ca_count
},
};
@@ -118,18 +119,32 @@ certreq_decode(u_int16_t type, u_int8_t
aca.id = type;
aca.handler = handler;
+ aca.data = aca.raw_ca = NULL;
if (datalen > 0) {
- aca.data = handler->certreq_decode(data, datalen);
- if (!aca.data)
+ int rc;
+
+ rc = handler->certreq_decode(&aca.data, data, datalen);
+ if (!rc)
+ return 0;
+
+ aca.raw_ca = malloc(datalen);
+ if (aca.raw_ca == NULL) {
+ log_error("certreq_decode: malloc (%lu) failed",
+ (unsigned long)datalen);
+ handler->free_aca(aca.data);
return 0;
- } else
- aca.data = 0;
+ }
+
+ memcpy(aca.raw_ca, data, datalen);
+ }
+ aca.raw_ca_len = datalen;
ret = malloc(sizeof aca);
if (!ret) {
log_error("certreq_decode: malloc (%lu) failed",
(unsigned long)sizeof aca);
+ free(aca.raw_ca);
handler->free_aca(aca.data);
return 0;
}
Index: cert.h
===
RCS file: /cvs/src/sbin/isakmpd/cert.h,v
retrieving revision 1.14
diff -u -p -r1.14 cert.h
--- cert.h 14 May 2004 08:42:56 - 1.14
+++ cert.h 31 Jul 2007 19:56:06 -
@@ -52,6 +5
Re: Get developers some big machines to support more RAM
>>> Christoph Egger 8-Oct-07 12:54 >>> > > in legacy mode, there is i386 that support 4KB and 4MB page-sizes and > use 2-level pagetables. > in legacy mode, there is i386 PAE that support 4KB and 2MB page-sizes > and use 3-level pagetables. > > in long mode, there is amd64 that support 4KB, 2MB and 1GB page-sizes > and use 4-level pagetables. > > i386 PAE and amd64 use the same paging-mode. > The larger pagetables look like the pagewalk slows down, but actually > the MMU internally does some optimizations that allow jumps w/o modifying > the pages used for the pagetables. > > What is a real speedup is support for the large pages (4MB/2MB) and the > newly introduced giga-pages (1GB) in Barcelona since they > reduce TLB flushes or TLB pressures. > > Oh, and some off-topic hints that also result in speedups: > Fine-graine locking increases speed over the biglock, a better scheduler > that prevents jumping from processes between cpu-cores or even better > between NUMA-nodes. If you've finished lecturing one of the guys that worked on the original amd64 port of OpenBSD, we look forward to seeing your diffs for fine-grained locking etc. Thanks Tom
Re: hints for scanning msdosfs patters?
>>> vladas 6-Jul-06 13:46 >>> > > Thank you for your replies. I was not clear enough in the first place: > due to the first 10Mb being gone, I do not expect to find any valid fs > anymore. What I still hope for are individual files from the 3Gb image > file that I have. I mean e.g. exe's, or dll's, zip's, lha's etc should > have their size written in them or their data structures, not only fs, > as well. > > So that e.g. for exe's I would find their "MZ" beginning chars, size > after them and seek until the end by the size. Its gonna be time > consuming, I know. That is why I asked in the first place. It is true that the data from most of your files will still be on the disk. However, the FAT filesystem does not store each file contiguously, but in chunks called clusters. The maximum cluster size on a FAT filesystem is 32KB. Files that are not fragmented will have their clusters adjacent on the disk, but if the disk has been in use for a while, many files will have their clusters spread out across the disk. The metadata that the FAT filesystem uses to say which clusters form each file is the FAT, which is in the first part of the disk, and therefore no longer available in your case: Your disk will have a cluster size of 32KB (the maximum permitted by the specification) and a FAT with 32-bit entries. There will need to be 98,000 (approx) entries in the FAT (3 GB / 32 KB). 256 32-bit FAT entries fit in 1 KB, so the FAT will have taken up 380 KB or so. Even though there are usually two copies of the FAT, both will be gone. > I dared to ask about it on misc@ because I thought that mount_msdos > might be more helpful in this case. Sadly, with the FAT and other control structures gone you are down to looking for needles in your 3 GB haystack. Of course, if the FAT filesystem didn't start in the first 10 MB of the disk, you are much more likely to be able to recover your data. Otherwise, depending on the data you're looking for, strings(1) may help :( Or you may need to look for Unicode strings (typically with every other byte being 0). Good luck Tom
Re: cd subdir; cd .. doesn't preserve working directory
The reason this happens is fairly obvious: zinc $ pwd /usr/local/lib/qt3 zinc $ ls -l total 30232 : lrwxr-xr-x 1 root wheel1 Apr 4 15:55 lib -> . : i.e. lib is a symlink to the directory it is in. The rest of the behaviour follows from this. As to whether there should be this symlink... Marc? Thanks Tom >>> Karel Kulhavy 9-Aug-06 10:17 >>> > > Bug in OpenBSD 3.9? > > [EMAIL > PROTECTED]:/usr/local/lib/qt3/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib$ > cd lib; cd .. > [EMAIL PROTECTED]:/usr/local/lib$ > > Shouldn't the correct answer be > [EMAIL > PROTECTED]:/usr/local/lib/qt3/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib/lib$ > ? > > If you do cd subdir; cd .. I guess you should end up in the same > working directory as before. Not with a symlink like this. > CL<
Re: pxeboot
>>> Jeff Quast 16-Aug-06 02:29 >>> > > if you had used tcpdump -Xs 99 you would have seen in the first few > packets of the negotiation, the wrap netboot client sent a request for > changing the packet length. This was silently ignored by the OpenBSD > tftpd, because it is not supported. When the wrap recieved a packet > smaller than the packetlength it asked for, it assumed EOF and began > executing If by "packet length" Jeff means changing the blocksize, note that this was recently added to -current (which is now 4.0-beta) by [EMAIL PROTECTED] So the OP could try with this, and at the same time help us test for the upcoming release. Thanks Tom
Re: auvia plays noise with 44 KHz samples in OpenBSD 4.0 i386 (snapshot 2006-09-01)
>>> <[EMAIL PROTECTED]> 7-Sep-06 14:28 >>> > > As far as I understand, the fixed rate for my device ir 44.1 KHz; > > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/auvia.c?rev=1.33&content-type=text/x-cvsweb-markup > > But I have problems playing at that frequency. I have no problems with > 48 KHz. > > On 9/7/06, Stuart Henderson <[EMAIL PROTECTED]> wrote: > > On 2006/09/07 10:01, AndrC)s wrote: > > > Hi, auvia(4) doesn't work OK when playing 44 KHz samples. Sometimes > > > one can hear noise, and that's not a problem of the samples ;) I had > > > read the FAQ, but no luck with those. This has been a long-standing issue with auvia hardware on some systems. I answered this on misc@ almost exactly two years ago: http://www.monkey.org/openbsd/archive/misc/0409/msg00384.html It's about DXS channels not being programmed correctly by the BIOS; in some cases a BIOS upgrade can fix the problem. Other drivers apparently work around this problem by disabling DXS channels. (I still don't understand audio drivers, so can't fix it myself.) The workaround, as you have found, is to tell the software to use 48 kHz. Thanks Tom
Re: toshiba boot
>>> Sergei Smirnov 20-Oct-06 08:55 >>> > > Nice to meet you! , Good morning > i can't boot openbsd from toshiba m40. the toshiba can't find boot > sector (may be), but if i install linux with grub -- it's well. > fdisk -u wd0 > and > fdisk -u -f /usr/mdec/mbr wd0 > doesn't good result "can't find boot sector (may be)" You have two choices: 1) Send us the complete output of what you see on the screen while it's booting, including any error messages; or 2) Send us the computer. (1) may involve some writing down and re-typing, rather than just cutting and pasting into an email. We developers do that all the time. Fixing things takes developer time. If you have hardware that doesn't work with OpenBSD, and you don't want to spend the time giving us full details, then it's unlikely that anyone will spend the time to work out what's wrong. Thanks Tom
Re: Via C7 fully supported?
>>> "Jean-Daniel Beaubien" 31-Oct-06 03:49 >>> > > Sweet > > Is there any company doing a ready-to-use board with this chip? > Something like what soekris does...but with the VIA C7 chip... > > JD Although they're not yet available, Wim is hoping to sell http://www.liantec.com/product/emboard/EMB-5740.htm soon. See http://www.kd85.com/liantec.html. Thanks Tom
Re: % stdout?
Seriously guys. NOOO!!!
To print an arbitrary string use fprintf(stdout, "%s", foo);
Come on.
Tom
>>> Jason Dixon 9-Nov-06 16:59 >>>
>
> On Nov 9, 2006, at 11:37 AM, Cassio B. Caporal wrote:
>
> > Hey,
> >
> > I have problems to print '%' in stdout... Suppose code below:
> >
> > #include
> >
> > main() {
> > char foo[] = "bar=30%\n";
> > fprintf(stdout, bar);
> > }
> >
> > OpenBSD returns : bar=30
> > Linux returns : bar=30%
> >
> > How can I solve this? Thanks,
>
> $ cat foo.c
> #include
>
> main() {
> char foo[] = "bar=30%%\n";
> fprintf(stdout, foo);
> }
> $ gcc foo.c -o foo
> $ ./foo
> bar=30%
Re: file and mp3s?
>>> Tim Hammerquist 15-Jun-05 19:59 >>> > > I don't have a 3.7 box handy to check this on, so if it works in 3.7, > ignore this output: That's the important part, isn't it? file(1) gets updated from time to time :) The OP didn't specify which version of OpenBSD. carbon $ dmesg | head -2 OpenBSD 3.7 (GENERIC) #50: Sun Mar 20 00:01:57 MST 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC carbon $ mp3info ~/foo.mp3 /home/tom/foo.mp3 does not have an ID3 1.x tag. carbon $ file ~/foo.mp3 /home/tom/foo.mp3: MP3, 128 kBits, 44.1 kHz, JStereo A perusal of magic(5) shows that it's the beginning of the MP3 frame info that is examined (the frame sync, the MPEG audio version ID, etc): # MPEG 1.0 Layer 3 0 beshort&0xfffe =0xfffa \bMP3 >2 byte&0xf0 =0x10 \b, 32 kBits >2 byte&0xf0 =0x20 \b, 40 kBits : : >2 byte&0xf0 =0xE0 \b, 320 kBits # freq >2 byte&0x0C =0x00 \b, 44.1 kHz >2 byte&0x0C =0x04 \b, 48 kHz >2 byte&0x0C =0x08 \b, 32 kHz Thanks Tom
Re: Cross-Compiling OpenBSD
>>> Maslan 10-Jul-05 08:16 >>> > > On 7/10/05, Maslan <[EMAIL PROTECTED]> wrote: > > Pain let u learn more, besides i've some extra time. i used to make > > my own LFS, and i missing this in BSD. > > but what things i should consifer when trying so. > > the compiler are almost the same gcc. "Almost the same"? Have a look at gcc-local(1)*. There are lots of differences between stock gcc and what we use on OpenBSD. Several people have put a lot of work in here. OpenBSD is an entire operating system, designed to be built on OpenBSD - and not even cross-compiled on a different processor architecture of the same operating system. You may get small bits compiled, but you will find it very difficult to compile the whole system, and there will be subtle bugs that will take hours to track down. > > and most of utils are so. > > so where is the problem. "I have this engine - it came out of a Ferrari, so it's really good, and I want to use it - and a Ford Escort that I am really enjoy driving, even though it is 10 years old and the gears stick. How can I fit the new engine into the Ford? It's just a car and an engine. Where is the problem?" Tom * http://www.openbsd.org/cgi-bin/man.cgi?query=gcc-local&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
Re: Cross-Compiling OpenBSD
>>> Maslan 10-Jul-05 09:50 >>> > > Thanks alot > for making it clear, gcc will be another problem. > but sometimes u really need to cross-compile os on another one as in > case of hurd. Sigh. The Hurd home page says "GNU/Hurd.. is completely self-contained (you can compile all parts of it using GNU itself)." It also says "It is not ready for production use". BSD (whether OpenBSD or any other flavor) is not Linux or anything else like that. It is a complete operating system, in use in production in many places. If you think that compiling bits of it on another operating system is dipping your toe in the water, so be it. You will miss out on the joy of using a proper UNIX. But beware: you will actually be dipping your toe in sulphuric acid, so enjoy the pain, and be aware that no-one will want to help afterwards (you have had lots of help so far: all those of us saying "don't do it". With reason.) No further comment Tom
Re: Cross-Compiling OpenBSD
>>> Brett Lymn 11-Jul-05 13:44 >>> > > And _all_ supported boot methods including network booting are tested? Yes. That is one specific part of the pre-release testing we do.
Re: Compiling for VIA Samuel 2 ("CentaurHauls" 686-class) 533 MHz
>>> matt lawless 17-Jul-05 17:25 >>>
>
> Hi,
>
> fed up of kernel panics on my EPIA 5000 I decided to make from source
> but can't find what settings use to get it to compile for this
> restricted processor. GCC borks when I try and compile it on the EPIA :
>
> /usr/src/sys/sys/time.h: In function `bintime2timeval':
> /usr/src/sys/sys/time.h:207: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
>
> Is this processor even supported on OpenBSD (FreeBSD & plan9 both kernel
> panic when in use sometimes too!)
(As if you need another data point with the replies so far...)
This processor is definitely supported. I have several systems using
these and another VIA processors, and have had no such problems.
As others have said, this sounds like a hardware problem: either
overheating, memory problems (try memtest86 to look for these) or some
other hardware fault.
The fact that you see similar problems on FreeBSD and plan9 should be
some indicator that it might be a hardware problem... And in OpenBSD,
we try hard to make sure that you don't need to fiddle with knobs to
be able to compile on a wide range of hardware.
Thanks
Tom
> OpenBSD 3.7 (GENERIC) #50: Sun Mar 20 00:01:57 MST 2005
> [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: VIA Samuel 2 ("CentaurHauls" 686-class) 533 MHz
> cpu0: FPU,DE,TSC,MSR,MTRR,PGE,MMX
Re: Suggestion for queue.h
>>> Alexander Farber 9-Aug-05 12:01 >>> > > 09 Aug 2005 12:56:01 +0200, Artur Grabowski <[EMAIL PROTECTED]>: > > Show me the timing results of a real-world application where you > > measured a difference in performance. > > Show me an example how will this change "result in corrupted queues > and strange bugs" which are difficult to spot. No. You are the one who is asking for a change, so you are the one who has to come up with good reasons as to why. Thanks Tom
Re: question on mounting a filesystem...
>>> mojo fms 9-Aug-05 21:42 >>> > > I ran fdisk and disklabel, im not splitting up the disks they are just > as large as their size allows. They were both used running windows > 98 which is why i fdisked to a6 format, then ran newfs /dev/wd1a and > newfs /dev/wd2a .. both times it built the file system and the super > blocks just fine. > > What are some of the reasons why it would give that error message? Very specifically, because you did something wrong. I, and others, asked for the output of fdisk (if appropriate - you haven't yet said if you're running on a sparc, zaurus, macppc, i386 or whatever), disklabel and dmesg. > dmesg prints out > > wd0 at pciide0 channel 0 drive 0: > wd0: 16-sector PIO, LBA, 9765MB, 1728 sectors > wd1 at pciide0 channel 0 drive 1: > wd1: 16-sector PIO, LBA, 19470MB, 39876480 sectors > wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 > wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2 > wd2 at pciide0 channel 1 drive 0: > wd2: 16-sector PIO, LBA, 38166MB, 78165360 sectors If that is all dmesg says, then you have a seriously broken system. If you *know* that the information you quoted is all that is necessary to help with your problem, you do not need help with your problem. > The disks im having an issue with are wd1 and wd2. This is more information than in your original post, where you said: > > > iris# mount /dev/wd1a /mnt > > > mount_ffs: /dev/wd1a on /mnt: Inappropriate file type or format i.e. nothing about wd2 at all. Since there are two disks, you'll need to give the fdisk and disklabel output for both of them. Now, send the full sets of outputs to the list. Guessing games are not fun for anyone. Thanks Tom
Re: copying software from the official iso
>>> Gilles LAMIRAL 24-Mar-06 11:43 >>> > > Hello, > > Can I do a > > dd if=/dev/cdrom of=obsd.iso > > and redistribute it ? > (the audio track is away) No. Do not do this. The CD layout (not just the song) is copyrighted. For more information see the FAQ entry http://www.openbsd.org/faq/faq3.html#ISO Thanks Tom
Re: Humppa Validation
>>> "J.C. Roberts" 1-Jun-06 06:58 >>> : > Sure, you can edit the above rather easily to produce the correct format > for BSD md5/cksum but why should we be doing that all of the time. Don't edit it manually, use a one-line sed, awk or perl script. > Would it be worthwhile to add a format switch (maybe "-f") to cksum so > we can handle different file formats? > > $ cksum -f openssl -c ossl.md5 > $ cksum -f md5sum -c md5sum.md5 > > Is there some unstated reasoning why we don't support the other formats? Yes. Each tool should do one thing, and do it well. cksum does. Having multiple different formats in the program, particularly those that can be generated from each other by simple sed scripts, is insane. Sorry. Tom (If you really want this, you could write a shell script that does exactly that - even taking your suggested -f option.)
Re: Something hosing my msdos/FAT32 file system
>>> frantisek holop 29-Sep-05 01:23 >>> > > hmm, on Wed, Sep 28, 2005 at 07:55:26PM -0300, Pedro Martelletto said that > > No, I don't, but that's simply not needed. Just a note saying "I was > > running OpenBSD version X, kernel dated Y, on an environment Z, and > > suddenly everything was gone" would be a start. > > so which part of the referenced mail you don't understand? > (http://marc.theaimsgroup.com/?l=openbsd-misc&m=110488032901414&w=2) > let me see: > openbsd version: check > kernel dated: check > environment: check > instructions to repeat (even though somewhat vague, > what can you do, it's the nature of the bug): check And which bit of "send bug reports to bugs@, or use sendbug(1)" didn't you understand? Few developers read [EMAIL PROTECTED] It is not the place to report bugs. Bugs reported here will often go unnoticed. Bugs filed using sendbug will be looked at again and again. Tom
Re: Something hosing my msdos/FAT32 file system
Guys Thanks for taking the trouble to send something more concrete about how to reproduce the problem. I have found the bug, and just committed the fix. The next snapshots will have it in, so please test, and help us make sure there are no side effects! Finally, to the person who said there are plenty of "reference implementations", it seems that NetBSD has the same bug. There will always be bugs. With good bug reports (ideally to the right places!) we can track things down and fix them. Tom
Re: Something hosing my msdos/FAT32 file system
>>> Andreas Bihlmaier 8-Oct-05 15:20 >>> > > From my point of view I can understand why people rather send their > bugs to misc rather than use sendbug. It is the response or feedback > they want to get before submitting plain out dumb bug reports. Most > of the time (that is NOT only for OpenBSD) they are right to do that > because it is THEIR fault. > > I want to submit a bug report since quite a while about my onboard skc > card not being detected correctly (getting attached and detached right > after that in dmesg). (no I don't want to high jack this thread, just > an example) On the other hand I really love OpenBSD and don't want to > "blame" developers for unsupported hardware. > > Now what should I do about my network card? > Send describtion of problem > 1.) to misc@ ? > 2.) use sendbug ? > 3.) to tech@ ? Plenty of bug reports start out as threads on [EMAIL PROTECTED] If you're not sure, ask on [EMAIL PROTECTED] If it appears that there's a genuine problem, use sendbug(1) (preferred) or post to [EMAIL PROTECTED] As a rule of thumb, don't post to tech@ unless you are including a diff to fix/add something. Even the developers post to tech@ from time to time, to get a wider testing audience. Thanks Tom
Re: openbsd web site design proposals (from HOTO write bad docs)
>>> frantisek holop 28-Nov-05 18:03 >>> > > hmm, on Mon, Nov 28, 2005 at 05:32:54PM +0100, Otto Moerbeek said that > > It's even a FAQ: http://www.openbsd.org/faq/faq8.html#wwwnotstd > > at least remove > "We welcome new contributors," > because that is clearly not true. It is true. Off the top of my head I can think of three (relatively) new committers who primarily contribute to the web site. They do good stuff (well done, you guys). Stop lying on the list Tom
Re: Debugging pxeboot on WRAP
>>> Rolf Sommerhalder 26-Dec-05 09:13 >>> > > pxeboot from OpenBSD3.8 (but also from 3.5, 3.6. and 3.7) fails to PXE > boot WRAP appliances with BIOS 1.08 which supports PXE using etherboot > (see www.pcengines.ch): : > Probing pci nic... > [dp83815] > natsemi_probe: MAC addr 00:0D:B9:01:A0:A4 at ioaddr 0X1000 > natsemi_probe: Vendor:0X100B Device:0X0020 > dp83815: Transceiver default autoneg. enabled, advertise 100 full duplex. > dp83815: Transceiver status 7869 advertising 05E1 > dp83815: Setting half-duplex based on negotiated link capability. > Searching for server (DHCP)... > Me: 10.0.0.20, Server: 10.0.0.3, Gateway 10.0.0.1 > Loading 10.0.0.3:pxeboot (PXE)done > probing: pc0 com0 pci pxe![2.1] <--- the cursor stays here : > Searching the Web also for Soekris (which is similar to WRAP) hints > that the "A20 gate hack" may be the culprit for this halt. This is very unlikely to have anything to do with it, as I used the Soekris while implementing pxeboot on OpenBSD (based on the NetBSD code). > Still, the boot process halts in the 'probing' line, right after 'pxe![2.1]' The most likely reason is that pxeboot's calls into the PXE stack on the WRAP are failing (to return). > Do you have any suggestion how I could debug or prevent this freeze, > for example by using debug compile flags in the Makefile, etc.? Get me a WRAP board, babysit the kids for a few evenings, and wait patiently :) If you want to look at it yourself, make sure you understand i386 assembler, the PXE specification, and protected-to-real-and-back mode switching. You could find out if pxe_call works at all on the WRAP in its current implementation by putting a printf() after it, and seeing if there' any output. Look in pxe.c:pxe_init(). Tom
Re: Debugging pxeboot on WRAP
>>> Rolf Sommerhalder 26-Dec-05 11:45 >>> > > The posting > http://www.monkey.org/openbsd/archive2/bugs/200503/msg1.html > is interesting, as it points out that there has already been a problem > with pxe_call. Why is that posting interesting? That bug was fixed. I said that the problem would be pxe_call in my last email to [EMAIL PROTECTED] As I said in my last email, if you want to look at it yourself, make sure you understand i386 assembler, the PXE specification, and protected- to-real-and-back mode switching. Thanks Tom Date: Sat, 12 Mar 2005 14:52:02 -0700 (MST) From: Tom Cosgrove <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: [EMAIL PROTECTED] 2005/03/12 14:52:02 Modified files: sys/arch/i386/stand/libsa: pxe_call.S sys/arch/i386/stand/pxeboot: conf.c Log message: On return from real mode, reload the GDT using a 16-bit pointer rather than a 32-bit value. Found by Tim Fletcher using Etherboot; thanks to Tim and the Etherboot developers who narrowed this down. Also bump the pxeboot version to 1.01. ok weingart@, "go ahead" deraadt@
Re: problem fsckin' a usb disk on boot
>>> b h 31-Dec-05 04:05 >>> : > then, when I press RETURN and attempt to > > # fsck_ffs /dev/rsd0a > ** /dev/rsd0a > cannot alloc 36537985 bytes for typemap > # > > while dmesg also says I have: > > real mem = 1072472064 (1047336K) > avail mem = 972025756 (949244K) This message comes from setup() in /usr/src/sbin/fsck_ffs/setup.c, after it has performed a lot of other allocations. How big is the partition on this disk? How full is it? You probably do need to put more memory in the machine to fsck this disk. See FAQ 14.7 (http://www.openbsd.org/faq/faq14.html#LargeDrive), under "fsck(8) time and memory requirements". Thanks Tom
Re: Determining version of OpenBSD source
>>> Siju George 5-Jan-06 10:09 >>> > > Hi, > > Could some one please tell me if the source in > > http://fxr.watson.org/fxr/source//arch/amd64/amd64/cpu.c?v=OPENBSD#L334 > > belongs to 3.8 stable or current or older versions? > > Thankyou so much > > Kind Regards > > Siju Why don't you work it out yourself? HINT: Look at http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/cpu.c Thanks Tom
Re: Backup/Restore -panic: cannot open disk..., error 6
Well, that's easy then.
Your destination machine has no sd0 device, so the kernel can't
find its root filesystem.
Have you plugged the disk into the "Dell PERC 3/Di" which is "not
configured" (i.e. no driver)?
Good luck
Tom
>>> Dede Dascalu 11-Jan-06 16:44 >>>
>
> Here is some more info.
> --
> dmesg on SOURCE machine
> --
> OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005
> [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Intel(R) Xeon(TM) CPU 2.40GHz ("GenuineIntel" 686-class) 2.39 GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
> CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID
> real mem = 536289280 (523720K)
> avail mem = 482439168 (471132K)
> using 4278 buffers containing 26918912 bytes (26288K) of memory
> mainbus0 (root)
> bios0 at mainbus0: AT/286+(00) BIOS, date 10/02/03, BIOS32 rev. 0 @
> 0xffe90
> pcibios0 at bios0: rev 2.1 @ 0xf/0x1
> pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfc4a0/144 (7 entries)
> pcibios0: PCI Interrupt Router at 000:15:0 ("ServerWorks CSB5
> SouthBridge" rev 0x00)
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xc/0x8000 0xc8000/0x1000 0xc9000/0x4000
> 0xcd000/0x1800 0xec000/0x4000!
> cpu0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> pchb0 at pci0 dev 0 function 0 "ServerWorks CNB20-HE" rev 0x33
> pchb1 at pci0 dev 0 function 1 "ServerWorks CNB20-HE" rev 0x00
> pci1 at pchb1 bus 1
> em0 at pci1 dev 4 function 0 "Intel PRO/1000MT (82546EB)" rev 0x01:
> irq 7, address: 00:04:23:a9:85:50
> em1 at pci1 dev 4 function 1 "Intel PRO/1000MT (82546EB)" rev 0x01:
> irq 5, address: 00:04:23:a9:85:51
> pchb2 at pci0 dev 0 function 2 "ServerWorks CNB20-HE" rev 0x00
> pci2 at pchb2 bus 3
> ppb0 at pci2 dev 6 function 0 "IBM PCIX-PCIX" rev 0x02
> pci3 at ppb0 bus 4
> em2 at pci3 dev 4 function 0 "Intel PRO/1000MT QP (82546EB)" rev
> 0x01: irq 7, address: 00:04:23:bc:4d:a0
> em3 at pci3 dev 4 function 1 "Intel PRO/1000MT QP (82546EB)" rev
> 0x01: irq 5, address: 00:04:23:bc:4d:a1
> em4 at pci3 dev 6 function 0 "Intel PRO/1000MT QP (82546EB)" rev
> 0x01: irq 7, address: 00:04:23:bc:4d:a2
> em5 at pci3 dev 6 function 1 "Intel PRO/1000MT QP (82546EB)" rev
> 0x01: irq 5, address: 00:04:23:bc:4d:a3
> vga1 at pci0 dev 14 function 0 "ATI Rage XL" rev 0x27
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> pchb3 at pci0 dev 15 function 0 "ServerWorks CSB5 SouthBridge" rev 0x93
> pciide0 at pci0 dev 15 function 1 "ServerWorks CSB5 IDE" rev 0x93: DMA
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus0 at atapiscsi0: 2 targets
> cd0 at scsibus0 targ 0 lun 0: SCSI0 5/cdrom
> removable
> cd0(pciide0:1:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 2
> ohci0 at pci0 dev 15 function 2 "ServerWorks OSB4/CSB5 USB" rev 0x05:
> irq 11, version 1.0, legacy support
> usb0 at ohci0: USB revision 1.0
> uhub0 at usb0
> uhub0: ServerWorks OHCI root hub, rev 1.00/1.00, addr 1
> uhub0: 4 ports with 4 removable, self powered
> pcib0 at pci0 dev 15 function 3 "ServerWorks CSB5 PCI" rev 0x00
> pchb4 at pci0 dev 16 function 0 "ServerWorks CIOB-E" rev 0x12
> pchb5 at pci0 dev 16 function 2 "ServerWorks CIOB-E" rev 0x12
> pci4 at pchb5 bus 2
> bge0 at pci4 dev 0 function 0 "Broadcom BCM5704C" rev 0x02, BCM5704
> A2 (0x2002): irq 7 address 00:0d:56:fd:73:a0
> brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
> bge1 at pci4 dev 0 function 1 "Broadcom BCM5704C" rev 0x02, BCM5704
> A2 (0x2002): irq 5 address 00:0d:56:fd:73:a1
> brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
> pchb6 at pci0 dev 17 function 0 "ServerWorks CIOBX2" rev 0x05
> pchb7 at pci0 dev 17 function 2 "ServerWorks CIOBX2" rev 0x05
> pci5 at pchb7 bus 5
> mpt0 at pci5 dev 5 function 0 "Symbios Logic 53c1030" rev 0x07: irq 7
> mpt0: sending FW Upload request to IOC (size: 36, img size: 33280)
> mpt0: IM support: 0
> scsibus1 at mpt0: 16 targets
> sd0 at scsibus1 targ 0 lun 0: SCSI3 0/
> direct fixed
> sd0: 34732MB, 48122 cyl, 2 head, 739 sec, 512 bytes/sec, 71132959 sec
> total
> safte0 at scsibus1 targ 6 lun 0: SCSI2 3/
> processor fixed
> mpt0: target 0 Synchronous at 160MHz width 16bit offset 127 QAS 1 DT
> 1 IU 1
> mpt1 at pci5 dev 5 function 1 "Symbios Logic 53c1030" rev 0x07: irq 5
> mpt1: sending FW Upload request to IOC (size: 36, img size: 33280)
> mpt1: IM support: 0
> scsibus2 at mpt1: 16 targets
> isa0 at pcib0
> isadma0 at isa0
> pckbc0 at isa0 port 0x60/5
> pckbd0 at pckbc0 (kbd slot)
> pckbc0: using irq 1 for kbd slot
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pmsi0 at pckbc0 (aux slot)
> pckbc0: using irq 12 for aux slot
> wsmouse0 at pmsi0 mux 0
> pcppi0 at isa0 port 0x61
> midi0 at pcppi0:
> spkr0 at pcppi0
> sysbeep0 at pcppi0
> npx0 at isa0 port 0xf0/16: using exception 16
> pccom0 at isa0 port 0x3
Re: In chroot: /dev/stdin: Device not configured
>>> Matthias Kilian 24-Feb-06 21:38 >>> > > Hi, > > can anyone tell me wtf I'm missing in the commands below? > > # mkdir foo > # cd foo > # mkdir bin dev > # cp -p /bin/cat bin > # cd dev > # /dev/MAKEDEV std > # cd .. > # chroot . /bin/cat /dev/stdin > cat: /dev/stdin: Device not configured > > The reason I ask is that I need to run tar -czf within a chroot > environment, but gzip(1) tries to open /dev/stdin and fails (as the > contrived invocation of cat(1) in the example above). > > Ciao, > Kili Are you on a partition with nodev set? Tom
