Re: 8.2-RELEASE pf rules not loading
On 25/02/2011 22:31, Jeremy Chadwick wrote: > On Fri, Feb 25, 2011 at 10:23:58PM +, Vincent Hoffman wrote: >> On 25/02/2011 17:35, Josh Carroll wrote: Hi All, Just upgraded my home machine to 8.2-RELEASE via freebsd-update remotely (spare time at work.) and on reboot my pf ruleset isnt being loaded. running '/etc/rc.d/pf start' once its booted does start it fine though. Any suggestions on debugging or shall i just try a verbose boot and watch the console when I get home? I still have pf_enable="YES" # Set to YES to enable packet filter (pf) pflog_enable="YES" # Set to YES to enable packet filter logging in /etc/rc.conf >>> > Please look at pf.conf(5) and search for the word "parentheses" (should > be under the "from x to x" section. This might resolve your problem. > Thanks, This did solve it. Slightly strange as its all statically set but at least I know now. Vince ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: urtw0: could not allocate USB transfers
On Friday 25 February 2011 21:53:54 joseph wrote: > Thanks for your fast answers! > I tryed your suggestions but only the urtw driver shows interrest in > my usb wlan device. > The patched urtw still gives the same error massage. > Could a update to 8.2 fix this issue? Possibly, worth a try. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
Hello, I updated a system from 8.1-RELEASE to 8.2-RELEASE today and now I'm having issues with gpart and gmirror. In the past I had two non-identical disks (one 250gb and one 750gb), which I wanted to create a mirror for them, so to do this, I gpart'ed them to equal sizes and then gmirror'ed them, without any issues. Of course that means that the rest 500gb of the bigger disk is not mirrored, but that wasn't a problem, since I was keeping non-important data there. Now I've got a second 750gb disk and updated to 8.2-RELEASE, and I wanted to create a full mirror of the two disks and the problems popped up. Hope you can help me a bit here. What I did is: 1. Backed up my system 2. Booted from FixIt image 3. Removed all previous partitions for gpart. 4. Did a gmirror for ad0 Fixit# gmirror label -vb round-robin gm0 /dev/ad0 5. gpart'ed the gm0 device, so I have gm0pN partitions 6. Restored everything from the backup to the gmirror'ed partitions 7. Reboot After a reboot I get this right before the FreeBSD bootloader starts: gptboot: invalid GPT backup header I suppose this error simply means that gpart can't find it's backup header, because gmirror and gpart both are using the last sectors for a provider to write it's metadata. Which would mean that gmirror and gpart metadata overlap, and that's why I see this message? Anyway, I can still boot from the primary GPT header, and here's the second message I get during boot: GEOM: ad0: secondary GPT header is not in the last LBA. Why does GEOM reports ad0, and not mirror/gm0 as the provider? I've used the gmirror'ed device for gpart, not ad0. I still have another option, and that is to create partitions on the disks and then gmirror them, just like a did before without issues, and my explanation for this would be that gpart would use the last sectors of ad0 and ad1, while gmirror would use the last sectors of the partitions - ad0pN. That way I don't get any issues, but why when I want to create mirror of the whole disks I get this? Shouldn't gmirror and gpart store it's data on different sectors in that case? What would happen if I try to glabel the disks first, then gmirror and then gpart them? I guess I would mess up everything again. Should I go back to my previous setup with mirroring partitions, instead of disks? gpart now supports a `backup' option, so inserting a new disk in case of disk crash is just as simple as putting the new disk, restoring GPT tables from backup and putting the partitions in a mirror. Thanks for any feedback. Marin -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Possible dri issue on the Kernel side
To whom it may concern: I am an avid Linux user and recent BSD convert. I have a Lenovo Thinkpad L412 with an Intel i3 370M & ATI HD 5145(rebadged HD4570) graphics. I recently tried Fedora 14 and had the same problem that I have had with PC-BSD, the underside of the laptop got HOT! When I was running on the radeon driver it was ridiculously hot, then when i switched to the catalyst it was managable. I found out that the following link worked in Fedora 14: http://forums.fedoraforum.org/showthread.php?t=155503. In PC-BSD I was using the radeon driver with DynamicPM, Clockgating, and ForceLowPowerMode all on and it was still hot. After careful consideration and diagnosis, with thanks to Dru and Martin, we believe that this might be a dri problem on the kernel side, possibly linked to the Intel Core i3. I am willing to do testing for you on PC-BSD 8.2 if you would like to help everyone. Let me know what I can do to help! Thought I would list the repo link: http://download1.rpmfusion.org/nonfree/fedora/updates/testing/14/i386/repoview/index.html *BEFORE SENDING FINISH THIS! pciconf -lv:* hostb0@pci0:0:0:0: class=0x06 card=0x218317aa chip=0x00448086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x218417aa chip=0x00458086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI none0@pci0:0:22:0: class=0x078000 card=0x215f17aa chip=0x3b648086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = simple comms ehci0@pci0:0:26:0: class=0x0c0320 card=0x216317aa chip=0x3b3c8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB hdac0@pci0:0:27:0: class=0x040300 card=0x215e17aa chip=0x3b568086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = multimedia subclass = HDA pcib2@pci0:0:28:0: class=0x060400 card=0x216417aa chip=0x3b428086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:1: class=0x060400 card=0x216417aa chip=0x3b448086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:2: class=0x060400 card=0x216417aa chip=0x3b468086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib5@pci0:0:28:3: class=0x060400 card=0x216417aa chip=0x3b488086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib6@pci0:0:28:4: class=0x060400 card=0x216417aa chip=0x3b4a8086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib7@pci0:0:28:5: class=0x060400 card=0x216417aa chip=0x3b4c8086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI ehci1@pci0:0:29:0: class=0x0c0320 card=0x216317aa chip=0x3b348086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB pcib8@pci0:0:30:0: class=0x060401 card=0x216517aa chip=0x24488086 rev=0xa6 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/5/6/7/8/9-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x216617aa chip=0x3b098086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = PCI-ISA ahci0@pci0:0:31:2: class=0x010601 card=0x216817aa chip=0x3b298086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'IBEX AHCI Controller(4Port)' class = mass storage subclass = SATA none1@pci0:0:31:3: class=0x0c0500 card=0x216717aa chip=0x3b308086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = SMBus vgapci0@pci0:1:0:0: class=0x03 card=0x21bb17aa chip=0x95531002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI Mobility Radeon HD 4570 Series (M92)' class = display subclass = VGA hdac1@pci0:1:0:1: class=0x040300 card=0x21bb17aa chip=0xaa381002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' class = multimedia subclass = HDA none2@pci0:2:0:0: class=0x088000 card=0x212e17aa chip=0x2382197b rev=0x00 hdr=0x00 vendor = 'JMicron Technology Corp.' device = 'JMB38X SD/MMC Host Controller (JMB38X)' class = base peripheral sdhci0@pci0:2:0:2: class=0x080501 card=0x212d17aa chip=0x2381197b rev=0x00 hdr=0x00 vendor = 'JMicron Technology Corp.' class = base peripheral subclass = SD host controller none3@pci0:2:0:3: class=0x088000 card=0x212f17aa chip=0x2383197b r
Re: 8.2/7.4-RELEASEs Announced...
On Fri, Feb 25, 2011 at 03:01:11PM -0500, John Baldwin wrote: ... > No, release branches long pre-date freebsd-update. However, before we > switched to svn for source, new branches did not bump all the $FreeBSD$ tags. > > That is a side effect of the way that the SVN -> CVS exporter works (and > arguably a bug). > > BTW, I did design etcupdate to support this sort of use case (you can build a > tarball from a given release tree and use that as the basis for comparisons > assuming you were bootstrapped to use etcupdate). Currently freebsd-update > doesn't use etcupdate and the author doesn't have any interest in changing it > to do so. > > At some point if I have some time to hack on freebsd-update to be more useful > for modified versions of FreeBSD (e.g. building snaps from tags in an SVN > repository instead of a directory of patches against a CVS checkout), I will > probably hack it to support using etcupdate to manage /etc updates as well. > > (etcupdate uses something akin to 'svn up' to update files in /etc, so things > like $FreeBSD$ changes just auto-update assuming they don't result in merge > conficts.) That would be nice. Since freebsd-update clearly has done something like generate the deltas for X.Y->Z.W for /etc files, if it were to assume the status quo ante is that files in /etc are based on the X.Y version of the /etc, it should already be able to do slightly smarter things than it's doing. Hmmm. -- Clifton -- Clifton Royston -- clift...@iandicomputing.com / clift...@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
On 26.02.2011 15:26, Marin Atanasov Nikolov wrote: > After a reboot I get this right before the FreeBSD bootloader starts: > > gptboot: invalid GPT backup header > > I suppose this error simply means that gpart can't find it's backup > header, because gmirror and gpart both are using the last sectors for > a provider to write it's metadata. This message is from gptboot. Loader does not know about your software mirror and it just checks GPT headers in the second and last LBA. As i see now, there is inconsistency in the behavior between gptboot and GEOM_PART_GPT. gptboot does reading of GPT backup header from the last LBA, but GEOM_PART_GPT from the alternate LBA which is not equal to last LBA in your case. > Which would mean that gmirror and gpart metadata overlap, and that's > why I see this message? No. > Anyway, I can still boot from the primary GPT header, and here's the > second message I get during boot: > > GEOM: ad0: secondary GPT header is not in the last LBA. > > Why does GEOM reports ad0, and not mirror/gm0 as the provider? I've > used the gmirror'ed device for gpart, not ad0. This is how GEOM tasting works. Do you have any problem except for those messages? What does not work? Also when you are writing problem report about gpart it will be not bad to add output of `gpart show` or `gpart list` commands. And `gmirror list` for GEOM_MIRROR. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
2011/2/26 Andrey V. Elsukov : > On 26.02.2011 15:26, Marin Atanasov Nikolov wrote: >> After a reboot I get this right before the FreeBSD bootloader starts: >> >> gptboot: invalid GPT backup header >> >> I suppose this error simply means that gpart can't find it's backup >> header, because gmirror and gpart both are using the last sectors for >> a provider to write it's metadata. > > This message is from gptboot. Loader does not know about your software > mirror and it just checks GPT headers in the second and last LBA. > As i see now, there is inconsistency in the behavior between gptboot and > GEOM_PART_GPT. > > gptboot does reading of GPT backup header from the last LBA, > but GEOM_PART_GPT from the alternate LBA which is not equal to last LBA > in your case. > >> Which would mean that gmirror and gpart metadata overlap, and that's >> why I see this message? > > No. > >> Anyway, I can still boot from the primary GPT header, and here's the >> second message I get during boot: >> >> GEOM: ad0: secondary GPT header is not in the last LBA. >> >> Why does GEOM reports ad0, and not mirror/gm0 as the provider? I've >> used the gmirror'ed device for gpart, not ad0. > > This is how GEOM tasting works. Do you have any problem except for > those messages? What does not work? No, no other issues noticed. > > Also when you are writing problem report about gpart it will be not bad > to add output of `gpart show` or `gpart list` commands. And `gmirror > list` for GEOM_MIRROR. Would do that, but unfortunately as mentioned I was running a Fixit image locally, so the only thing I got was a lit of paper and a pen to write down the messages :) Anyway, I've switched back to partition mirroring, which is good enough for me. Redundancy is still present in case of a disk failure since the second disk also contains bootcode and it boots up normally. Thanks for the feedback. Regards, Marin > > -- > WBR, Andrey V. Elsukov > > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How to bind a static ether address to bridge?
Am 25.02.2011 um 07:56 schrieb Zhihao Yuan: > My server is behind a DHCP-enabled router, and it has two network > interfaces, wlan0 and bge0. I want to use them together, so I bind > them, plus tap0 to bridge0. But bridge has a random MAC address for > each time it was created, which makes me hard to reserve an IP for it > (since I need to forward some ports to this server). So I set > net.link.bridge.inherit_mac=1, which makes bridge0 to use bge0's MAC > address, always. But this causes another problem: the packets sent to > bridge0 is also sent to bge0, -- the packets are duplicated! The > kernel have to drop half of them. So how can I bind a distinct MAC > address to a bridge? This is in my router's rc.conf: ifconfig_bridge0="ether 02:00:00:00:00:01 addm tap0 addm vlan1" ifconfig_bridge0_alias0="inet 192.168.0.1/24" vlan1 is on em0; neither as an address assigned. And if you want to put IPv6 on there, you also have to add a link-local address to make rtadvd happy, something like: ipv6_network_interfaces="bridge0 gif0" ipv6_ifconfig_bridge0="fe80::21c:c0ff:fe7d:8c50%bridge0" ipv6_ifconfig_bridge0_alias0="2001:470:1f0b:::1 prefixlen 64" -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2/7.4-RELEASEs Announced...
On Fri, Feb 25, 2011 at 03:01:11PM -0500, John Baldwin thus spake: On Friday, February 25, 2011 1:00:19 pm jhelf...@e-e.com wrote: > On Fri, Feb 25, 2011 at 02:42:25PM +0100, Marco van Tol wrote: >> >> Read up on the mergemaster manual for options "-F" and "-i" :-) > > freebsd-update does not use mergemaster, though probably it should. My understanding is that freebsd-update was introduced prior to releases being branched, so this issue surfaced at that time. The patch I believe would be a fix to the freebsd-update client to better handle the tag. I can't see mergemaster as being an easier solution, as the actual binary would need to be verified against a known good index that would exist on the update server. No, release branches long pre-date freebsd-update. However, before we switched to svn for source, new branches did not bump all the $FreeBSD$ tags. That is a side effect of the way that the SVN -> CVS exporter works (and arguably a bug). Yes. This is what I was trying to explain. Thanks for clearing this up, John. BTW, I did design etcupdate to support this sort of use case (you can build a tarball from a given release tree and use that as the basis for comparisons assuming you were bootstrapped to use etcupdate). Currently freebsd-update doesn't use etcupdate and the author doesn't have any interest in changing it to do so. Speaking as an administrator of my own set of freebsd-update-servers, I would suggest a different path to solve the issue. I am not certain what the exact path would be, but let me attempt to explain the issues I believe would come up. The freebsd-update-server software builds binary updates for distribution using that are updated using the freebsd-client off of an actual distribution iso that is built using the standard 'make release' process. So in edition to modifying the freebsd-update-server code to not build this portion of the release, or at least not distribute it, the client would need to be aware not to look for it, as well. You can update the client to use a different method for updating /etc, however the freebsd-update mirror servers will still be distributing the files, so you will have either a similar issue, or a new issue. Using the freebsd-update-software, I am not only able to apply security patches that are distributed by the security team, but I can also apply patches to /etc, or any part of the release for that matter, when it comes to distribution of updates from my updates servers. This is the flexibility I enjoy, and celebrate, in using FreeBSD. All of this being said, if an update software, and respective client were created specifically for /etc, it would be great to have similar functionality, in building off of a distributed iso, with the possibility of patching available, so this functionality is not lost. In addition to this, also using keyprints to authenticate the client, and distribute in a similar matter. I am copying Colin on this, in case he has any thoughts on the matter, or ideas that may make this a possibility. At some point if I have some time to hack on freebsd-update to be more useful for modified versions of FreeBSD (e.g. building snaps from tags in an SVN repository instead of a directory of patches against a CVS checkout), I will probably hack it to support using etcupdate to manage /etc updates as well. This would be great, if you can have it build and work off of a distributed iso. It would be very disappointing to be restricted to an svn/cvs tag/branch from FreeBSD, without the flexibility that is possible now using the freebsd-update-server software. This flexibility allows me to distribute binary updates for a custom kernel, and to modify /etc and distribute it at my leisure. (etcupdate uses something akin to 'svn up' to update files in /etc, so things like $FreeBSD$ changes just auto-update assuming they don't result in merge conficts.) -- John Baldwin Thanks, and would enjoy being in on any future development thoughts, or ideas regarding your work on this. Jason -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2/7.4-RELEASEs Announced...
When I was looking at this problem myself recently it occurred to me that one way to handle it would be to have the freebsd-update code build and populate the temproot directory that mergemaster uses and then offer the user the option to use that alternative. The process could use something like what's done in src/release/scripts/mm-mtree.sh if this direction is desirable. Obviously the temproot directory would have to be distributed as an additional blob by freebsd-update, but this method has the advantage of reusing existing tools, and it's able to handle updates from arbitrarily old existing installations. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
