Re: 'pkg_add -u' question
On Sat, Jan 14, 2012 at 06:29:26PM -0700, Theo de Raadt wrote: How often is firmware updated without a maching driver update? fw_update is really just to provide an automated fuction during install or upgrade, the same time when you are getting a new kernel/drier, it would be rare that a new firmware is available for an existing system, although potentially useful given how buggy some of these things are. it has already happened plenty of times before fw_update was created -- as a result, why fw_update was created by halex at my request. in that timeframe since, no new firmwares have shown up in the place where fw_update looks. unfortunately that is not proof that this will not happen in the future. so the answer to your question is: At least once in the future. ok, so perhaps the diff below will avoid future confusion. jmc Index: usr.sbin/pkg_add/pkg_add.1 === RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v retrieving revision 1.111 diff -u -r1.111 pkg_add.1 --- usr.sbin/pkg_add/pkg_add.1 23 Aug 2011 10:32:26 - 1.111 +++ usr.sbin/pkg_add/pkg_add.1 15 Jan 2012 08:26:37 - @@ -68,6 +68,9 @@ option .Fl u .Pc . +A separate utility, +.Xr fw_update 1 , +is used to update non-free firmware packages. .Pp Details of packing-list internals are documented in .Xr pkg_create 1 . @@ -765,6 +768,7 @@ .El .Sh SEE ALSO .Xr ftp 1 , +.Xr fw_update 1 , .Xr pkg_create 1 , .Xr pkg_delete 1 , .Xr pkg_info 1 , Index: share/man/man8/afterboot.8 === RCS file: /cvs/src/share/man/man8/afterboot.8,v retrieving revision 1.135 diff -u -r1.135 afterboot.8 --- share/man/man8/afterboot.8 11 Jun 2011 17:52:00 - 1.135 +++ share/man/man8/afterboot.8 15 Jan 2012 08:26:37 - @@ -614,11 +614,16 @@ impossible. Sometimes checking the mailing lists for past problems that people have encountered will result in a fix posted. +.Pp +Non-free firmware packages have their own tool for installing/updating, +.Xr fw_update 1 . +It is run automatically as part of the system upgrade. .Ss Compiling a kernel Information on building and modifying kernels is contained within .Xr config 8 . .Sh SEE ALSO +.Xr fw_update 1 , .Xr ksh 1 , .Xr man 1 , .Xr pkg_add 1 ,
Re: locate weirdness
On Sat, Jan 14, 2012 at 10:07:15PM -0600, L. V. Lammert wrote:
| On Sat, 14 Jan 2012, Philip Guenther wrote:
|
| Any progress? I see plenty of replies to the people that you *don't*
| think are helping you but no reply to my question about what user you
| think locate.updatedb runs as, something which does factor into being
| able to solve this...
|
| The answer was already posted, .. perhaps you missed it?
Perhaps he did. Wouldn't it be useful to help the guy trying to help
you (you know, the wheat) by giving a really simple and
straightforward answer, even if it is repeating yourself ? Probably
would've been less typing than what you just did (e.g. Sorry, I think
it runs as user ).
However, unless I've missed an e-mail from you, you have *not*
answered the question. Here's what you did reply (that is somewhat
related to Philip's question):
In pine.bso.4.53.120716310.7...@mail.omnitec.net
Agreed, .. but if locate.update does NOT run as root, that would seem to
indicate some problem other than permissions.
...and...
In pine.bso.4.53.120804330.7...@mail.omnitec.net
If it does not run as root, then it isn't a permission issue as running as
root provides all required permissions, eh?
I have never seen locate.updatedb fail when run as root (3.0 to 5.0,
actually), .. but, then, it isn't exactly 'failing', it just isn't
indexing anything except /home.
You see how you don't mention what user you think it runs as ? You
make some roundabout statements concerning what would or would not
work if it did or did not run as root (quite confusing), but a clear
cut, straightforward answer is missing. Let's analyze one part in
particular:
If it does not run as root, then it isn't a permission issue
If you do not run as root, you don't have root privileges so you have
fewer permissions. But if you have these fewer permissions, that can
not be an issue.
Do you see how that statement is wrong ? Philip called you out on it,
saying he didn't understand what you were saying. He replies with:
In cakkmsngtnz65nfkocgem9bdd3e6svqwtym3j5uyu9ccl8zh...@mail.gmail.com
I'm sorry, but I don't understand that sentence. It appears to
conflate running as root with not running as root, or I'm miscounting
the 'not's.
So let me try again: what user do you think locate.updatedb is run as?
Yet you never (publically) answered this e-mail (at least not
according to http://marc.info/ or my own archive of misc@).
Here's another piece of the puzzle for you .. locate.updatedb does NOT
run as root by default:
--- from /etc/weekly -
UPDATEDB=/usr/libexec/locate.updatedb
echo ${UPDATEDB} --fcodes=- --tmpdir=${TMPDIR:-/var/tmp} | \
nice -5 su -m nobody 2/dev/null 1$TMP
--
So /by default/ it runs as user 'nobody'. Now you can change your
setup so that locate.updatedb does run as root, but we all know you
didn't do this as you would have mentioned it in your first post.
One thing you actually could try is removing the 2/dev/null from
those lines, to see if any errors show up that might further help you
debug this issue.
Anyway, I hadn't seen a reply to my questions either. I'm quite
curious by now what the find and locate snippets I suggested would
output on your system. Also wondering if fsck showed you any errors
which might explain what's going on.
So, what's up with those ? Curious minds want to know. The archive
is also still waiting for answers to provide as feedback to future
google queries.
Paul 'WEiRD' de Weerd
--
[++-]+++.+++[---].+++[+
+++-].++[-]+.--.[-]
http://www.weirdnet.nl/
Re: 'pkg_add -u' question
On 2012-01-14, Jason McIntyre j...@cava.myzen.co.uk wrote: i ask because we need to watch how we word this. we could reasonably assume that people would also run it from time to time just to see if there's an update available, right? Newer firmware versions often require changes to the driver, so this isn't something I would normally want to update unless I've just updated the kernel.
Re: 'pkg_add -u' question
Hi Jason, Jason McIntyre wrote on Sun, Jan 15, 2012 at 08:28:29AM +: ok, so perhaps the diff below will avoid future confusion. I agree with adding that information and don't strongly object to your wording, but given that fw_update(1) is just a wrapper around pkg_add(1), some might consider it slightly misleading: there is nothing wrong with using pkg_add(1) itself for updating firmwares, as long as you specify the right PKG_PATH and options. See inline for an alternative wording you might consider. Regarding afterboot(8), i think your wording is fine. Yours, Ingo Index: usr.sbin/pkg_add/pkg_add.1 === RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v retrieving revision 1.111 diff -u -r1.111 pkg_add.1 --- usr.sbin/pkg_add/pkg_add.123 Aug 2011 10:32:26 - 1.111 +++ usr.sbin/pkg_add/pkg_add.115 Jan 2012 08:26:37 - @@ -68,6 +68,9 @@ option .Fl u .Pc . +A separate utility, +.Xr fw_update 1 , +is used to update non-free firmware packages. Since non-free firmware packages are distributed via separate package repositories, the convenience wrapper .Xr fw_update 1 is normally used to update them. .Pp Details of packing-list internals are documented in .Xr pkg_create 1 . @@ -765,6 +768,7 @@ .El .Sh SEE ALSO .Xr ftp 1 , +.Xr fw_update 1 , .Xr pkg_create 1 , .Xr pkg_delete 1 , .Xr pkg_info 1 , Index: share/man/man8/afterboot.8 === RCS file: /cvs/src/share/man/man8/afterboot.8,v retrieving revision 1.135 diff -u -r1.135 afterboot.8 --- share/man/man8/afterboot.811 Jun 2011 17:52:00 - 1.135 +++ share/man/man8/afterboot.815 Jan 2012 08:26:37 - @@ -614,11 +614,16 @@ impossible. Sometimes checking the mailing lists for past problems that people have encountered will result in a fix posted. +.Pp +Non-free firmware packages have their own tool for installing/updating, +.Xr fw_update 1 . +It is run automatically as part of the system upgrade. .Ss Compiling a kernel Information on building and modifying kernels is contained within .Xr config 8 . .Sh SEE ALSO +.Xr fw_update 1 , .Xr ksh 1 , .Xr man 1 , .Xr pkg_add 1 ,
Re: 'pkg_add -u' question
On Sun, Jan 15, 2012 at 11:57:34AM +0100, Ingo Schwarze wrote: Hi Jason, Jason McIntyre wrote on Sun, Jan 15, 2012 at 08:28:29AM +: ok, so perhaps the diff below will avoid future confusion. I agree with adding that information and don't strongly object to your wording, but given that fw_update(1) is just a wrapper around pkg_add(1), some might consider it slightly misleading: there is nothing wrong with using pkg_add(1) itself for updating firmwares, as long as you specify the right PKG_PATH and options. See inline for an alternative wording you might consider. Regarding afterboot(8), i think your wording is fine. Yours, Ingo Index: usr.sbin/pkg_add/pkg_add.1 === RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v retrieving revision 1.111 diff -u -r1.111 pkg_add.1 --- usr.sbin/pkg_add/pkg_add.1 23 Aug 2011 10:32:26 - 1.111 +++ usr.sbin/pkg_add/pkg_add.1 15 Jan 2012 08:26:37 - @@ -68,6 +68,9 @@ option .Fl u .Pc . +A separate utility, +.Xr fw_update 1 , +is used to update non-free firmware packages. Since non-free firmware packages are distributed via separate package repositories, the convenience wrapper .Xr fw_update 1 is normally used to update them. hmm. i would argue that it's more rightly fw_update(8)'s place to go into that level of detail, not pkg_add(1). jmc
Re: locate weirdness
Perhaps he did. Wouldn't it be useful to help the guy trying to help you (you know, the wheat) by giving a really simple and straightforward answer, even if it is repeating yourself ? Probably would've been less typing than what you just did (e.g. Sorry, I think it runs as user ). No, we've been over that and the answer from the argumentative sonsabitches was as long as you contribute one patch you are permitted nay might we suggest *encouraged* to flame rather than help. I guess it makes them feel like men, but to the rest of us they only seem like girl scouts. If you point this out you spawn an entire new subthread of postings by the abovementioned argumentative sonsabitches reaffirming their girl scout status. Why actually answer a question when you can create a sharkfest of insults and make yourself feel like a man? So what if you contribute? I fired a few assholes like you. I don't need prima donnas, you're not worth it. Helpful people who actually know something aren't mutually exclusive. To you primma donnas, go fuck yourselves. You aren't worth it.
Re: 'pkg_add -u' question
Hi Jason, Jason McIntyre wrote on Sun, Jan 15, 2012 at 01:01:50PM +0001: On Sun, Jan 15, 2012 at 11:57:34AM +0100, Ingo Schwarze wrote: Jason McIntyre wrote on Sun, Jan 15, 2012 at 08:28:29AM +: ok, so perhaps the diff below will avoid future confusion. I agree with adding that information and don't strongly object to your wording, but given that fw_update(1) is just a wrapper around pkg_add(1), some might consider it slightly misleading: there is nothing wrong with using pkg_add(1) itself for updating firmwares, as long as you specify the right PKG_PATH and options. +A separate utility, +.Xr fw_update 1 , +is used to update non-free firmware packages. Since non-free firmware packages are distributed via separate package repositories, the convenience wrapper .Xr fw_update 1 is normally used to update them. hmm. i would argue that it's more rightly fw_update(8)'s place to go into that level of detail, not pkg_add(1). The pkg_add(1) manual does talk about PKG_PATH later on, so mentioning that a specific class of packages has their own repository doesn't seem off-topic when specifically talking about those packages. Besides, when documenting one tool and pointing to another one, mentioning that the latter is just just a wrapper around the former wouldn't qualifiy as excessive detail in my book. But feel free to decide, lest the bikes get all soaked! Yours, Ingo
Re: 'pkg_add -u' question
On Sun, Jan 15, 2012 at 01:01:50PM +0001, Jason McIntyre wrote: hmm. i would argue that it's more rightly fw_update(8)'s place to go into that level of detail, not pkg_add(1). I agree. I'm not too fond of fw_update(1), though synching to the kernel makes it a necessity. And pkg_add(1) documentation is already very long. I'm fine with a SEE ALSO .Xr fw_update 1 entry in pkg_add(1), though.
Re: 'pkg_add -u' question
On Sun, Jan 15, 2012 at 02:26:19PM +0100, Ingo Schwarze wrote: hmm. i would argue that it's more rightly fw_update(8)'s place to go into that level of detail, not pkg_add(1). The pkg_add(1) manual does talk about PKG_PATH later on, so mentioning that a specific class of packages has their own repository doesn't seem off-topic when specifically talking about those packages. Besides, when documenting one tool and pointing to another one, mentioning that the latter is just just a wrapper around the former wouldn't qualifiy as excessive detail in my book. it is excessive in a comparative sense. since fw_update(8) does not document at any level the fact that it is a wrapper for pkg_add, having pkg_add document what fw_update is is odd. jmc
Re: 'pkg_add -u' question
On Sun, Jan 15, 2012 at 02:32:56PM +0100, Marc Espie wrote: On Sun, Jan 15, 2012 at 01:01:50PM +0001, Jason McIntyre wrote: hmm. i would argue that it's more rightly fw_update(8)'s place to go into that level of detail, not pkg_add(1). I agree. I'm not too fond of fw_update(1), though synching to the kernel makes it a necessity. And pkg_add(1) documentation is already very long. I'm fine with a SEE ALSO .Xr fw_update 1 entry in pkg_add(1), though. the Xr, fine. what about the brief note i suggested? my worry is that reading the beginning of pkg_add, you'll have no idea that there even is such a thing. having an Xr will not help that case. it's doesn;t have to go in pkg_add(1), but i cannot think of a better place. jmc
/bsd: carpN: ip_output failed: 65
Hi all After upgrading to 5.0 (and also on -current) I keep getting those errors for 2 out of 4 carp'd interfaces in a fw cluster pair: /bsd: carp2: ip_output failed: 65 /bsd: carp3: ip_output failed: 65 And effectively, no CARP traffic is seen on those two interfaces, neither in nor out. Both boxes assume master status on the if. I got a gut feeling that this has something to do with ipv6, which I do not use at all on the boxes. My pf ruleset is actually ipv4 only. I do see ipv6 addresses on the phyif and carpif though (which I have not configured). Could it be that I need to add something to my ruleset? Any way to totally disable ipv6 for a test? krgds /markus
Scannedonly (for samba vfs) make fails - pthread_spinlock_t definition missing(?) in libpthread
Hello: I was wondering if anyone has tried using scannedonly with samba on openbsd (4.9). Scannedonly is a daemon/VFS module for samba that scans files on request using clamav (description at http://olivier.sessink.nl/scannedonly/ ) The samba version (3.5.6) available with openbsd 4.9 already includes the VFS module (at /usr/local/lib/samba/vfs/scannedonly.so). However, when I try to compile the deamon from source, it dies almost immediately with the error: scannedonlyd_clamav.c:73: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'statuslock' at the statement: pthread_spinlock_t statuslock; When I look at the pthread.h header file (which is included in the source), I cannot find pthread_spinlock_t defined. It is my understanding that on linux pthread_spinlock_t is defined in /usr/include/bits/pthreadtypes.h; however, there is no pthreadtypes.h header file that I can find on openbsd 4.9. I must admit that this is a bit beyond my current understanding. I am wondering if there is some way around this, or if there is something in ports/packages that can be installed to provide the missing pthread_spinlock_t definition? Or, am I just out of luck? Thanks in advance for any advice. Bye - ted
Re: openbsd.cs.fau.de downtime on Jan 14th
Hi, On Wed, Jan 11, 2012 at 12:27:56PM +0100, Simon Kuhnle wrote: openbsd.cs.fau.de will be down on January 14th, from 08:00 to approximately 12:00 o'clock due to yearly power system maintenance works. Same problem I had last year: the RAID controller forgot his setup again and now I can't convince it to boot the system again... I could do a fresh install and sync again, but that controller will still continue to suck... I talked to grunk@, who has a complete SAS-kit for this box, including a new RAID controller and HDs. The other alternative is that I could bum a completely different server, which would suffice, too, but I need to ask some people. Anyway, openbsd.cs.fau.de will be down for at least 14 days, either until grunk visits Erlangen or I get the OK to pick up the new box. I'm sorry if this causes any inconvenience and I hope to bring back the mirror as soon as possible. Please remove the mirror (at least for the time being). Regards, Simon
MIPS-BE_architecture_(RouterBoard_RB_750_GL)
Hello, I was wondering is it possible to run OpenBSD (5.0-stable) on RouterBoard RB750GL. I've searched for the supported hardware on OpenBSD and are aware that only RouterBoard 600A is supported (and was discontinued by the manufacturer about a week after it's been included into the supported hardware). But it was socppc port and the manufacturer says 750GL is MIPS-BE architecture. Which of OpenBSD's ports would that be? Moreover, are there any known low-cost router/firewall devices with gigabyte NICs capable running OpenBSD? Thanks in advance for your responses
Re: MIPS-BE_architecture_(RouterBoard_RB_750_GL)
RB750GL use the sames CPU and ethernet switch as RB450G and Ubiquiti Routerstation Pro. The big difference is that RB750GL have 2 ethernet switch instead of 1. I know that RSPro is support by FreeBSD and if I remeber well, I read on this list that it could easily be port to OpenBSD. If one of the dev want to work on this, since I don't have the developement skill to port it, I would gladly send 1 or 2 routerstation pro. Michel Le 2012-01-15 11:14, soko.tica a icrit : Hello, I was wondering is it possible to run OpenBSD (5.0-stable) on RouterBoard RB750GL. I've searched for the supported hardware on OpenBSD and are aware that only RouterBoard 600A is supported (and was discontinued by the manufacturer about a week after it's been included into the supported hardware). But it was socppc port and the manufacturer says 750GL is MIPS-BE architecture. Which of OpenBSD's ports would that be? Moreover, are there any known low-cost router/firewall devices with gigabyte NICs capable running OpenBSD? Thanks in advance for your responses
Strange connection problems with athn interface
Hi list, I'm in the process of finding out why my Ubiquity SR7-e PCIe module worked perfectly with the 29.12.2011-snapshot, while I only see problems with the 13.01.2012-snapshot. When testing the module for the first time with the December snapshot, I thought I'd never saw a card working that well before. I had perfect connectivity in all my flat - which has extremely thick concrete walls, reducing my current WLAN to about 2 rooms. This is the CE-version of the module, reduced to 100 dBm, BTW. I'm using two 20 dBm gain omni-antennas. I then decided to install the latest snapshot. As of now, I can configure the module as an AP, run it and associate with it from a client node. I even get a DHCP lease from it. But that's it so far. Pinging the AP gives me an immediate ping: sendto: Host is down ping: wrote 10.10.10.1 64 chars, ret=-1 after I got a valid DHCP lease. Of course, any other IP traffic doesn't work as well. I occasionally see a packet or another show up in the AP's tcpdump output, but no constant reception of packets at all. I'm testing all this while sitting a couple of meters beside the AP. I skimmed the CVS commit log from end of December to know and did not spot any changes that would make me suspicious in the first place. The first obvious thing to do was switching on debug mode for the driver, but as soon as I do a ifconfig athn0 up, my serial console gets flooded with ... athn0: received beacon from 00:02:6f:21:ef:xx rssi 52 mode 11g athn0: received beacon from 00:02:6f:21:ef:xx rssi 48 mode 11g ... messages in an endless loop, forcing me to reboot my host box. My suspicions go towards incorrectly autoconfigured RX/TX power levels. I tried to grasp ar5416_set_txpower(), and if I don't err, I should see a difference in autoset power if I connect the rubberduck antennas after the interface has been set up. This is however not the case, at least I see no difference in behaviour. As of now, I'm really stuck. Has anybody experienced something similar and is able to give a hint or another? Thanks in advance, /Markus OpenBSD 5.1-beta (GENERIC) #0: Sun Jan 15 18:04:40 CET 2012 r...@flash.target23.de:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Genuine Intel(R) CPU @ 1.00GHz (GenuineIntel 686-class) 1.01 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,NXE,LONG,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF real mem = 1073131520 (1023MB) avail mem = 1045491712 (997MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 20/11/03, BIOS32 rev. 0 @ 0xfac40 mpbios0 at bios0: Intel MP Specification 1.4 cpu0 at mainbus0: apid 0 (boot processor) cpu0: unknown i686 model 0x26, can't get bus clock (0x4188) cpu0: apic clock running at 99MHz cpu at mainbus0: not configured mpbios0: bus 0 is type PCI mpbios0: bus 64 is type ISA ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins pcibios0 at bios0: rev 2.0 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf3880/96 (4 entries) pcibios0: no compatible PCI ICU found: ICU vendor 0x8086 product 0x8186 pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #13 is the last bus bios0: ROM list: 0xc8000/0x2400 0xca800/0x4c00 0xcf800/0xee00 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel E600 Host rev 0x03 pchb1 at pci0 dev 1 function 0 Intel E600 Config rev 0x00 ppb0 at pci0 dev 23 function 0 Intel E600 PCIE rev 0x00 pci1 at ppb0 bus 1 ppb1 at pci1 dev 0 function 0 Intel EG20T PCIE rev 0x01 pci2 at ppb1 bus 2 Intel EG20T Packet Hub rev 0x01 at pci2 dev 0 function 0 not configured Intel EG20T Ethernet rev 0x01 at pci2 dev 0 function 1 not configured Intel EG20T GPIO rev 0x00 at pci2 dev 0 function 2 not configured ohci0 at pci2 dev 2 function 0 Intel EG20T USB rev 0x01: apic 0 int 19, version 1.0, legacy support ohci1 at pci2 dev 2 function 1 Intel EG20T USB rev 0x01: apic 0 int 19, version 1.0, legacy support ohci2 at pci2 dev 2 function 2 Intel EG20T USB rev 0x01: apic 0 int 19, version 1.0, legacy support ehci0 at pci2 dev 2 function 3 Intel EG20T USB rev 0x01: apic 0 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 Intel EG20T USB Client rev 0x01 at pci2 dev 2 function 4 not configured sdhc0 at pci2 dev 4 function 0 Intel EG20T SDIO rev 0x01: apic 0 int 18 sdmmc0 at sdhc0 sdhc1 at pci2 dev 4 function 1 Intel EG20T SDIO rev 0x01: apic 0 int 18 sdmmc1 at sdhc1 ahci0 at pci2 dev 6 function 0 Intel EG20T AHCI rev 0x01: msi, AHCI 1.1 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: ATA, TS32GMSA300, 2011 SCSI3 0/direct fixed t10.ATA_TS32GMSA300_2018475116133314 sd0: 30208MB, 512 bytes/sector, 61865984 sectors, thin ohci3 at pci2 dev 8 function 0 Intel EG20T USB rev 0x01: apic 0 int 16, version 1.0, legacy support ohci4 at pci2 dev 8 function 1 Intel EG20T USB rev 0x01: apic 0 int 16, version 1.0,
vnconfig: /dev/rsvnd0c: Device not configured
Hi everybody, I wonder if anybody knows a solution for this: I had an encrypted partition working wonderfully in my system. my /etc/fstab is: /dev/sdXX /dev/svnd0c vnd rw,noauto,-k 0 0 /dev/svnd0c /mnt/ZZ ffs rw,noauto,nodev 0 0 so I used to do: mount /dev/sdXX Encryption key: enter my key and it would work. Now (after upgrading to 5.0 from the previous release) it returns: mount_vnd: /dev/rsvnd0c: Device not configured I try to configure it again: vnconfig -ck svnd0 /dev/sdXX but it returns again: vnconfig: /dev/rsvnd0c: Device not configured This is probably due to the fact that I overwrote the old /etc folder but I don't know where the problem is... Thanks in advance, Marc
Re: vnconfig: /dev/rsvnd0c: Device not configured
vnd's used to be seperated into two modes: raw vnd mode, and the cooked svnd mode. The raw vnd mode has been killed. Only the cooked svnd mode remains -- and at the same time we renamed it to vnd. Hi everybody, I wonder if anybody knows a solution for this: I had an encrypted partition working wonderfully in my system. my /etc/fstab is: /dev/sdXX /dev/svnd0c vnd rw,noauto,-k 0 0 /dev/svnd0c /mnt/ZZ ffs rw,noauto,nodev 0 0 so I used to do: mount /dev/sdXX Encryption key: enter my key and it would work. Now (after upgrading to 5.0 from the previous release) it returns: mount_vnd: /dev/rsvnd0c: Device not configured I try to configure it again: vnconfig -ck svnd0 /dev/sdXX but it returns again: vnconfig: /dev/rsvnd0c: Device not configured This is probably due to the fact that I overwrote the old /etc folder but I don't know where the problem is... Thanks in advance, Marc
Re: vnconfig: /dev/rsvnd0c: Device not configured
It's in the fine manual: http://www.openbsd.org/faq/upgrade50.html#vnd
Re: vnconfig: /dev/rsvnd0c: Device not configured
On Sun, 15 Jan 2012 19:33:33 +0100, marc wrote: Hi everybody, I wonder if anybody knows a solution for this: I had an encrypted partition working wonderfully in my system. my /etc/fstab is: /dev/sdXX /dev/svnd0c vnd rw,noauto,-k 0 0 /dev/svnd0c /mnt/ZZ ffs rw,noauto,nodev 0 0 so I used to do: mount /dev/sdXX Encryption key: enter my key and it would work. Now (after upgrading to 5.0 from the previous release) it returns: mount_vnd: /dev/rsvnd0c: Device not configured I try to configure it again: vnconfig -ck svnd0 /dev/sdXX but it returns again: vnconfig: /dev/rsvnd0c: Device not configured This is probably due to the fact that I overwrote the old /etc folder but I d on't know where the problem is... Thanks in advance, Marc http://www.openbsd.org/faq/upgrade50.html#vnd
Re: locate weirdness
On Thu, 12 Jan 2012 02:15:39 -0700 Duncan Patton a Campbell campb...@neotext.ca wrote: On Wed, 11 Jan 2012 13:47:48 -0600 L. V. Lammert l...@omnitec.net wrote: At 01:30 PM 1/11/2012, Jeremy O'Brien wrote: 4.3 was released May 1, 2008. That's almost 4 years old software. What are you expecting here? Someone to check out the code from that version and deeply inspect what may be causing your problem, that is more than likely already fixed in a later version? Another typical reply - the question was has anyone ever seen anything like this, .. or, perhaps, what could be causing it. No need for the off-topic diatribes - a simple no would more than suffice. Lee Yes. I have seen problems with locate in all releases that I have run. Unfortunately I have never bothered to characterize these problems. Dhu I should add that this has happened on deeply nested file systems with longpathnames and highbit characters. Dhu
Fw: Documento.
Anexo: Documento-Planilha.doc (149,1 KB) Segue em anexo conforme solicitado o relatorio. Tenha um bom dia!
Re: vnconfig: /dev/rsvnd0c: Device not configured
Thx! I renamed svnd to vnd and it worked like a charm. PS. I think I read vnd(4) removed, oh how bad for them.. svnd will still rock... why should I care to read further? leaving svnd(4) renamed to vnd(4) in a world of disregard and darkness. Sorry... PS2. 5.0 rocks for me, it's a professional bitch. On 1/15/2012 8:58 PM, Tobias Ulmer wrote: It's in the fine manual: http://www.openbsd.org/faq/upgrade50.html#vnd
Re: Scannedonly (for samba vfs) make fails - pthread_spinlock_t definition missing(?) in libpthread
On Sun, Jan 15, 2012 at 7:19 AM, Ted Wynnychenko ted@comcast.net wrote: ... When I look at the pthread.h header file (which is included in the source), I cannot find pthread_spinlock_t defined. It is my understanding that on linux pthread_spinlock_t is defined in /usr/include/bits/pthreadtypes.h; however, there is no pthreadtypes.h header file that I can find on openbsd 4.9. I must admit that this is a bit beyond my current understanding. I am wondering if there is some way around this, or if there is something in ports/packages that can be installed to provide the missing pthread_spinlock_t definition? Or, am I just out of luck? Currently, you're out of luck. I expect that this will change some time after we make the switch from our current user-space-only threads (as implemented in the current libpthread) to real kernel threads (as presented by the not-built-or-enabled-by-default librthread). Philip Guenther
Re: Strange connection problems with athn interface
On 2012-01-15, Markus li...@neuronenwerk.de wrote: I'm in the process of finding out why my Ubiquity SR7-e PCIe module worked perfectly with the 29.12.2011-snapshot, while I only see problems with the 13.01.2012-snapshot. ... I skimmed the CVS commit log from end of December to know and did not spot any changes that would make me suspicious in the first place. Me neither. But around this time of year it's more likely than usual that people might have new wireless gadgets which might be tickling an existing bug. Does reverting to the older kernel restore things? This is the CE-version of the module, reduced to 100 dBm, BTW. I think (hope :) you're confusing your units here.
Re: Strange connection problems with athn interface
On 01/15/12 20:52, Stuart Henderson wrote: On 2012-01-15, Markusli...@neuronenwerk.de wrote: I'm in the process of finding out why my Ubiquity SR7-e PCIe module worked perfectly with the 29.12.2011-snapshot, while I only see problems with the 13.01.2012-snapshot. ... I skimmed the CVS commit log from end of December to know and did not spot any changes that would make me suspicious in the first place. Me neither. But around this time of year it's more likely than usual that people might have new wireless gadgets which might be tickling an existing bug. Does reverting to the older kernel restore things? This is the CE-version of the module, reduced to 100 dBm, BTW. I think (hope :) you're confusing your units here. Um, yeah--100dBm is 10 mega watts. The laptop (and user) might catch fire exposed to that kind of RF. --STeve Andre'
mailserv project
Hi, It will be famous if somebody can update mailserv project to work on the last version OpenBSD 5.0 Therefore it works like a charm on OpenBSD 4.8/4.9 Here the source : https://github.com/mailserv/mailserv/ Best regards, Wesley.
Re: mailserv project
On Mon, Jan 16, 2012 at 7:11 AM, Wesley M. open...@e-solutions.re wrote: Hi, It will be famous if somebody can update mailserv project to work on the last version OpenBSD 5.0 Therefore it works like a charm on OpenBSD 4.8/4.9 Here the source : https://github.com/mailserv/mailserv/ There's sendmail in base system and there's ongoing work on smtpd by OpenBDS devs (other components are in ports). Anyway you're welcome to start port see http://www.openbsd.org/faq/ports/index.html BTW if it's running for at least 2 releases why author/authors did not create port yet? Best regards, Wesley.
Re: mailserv project
On Mon, 16 Jan 2012 07:40:57 +0100, Tomas Bodzar tomas.bod...@gmail.com wrote: There's sendmail in base system and there's ongoing work on smtpd by OpenBDS devs (other components are in ports). Anyway you're welcome to start port see http://www.openbsd.org/faq/ports/index.html It is not an other MTA. It is a script with config files, it installs a secure mail server (Administration using a Web interface) Postfix+Nginx+Spamd+Spamassassin+Dovecot+Roundcube+sql database Actually works on OpenBSD 4.8 / 4.9 It doesn't work on OpenBSD 5.0 There's a lot of changes like Nginx/Dovecot/php If someone can update the work : http://mailserv.github.com/ Best regards, Wesley.
