Re: gvinum/vinum on 6.0
On Wed, Jan 11, 2006 at 06:58:34AM -0500, Brian Szymanski wrote: > Stijn, thanks for your help, I'm getting closer... Great! > > > But most importantly, gvinum configuration (at least for a raid-5 plex) > > > still doesn't persist across a reboot :( > > > > That's a bug; I think it might be related to compiling gvinum in the > > kernel > > as opposed to loading it from /boot/loader.conf. I also think there is a > > fix already commited to 6-STABLE. > > Hmm, I upgraded to 6-STABLE and I'm still having the problem. > > Here's basically how it happens: > gvinum create /etc/vinum.cnf > newfs /dev/gvinum/VOLUME > mount /dev/gvinum/VOLUME /mnt > #screw with /mnt, everything works and is happy, yay! > reboot > > At this point I call "gvinum l" (which loads geom_vinum.ko) by hand (after > the reboot). My configuration mostly seems to persist - except or the > "drives" section... Ah ok. Hmm. Lukas will need to look at the initialization code path again I think. Sounds like some random pointer is being used somewhere. > Would I have better luck compiling gvinum into the kernel instead of > loading the module? What do other folks who have successful config's do? I use a third method: load geom_vinum.ko in /boot/loader.conf: [EMAIL PROTECTED] <~> cat /boot/loader.conf | grep geom_vinum geom_vinum_load="YES" But maybe those lost configurations have something to do with disks/controllers as well? Mine are Promise Ultra133 with Maxtor 200/250G drives, as well as an internal IDE chipset with Maxtor 120G drives. In any case, that's really an area that I'm unable to help you with, it all depends on a lot of GEOM internal stuff that I don't understand (yet). HTH, --Stijn -- > Thus again, we have succesfully proven that I cannot read minds. It doesn't help. Almost all you ever get is "This mind intentionally left blank." -- Steve VanDevender, alt.sysadmin.recovery pgp9f7NrImMmK.pgp Description: PGP signature
Re: gvinum/vinum on 6.0
Hi, On Tue, Jan 10, 2006 at 10:38:29PM -0500, Brian Szymanski wrote: > I took 6.0 for a test drive today and was disappointed to find that > vinum/gvinum are still in disarray. For example there is a man page for > vinum, but only a gvinum binary. gvinum help still lists lots of old vinum > commands that are not implemented in gvinum. Lots of basic things I try > from the gvinum prompt just tell me "not yet supported". Hmm. There is a manpage in 6-STABLE. And there are a few things that don't work but I wouldn't call it "lots". > But most importantly, gvinum configuration (at least for a raid-5 plex) > still doesn't persist across a reboot :( That's a bug; I think it might be related to compiling gvinum in the kernel as opposed to loading it from /boot/loader.conf. I also think there is a fix already commited to 6-STABLE. > Has anyone had success with software Raid-5 under freebsd 6.0 ? If so, how > did you do it? I'm succesfully running gvinum RAID-5 on two plexes on the same machine since 6.0-RC3 or thereabouts. I just used the same procedure I used to setup volumes with "regular" vinum. I did not try to migrate volumes however, I started from scratch and restored my data. > I've been forced, rather unhappily, to stick with 4.x and some early 5.x > releases b/c vinum is critical for me... Any advice would be greatly > appreciated. Two things: - contact Lukas Ertl <[EMAIL PROTECTED]> and/or send PRs with any problems that you encounter. He is very responsive, especially when you send in detailed problem reports. - try 6-STABLE instead of 6.0-RELEASE. It might not be useful for you in production, but at least you get a manpage, and the disappearing volume bug might be fixed. If not, you can try option 1. HTH, --Stijn -- My server has more fans than Britney. -- Steve Warwick, from a posting at [EMAIL PROTECTED] pgp5kIkXdmBsq.pgp Description: PGP signature
Re: kernel cpu entries
On Thu, Dec 15, 2005 at 12:17:21AM -0500, Mike Jakubik wrote: > Mark Kirkwood wrote: > >Is a minor update to the handbook needed in order avoid confusion > >then? e.g. I have been commenting out CPU_I586 on all my PIII systems > >in the (mistaken it would seem) belief that having CPU_I686 only was > >better. > > Agreed, i have always just used I686, assuming it inherited the features > of I586. I think most people will assume this. I did. (just another datapoint) --Stijn -- "I used to think I was indecisive, but now I'm not so sure." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.0 as storage server with raid5?
On Thu, Dec 08, 2005 at 05:04:57PM -0700, secmgr wrote: > Whatever you do, don't complain about it on this list, or you'll just be > told that if you really wanted raid, you should be running SCSI disks > and a raid adapter. They may allow that 3ware does ok, but no ATA drive > should ever be relied on and even s/w raid on scsi is only for ignorant > lusers who are too cheap to do the "right thing". > Those who think I run to hyperbole need only visit the archives. I know what you mean but I think this write-up is a bit too harsh. As long as the goal is to get _as reliable as possible_ without spending too much money, I think software RAID has its niche. Besides, I've seen a few hardware RAID controllers having issues themselves (and they weren't the cheapest ones available either). > One can only hope that gvinum actually works in 6 vs the buggy and > incomplete alpha code that shipped in 5.x. Having a man page is nice, > but I'd rather have a raid 5 set that didn't panic the system and > corrupt the set when it lost a drive (and this with modern scsi drives > and adapter). I haven't seen this (luckily!). I do know that sometime in 5.x there was a RAID-5 bug in gvinum but then again the whole vinum/gvinum transition was pretty dodgy back then. This is why I waited until 6.x to migrate. > I'd strongly suggest anyone using GEOM raid to do some > fault insertion testing of their setup prior to actually relying on it. I did. It worked. --Stijn -- There are of course many problems connected with life, of which some of the most popular are 'Why are people born?', 'Why do they die?', and `Why do they spend so much of the intervening time wearing digital watches?' -- Douglas Adams, "The Hitchhikers Guide To The Galaxy" pgpjc3SVsnCEy.pgp Description: PGP signature
Re: FreeBSD 6.0 as storage server with raid5?
On Thu, Dec 08, 2005 at 08:49:15PM +0100, Christian Brueffer wrote: > On Thu, Dec 08, 2005 at 02:31:00PM +0100, Stijn Hoop wrote: > > On Thu, Dec 08, 2005 at 12:18:57AM +0100, Torfinn Ingolfsen wrote: > > > I was thinking about gvinum for the storage server, but given the > > > current documentation and the discussions about it now, I don't want to > > > risk it. > > > > IMHO it's pretty stable in 6.0. I've been running gvinum RAID-5 for a > > while now; other than one strange panic (something to do with out of > > memory situations, see kern/89660) I haven't had a hitch yet. That > > said, I haven't needed to replace a disk yet either (I've demoed this > > but it was not yet needed in production use). > > > > In short, don't write gvinum off just yet. Documentation is around the > > corner (as a result of a SoC project). > > Actually gvinum(8) has been committed to CURRENT and RELENG_6 a couple > of days ago. Ah, I missed that, great :-) --Stijn -- Help Wanted: Telepath. You know where to apply. pgpjxs5Of2tKy.pgp Description: PGP signature
Re: FreeBSD 6.0 as storage server with raid5?
On Thu, Dec 08, 2005 at 12:18:57AM +0100, Torfinn Ingolfsen wrote: > I was thinking about gvinum for the storage server, but given the > current documentation and the discussions about it now, I don't want to > risk it. IMHO it's pretty stable in 6.0. I've been running gvinum RAID-5 for a while now; other than one strange panic (something to do with out of memory situations, see kern/89660) I haven't had a hitch yet. That said, I haven't needed to replace a disk yet either (I've demoed this but it was not yet needed in production use). In short, don't write gvinum off just yet. Documentation is around the corner (as a result of a SoC project). --Stijn -- "Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent man requires only two thousand five hundred." -- The Mahabharata. pgpW4eaFpgDLj.pgp Description: PGP signature
Re: Laptop choices
On Tue, Nov 29, 2005 at 10:28:23AM +, Nick Barnes wrote: > At 2005-11-29 10:19:17+, "Greg 'groggy' Lehey" writes: > > On Thursday, 24 November 2005 at 11:17:41 -0500, > > [EMAIL PROTECTED] wrote: > > > > > > On the [Dell] warrenty... I'm hard on equipment and I depend on my > > > equipment. I've been impressed that if I put my foot down and "say" > > > that I believe something needs replacing, then without much fuss, > > > they do it. The next day onsite service is cool. > > > > You obviously have better experience than I do. My Inspiron 6000 was > > apparently used: it arrived without the usual plastic coating on the > > lid, with scratches which couldn't have come from transport instead. > > Also the ejector for the PC Card fell apart shortly after I got it. > > It took them over 3 weeks to get a replacement lid to me, by which > > time I had left for Europe. By the time I get home I will have had > > the machine for 6 weeks, too long to return it, and only then will I > > be able to fight the Dell service department about the ejector. Only > > some time after then will they be able to replace the lid. > > Yeah. > > The "next day on-site service" for my wife's Dell took *two weeks* to > arrive (and replace the motherboard, which we had diagnosed as the > source of the fault after about 10 minutes). Never again. iBook on > order. We have lots of Dell Laptops on-site as we get a university discount. I have seen both sides of Dell's support; sometimes we were serviced *very* quickly, sometimes it took ages just to order a single memory stick. And for the 3 or 4 iBooks that we have around here, support has been different as well. As usual with support, YMMV. As far as the laptops themselves go, I think they're pretty good. Lots of features for a low price, and besides the occasional DOA they are only starting to break down after about 3-4 years of hard service. Do note that we buy the 'stable' Latitude series that doesn't change every other month. Just my EUR 0.02, do with this information as you wish, --Stijn -- There are of course many problems connected with life, of which some of the most popular are 'Why are people born?', 'Why do they die?', and `Why do they spend so much of the intervening time wearing digital watches?' -- Douglas Adams, "The Hitchhikers Guide To The Galaxy" pgpRAcvW9lWVQ.pgp Description: PGP signature
Re: vinum or gvinum
On Thu, Sep 08, 2005 at 01:20:47PM +0100, Tomas Palfi wrote: > I thought I could check previous gvinum config with the gvinum> list > command in its own shell. When I run this command for either gvinum or > vinum, they both reported no volumes. You should be able to use the list command to view the configuration. It's just that I'd start with a clean slate so to speak. > Also I noticed that you have IDE hard drives, whereas I have SCSI, would > that matter? Not that I know. To gvinum, they're just drives. By the way, you can also consider geom_mirror, for which an excellent article is available here: http://people.freebsd.org/~rse/mirror/ Both gvinum and gmirror approaches are able to boot from a mirrored system disk. It depends on other factors which one you choose. > Thank you No problem. --Stijn -- Fairy tales do not tell children that dragons exist. Children already know dragons exist. Fairy tales tell children the dragons can be killed. -- G.K. Chesterton pgprpwYivdc8s.pgp Description: PGP signature
Re: vinum or gvinum
On Thu, Sep 08, 2005 at 01:59:27PM +0200, Stijn Hoop wrote: > Did you start from scratch by wiping the former configuration without loading > gvinum? > > Use > > # dd if=/dev/zero of=/dev/da0 bs=1m count=128 > > to be sure. Do this WITHOUT loading any of the vinum modules. :( Forgot to add a big fat warning: ==> this hoses your system if you do this on your system disk of course <==! --Stijn -- Nostalgia ain't what it used to be. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vinum or gvinum
Hi, First: do _NOT_ use vinum on 5.4, use gvinum. On Thu, Sep 08, 2005 at 12:43:01PM +0100, Tomas Palfi wrote: > I am still struggling to set up a one way mirror on two 72GB disks on > 5.4 intel platform, however, there seems to be a lot of confusion about > what to use in the first place. this is vinum v gvinum. gvinum. Just to be safe you could move the vinum command and kernel modules out of the way. > Tried to configure the same with gvinum replicating the vinum.conf, > however, still nothing. Did you start from scratch by wiping the former configuration without loading gvinum? Use # dd if=/dev/zero of=/dev/da0 bs=1m count=128 to be sure. Do this WITHOUT loading any of the vinum modules. > You know, when you are creating the vinum > volume in bsdlabel and offsetting it with 16 blocks giving it vinum > format, do you change this for gvinum as well??? my config would not > have it, I can save it? I don't understand this. Here is my gvinum.conf for my mirrored system at home: %%% drive pain device /dev/ad4s1e drive panic device /dev/ad6s1e volume root plex org concat sd length 192m drive pain plex org concat sd length 192m drive panic volume swap plex org concat sd length 2080m drive pain plex org concat sd length 2080m drive panic volume usr plex org concat sd length 6g drive pain plex org concat sd length 6g drive panic volume var plex org concat sd length 256m drive pain plex org concat sd length 256m drive panic volume local plex org concat sd length 0 drive pain plex org concat sd length 0 drive panic %%% Be aware that gvinum's configuration syntax only allows the short forms for many keywords. /dev/ad4s1 and /dev/ad6s1 have this label: %%% [EMAIL PROTECTED] <~> sudo bsdlabel ad4s1 # /dev/ad4s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 393216 2814.2BSD0 0 0 c: 1562490090unused0 0 # "raw" part, don't edit e: 156248993 16 vinum %%% > I also tried the geom_vinum_load="YES" in the /boot/loader.conf, > however, should I have vinum.autostart="YES" there as well for the > gvinum?? No, vinum.autostart is for legacy vinum. > On another occasion I have edited /etc/rc.d/vinum changing the > start_cmd to "gvinum start" - nothing happened??? Don't do that, it's not necessary to edit anything in /etc/rc.d. > Also in the vinum.conf file that I laboriously create each time I try, > is the > > drive Master device /dev/da0s1h > > with the h which is the slice which I create in the bsdlabel or is it > the device name /dev/da0s1a for the root volume?? Non of it worked for > me. Use only vinum BSD partitions for gvinum drive declarations. > Help me out from here please. This is supposed to be a production > server and I have spent two days on it already. Keep at it until it makes sense, that's what I did. There are a lot of concepts to get until it clicks. HTH, --Stijn -- My server has more fans than Britney. -- Steve Warwick, from a posting at [EMAIL PROTECTED] pgpCEkUHfKnuT.pgp Description: PGP signature
Re: nve0 nvidia onboard ethernet dies daily on 6.0 beta1
On Fri, Aug 19, 2005 at 12:27:28PM +0200, O. Hartmann wrote: > I'm also interested in fixing the omnipresent nve-problems, but reading > the manpages for nve(4) reveals the bad circumstance that this driver > seems to be 'wrapped' around a Linux binary object. Nvidia obviously > isn't willing to offer documentation about the chip's internals so it > will be hard to develop an open source driver for this NIC. That sounds > to me to get happy with a 'ever GIANT locked' nve NIC using FreeBSD 6.X The Linux kernel includes a real opensource driver in the kernel for some time now, called 'forcedeth'. It seems that this works better than the nVidia driver. See http://www.hailfinger.org/carldani/linux/patches/forcedeth/ http://dev.gentoo.org/~dsd/nforce-net-to-forcedeth.htm For someone with enough driver-writing-fu it would be possible to look at the linux code and port it (GPL), or even better, write a new BSD licensed driver based on the things they do. That someone is not me, however... --Stijn -- Tact, n.: The unsaid part of what you're thinking. pgpphWJQ6RIj3.pgp Description: PGP signature
5.4 GEOM taste/gvinum trouble
Hi, I have a server set up to boot from a gvinum mirror volume. This was all working fine, so I then proceeded to load my data on it, safe in the knowledge that all was well. However, all was not well after the last reboot: it seems that while the two ATA disks probe, for some odd reason GEOM does not create device entries in /dev for one of the disks, while gvinum has gotten totally confused and thinks that the plex on the disappearing disk is still up! See the attached log for lots of details. All of this is on FreeBSD 5.4-RELEASE #2: Sun May 8 09:56:34 CEST 2005 Can anyone tell me: - how to force GEOM to 'taste' ad6 and therefore create the /dev entries? - how to tell gvinum that ad6 is really gone so that it will be forced to sync my data on ad6 after the GEOM problem is fixed? - the clue to how the machine has gotten in such a confused state? --Stijn -- I really hate this damned machine I wish that they would sell it. It never does quite what I want But only what I tell it. [EMAIL PROTECTED] <~> dmesg | grep '^ad' ad4: 76293MB [155009/16/63] at ata2-master UDMA100 ad6: 76293MB [155009/16/63] at ata3-master UDMA100 [EMAIL PROTECTED] <~> sudo geom disk list ad6 Geom name: ad6 Providers: 1. Name: ad6 Mediasize: 800 (75G) Sectorsize: 512 Mode: r0w0e0 fwsectors: 63 fwheads: 16 [EMAIL PROTECTED] <~> sudo gvinum ld 1 drive: D pain State: up /dev/ad4s1e A: 0/76293 MB (0%) [EMAIL PROTECTED] <~> sudo gvinum lv -r local V local State: up Plexes: 1 Size: 66 GB P local.p0C State: up Subdisks: 1 Size: 66 GB S local.p0.s0 State: up D: pain Size: 66 GB [EMAIL PROTECTED] <~> sudo gvinum lp -r local.p1 P local.p1C State: up Subdisks: 0 Size: 0 B [EMAIL PROTECTED] <~> ls -ld /dev/ad6* crw-r- 1 root operator4, 12 Aug 14 16:55 /dev/ad6 [EMAIL PROTECTED] <~> sudo fdisk ad6 *** Working on device /dev/ad6 *** parameters extracted from in-core disklabel are: cylinders=155009 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=155009 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 156249009 (76293 Meg), flag 81 beg: cyl 0/ head 1/ sector 1; end: cyl 384/ head 15/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: [EMAIL PROTECTED] <~> sudo disklabel ad6s1 disklabel: /dev/ad6s1: No such file or directory pgpLrZJz1ErfJ.pgp Description: PGP signature
Re: cvs commit: src/sys/net80211 ieee80211.c ieee80211_input.c ieee80211_ioctl.c ieee80211_node.c ieee80211_node.h ieee80211_output.c ieee80211_proto.c ieee80211_proto.h ieee80211_var.h src/sys/dev/ath if_ath.c src/sys/dev/ipw if_ipw.c ...
On Sat, Aug 13, 2005 at 08:11:52PM -0700, [EMAIL PROTECTED] wrote: > Quoting Sam Leffler <[EMAIL PROTECTED]>: > > > >The ipw and iwi drivers (at least) have never worked right so far as > >I can tell. At one point I tried the iwi driver and it kinda worked > >but failed in many common scenarios and in general was very fragile. > >I no longer have the facilities to even test these drivers and given > >that I know of no cardbus cards w/ intel parts in them it's unlikely > >I ever will unless someone wants to donate a laptop dedicated to > >testing. > > If you have a notebook with a MiniPCI slot, the Intel 2100, 2200 and 2915 > MiniPCI cards can be had in the after-market for US$30 or less. I can send a developer willing to work out the issues a 2200bg MiniPCI card for free. --Stijn -- "...I like logs. They give me a warm fuzzy feeling. I've been known to keep logs for 30 months at a time (generally when I thought I was rotating them daily, but was actually rotating them once a month)." -- Michael Lucas, in Big Scary Daemons article 'Controlling Bandwidth' pgpt5KD9oWLbN.pgp Description: PGP signature
Re: xl0: transmission error: 90
On Fri, Apr 15, 2005 at 08:27:13AM -0400, Mike Jakubik wrote: > On Fri, April 15, 2005 5:13 am, Ulrik Guenther said: > > on my 5.4-RC1 installation with a 3com 3c905B NIC I got the following > > messages while transferring a big file (31GByte) over 100MBit ethernet: > > > > Apr 15 08:46:18 verleihnix kernel: xl0: transmission error: 90 > > Apr 15 08:46:18 verleihnix kernel: xl0: tx underrun, increasing tx start > > > > So, okay the threshold was increaed in 60byte steps from 120 to 420 > > bytes, then it stopped. This procedure took place only during the first > > gigabytes of the transmission. I noticed no negative side effects (say: > > the file arrived completely on the other computer, checksum was okay as > > well). Transmission was done via SSH/SCP. > > > > Now my question: What do these messages from the xl(4) mean? > > Im assuming the xl cards default tx buffer is too low, or something of > that nature. I get the same messages, but everything works fine. I've been getting them for a few years now, always after a reboot: xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 120 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 240 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 300 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 360 bytes (not exactly all at the same time of course). Machine functions just fine as far as I can tell. --Stijn -- Coughlin's law: never tell tales about a woman no matter how far away she is, she'll always hear you. -- Cocktail pgpwm6LE4sK0P.pgp Description: PGP signature
Re: gvinum or vinum in 5.3-STABLE
On Mon, Feb 14, 2005 at 11:08:26AM +1030, Tristan wrote: > can anyone confirm what the preferred tool is > in 5.3-STABLE, vinum or gvinum ? Is gvinum > ready for production use in a RAID5 config ? You need to use gvinum on 5-STABLE and -CURRENT. As far as I can tell, it would be wise to update to 5-STABLE or wait for 5.4 in order to use gvinum with RAID-5 configurations. There have been some important fixes to gvinum wrt RAID-5 on the -STABLE branch. Do _not_ use regular vinum on 5-STABLE, it will not work. --Stijn -- An Orb is for life, not just for Christmas. pgpW894LURyWM.pgp Description: PGP signature
Re: vinum troubles on 5.3
Hi, On Thu, Nov 11, 2004 at 10:44:10PM -0500, Brian Szymanski wrote: > After a long and happy time with vinum under 4.8 -> 4.10, I'm finding > things very broken in 5.3. The config I'm trying to accomplish is > relatively simple, just a root mirrored volume configuration which worked > under 4.x. A root mirrored configuration isn't that straightforward, imo :) But it should work. > Using vinum, I lose state information for the drive on ad2 after reboot - > M2 is shown in "vinum l" output only as "referenced"... That is to be expected, as you discovered below... > Browsing some mailing lists I found that gvinum is the way to go these > days, so I changed to using geom_vinum/gvinum, and the information is > retained across boot, but when I try to boot to the root volume, it says > that the drive is not UFS. When I boot on another partition to look at the > situation, I found that there were no entries in /dev for /dev/ad0s1a. I > wanted to create a ad0s1a entry with mknod, but of course we've got devfs > now, so that didn't work. I'm stumped and not sure how to proceed. Any > ideas? That's strange. What is the output of fdisk ad0 bsdlabel ad0s1 Maybe something in GEOM gets confused... If the disappearing device node problem is fixed, gvinum should work in this case. > I originally was trying a complex configuration like so: > drive A 200G > drive B 200G > drive C 100G > drive D 100G > > I set the concat of drive all of drives C+D to be a volume makeshift, and > added drive definition like so: > drive MS /dev/gvinum/makeshift > > Then, the idea was to do a raid5 of drives A, B, and "drive" MS. I don't know if this is even possible. It's an interesting idea but even if it works, recovery is totally non-trivial when either drive C or drive D goes away. Plus, you'll surely take a huge performance hit because of the two vinum layers you have to go through for every single access. RAID-5 is normally used when you need redundancy but can't afford to shell out the cash for mirroring. If you don't care about loss of data you are better off using stripe, if you are absolutely paranoid about your data you are better off mirroring [1]. If you do need RAID-5 though, you have to do it properly, which means evenly-sized disks. Do make sure they're not all from the same manufacturing batch also... > Unfortunately this caused a panic, which is less surprising. Does anyone > know of another way to accomplish the same thing (Raid5 over two disks and > 2 half sized disks concatenated together?) or a similar result? The best you can do is have 100G of drives A & B participate in a 4 x 100G RAID-5, then use the other 2 x 100G in a separate volume. You *could* theoretically concat 2 plexes in one volume, where one plex is RAID-5 and the other mirror or some such, but as said above, it's not easy to recover from a drive failure in that case, defeating the point of RAID imho. HTH, --Stijn [1] all my opinion; there are lots of opinions on what type of RAID is best in what situation. My point is mainly that you really need to consider what you are trying to accomplish by using RAID. -- "Linux has many different distributions, meaning that you can probably find one that is exactly what you want (I even found one that looked like a Unix system)." -- Mike Meyer, from a posting at [EMAIL PROTECTED] pgpwIegHTc3N4.pgp Description: PGP signature
make installincludes does not populate /usr/include/g++
Hi, I downgraded a machine from 5-CURRENT to 4-STABLE this morning, so I tried to get me a new include directory after the installworld by doing # cd /usr # mv include include.old # mkdir include # cd src # make installincludes Which went okay, but my new build of ports/www/phoenix failed due to a non-existant headerfile 'g++/new.h'. After checking I found that installincludes does not populate the /usr/include/g++ directory, but installworld does. Is this a deliberate oversight? --Stijn -- Tact, n.: The unsaid part of what you're thinking. pgp0.pgp Description: PGP signature
Re: Is XFree86 4.3.0 going to be in 4.8? -nt-
On Mon, Mar 10, 2003 at 11:48:38AM +0100, Dag-Erling Smorgrav wrote: > Stijn Hoop <[EMAIL PROTECTED]> writes: > > This is with PERL_VERSION=5.8.0 in /etc/make.conf, and no /usr/bin/perl > > (since this is -CURRENT), which is why mkhtmlindex barfs. > > "use.perl port" Noted, thanks. I thought this was only needed for -STABLE, but apparently I was wrong. After manually installing a symlink the port installed fine of course, but I gather this the canonical way of installing the link? --Stijn -- The most reliable proof that there are extraterrestrial intelligent lifeforms out there is that nobody actually tries to get in contact with us. -- Dirk Mueller pgp0.pgp Description: PGP signature
Re: The plot thickens (problem solved!) (was Re: More information ...)
On Fri, Dec 20, 2002 at 10:05:28AM -0800, [EMAIL PROTECTED] wrote: > On 20 Dec, Emiel Kollof wrote: > > * Stijn Hoop ([EMAIL PROTECTED]) wrote: > > > >> > I might be the first to have noticed. What if suddenly 20 more people in > >> > the span of the next 24 hours report that X or X apps won't build? > >> > >> That's of course true, but 16 hours have passed since your first email > >> and noone else reports such a problem. Experience has shown that X build > >> problems will probably be reported more frequently here or on -ports > >> during that period if they affect all of the FreeBSD user group. > >> Or maybe everyone's on holiday of course, I don't know... > > > After a portupgrade last night /usr/ports/multimedia/mplayer would not > build so this morning I went to rebuild XFree and it failed with: > /usr/X11R6/lib/libXt.so: undefined reference to `pthread_cond_signal' [snip rest of similar errors] Great, that looks like the same error indeed. Now all you two have to do is find out what your systems have in common. FWIW attached is a listing of my installed ports, my make.conf, and uname output, so you can compare to a 'working' system. HTH, --Stijn -- The very powerful and the very stupid have one thing in common. Instead of altering their views to fit the facts, they alter the facts to fit their views ... which can be very uncomfortable if you happen to be one of the facts that needs altering. -- Doctor Who, "Face of Evil" FreeBSD firsa.sandcat.nl 4.7-STABLE FreeBSD 4.7-STABLE #1: Mon Dec 16 18:28:30 CET 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FIRSA i386 --- USA_RESIDENT=NO CPUTYPE=i686 XFREE86_VERSION=4 DISTDIR=/local/distfiles WRKDIRPREFIX=/local/build KERNCONFDIR=/usr/local/etc # -- use.perl generated deltas -- # # Created: Sat Nov 30 00:51:52 2002 # Setting to use base perl from ports: PERL_VER=5.8.0 PERL_VERSION=5.8.0 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo --- Mesa-3.4.2_2 ORBit-0.5.17 OpenSSH-askpass-1.2.2.2001.02.24 Sablot-0.96_2 XFree86-Server-4.2.1_6 XFree86-clients-4.2.1_2 XFree86-fontDefaultBitmaps-4.2.0 XFree86-fontEncodings-4.2.0 XFree86-libraries-4.2.1_5 Xaw3d-1.5 Xft-2.0_1 aalib-1.4.r5_1 apache-2.0.43_1 autoconf-2.53_1 autoconf213-2.13.000227_5 automake-1.5,1 automake14-1.4.5_9 bbkeys-0.8.5 bbpager-0.3.0 bison-1.75 blackbox-0.65.0 boxtools-0.65.0 cabextract-0.6 curl-7.9.8 cvsup-16.1f docbook-1.2 docbook-241 docbook-3.0 docbook-3.1 docbook-4.0 docbook-4.1 drm-kmod-0.9.6 esound-0.2.29 expat-1.95.5 ezm3-1.0 fontconfig-2.0_2 freetype-1.3.1_2 freetype2-2.1.2_1 gd-2.0.1_3 gdk-pixbuf-0.21.0 gettext-0.11.5_1 gimp-1.2.3_2,1 gle-3.0.3 glib-1.2.10_8 gmake-3.80 gqview-1.1.1 gtk-1.2.10_9 gv-3.5.8_1 help2man-1.29 imake-4.2.0_1 iso8879-1986 jade-1.2.1_1 jpeg-6b_1 lame-3.93.1 lcms-1.09 libaudiofile-0.2.3 libgnugetopt-1.2 libiconv-1.8_2 libmikmod-esound-3.1.10 libmng-1.0.4 libogg-1.0_1,3 libtool-1.3.4_4 libvorbis-1.0_1,3 libxml-1.8.17_1 linuxdoc-1.1 localfonts-0.4 m4-1.4_1 mad-esound-0.14.2b_2 mkcatalog-1.1 mkfontalias-0.3 mod_php4-4.2.3 mplayer-fonts-0.50 mplayer-gtk-0.90.0.10_1 mutt-1.4 mysql-client-3.23.54 mysql-server-3.23.54 nasm-0.98.33,1 open-motif-2.2.2_1 p5-DBD-mysql-2.1018 p5-DBI-1.28 p5-Net-Daemon-0.36 p5-PlRPC-0.2016 p5-Storable-2.05 p5-Test-Harness-2.26 p5-Test-Simple-0.47_1 perl-5.8.0_4 phoenix-0.5_3 pkgconfig-0.13.0 pkgdb.db png-1.2.5 portupgrade-20021209 pth-1.4.1_1 python-2.2.2_2 reallyslick-0.6.6 ripnews-0.0.9 rsync-2.5.5_1 ruby-1.6.8.p3 ruby-bdb1-0.1.7 ruby-shim-ruby18-1.7.3.2002.12.11 samba-2.2.7a screen-3.9.13 scummvm-0.3.0b sdl-1.2.4_1 sed_inplace-2002.10.19 sgmlformat-1.7_2 sudo-1.6.6 svgalib-1.4.2_1 t1lib-1.3.1 tiff-3.5.7 ttmkfdir-0.0_1 unrar-3.10b1 unzip-5.50 wget-1.8.2_2 win32-codecs-011002.0.0.90pre7 wine-2002.10.31 wrapper-1.0_2 xmms-esound-1.2.7_3 xpdf-2.00 xscreensaver-4.06 zip-2.3_1 zsh-4.0.6 msg52599/pgp0.pgp Description: PGP signature
nvidia driver port
Hi, for those interested I've just submitted a port that compiles and installs the NVIDIA driver for you. See PR ports/45988, http://www.freebsd.org/cgi/query-pr.cgi?pr=45988 Anybody is welcome to improve upon this version, it works for me as is and I won't have the time to maintain this in the near future. Hope this helps someone, --Stijn -- SIGSIG -- signature too long (core dumped) msg52162/pgp0.pgp Description: PGP signature
Re: stability & nvidia drivers?
On Wed, Dec 04, 2002 at 10:06:11AM +, Tarquin McDowell wrote:
> On Wed, Dec 04, 2002 at 09:47:39AM +0100, Stijn Hoop wrote:
> > Anyone getting any better results? Is there something I can do to fix
> > this? The drivers are of no use to me if they are this unreliable.
> > More info available on request, of course.
>
> I had a problem on my Gforcce 2MX400 where the first GL app I ran would be ok,
> but running any GL apps after that would cause a core dump (and sometimes a
> hard lock of the machine). A problem I noticed, though, was that
> sysctl -a | grep nv was showing a selected AGP rate of x4. I was able to
> change that value to x1 by making a change as documented on the Nvidia
> FreeBSD FAQ page:
>
> "Try lowering your AGP rate in the BIOS or nvidia_os_registry.c. If you want
> to use nvidia_os_registry.c to do this, find the line that reads
> { "ReqAGPRate", "Force AGP Rate", 4, 0 }, and change the last 0 to 1. Now you
> will be able to set the sysctl hw.nvidia.registry.ReqAGPRate to the value of
> the desired AGP rate. You will of course need to rebuild/reinstall/reload the
> kernel driver before attempting to set the sysctl."
>
> This fixed all my problems -- the driver seems to be very stable now.
Yes, that's it! Thanks for the pointer, this solved all the coredumps!
a happy
--Stijn
--
Q: Why is Batman better than Bill Gates?
A: Batman was able to beat the Penguin.
msg52157/pgp0.pgp
Description: PGP signature
Re: cdrecord under 4.5-stable
On Wed, Mar 13, 2002 at 10:23:04PM +0100, Wilko Bulte wrote: > If it is any consolation: Philips CDRW drives die anyway. One for me, > and 2 for 2 friends, all early deads with low mileage. Add another one to that list :( Burned roughly 100 CDs in 1 year... --Stijn -- ] Nothing safer than a 'cat /dev/wallet | grep $price > real-person; \ ] mv $thing-to-buy $my-case I'd prefer 'mv $thing-to-buy $my-case && cat /dev/wallet | \ grep $price > real-person -- Anonymous, [EMAIL PROTECTED], in message <[EMAIL PROTECTED]> msg42548/pgp0.pgp Description: PGP signature
Re: repository size
On Wed, Nov 21, 2001 at 11:40:45PM -0700, Chad R. Larson wrote: > Guys, there seems to be being an explosive growth in the size of the > CVS repository. > > When I first started keeping a local copy, it was about 800meg. Now > on my system it's almost run itself out of a 3GB partition. Is > there some flaw in my tracking, or have we all been very busy > beavers lately? I suspect something is broken at your end; mine is at 1.3G (which seems reasonable to me). --Stijn -- What would this sentence be like if it weren't self-referential? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Administrative tag a possibility?
On Thu, May 17, 2001 at 09:31:27AM -0400, Jamie Norwood wrote: > On Thu, May 17, 2001 at 07:43:27AM -0500, Stephen Montgomery-Smith wrote: > > > > That seems a little dangerous - perhaps some of the files will have > > md5 appearing in other lines for other reasons, and that would mess Read 'CHECKSUM' instead of 'md5' and your statement is correct. > > up this simple grep. Perhaps a more complicated tag in the file would > > be more appropriate. > > Not to mention that, AFAIK, once you add the checksum to the file, the > checksum would be different because the file is no longer the same, ne? > I am not aware of a way to include a checksum in the file being checked. Ehm, the original poster did the grep -v thing to avoid this, and I'm reasonably sure he also envisioned using a better tag than 'CHECKSUM' - it's the principle that's worth implementing. Anyway, I also haven't got any patches so I'll shut up now. --Stijn -- Tact, n.: The unsaid part of what you're thinking. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: delayed security email?
On Tue, Apr 17, 2001 at 03:35:44PM +0100, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Stijn Hoop writes: > >Now, I know for sure that I only had /usr/ports mounted during the time. > >And I think it's very strange that the daily security check would fail > >to mail me when a mount of /usr/ports is failing. Can anyone explain > >why this would happen? I don't think the security mail should be delayed > >for a reason like this. > > This is well-known and expected NFS behaviour. However, there are > some NFS mount options that can help. By default, NFS filesystems > maintain the semantics of local disks; i.e. accesses to them will > never time out, and are not interruptible, so if an NFS server > takes week to successfully read file, then the read operation on > the client will simply take a week to complete. Obviously with > local disks you rarely see delays this long :-) Yes, I know that. However, my point was that a hung NFS mount shouldn't cause the periodic security emails to stall. > If the "-i" (interruptible) flags is given, then the client will > still wait forever if a server doesn't respond, but you can interrupt > the process if you wish. Unless you have a very good reason not to > want interruptable mounts, you should always specify this to avoid > unkillable hung processes while the server is down. Yes, that was my mistake (and probably also that of Gavin Atkinson). It's also changed now at my client :) > The "-s" (soft) option is probably what you want. When specified, > the client will timeout if the server has not responded within a > reasonable time. Note that doing this can be bad; some applications > may not be expecting a failure from a supposedly-reliable disk > operation, so data loss might occur. There are also occasions where > NFS can get confused, and time out a request when the server is > alive, but just busy. See the mount_nfs manpage for further details. That is also good to know. However, my original point still stands. Thanks to Gavin's email, I understand why it hangs (ie /etc/security traverses nfs filesystems if they don't have nosuid), but I still want to know if this is wanted behaviour. It makes it rather easy to shoot yourself in the foot, since non-interruptible, non-soft mounts are still the default. Any NFS outage in that case causes all periodic jobs to stall (which is wrong, IMHO). And in my case, the NFS filesystems are all checked for setuid changes at the server side, no need to traverse them again on the client side. This only causes more NFS traffic, with no net gain. > In general though, NFS only works well when the server is available > at all times. You may have some success with the "amd" automounter > which can unmount filesystems that are not in use, but even that > can result in hung mounts when the server goes away. Hmm, I could also try that for solving hung NFS mounts - but notice that /etc/security still searches all suid filesystems. Thanks for the suggestions though, they still are helpful! --Stijn -- Nostalgia ain't what it used to be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
delayed security email?
Hi, I recently installed a new machine for testing NFS mounts. Things worked great, so I went to attend to other things. I tested the NFS mounts with my work machine as the server. Now I regularly upgrade my work machine, so it gets reboot every couple of days. I forgot that the client still had /usr/ports (and only /usr/ports) mounted from my work machine, so I didn't unmount that first. In fact, I failed to look at the client for a few days. What I didn't notice at first was that the client failed to report its security status from then on. I didn't get any daily mail from that machine anymore. Today I found out that I had a stale mount hanging around on the client. After turning my work machine into an NFS server once again, my 'cd /usr/ports' got unstuck (of course). However, I instantaneously got all delayed security mails from last week onward, all of which had kernel log messages like this pcwin165.win.tue.nl kernel log messages: > nfs server pcwin002:/usr/ports: not responding > nfs server pcwin002:/usr/ports: is alive again Now, I know for sure that I only had /usr/ports mounted during the time. And I think it's very strange that the daily security check would fail to mail me when a mount of /usr/ports is failing. Can anyone explain why this would happen? I don't think the security mail should be delayed for a reason like this. FWIW, I don't have weekly_status_pkg_enable set, and I can't think of anything else in periodic that needs /usr/ports. The client is running FreeBSD 4.3-RC #0: Tue Apr 3 10:28:00 CEST 2001. I don't have anything interesting in rc.conf, but I'll gladly provide it if required. --Stijn -- Tact, n.: The unsaid part of what you're thinking. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: cvs mailing list for RELENG_4 only?
On Fri, Mar 09, 2001 at 10:19:07AM +, Josef Karthauser wrote: > It's my long term goal to produce a proper branch mailing list, but this > means doing clever stuff with the commits because it's possible for a > committer to affect more than one branch at a time. And it would be even more cool if those MFCs would also automatically list the log messages of the committer-specified HEAD revisions. IE., someone MFCs rev. 110 of bar.c which adds foo support, committer specifies only MFC: 110 in the log message, and the mailing script retrieves the log message for HEAD revision 110 and inserts it where appropriate. That way, you can send all -current cvs mail to /dev/null... And no, I don't have patches :) --Stijn -- What would this sentence be like if it weren't self-referential? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: How's the latest snaphot?
Hi, On Wed, Mar 07, 2001 at 10:35:33PM +1300, Dan Langille wrote: > Tomorrow I'm going to install a stable snaphot on a client's box. I've > seen some issues lately in the list. All of which seem to have been > resolved lately. I'm wondering if I should be going for 4.2-20010306- > STABLE or 4.2-20010303-STABLE. I'm running 4.3-20010306-BETA successfully, with the CPUTYPE optimizations. HTH, --Stijn -- Nostalgia ain't what it used to be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Removal of Disklabel
On Tue, Nov 21, 2000 at 12:33:11PM -0800, Cy Schubert - ITSD Open Systems Group wrote: > > > > I'm on tangent mode this afternoon, so this is not a direct reply. > > [excellent explanation that makes perfect sense snipped for brevity] Even if there's nothing else gained by this discussion, can this be put in the handbook? This is definitely a very good explanation of the whole situation wrt slices/partitions and FreeBSD/other OSes. --Stijn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
