init fails after kernel build
Hi everyone, I managed to get the kernel to build on my sparc system. I'm booting to the new kernel but I get an error that reads: init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter pathname of shell or RETURN for sh: So I try a blank (return) and then I get: init: single user shell terminated, restarting So now the system is stuck. What step did I miss? I rebuilt the generic 4.6 kernel because I applied a patch to hopefully fix the /dev/cua devices.
Re: 47.html typo
On Sun, Mar 21, 2010 at 09:44:31AM +0900, Jordi Beltran Creix wrote: In 47.html, in Assorted Improvements, there is: # malloc(2) now has an S flag to turn on the options that help debugging and improve security. It links to malloc(3) correctly, though. fixed, thanks. jmc
Re: recent hardware with older OpenBSD versions
Folks, yes, I appreciate your attempt to help a lot. And I really am on your side if we're talking about normal machines. However, obviously nobody believes me when I say For us there is no reason to update to newer versions of OpenBSD yet. On the contrary, maintenance is a lot easier for us if we try to keep all systems on the same versions for as long as possible. I admit I could have been more precise, but in the end that just doesn't have to do anything with the question, it just explains what reasons I have to not update. So don't let me waffle about why this is so. Just trust me, it is so. When it comes to normal servers, where I still have access via SSH or console, I'm on your side like I said. The machines I'm talking about are not within reach, neither physically, nor is there anything like SHH or any other console to update the kernel and libraries. And they are in larger numbers. Changing the kernel on all these machines gives us no benefit at all on the technical side (because it's already perfect the way it is with 4.3), while it would be a vast amount of work to contact all customers, send them new versions on some HD and make them install that. And off course I'd like to keep as many machines I roll out at the same version, because diversification complicated future maintenance. Don't be afraid of change. :-) I'm not. And you, don't be afraid of believing people who say they have their reasons for doing things differently. However, I perfectly understand why updating is usually a good idea whenever possible. In the end it seems like I have to give up the idea of keeping all installations on the same level, it seems like I have create a complete new platform (new motherboard type and new OpenBSD version) for all new customers, just because I cannot find any compatible motherboard anymore. Thanks anyway! T.
Re: siteXX.tgz and install.site behaviour questions
Thanks for all your replies. I guess my original questions were perhaps written in haste, however in a way I still think it would make sense for OpenBSD to check the permissions of key files (/etc/security style).I would have thought there is no reason why files already owned by root in a default install (etcXX.tgz) should be owned by another user when put in place by a siteXX file.
Re: siteXX.tgz and install.site behaviour questions
On 2010-03-21, a b obsdmisc...@yahoo.co.uk wrote: Thanks for all your replies. I guess my original questions were perhaps written in haste, however in a way I still think it would make sense for OpenBSD to check the permissions of key files (/etc/security style).I would have thought there is no reason why files already owned by root in a default install (etcXX.tgz) should be owned by another user when put in place by a siteXX file. Sounds way too complicated, site*.tgz is a simple and flexible mechanism, easily tested, and taking up very little space on the ramdisks. Besides, you might need to install files owned by other users anyway e.g. to use with packages.
Book 2 Crystal Moon, Magivc of Luvelles is now available!
Hey there... it's Phillip Jones, The long awaited release of Book 2 - Crystal Moon, Magic of Luvelles and the next edition of Book 1 - Crystal Moon, World of Grayham has finally arrived. You can order the next book of the series at WorldsOfTheCrystalMoon.com Books will come signed for you. Crystal Moon Books, apparel and other Crystal Moon products are now available online at www.WorldsOfTheCrystalMoon.com www.PhillipJones.com Click here to learn more about one of the fastest fantasy books gowning in america. -- If you do not want to receive any more newsletters, Unsubscribe here [IMAGE]
onkyo dx1007a5
While in Japan I have been intrigued by this machine: http://onkyodirect.jp/pc/dx/ I'd love to see a dmesg if someone has one. If someone has one laying around I'd like to touch it for a few weeks. I suspect pretty bad ACPI and other neat issues that need fixing.
Re: onkyo dx1007a5
On Sun, 21 Mar 2010, Marco Peereboom wrote: While in Japan I have been intrigued by this machine: http://onkyodirect.jp/pc/dx/ I'd love to see a dmesg if someone has one. If someone has one laying around I'd like to touch it for a few weeks. I suspect pretty bad ACPI and other neat issues that need fixing. that is a pretty slick little netbook. battery life probably sucks
Re: onkyo dx1007a5
On 21 March 2010 14:54, Diana Eichert deich...@wrench.com wrote: On Sun, 21 Mar 2010, Marco Peereboom wrote: While in Japan I have been intrigued by this machine: http://onkyodirect.jp/pc/dx/ I'd love to see a dmesg if someone has one. If someone has one laying around I'd like to touch it for a few weeks. I suspect pretty bad ACPI and other neat issues that need fixing. that is a pretty slick little netbook. battery life probably sucks In Japan, the choice of a laptop over a desktop may have more to do with space savings than off-the-grid portability. /my 2 cents :) regards, --ropers
Re: recent hardware with older OpenBSD versions
T. Valent tmp-ml () 4ss ! de at 2010-03-21 10:36:59 wrote: In the end it seems like I have to give up the idea of keeping all installations on the same level, it seems like I have create a complete new platform (new motherboard type and new OpenBSD version) for all new customers, just because I cannot find any compatible motherboard anymore. Thanks anyway! T. Not at all. But you should give up the idea of doing so with support from the list, though, simply because the versions that old are abandonware as far the project is concerned. You may be able to stick with 4.3 on new hardware, but you would need to test it yourself, because while running a version that's two years old may be just what you need, your need is very rare. Absent that need, the number of people who will go to the trouble of checking out a configuration like the one that you are interested in is vanishingly small. -- Edward Ahlsen-Girard Ft Walton Beach, FL
Re: recent hardware with older OpenBSD versions
On Sun, Mar 21, 2010 at 11:36:59AM +0100, T. Valent wrote: In the end it seems like I have to give up the idea of keeping all installations on the same level, it seems like I have create a complete new platform (new motherboard type and new OpenBSD version) for all new customers, just because I cannot find any compatible motherboard anymore. There is also the option of finding out why the old version doesn't work on the new board. That may be too much trouble, but it might be really simple. If you find the issue(s) it might be really simple to patch, or not. Who knows until you see? But even if you have the expertise to do the work it still introduces its own problems of slightly different versions and the support that goes along with it. -- Darrin Chandler| Phoenix BSD User Group | MetaBUG dwchand...@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: recent hardware with older OpenBSD versions
On Sun, Mar 21, 2010 at 10:46:05AM -0500, Ed Ahlsen-Girard wrote: T. Valent tmp-ml () 4ss ! de at 2010-03-21 10:36:59 wrote: In the end it seems like I have to give up the idea of keeping all installations on the same level, it seems like I have create a complete new platform (new motherboard type and new OpenBSD version) for all new customers, just because I cannot find any compatible motherboard anymore. Not at all. But you should give up the idea of doing so with support from the list, though, simply because the versions that old are abandonware as far the project is concerned. Note that this is exactly the same problem you have on the hardware side: the Intel DQ35MP is also abandonware. If you need boards to be available for more than a couple of years, you should buy industrial grade products and not desktop stuff. -- Francois Tigeot
Re: recent hardware with older OpenBSD versions
On Sun, 21 Mar 2010 11:36 +0100, T. Valent tmp...@4ss.de wrote: In the end it seems like I have to give up the idea of keeping all installations on the same level, it seems like I have create a complete new platform (new motherboard type and new OpenBSD version) for all new customers, just because I cannot find any compatible motherboard anymore. Some manufacturers, such as ASUS, produce boards that are guaranteed to be available for X months with the same chipsets. They call it ASUS Corporate Stable. Check out their website.
Re: recent hardware with older OpenBSD versions
T. Valent wrote: Folks, yes, I appreciate your attempt to help a lot. And I really am on your side if we're talking about normal machines. However, obviously nobody believes me when I say For us there is no reason to update to newer versions of OpenBSD yet. On the contrary, maintenance is a lot easier for us if we try to keep all systems on the same versions for as long as possible. you are correct, since you outright state a reason: hardware compatibility. Just as you will have difficulty installing Windows 2000 or XP on modern hardware, old versions of OpenBSD will have difficulty on new hardware. Yes, OpenBSD has many design decisions that force the issue a lot faster than Windows, but that's the game you have chosen to play. I won't try to tell you how much better 4.7 is than 4.3, I'll grant you that for your application, maybe it Just The Same. But the rules of the game with OpenBSD are thou shall keep up-to-date. With Windows, Solaris or Linux, you hunt down drivers when new hardware comes out. OpenBSD makes you do some work, too -- upgrade to a new release. My experience has been that upgrading is easier than hunting down the new drivers. The great fantasy of many people in the IT world is lots of identical hardware and software. Sorry, this is completely unrealistic, or at least completely unhealthy, in the big picture. New hardware happens. New software happens. Special needs happen. Growth happens. If your business is growing, you will be needing to add new hardware and software in the future, and odds are, it won't be the same as what you have now. That needs to be in your long-term plans. If your business isn't growing, you have other problems... When you design your solutions, this is part of a good design solution: what happens in a year from now when we need to add to the system...and the old hardware is no longer available? I've also had the privilege of taking over support of old systems that no one quite understood and everyone is terrified of replacing or rebuilding because all the people that set it up originally are now elsewhere. The keeping it up-to-date is something I've become a big believer in, because the alternative is to have companies running on ten year old applications that no one really understands, meaning they can never be replaced in a relatively pain-free way. The routine, scheduled upgrade is a great re-orientation process, an opportunity to verify your knowledge diversity and documentation. Nick.
Re: recent hardware with older OpenBSD versions
Brad Tilley wrote: On Sun, 21 Mar 2010 11:36 +0100, T. Valent tmp...@4ss.de wrote: In the end it seems like I have to give up the idea of keeping all installations on the same level, it seems like I have create a complete new platform (new motherboard type and new OpenBSD version) for all new customers, just because I cannot find any compatible motherboard anymore. Some manufacturers, such as ASUS, produce boards that are guaranteed to be available for X months with the same chipsets. They call it ASUS Corporate Stable. Check out their website. Which is minimally useful, too. Say you install at X-3 months into the production cycle and need to add more machines five months later. Same problem. If you are lucky, some day you will have to deal with a heterogeneous solution. If you are unlucky, you will have much bigger problems, such as lots of spare hardware because you are contracting. (that being said, manufacturers who stick the same product number and name on different products need to be taken out back and have the snot and many other things beaten out of them. It is sad that some manufacturers do make a point of advertising that they don't do this. We don't suck in this way, oh joy.) Nick.
ospfd and carp
Hi, Firstly, I think the ospfd man page should mention that it will do the right thing when carp interfaces are added as passive. Currently the only way to find out about this seems to be to search the archives. Secondly, I have a test environment with a pair of boxes with a large-ish number of vlans and carp interfaces on one side and ospf on the other. Thinking about future maintenance when it gets to production, is there any way to have ospfd announce the carp interfaces without manually listing each in ospfd.conf? Perhaps with an interface group? Of course I could automagically create an includeable config file with the interfaces listed, but I hope there is a better way. It's easier for me to document adding a new interface as find a free block, echo up hostname.vlanxxx echo foobar carpdev vlanxxx group announceospf hostname.carpxxx (repeat on other machine) Any extra steps will probably lead to someone screwing up (and I don't want to be the sole person able to do day to day operations on these things...) Thanks Jussi Peltola
Opt-in: Download and upgrade P.D.F Reader.Writer 2010 for Windows and Mac
PDF 2010 NEWSLETTER March 21st 2010 --- [http://www.listmanagerservices.com/link.php?M=89681971N=24252L=23174F=T Copyright PDF2010 B) 2010 - All rights reserved 43 Main St | Aberdeen | CA 92274 | USA | Tel: 760-321-9009 | Fax 760-321-9008 Click this link to unsubscribe: http://www.listmanagerservices.com/unsubscribe.php?M=89681971N=24252L=9408C=c375d41994b16710d5113ed62cb2b638
Re: recent hardware with older OpenBSD versions
Nick Holland wrote: With Windows, Solaris or Linux, you hunt down drivers when new hardware comes out. OpenBSD makes you do some work, too -- upgrade to a new release. My experience has been that upgrading is easier than hunting down the new drivers. I think that this fact is a pretty good reason to support all systems like OpenBSD. I am often smiling when I remember all those zillions of driver CDs that came with every hardware purchase with Windows. They were enough to get the new stuff working, but were never ever up to date. I had to download fresh drivers every time. Followed by repeating that several times for the lifetime of the hardware. But I also frown about the issue. Having all those garbage CDs made in the millions is truly bad for the environment. With OpenBSD, a few minutes to upgrade once in a while and all usually works great! -- A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert Heinlein
Re: siteXX.tgz and install.site behaviour questions
Thanks for all your replies. I guess my original questions were perhaps written in haste, however in a way I still think it would make sense for OpenBSD to check the permissions of key files (/etc/security style).I would have thought there is no reason why files already owned by root in a default install (etcXX.tgz) should be owned by another user when put in place by a siteXX file. Oh come on, admit it, you are wrong. Say you specifically wanted to change the uid a file, using siteXX.tgz With this model, you can. Wth what you suggest, you can't. It is obvious.
Re: siteXX.tgz and install.site behaviour questions
Hello Theo, my crazy idea /dev/null 21 Happy now ? ;-) - Original Message From: Theo de Raadt dera...@cvs.openbsd.org To: a b obsdmisc...@yahoo.co.uk Cc: Adriaan misc.adri...@gmail.com; misc@openbsd.org Sent: Sun, 21 March, 2010 16:57:51 Subject: Re: siteXX.tgz and install.site behaviour questions Thanks for all your replies. I guess my original questions were perhaps written in haste, however in a way I still think it would make sense for OpenBSD to check the permissions of key files (/etc/security style).I would have thought there is no reason why files already owned by root in a default install (etcXX.tgz) should be owned by another user when put in place by a siteXX file. Oh come on, admit it, you are wrong. Say you specifically wanted to change the uid a file, using siteXX.tgz With this model, you can. Wth what you suggest, you can't. It is obvious.
Why does dhclient-script set a route to 127.0.0.1?
Hi there, I switched to a new DSL provider, and this provider assigns an IP address using DHCP. No problem, a hostname.msk1 with just dhcp in it works great. When digging a bit deeper (purely out of interest), I noticed that /sbin/dhclient-script explicitly does: route add $new_ip_address 127.0.0.1 /dev/null 21 ... when it gets a lease. This route is deleted when necessary. When I use hostname.if to statically assign an address to an interface, no route to 127.0.0.1 is created. I've looked around, but I'm afraid I don't understand why dhclient-script goes out of its way to set this route. Could someone point me in the right direction? I'd like to understand the effects of setting (or not setting) such a route... Regards, -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: recent hardware with older OpenBSD versions
On Sun, 21 Mar 2010 11:34:14 -0400 Nick Holland n...@holland-consulting.net wrote: The great fantasy of many people in the IT world is lots of identical hardware and software. Sorry, this is completely unrealistic, or at least completely unhealthy, in the big picture. Until they understand reality and finally achieve enlightenment, they should stare at the contents of the drawer where they keep their socks. jcr
ALTQ Gigabit performance
I have two OpenBSD 4.6-stable boxes which I am having network
performance issues with while ALTQ is in use. This testing is being
performed while there is virtually no source of load on the boxes. I'm
looking to find out if this a limitation of ALTQ throughput, or
something with my configuration. I have tried changing the qlimit,
tbrsize, and from cbq to hfsc with no success.
The boxes use quad port em(4) network cards, on a PCIe 8x bus, and have
a relatively basic PF ruleset applied to them. When I add a basic ALTQ
rule, such as:
altq on trunk1 cbq bandwidth 2Gb queue { INTERNAL }
queue INTERNAL bandwidth 2Gb cbq(default)
iperf drops in performance by nearly 400Mbps. I have also tried this on
em9, a /30 shared between the two boxes via a crossover cable, with the
same results.
If it matters, trunk1 contains em2 and em3, with trunkproto lacp, and
uplink to a Cisco ME3400 with 'channel-group 2 mode active !
channel-protocol lacp'.
I have made the following sysctl adjustments:
net.inet.ip.ifq.maxlen=1536 # Despite this, it seems net.inet.ip.ifq.len
is always 0
net.inet.tcp.recvspace=98304# Tested tons of these sizes, and found
this is the minimum needed
net.inet.tcp.sendspace=98304# to acheive gigabit speeds. Was able to
push and pull 939Mbps at
net.inet.udp.recvspace=98304# this size using iperf(1) across a Cisco
ME3400.
net.inet.udp.sendspace=98304# see above
kern.maxclusters=32768 # Set this based on the output of `netstat -m`
under usual load
iperf testing w/ ALTQ disabled, across trunk1: (IP addresses masked)
[ 4] local X.X.X.X port 5001 connected with Y.Y.Y.Y port 7638
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 1.09 GBytes937 Mbits/sec
iperf testing w/ ALTQ enabled, across the same trunk:
[ 4] local X.X.X.X port 5001 connected with Y.Y.Y.Y port 47456
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec659 MBytes553 Mbits/sec
This is the output of `netstat -m` while ALTQ is enabled and a test is
being performed. Both machines look very similar, so I will only post one:
171 mbufs in use:
122 mbufs allocated to data
29 mbufs allocated to packet headers
20 mbufs allocated to socket names and addresses
82/1442/32768 mbuf 2048 byte clusters in use (current/peak/max)
0/8/32768 mbuf 4096 byte clusters in use (current/peak/max)
0/8/32768 mbuf 8192 byte clusters in use (current/peak/max)
0/8/32768 mbuf 9216 byte clusters in use (current/peak/max)
0/8/32768 mbuf 12288 byte clusters in use (current/peak/max)
0/8/32768 mbuf 16384 byte clusters in use (current/peak/max)
0/8/32768 mbuf 65536 byte clusters in use (current/peak/max)
3672 Kbytes allocated to network (5% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
This is the output of `pfctl -vs queue` just after creating the queue
and performing a test:
Server:
queue root_trunk1 on trunk1 bandwidth 2Gb priority 0 cbq( wrr root )
{INTERNAL}
[ pkts: 309242 bytes: 24187312 dropped pkts: 0 bytes:
0 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
queue INTERNAL on trunk1 bandwidth 2Gb cbq( default )
[ pkts: 309242 bytes: 24187312 dropped pkts: 0 bytes:
0 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
Client:
queue root_trunk1 on trunk1 bandwidth 2Gb priority 0 cbq( wrr root )
{INTERNAL}
[ pkts: 474136 bytes: 716710984 dropped pkts: 0 bytes:
0 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
queue INTERNAL on trunk1 bandwidth 2Gb cbq( default )
[ pkts: 474136 bytes: 716710984 dropped pkts: 2 bytes:
3036 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
Note, the qlength does not change any during the actual testing.
This is the output of `vmstat 1 15` while running the test:
Server:
procsmemory pagediskstraps cpu
r b wavm fre flt re pi po fr sr wd0 wd1 int sys cs
us sy id
1 1 0 198472 2156464 65 0 0 0 0 0 0 0 1848 769 198 0
2 98
0 1 0 198472 2156456 25 0 0 0 0 0 0 0 1336 185 113
0 1 99
0 1 0 198472 21563848 0 0 0 0 0 0 0 1620 116 26
0 0 100
0 1 0 198484 2156296 14 0 0 0 0 0 0 0 8175 12073 12593
0 18 81
0 1 0 198484 21562887 0 0 0 0 0 0 0 9962 15079 15726
0 24 76
0 1 0 198484 21562167 0 0 0 0 0 0 0 9943 15334 15677
0 28 72
0 1 0 198484 21562087 0 0 0 0 0 0 0 9955 15074 15968
0 26 74
0 1 0 198484 21561367 0 0 0 0 0 0 0 9882 15130 15796
0 26 74
1 1 0 198484 2156064 11 0 0 0 0 0 0 0 10130 14935 15820
0 26 74
0 1 0 198488 21560527 0 0 0 0 0 0 0 9854 15130 15917
0 26 74
0 1 0 198488 21559847 0 0 0 0 0 0 0 9744 15089 15806
0 24 76
0 1 0 198488 21559807 0 0 0 0 0 0 0 10038 15207 15856
0 24 76
1 1
Re: Sparc classic serial ports ttya vs cuaa
Miod Vallat wrote: Hi all, I've been working on getting gpsd working on one of my old Sun IPXes but I've run into a problem with ldattach needing the /dev/cuaa device. The serial port /dev/ttya is working with gpsd directly but ldattach requires /dev/cuaa. However, according to the system logs, ldattach issues the error (ldattach is run as root): ldattach: can't open /dev/cuaa: Device not configured Oops. Big oops. cua support for zstty was removed about 7.5 years ago, it was intended to be brought back, but I had completely forgotten about this. Does the following diff help? It should apply cleanly to 4.6 too (apply in sys/arch/sparc/dev). The patch did enable the /dev/cua* devices. I was able to use minicom to connect to /dev/cuaa and see the data streaming back from my GPS receiver. However, ldattach still doesn't seem to know what to do with the device. I started up ldattach as: ldattach -d -p -t dcd nmea /dev/cuaa But it just sits there and does nothing.
Re: Sparc classic serial ports ttya vs cuaa
Miod Vallat wrote: Hi all, I've been working on getting gpsd working on one of my old Sun IPXes but I've run into a problem with ldattach needing the /dev/cuaa device. The serial port /dev/ttya is working with gpsd directly but ldattach requires /dev/cuaa. However, according to the system logs, ldattach issues the error (ldattach is run as root): ldattach: can't open /dev/cuaa: Device not configured Oops. Big oops. cua support for zstty was removed about 7.5 years ago, it was intended to be brought back, but I had completely forgotten about this. Does the following diff help? It should apply cleanly to 4.6 too (apply in sys/arch/sparc/dev). Miod The patch did enable the /dev/cua* devices. I was able to use minicom to connect to /dev/cuaa and see the data streaming back from my GPS receiver. However, ldattach still doesn't seem to know what to do with the device. I started up ldattach as: ldattach -d -p -t dcd nmea /dev/cuaa But it just sits there and does nothing.
Berburu Genk Ovi - Undangan Baru
Hai, Kamu direferensikan oleh: Nama : K.WIDJANARKO/Male/41 tahun Kota : SEMARANG Deskripsi : SD Teladan bankinang,SD PA3 mageleng,SMPN 7magelang,sma 1Magelang,plp curug tangerang,PT Angkasa pura I air traffic controller Untuk bergabung dalam program Berburu Genk Ovi dan kesempatan meraih Honda Jazz dan hadiah menarik lainnya dari Nokia. Silakan klik link berikut untuk bergabung dengan Berburu Genk Ovi: http://www.berburugenkovi.com/reg/?r=5TEeYAnNRXhw Salam, Berburu Genk Ovi
***SPAM*** ddddd
a b c
