From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 00:15:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3081B1065670 for ; Sun, 27 Sep 2009 00:15:36 +0000 (UTC) (envelope-from mlobo@digiart.art.br) Received: from sv4.hmnoc.net (sv4.hmnoc.net [63.247.76.174]) by mx1.freebsd.org (Postfix) with ESMTP id E5C888FC13 for ; Sun, 27 Sep 2009 00:15:35 +0000 (UTC) Received: from [187.78.69.120] (port=57410 helo=papi.localnet) by sv4.hmnoc.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MrfRw-0004Zr-Fq for freebsd-current@freebsd.org; Sat, 26 Sep 2009 19:09:05 -0300 From: Mario Lobo To: freebsd-current@freebsd.org Date: Sat, 26 Sep 2009 19:10:08 -0300 User-Agent: KMail/1.12.1 (FreeBSD/8.0-RC1; KDE/4.3.1; amd64; ; ) MIME-Version: 1.0 Message-Id: <200909261910.08635.mlobo@digiart.art.br> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sv4.hmnoc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - digiart.art.br Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL (recap) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 00:15:36 -0000 Hi to all; Recently I've upgraded my home box from FreeBSD 7.2-stable i386 to 8-CURRENT amd64 (specifically 200906 snapshot)because of a major CPU-BOARD-MEMORY (Phenon 955-AOD790GX/128M-8G RAM)overhaul. 7.2 stable amd64 wouldn't install on it (/dev/cd0 disapeared right after sysinstall screen, so no CD/DVD to install from. Same with all attempts with any previous amd64 revision). So I figured, what the heck, lets do it! 8-CURRENT intalled fine. My box is pretty full of stuff. A lot of the files I have here have been migrating from version to version of all these OSses along the years, without any problem. Please, just try to bear with the fact that I do need to have all this, leaving the "why" out of scope and knowing that I DO have backups for almost all of it. I use this box from pro audio productions (winedows) to devel (winedows (VBox),BSD, & linux (Vbox), to network environment emulation (Vbox), and in- betweens. 2 500G SATA drives and 1 20G ide for XP64 "fun". On those sata drives I have: SATA1:1 primary FAT32 part, 1 primary BSD / 1 EXT -> 3 FAT32, 1 NTFS 1 primary ext2fs SATA2:1 primary BSD (5 slices /usr, /apps, /var, /tmp and swap) 1 EXT -> 3 FAT32, 1 NTFS By now you should have a clue as to why I brought this subject back. On the first boot, first question: Where were those nice GEOM devices that so nicely showed up and held ALL of the above on my previous 7.2-STABLE? At first, I found out that sysinstall (label or fdisk, I don't know) did something to my part table that made everything disappear. I went to the IDE drive and restored everything with testdisk (nice program !). booted BSD. result: 2 GEOM label mismatch errors (1 for /, 1 for the other SATA2 BSD part) only 2 FAT32 and 1 NTFS from SATA1 only 1 FAT32 SATA2 Well, back and forth from my XP64 part, googling started (no X yet on 8). I tried to manually mount the devices that didn't show up on /dev/msdosfs,ntsf,ext2fs. Errors. Tried by taking GEOM_PART out of the picture and kernel recompile. Didn't even boot. Livecd and loaded geom_part as modules. Booted back but still no EXT parts. After a good while, I picked up this subject, which gave me a clue to what to do: 1)I tried to put "options GEOM_MBR, _BSD & _LABEL" into the kernel. It wouldn't config. 2)I noticed that the modules geom_mbr,geom_bsd and geom_label were present in /boot, so I kept the GEOMles kernel and loaded those from loader.conf. crossed my fingers and rebooted. BANG !! I could not believe my eyes ! EVERY SINGLE PARTITION showed up on my face, as neatly arranged devices, asking "what are you waiting for?" This is just a rough outline of many days of pain and agony. Right now, I am typing this e-mail from a fully functional 8-CURRENT/X/KDE 4.3.1 desktop (yes, BSD IS my desktop), accessing ALL my drives, thanks to good old GEOM_XXX. On one of the subject's thread, I quote Marcel Moolenaar: >> 1. What's getting removed and why? > GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL They're so yesterday. >> 2. What's it being replaced with? > GEOM_PART_BSD, GEOM_PART_MBR, GEOM_PART_PC98 and GEOM_PART_VTOC8 >> 3. How do I migrate from the old system to the new one? > No migration is needed. You already use the new kernel options. All I'm > doing is remove the old not-to-be-used options. FYI, -- Marcel Moolenaar" Well, # 3 DIDN'T work for me, no matter how hard I tried. GEOM_PART did not "understand" what I had, while GEOM_ did, on the first attempt ! Then I quote John Baldwin, a few e-mails ahead on the thread: "I think it is less painful for folks upgrading from 7 to just use the old names. It is also a lot easier on the eyes. I'm also not sure people are going to be changing their partition layout once it is done so having the names 'change' would not seem to be something that would happen very often at all in practice. -- John Baldwin" This is my EXACT experience with GEOM, so this e-mail is and absolute plea to the developers: Please don't take GEOM_XXX away. Folks on the same situation as mine won't be able to work if, after one fine csup src and make buildworld/kernel day, those geom_xxx.kos are not there !. A put myself and my box at your disposal in trying to find out what went wrong. Meanwhile, please keep them in the source tree. My apologies for such a long e-mail, but believe me, I made it as short as I could. Best regards to all, -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winedows FREE) From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 02:33:40 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9507E106566C for ; Sun, 27 Sep 2009 02:33:40 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 27E758FC16 for ; Sun, 27 Sep 2009 02:33:39 +0000 (UTC) Received: from [10.29.62.2] (port=62755 helo=Aris-MacBook-Pro.local) by fish.ish.com.au with esmtpa (Exim 4.69) (envelope-from ) id 1MrjaZ-00064Y-30; Sun, 27 Sep 2009 12:34:16 +1000 Message-ID: <4ABECEFD.5020001@ish.com.au> Date: Sun, 27 Sep 2009 12:33:33 +1000 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Shredder/3.0b4pre MIME-Version: 1.0 To: Robert Watson References: <20090921112657.GW95398@hoeg.nl> <19e9a5dc0909211728m159c1b50id00dec2b3f8110b0@mail.gmail.com> <20090922101329.K39832@ury.york.ac.uk> <200909221231.27713.gnemmi@gmail.com> <20090922174713.B39832@ury.york.ac.uk> <19e9a5dc0909221042l4f5a3e13p27776ee8bbc9713e@mail.gmail.com> <20090922225905.GC21416@lonesome.com> <4ABD68FA.5010103@ish.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Linimon , Gonzalo Nemmi , current@freebsd.org Subject: Re: Various problems seen in RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 02:33:40 -0000 On 27/09/09 9:52 AM, Robert Watson wrote: > Unfortunately, I fell behind due to running the developer summit and > EuroBSDCon, but really that's a symptom of an underlying problem: I was > (and > am) manually maintaining the wiki list based on re@ e-mail correspondence. > > That is fundamentally the wrong approach--we should be using the > bug-tracking system to manage pending requests and known issues. In > particular, I'd like each merge request and in-progress issue to be > captured by a bug entry, and referenced during commits and merges. This > would allow 99% of the information on the wiki page to be mechanically > generated, and avoid the "missed stuff" problem. We'd also have to get > better at saying "it's a real bug but we can't > fix it for this release" explicitly, of course. > > There's not an opportunity to fix that for 8.0, but my recommendation > has been that we at least use gnats, if not some more capable, > issue-tracking system to handle pending changes and merge requests, with > approvals to commit to > branches linked back to the request so re@ can track what's going on. Absolutely! And my mention of your wiki page was certainly not a criticism of your efforts with the wiki page. A valiant effort I think (and much more useful than no information at all), but as you say, fundamentally doomed. Far too much work to maintain over more than a very short period. I sent you/Mark an email in February about this topic and my offer to help because I think this is one area where FreeBSD communication channels could be significantly improved without creating more work (after the short term effort of change of course). Any one of about a dozen sophisticated bug trackers would be capable of integrating svn linking, bug tracking, feature requests, feature voting, milestone management, developer task assignment, release management, release notes, and even have a workflow component that could integrate with the ports lifecycle (port owners without commit rights). Regards Ari Maniatis -- --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 02:40:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC4C2106566B for ; Sun, 27 Sep 2009 02:40:40 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 67F1C8FC08 for ; Sun, 27 Sep 2009 02:40:40 +0000 (UTC) Received: from lightning.wonkity.com (lightning.wonkity.com [10.0.0.8]) by wonkity.com (8.14.3/8.14.3) with ESMTP id n8R2ed9h030815 for ; Sat, 26 Sep 2009 20:40:39 -0600 (MDT) (envelope-from wblock@lightning.wonkity.com) Received: from lightning.wonkity.com (localhost [127.0.0.1]) by lightning.wonkity.com (8.14.3/8.14.3) with ESMTP id n8R2edCR013338 for ; Sat, 26 Sep 2009 20:40:39 -0600 (MDT) (envelope-from wblock@lightning.wonkity.com) Received: from localhost (wblock@localhost) by lightning.wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id n8R2edgm013335 for ; Sat, 26 Sep 2009 20:40:39 -0600 (MDT) (envelope-from wblock@lightning.wonkity.com) Date: Sat, 26 Sep 2009 20:40:39 -0600 (MDT) From: Warren Block To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (wonkity.com [10.0.0.1]); Sat, 26 Sep 2009 20:40:39 -0600 (MDT) Subject: Re: 8.0-RC1 install "Leave MBR untouched" writes MBR anyway X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 02:40:40 -0000 I had written: > Just did a mini install of the 8.0-RC1 ISO. After slicing, choosing > "Leave the Master Boot Record untouched" is ignored. A standard MBR is > installed. That was on a Toshiba notebook with Vista freshly installed and ACPI disabled. I tried it twice to make sure. Installing from the same 8.0-RC1 image in qemu works fine, leaving the MBR alone. So either the problem is a figment of my imagination, or is rare enough to ignore. Same thing, really. -Warren Block * Rapid City, South Dakota USA From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 03:54:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F2E1106566C for ; Sun, 27 Sep 2009 03:54:07 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by mx1.freebsd.org (Postfix) with ESMTP id 356E48FC18 for ; Sun, 27 Sep 2009 03:54:06 +0000 (UTC) Received: by ewy5 with SMTP id 5so2002370ewy.36 for ; Sat, 26 Sep 2009 20:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=hp5DPfFgMM2YZLEN9z8zfjl9VXfHhcRMnpEdoK5+fzw=; b=AmRDgmzb+5EilOOPSIZ3tf7bsVb2jfogEq5pUMwu644qcRxZy4G4DgtPter3OdqUD9 ydMqnPBmH0bmzuBE+RDHW1wITugMiDryQKwcPENGVf7nhg2gW7l6dClKm7GBWTh/vSdu 3qo1qqryvkwVya3OhZARzXkqQO+wpp5/wpyNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=VexT4+A1wraDmry7bK/QlBnshIHweHyeTFrmei/5r/+acPu8xL1YQ+sEwXFHvwY05K M4WD9Us2rAgr6mmOzDrJbl0h4Ctr+XXpfcANW1cJsKZFx4tORe4ioFtYjhr3HT4Mk1W1 iZE5XEOGyDYOFOg+mzAG03pmC8brt+Jh0wA+s= MIME-Version: 1.0 Received: by 10.211.154.17 with SMTP id g17mr1575599ebo.32.1254023646213; Sat, 26 Sep 2009 20:54:06 -0700 (PDT) In-Reply-To: References: Date: Sat, 26 Sep 2009 22:54:06 -0500 Message-ID: <58c737d70909262054k7c7b1402w4f9c902fdca2640c@mail.gmail.com> From: Chris Ruiz To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: 8.0-RC1 install "Leave MBR untouched" writes MBR anyway X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 03:54:07 -0000 On Sat, Sep 26, 2009 at 9:40 PM, Warren Block wrote: > I had written: > >> Just did a mini install of the 8.0-RC1 ISO. After slicing, choosing "Lea= ve >> the Master Boot Record untouched" is ignored. A standard MBR is >> installed. > > That was on a Toshiba notebook with Vista freshly installed and ACPI > disabled. =A0I tried it twice to make sure. > > Installing from the same 8.0-RC1 image in qemu works fine, leaving the MB= R > alone. =A0So either the problem is a figment of my imagination, or is rar= e > enough to ignore. =A0Same thing, really. Actually, I had the same thing happen when installing 7.2 on my MacBook (because 8.0-betas/rcs and CURRENT panic on boot). I selected Leave the MBR untouched and a standard MBR that only listed my FreeBSD partition was installed. I had to boot my OSX install dvd and run fdisk to fix the MBR. -- Chris ----------------------------------------- http://twitter.com/chrisattack http://chrisattack.com From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 08:33:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C141065670 for ; Sun, 27 Sep 2009 08:33:04 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by mx1.freebsd.org (Postfix) with ESMTP id 961F58FC13 for ; Sun, 27 Sep 2009 08:33:03 +0000 (UTC) Received: by ewy5 with SMTP id 5so2085838ewy.36 for ; Sun, 27 Sep 2009 01:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Dokw2K+9sHrhCflpuT42Wv8Bc0I3GNVHW10y/IvfRF0=; b=J9B31rGTEcQZApQ/XCb5ghfwQmAQ5z3gEfnOTpQMnY7D2gBEGEBWPARoBAsoJZUQy+ qxBl3uKHpr4UN3LnnsGxW4E/4CMfEPI05gZVr4bAKn4LsorqP68zHS3kM1oswXIXDCw8 tOnwd0lrrl9UjLsHELGB4PVePRrK5TVsPZJ1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Cp2hRPxJhjF9NOexoZmNx/GWpRhBC+yDM1UFA82eurbC0Bc09JQJodWsVIezswtsnW nVav7zhN5N+rCjvWgGNQ0qrcp7+5YBXY90wYluuIPd36do8UAA08+nCq8uGYnysiLIhu 3kIfGILDB0TpeKiGcPhy/YSZRuH2DTGcxCQ5M= MIME-Version: 1.0 Received: by 10.211.147.10 with SMTP id z10mr1741932ebn.28.1254040382421; Sun, 27 Sep 2009 01:33:02 -0700 (PDT) In-Reply-To: <200909261910.08635.mlobo@digiart.art.br> References: <200909261910.08635.mlobo@digiart.art.br> Date: Sun, 27 Sep 2009 10:33:02 +0200 Message-ID: <3a142e750909270133q63062558tf7bab06006e05953@mail.gmail.com> From: "Paul B. Mahol" To: Mario Lobo Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL (recap) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 08:33:04 -0000 On 9/27/09, Mario Lobo wrote: > Hi to all; > > Recently I've upgraded my home box from FreeBSD 7.2-stable i386 to 8-CURRENT > amd64 (specifically 200906 snapshot)because of a major CPU-BOARD-MEMORY > (Phenon 955-AOD790GX/128M-8G RAM)overhaul. 7.2 stable amd64 wouldn't install > on it (/dev/cd0 disapeared right after sysinstall screen, so no CD/DVD to > install from. Same with all attempts with any previous amd64 revision). So I > figured, what the heck, lets do it! 8-CURRENT intalled fine. > > My box is pretty full of stuff. A lot of the files I have here have been > migrating from version to version of all these OSses along the years, > without > any problem. Please, just try to bear with the fact that I do need to have > all > this, leaving the "why" out of scope and knowing that I DO have backups for > almost all of it. > > I use this box from pro audio productions (winedows) to devel (winedows > (VBox),BSD, & linux (Vbox), to network environment emulation (Vbox), and in- > betweens. > > 2 500G SATA drives and 1 20G ide for XP64 "fun". > > On those sata drives I have: > > SATA1:1 primary FAT32 part, > 1 primary BSD / > 1 EXT -> 3 FAT32, 1 NTFS > 1 primary ext2fs > SATA2:1 primary BSD (5 slices /usr, /apps, /var, /tmp and swap) > 1 EXT -> 3 FAT32, 1 NTFS > > By now you should have a clue as to why I brought this subject back. > > On the first boot, first question: Where were those nice GEOM devices that > so > nicely showed up and held ALL of the above on my previous 7.2-STABLE? > > At first, I found out that sysinstall (label or fdisk, I don't know) did > something to my part table that made everything disappear. I went to the IDE > drive and restored everything with testdisk (nice program !). > > booted BSD. result: > 2 GEOM label mismatch errors (1 for /, 1 for the other SATA2 BSD part) > only 2 FAT32 and 1 NTFS from SATA1 > only 1 FAT32 SATA2 > > Well, back and forth from my XP64 part, googling started (no X yet on 8). > > I tried to manually mount the devices that didn't show up on > /dev/msdosfs,ntsf,ext2fs. Errors. Tried by taking GEOM_PART out of the > picture > and kernel recompile. Didn't even boot. Livecd and loaded geom_part as > modules. Booted back but still no EXT parts. > > After a good while, I picked up this subject, which gave me a clue to what > to > do: > 1)I tried to put "options GEOM_MBR, _BSD & _LABEL" into the kernel. It > wouldn't config. > > 2)I noticed that the modules geom_mbr,geom_bsd and geom_label were present > in > /boot, so I kept the GEOMles kernel and loaded those from loader.conf. > crossed > my fingers and rebooted. > > BANG !! I could not believe my eyes ! EVERY SINGLE PARTITION showed up on my > face, as neatly arranged devices, asking "what are you waiting for?" > > This is just a rough outline of many days of pain and agony. > > Right now, I am typing this e-mail from a fully functional 8-CURRENT/X/KDE > 4.3.1 desktop (yes, BSD IS my desktop), accessing ALL my drives, thanks to > good old GEOM_XXX. > > On one of the subject's thread, I quote Marcel Moolenaar: > >>> 1. What's getting removed and why? >> GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL They're so yesterday. >>> 2. What's it being replaced with? >> GEOM_PART_BSD, GEOM_PART_MBR, GEOM_PART_PC98 and GEOM_PART_VTOC8 >>> 3. How do I migrate from the old system to the new one? >> No migration is needed. You already use the new kernel options. All I'm >> doing is remove the old not-to-be-used options. FYI, -- Marcel Moolenaar" > > Well, # 3 DIDN'T work for me, no matter how hard I tried. GEOM_PART did not > "understand" what I had, while GEOM_ did, on the first attempt ! > > Then I quote John Baldwin, a few e-mails ahead on the thread: > > "I think it is less painful for folks upgrading from 7 to just use the old > names. It is also a lot easier on the eyes. I'm also not sure people are > going > to be changing their partition layout once it is done so having the names > 'change' would not seem to be something that would happen very often at all > in > practice. -- John Baldwin" > > This is my EXACT experience with GEOM, so this e-mail is and absolute plea > to > the developers: > > Please don't take GEOM_XXX away. Folks on the same situation as mine won't > be > able to work if, after one fine csup src and make buildworld/kernel day, > those > geom_xxx.kos are not there !. > > A put myself and my box at your disposal in trying to find out what went > wrong. Meanwhile, please keep them in the source tree. > > My apologies for such a long e-mail, but believe me, I made it as short as I > could. geom_part* is going to be only partitioning interface in future. So you should really forget about geom_bsd and geom_mbr and try all geom_part* modules or if that do not work recreate partitioning table with gpart(8) Older modules are just buggy and provide no additional features. -- Paul From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 08:52:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86250106566B for ; Sun, 27 Sep 2009 08:52:07 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 0EB708FC18 for ; Sun, 27 Sep 2009 08:52:07 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 1AF2A648F; Sun, 27 Sep 2009 10:52:06 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n8R8q3Rn043627; Sun, 27 Sep 2009 10:52:04 +0200 (CEST) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be n8R8q3Rn043627 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1254041525; bh=Nwb4+9tzS4yidRN4EGmC0IJUZhexaXb15dwpPZHenx4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lKMaqnsPV2HZYS+NXizELmGr+3In5jByoDGNYMql6qBSqhMZZH9Xv69KMJjMv0GHH VWuc7KZ+O9kMA3JRUitXg== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be n8R8q3Rn043627 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=S6zeCOIX203W2kRzCcdZx7/c2Ues/CnU5nulhQhqm1F0sHPMQr0N++WTQiy/tQ558 gVYsqNfofOHFxpA+Lovrg== Message-ID: <4ABF27B3.9030507@restart.be> Date: Sun, 27 Sep 2009 10:52:03 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Mario Lobo References: <200909261910.08635.mlobo@digiart.art.br> In-Reply-To: <200909261910.08635.mlobo@digiart.art.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL (recap) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 08:52:07 -0000 Mario Lobo wrote: > Hi to all; > > Recently I've upgraded my home box from FreeBSD 7.2-stable i386 to 8-CURRENT > amd64 (specifically 200906 snapshot)because of a major CPU-BOARD-MEMORY > (Phenon 955-AOD790GX/128M-8G RAM)overhaul. 7.2 stable amd64 wouldn't install > on it (/dev/cd0 disapeared right after sysinstall screen, so no CD/DVD to > install from. Same with all attempts with any previous amd64 revision). So I > figured, what the heck, lets do it! 8-CURRENT intalled fine. > > My box is pretty full of stuff. A lot of the files I have here have been > migrating from version to version of all these OSses along the years, without > any problem. Please, just try to bear with the fact that I do need to have all > this, leaving the "why" out of scope and knowing that I DO have backups for > almost all of it. > > I use this box from pro audio productions (winedows) to devel (winedows > (VBox),BSD, & linux (Vbox), to network environment emulation (Vbox), and in- > betweens. > > 2 500G SATA drives and 1 20G ide for XP64 "fun". > > On those sata drives I have: > > SATA1:1 primary FAT32 part, > 1 primary BSD / > 1 EXT -> 3 FAT32, 1 NTFS > 1 primary ext2fs > SATA2:1 primary BSD (5 slices /usr, /apps, /var, /tmp and swap) > 1 EXT -> 3 FAT32, 1 NTFS > > By now you should have a clue as to why I brought this subject back. > > On the first boot, first question: Where were those nice GEOM devices that so > nicely showed up and held ALL of the above on my previous 7.2-STABLE? > > At first, I found out that sysinstall (label or fdisk, I don't know) did > something to my part table that made everything disappear. I went to the IDE > drive and restored everything with testdisk (nice program !). > > booted BSD. result: > 2 GEOM label mismatch errors (1 for /, 1 for the other SATA2 BSD part) > only 2 FAT32 and 1 NTFS from SATA1 > only 1 FAT32 SATA2 > > Well, back and forth from my XP64 part, googling started (no X yet on 8). > > I tried to manually mount the devices that didn't show up on > /dev/msdosfs,ntsf,ext2fs. Errors. Tried by taking GEOM_PART out of the picture > and kernel recompile. Didn't even boot. Livecd and loaded geom_part as > modules. Booted back but still no EXT parts. > > After a good while, I picked up this subject, which gave me a clue to what to > do: > 1)I tried to put "options GEOM_MBR, _BSD & _LABEL" into the kernel. It > wouldn't config. Maybe it is due to /sys/amd64/conf/DEFAULTS which contains: options GEOM_PART_BSD options GEOM_PART_EBR options GEOM_PART_EBR_COMPAT options GEOM_PART_MBR Henri > > 2)I noticed that the modules geom_mbr,geom_bsd and geom_label were present in > /boot, so I kept the GEOMles kernel and loaded those from loader.conf. crossed > my fingers and rebooted. > > BANG !! I could not believe my eyes ! EVERY SINGLE PARTITION showed up on my > face, as neatly arranged devices, asking "what are you waiting for?" > > This is just a rough outline of many days of pain and agony. > > Right now, I am typing this e-mail from a fully functional 8-CURRENT/X/KDE > 4.3.1 desktop (yes, BSD IS my desktop), accessing ALL my drives, thanks to > good old GEOM_XXX. > > On one of the subject's thread, I quote Marcel Moolenaar: > >>> 1. What's getting removed and why? >> GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL They're so yesterday. >>> 2. What's it being replaced with? >> GEOM_PART_BSD, GEOM_PART_MBR, GEOM_PART_PC98 and GEOM_PART_VTOC8 >>> 3. How do I migrate from the old system to the new one? >> No migration is needed. You already use the new kernel options. All I'm >> doing is remove the old not-to-be-used options. FYI, -- Marcel Moolenaar" > > Well, # 3 DIDN'T work for me, no matter how hard I tried. GEOM_PART did not > "understand" what I had, while GEOM_ did, on the first attempt ! > > Then I quote John Baldwin, a few e-mails ahead on the thread: > > "I think it is less painful for folks upgrading from 7 to just use the old > names. It is also a lot easier on the eyes. I'm also not sure people are going > to be changing their partition layout once it is done so having the names > 'change' would not seem to be something that would happen very often at all in > practice. -- John Baldwin" > > This is my EXACT experience with GEOM, so this e-mail is and absolute plea to > the developers: > > Please don't take GEOM_XXX away. Folks on the same situation as mine won't be > able to work if, after one fine csup src and make buildworld/kernel day, those > geom_xxx.kos are not there !. > > A put myself and my box at your disposal in trying to find out what went > wrong. Meanwhile, please keep them in the source tree. > > My apologies for such a long e-mail, but believe me, I made it as short as I > could. > > Best regards to all, From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 10:11:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03025106566B for ; Sun, 27 Sep 2009 10:11:40 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id BB36A8FC17 for ; Sun, 27 Sep 2009 10:11:39 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5E4D969959; Sun, 27 Sep 2009 10:11:38 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n8RABfLU004807; Sun, 27 Sep 2009 10:11:41 GMT (envelope-from phk@critter.freebsd.dk) To: "Paul B. Mahol" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 27 Sep 2009 10:33:02 +0200." <3a142e750909270133q63062558tf7bab06006e05953@mail.gmail.com> Date: Sun, 27 Sep 2009 10:11:41 +0000 Message-ID: <4806.1254046301@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org, Mario Lobo Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL (recap) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 10:11:40 -0000 In message <3a142e750909270133q63062558tf7bab06006e05953@mail.gmail.com>, "Paul B. Mahol" writes: >geom_part* is going to be only partitioning interface in future. >So you should really forget about geom_bsd and geom_mbr and try all geom_part* >modules or if that do not work recreate partitioning table with gpart(8) I'm pretty certain that Mario has what was until recently a valid disk configuration which geom_part does not support. >Older modules are just buggy and provide no additional features. Apart of course from the historical modes not supported by geom_part and the fact that hot-spot'ing is not supported and so on... Lets stick with the facts, should we ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 10:41:21 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E444A1065698; Sun, 27 Sep 2009 10:41:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C0E378FC15; Sun, 27 Sep 2009 10:41:21 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 763DB46B23; Sun, 27 Sep 2009 06:41:21 -0400 (EDT) Date: Sun, 27 Sep 2009 11:41:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 10:41:22 -0000 Dear all-- Those of you at the Cambridge devsummit are already aware of the port of Apple's Grand Central Dispatch (GCD), a.k.a. libdispatch, to FreeBSD by Stacey Son and I, in collaboration with Apple. I've now uploaded my GCD talk slides to the wiki: http://wiki.freebsd.org/200909DevSummit We now have a devel/libdispatch port, which works out-of-the-box on FreeBSD 9-CURRENT. libdispatch requires modest changes to kqueue, which we will merge to 8.x once the code freeze lifts. As of yesterday, I have libdispatch working with Apple's "Blocks" C languae extension as found in clang, the last major architecture component required to use GCD-based applications FreeBSD. Jordan Hubbard at Apple has kindly provided the necessary bits bundled up in a clang/llvm/compiler-rt package for FreeBSD until the clang port is updated. Some details in the attached e-mail. As I mentioned at the FreeBSD developer summit, this is a work-in-progress (in particular, we don't support pthread work queues, which allow the kernel schedule to get involved in expanding the size of the thread worker pool dynamically), but it should now be more than adequate to use in practice. Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Sat, 26 Sep 2009 20:37:51 +0100 (BST) From: Robert Watson To: libdispatch-dev@lists.macosforge.org Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on FreeBSD Dear all: This is a quick update for those interested in the general portability of libdispatch, and perhaps specifically FreeBSD. With a bit of help from Jordan Hubbard, I now have libdispatch working with Blocks on FreeBSD. Jordan has put up a FreeBSD clang-devel package that includes Blocks parts and the C runtime bits here: http://static.macosforge.org/libdispatch/downloads/clang-devel.tgz I've updated the libdispatch build parts to detect and use Blocks when compiled with clang, and fixed a few nits in libdispatch that I ran into along the way (and one apparent clang bug). With Jordan's package as a starting point, Blocks pretty much "just worked", so I'm optimistic that people will be able to reproduce this on other platforms able to run the non-Blocks libdispatch without much difficulty. If you update to at least r45 of libdispatch, you should now be able to do: CC=clang ./configure --with-blocks-runtime=/usr/local/lib and get a libdispatch with Blocks support. The reason for the configure argument is that the current clang-devel package doesn't automatically add libBlocksRuntime dependency for binaries compiled with -fblocks. Once Blocks support shakes out a bit more in clang/FreeBSD, this should go away. I am able to run basic Blocks-based test tools with GCD on FreeBSD without difficulty. The FreeBSD port should be updated to reflect this shortly. Robert N M Watson Computer Laboratory University of Cambridge _______________________________________________ libdispatch-dev mailing list libdispatch-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 09:43:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6F831065693 for ; Sun, 27 Sep 2009 09:43:52 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 61CA48FC08 for ; Sun, 27 Sep 2009 09:43:51 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1MrqII-00018h-AC>; Sun, 27 Sep 2009 11:43:50 +0200 Received: from e178017133.adsl.alicedsl.de ([85.178.17.133] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1MrqII-0000UL-5a>; Sun, 27 Sep 2009 11:43:50 +0200 Message-ID: <4ABF33D5.2060909@mail.zedat.fu-berlin.de> Date: Sun, 27 Sep 2009 11:43:49 +0200 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Olivier Smedts References: <6A973ECE-83E7-4653-BBE7-CC3093361D19@lassitu.de> <367b2c980909261132n60bd0789s1e3077c8ac6eab0b@mail.gmail.com> In-Reply-To: <367b2c980909261132n60bd0789s1e3077c8ac6eab0b@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 85.178.17.133 X-Mailman-Approved-At: Sun, 27 Sep 2009 11:39:09 +0000 Cc: freebsd-current@freebsd.org, krad , Stefan Bethke , Dmitry Morozovsky Subject: Re: ZFS on entire disks setup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 09:43:53 -0000 Olivier Smedts wrote: > 2009/9/26 krad : >> 2009/9/26 Stefan Bethke >> >>> Am 26.09.2009 um 13:39 schrieb Dmitry Morozovsky: >>> >>> =EF=BF=BDDear colleagues, >>>> is there a way to configure ZFS-only setup without partitions? >>>> >>>> I tried to reproduce the trick with `skip=3D1 seek=3D1024', and have= >>>> loot/loader >>>> running, but it does not see the pool. >>>> >>> This sequence is working for me: >>> dd if=3D/boot/zfsboot of=3D/dev/da0 count=3D1 >>> dd if=3D/boot/zfsboot of=3D/dev/da0 skip=3D1 seek=3D1024 >>> zpool create zroot /dev/da0 >>> zpool set bootfs=3Dzroot zroot >>> cd /usr/src && make installworld installkernel distribution DESTDIR=3D= /zroot >>> cp /boot/loader.conf /zroot/boot/loader.conf >>> cp /etc/rc.conf /zroot/etc/ >>> touch /zroot/etc/fstab >>> echo 'zfs_load=3D"YES"' >>/zroot/boot/loader.conf >>> echo 'vfs.root.mountfrom=3D"zfs:zroot"' >>/zroot/boot/loader.conf >>> zpool export zroot >>> zpool import zroot >>> cp /boot/zfs/zpool.cache /zroot/boot/zfs/ >>> zfs set mountpoint=3Dlegacy zroot >>> >>> ... except that it doesn't anymore. =EF=BF=BDI saw this working about= two months >>> ago, but now it fails to mount root. =EF=BF=BDVerbose boot doesn't gi= ve any >>> indication why ZFS can't find the pool. >>> >>> >>> Stefan >>> >>> -- >>> Stefan Bethke =EF=BF=BD Fon +49 151 14070811 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= =2Eorg" >>> >> >> have the performance issues with zvols been fixed. I remember a while = ago it >> wasn't a good idea to run swap on a zvol. This is why i left a partiti= on >> free for swap >=20 > Still not a good idea, I've got lockups for many minutes when > consuming heavy memory ressources, for example when doing a "make" in > ports/emulators/virtualbox with firefox and amarok opened. I've got > 2GB RAM on amd64. >=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" >> >=20 I see those lockups on three boxes when compiling or having heavy disk I/O on three different boxes, one (private) UP amd64 with 2GB, one SMP 4-core box amd64 with 8 GB and one SMP 8-core box amd64 SMP with 16 GB RAM. It doesn't matter what filesystem is involved, either UFS2 or ZFS! When compiling world AND compiling KDE4-libs or GCC44/GCC45, even those boxes with 8 or 16 GB of RAM and 4 or 8 cores have painful performance issues (locking for several seconds, no response over network or, if enabled and running, X11/mouse gets jumpy and completely inresponsible, quite near useless that moment). I doubt that ZFS causes the problem, it sounds more like a scheduling problem introduced with the early 8.0 (since 7.2 ran fluently on mentioned boxes, but have had other issues). All three boxes under my supervision run FreeBSD 8.0-RC1/amd64 and they all use UFS2-partioned harddrives for OS separated from data drives using ZFS-only. Even copying/backup data from /home on a ZFS volume to another ZFS volume with compression enabled (on another SATA-II drive) does not reveale those issues on the 2GB, UP amd64 box as showed when the box is under heavy load when the GCC compiler is running or PERL scripts are doing their duties. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 11:45:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 204CB1065670 for ; Sun, 27 Sep 2009 11:45:18 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9ECA38FC1C for ; Sun, 27 Sep 2009 11:45:17 +0000 (UTC) Received: by fxm22 with SMTP id 22so3387838fxm.36 for ; Sun, 27 Sep 2009 04:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=6/EoqjZI7WnOOTC8nrmLnks0VaZXCMhKxsjlVGih2G4=; b=iDiUwbtqrZd85SDV/kWpSkq/kyI40SOGDPDIw/TmYKMHjWK1UEFw4tkka/P234qRlL 1UzocPcJXpfucgY2rsUVR3uyBItJRf7E84Z+AKfDwhbIWhm92st/+NHMXTk7HZc1BdKV NwrbcLBc6nXJ7dLEqOyNqh3X4MpHg/wyJ39Yo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TS9uCxiDSMSuaayiLsornA5rxFjzJylxrcS8G9sl19wdLzOroZLLz8NChLHnvvT3rQ 5g10BuoIzTiCgfTDAPT+Ytkv6lI+d6RCRqqKg7SYCPzTCl+T1vMduxgY5IgGLg4diPDM fTjotNjdZuG6RUKvool3f5S6j3Eaz6QkW0IgI= MIME-Version: 1.0 Received: by 10.239.168.138 with SMTP id k10mr210432hbe.100.1254051916408; Sun, 27 Sep 2009 04:45:16 -0700 (PDT) Date: Sun, 27 Sep 2009 12:45:16 +0100 Message-ID: From: krad To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: make world on a zfs system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 11:45:18 -0000 HI, I have a pure zfs system at home, and was interested in how most others are implementing theirs with regard to the os installation. Most of the guides I have seen have a zpool eg system made up of mirrored/raided vdevs, but they usually install the os on the root zfs fs for that pool, and have that in loader.conf eg vfs.root.mountfrom="zfs:system" I have done this slightly differently on my system. I initially installed onto /system/root. Therefore my loader.conf has the following line vfs.root.mountfrom="zfs:system/root" Nothing special there. However this next bit is the cool bit. Next time i want to upgrade the os i do one of the following zfs snapshot system/root@20090926 # if i want speed zfs clone system/root@20090926 system/root_20090926 # or better way but a bit slower (2-3 mins) zfs send system/root@20090926 | zfs receive system/root_20090926 I tend to use the send and receive, as disk space isn't really an issue and I dont like having the dependency that you clones as it makes it more complicated to delete old file systems. Now lets install the new os zfs set mountpoint=legacy system/root_20090926 mount -t zfs system/root_20090926 /mnt sed -i -e "system\/root\"/system\/root_20090926\"/" /mnt/boot/loader.conf export DESTDIR=/mnt cd /usr/src make installkernel && make installworld zpool set bootfs=system/root_20090926 system mergmaster init 6 The system will now boot onto the new filesystem. If there is a problem I can just boot in with my rescue usb stick and flip the bootfs flag back and bang im back in the old os. Why not just use snapshots I hear you say. Well if I roll back the os I have lost the new stuff I have installed. This is ok in terms of getting the os back up. However in terms of getting the new installation fixed this isn't much help. This way I can flip flop back and two between the installations. This could be ideal for people who want to have a quick look at current every now and again. It would be really cool if this type of thing could get integrated into the make world scripts. Before anyone points out I did steal this idea from opensolaris. Ideally I need to do is see if I can get something built into beastie, to choose the bootfs for the pool. I'm not sure this is viable, as once you have started to load the loader, you must have chosen the bootfs. Has anyone looked at this already and can they offer any advice? From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 12:01:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF9BE1065676 for ; Sun, 27 Sep 2009 12:01:09 +0000 (UTC) (envelope-from edhoprima@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id C5AF98FC22 for ; Sun, 27 Sep 2009 12:01:09 +0000 (UTC) Received: by pzk40 with SMTP id 40so1787229pzk.7 for ; Sun, 27 Sep 2009 05:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Pj9bGArjxZ/1Mf//6TV1BjfNvWj/q9HkqNZk4AHta8M=; b=a3KU+kqpH+x6sl5u+VoceOCSvXemDVIDgxwxxQtbS16eH8uj0z56mfJr26YoevDh3D CW0MKsNYaal1UTyVSgkynwz2wSN2ebWGSuQOG2f7qbAgylAVSLb2hOEZgdl3g7irTenT Yqi0qkUS6XOl4FYGgMFc/oV/+1zTBwiW5Yhkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XtcixAbfeXZCRh6B/loqhzu2TPz6FH+8VnXNOjEcIjAjHFTvEbirsV2U2GcIwRULP4 UyUUKMDxfUI6UY804iM4kepOVbpG2B75Zm92tTTG8IIQZZc9z+iikGPWtIhjR0ItzRr1 S68TBePa5kKHd29dwUSMtIOZULgjEgfR4Yzy4= MIME-Version: 1.0 Received: by 10.142.2.34 with SMTP id 34mr163437wfb.143.1254052869346; Sun, 27 Sep 2009 05:01:09 -0700 (PDT) In-Reply-To: References: Date: Sun, 27 Sep 2009 19:01:09 +0700 Message-ID: From: Edho P Arief To: krad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: make world on a zfs system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 12:01:10 -0000 On Sun, Sep 27, 2009 at 6:45 PM, krad wrote: > HI, > > I have a pure zfs system at home, and was interested in how most others a= re > implementing theirs with regard to the os installation. > > Most of the guides I have seen have a zpool eg system made up of > mirrored/raided vdevs, but they usually install the os on the root zfs fs > for that pool, and have that in loader.conf > > eg > > vfs.root.mountfrom=3D"zfs:system" > > I have done this slightly differently on my system. I initially installed > onto /system/root. Therefore my loader.conf has the following line > > vfs.root.mountfrom=3D"zfs:system/root" > > Nothing special there. However this next bit is the cool bit. > > Next time i want to upgrade the os i do one of the following > > > zfs snapshot system/root@20090926 > > # if i want speed > zfs clone system/root@20090926 system/root_20090926 > > # =C2=A0or better way but a bit slower (2-3 mins) > zfs send system/root@20090926 | zfs receive system/root_20090926 > > I tend to use the send and receive, as disk space isn't really an issue a= nd > I dont like having the dependency that you clones as it makes it more > complicated to delete old file systems. > > Now lets install the new os > > > zfs set mountpoint=3Dlegacy system/root_20090926 > mount -t zfs system/root_20090926 /mnt > sed -i -e "system\/root\"/system\/root_20090926\"/" /mnt/boot/loader.conf > export DESTDIR=3D/mnt > cd /usr/src > make installkernel && make installworld > zpool set bootfs=3Dsystem/root_20090926 system > mergmaster > init 6 > > The system will now boot onto the new filesystem. If there is a problem I > can just boot in with my rescue usb stick and flip the bootfs flag back a= nd > bang im back in the old os. > > Why not just use snapshots I hear you say. Well if I roll back the os I h= ave > lost the new stuff I have installed. This is ok in terms of getting the o= s > back up. However in terms of getting the new installation fixed this isn'= t > much help. This way I can flip flop back and two between the installation= s. > This could be ideal for people who want to have a quick look at current > every now and again. It would be really cool if this type of thing could = get > integrated into the make world scripts. > > Before anyone points out I did steal this idea from opensolaris. > > Ideally =C2=A0I need to do is see if I can get something built into beast= ie, to > choose the bootfs for the pool. I'm not sure this is viable, as once you > have started to load the loader, you must have chosen the bootfs. Has any= one > looked at this already and can they offer any advice? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > I've done this before - but instead of make installword I did 'freebsd-update upgrade -r ' instead by chrooting to the new root environment. --=20 O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 12:18:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60051106568D; Sun, 27 Sep 2009 12:18:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 303548FC13; Sun, 27 Sep 2009 12:18:03 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA14452; Sun, 27 Sep 2009 15:18:01 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1MrshU-0004h6-Sv; Sun, 27 Sep 2009 15:18:01 +0300 Message-ID: <4ABF57F5.1050106@icyb.net.ua> Date: Sun, 27 Sep 2009 15:17:57 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090823) MIME-Version: 1.0 To: Hans Petter Selasky References: <4ABA36B1.9070706@icyb.net.ua> <200909241651.47850.hselasky@c2i.net> <4ABC646D.4070604@icyb.net.ua> <200909250928.51515.hselasky@c2i.net> In-Reply-To: <200909250928.51515.hselasky@c2i.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 12:18:05 -0000 on 25/09/2009 10:28 Hans Petter Selasky said the following: > On Friday 25 September 2009 08:34:21 Andriy Gapon wrote: >> Not sure how to interpret this. > > In ohci_controller_init() try to disable the > > DPRINTF("SMM active, request owner change\n"); > > part of the code for !(ohci_unit == 0) or (ohci_unit == 2) and see what > happens. > > Your clue might also indicate that we should request owner change for all > OHCI's before resetting any of them. Possibly a BIOS bug! Haven't tried the suggested changes yet, but here is some more info. This is register dump of ohci0 just _before_ we start doing anything with it: ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: [ITHREAD] ohci_dumpregs:567: ohci_dumpregs: rev=0x00000110 control=0x00000184 command=0x00000000 ohci_dumpregs:571: intrstat=0x00000024 intre=0xc0000042 intrd=0xc0000042 ohci_dumpregs:575: hcca=0xbfdf1f00 percur=0x00000000 ctrlhd=0xbfdf1c50 ohci_dumpregs:579: ctrlcur=0x00000000 bulkhd=0x00000000 bulkcur=0x00000000 ohci_dumpregs:583: done=0xbfdf1ca0 fmival=0x27782edf fmrem=0x000009bd ohci_dumpregs:587: fmnum=0x00008e3a perst=0x00002a27 lsthrs=0x00000628 ohci_dumpregs:591: desca=0x02000b03 descb=0x00000000 stat=0x00000000 ohci_dumpregs:594: port1=0x00000303 port2=0x00000100 ohci_dumpregs:600: HCCA: frame_number=0x0000 done_head=0x00000000 This is dump just after we programmed it: ohci_controller_init:308: rewrite head regs ohci_dumpregs:567: ohci_dumpregs: rev=0x00000110 control=0x000000af command=0x00000000 ohci_dumpregs:571: intrstat=0x00000044 intre=0x8000005a intrd=0x8000005a ohci_dumpregs:575: hcca=0x06647000 percur=0x00000000 ctrlhd=0x06692000 ohci_dumpregs:579: ctrlcur=0x00000000 bulkhd=0x06693000 bulkcur=0x00000000 ohci_dumpregs:583: done=0x00000000 fmival=0xa7782edf fmrem=0x80001096 ohci_dumpregs:587: fmnum=0x0000000d perst=0x00002a2f lsthrs=0x00000628 ohci_dumpregs:591: desca=0x02000b03 descb=0x00000000 stat=0x00000000 ohci_dumpregs:594: port1=0x00010301 port2=0x00000100 ohci_dumpregs:600: HCCA: frame_number=0x000e done_head=0x00000000 This is dump of ohci0 registers just before we run takeover code of ohci1: ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: [ITHREAD] ohci_controller_init:185: reread ohci0 regs: ohci_dumpregs:567: ohci_dumpregs: rev=0x00000110 control=0x000000af command=0x00000000 ohci_dumpregs:571: intrstat=0x00000044 intre=0x8000005a intrd=0x8000005a ohci_dumpregs:575: hcca=0x06647000 percur=0x00000000 ctrlhd=0x06692000 ohci_dumpregs:579: ctrlcur=0x00000000 bulkhd=0x06693000 bulkcur=0x00000000 ohci_dumpregs:583: done=0x00000000 fmival=0xa7782edf fmrem=0x800003b5 ohci_dumpregs:587: fmnum=0x00000012 perst=0x00002a2f lsthrs=0x00000628 ohci_dumpregs:591: desca=0x02000b03 descb=0x00000000 stat=0x00000000 ohci_dumpregs:594: port1=0x00010301 port2=0x00000100 ohci_dumpregs:600: HCCA: frame_number=0x0012 done_head=0x00000000 And this is dump of ohci0 right after we've taken over ohci1: ohci_controller_init:195: SMM active, request owner change ohci_controller_init:219: usbus1: resetting ohci_controller_init:246: reread ohci0 regs: ohci_dumpregs:567: ohci_dumpregs: rev=0x00000110 control=0x000000af command=0x00000000 ohci_dumpregs:571: intrstat=0x00000004 intre=0x8000005a intrd=0x8000005a ohci_dumpregs:575: hcca=0x06647000 percur=0x00000000 ctrlhd=0xbfdf1c50 ohci_dumpregs:579: ctrlcur=0x00000000 bulkhd=0x06693000 bulkcur=0x00000000 ohci_dumpregs:583: done=0xbfdf1ca0 fmival=0xa7782edf fmrem=0x80002122 ohci_dumpregs:587: fmnum=0x00000192 perst=0x00002a2f lsthrs=0x00000628 ohci_dumpregs:591: desca=0x02000b03 descb=0x00000000 stat=0x00000000 ohci_dumpregs:594: port1=0x00000303 port2=0x00000100 ohci_dumpregs:600: HCCA: frame_number=0x0192 done_head=0x00000000 As you can see, indeed, the register gets over-written right when we take over ohci1. Some additional observations: 1. frame_number seems to grow quite a lot for ohci0 2. before we touch ohci0 it has port1=0x00000303, after reset port1=0x00010301, after ohci1 takeover port1=0x00000303 again. I'd say that this is a pretty strong evidence that BIOS does something to ohci0 after we took over it and while we are taking over ohci1. Another idea of working around this: 1) in pci fixup code disable USB SMI for these chipsets 2) (optional) in ohci code skip takeover step Sounds messy. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 12:21:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 960D4106566B; Sun, 27 Sep 2009 12:21:18 +0000 (UTC) (envelope-from nyan@jp.FreeBSD.org) Received: from sakura.ccs.furiru.org (sakura.ccs.furiru.org [IPv6:2001:2f0:104:8060::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2B30E8FC0A; Sun, 27 Sep 2009 12:21:17 +0000 (UTC) Received: from localhost (authenticated bits=0) by sakura.ccs.furiru.org (unknown) with ESMTP id n8RCLD8b055342; Sun, 27 Sep 2009 21:21:16 +0900 (JST) (envelope-from nyan@jp.FreeBSD.org) Date: Sun, 27 Sep 2009 21:20:32 +0900 (JST) Message-Id: <20090927.212032.94955070.nyan@jp.FreeBSD.org> To: dfr@FreeBSD.org From: Takahashi Yoshihiro X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Sep_27_21_20_32_2009_191)--" Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: nfslockd module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 12:21:18 -0000 ----Next_Part(Sun_Sep_27_21_20_32_2009_191)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit The nfslockd module does not work for NFS client, since NFSCLIENT is not defined in sys/modules/nfslockd/Makefile. I attach a patch for sys/modules/nfslockd/Makefile to fix this problem. If it's no problem, I'll commit it. --- TAKAHASHI Yoshihiro ----Next_Part(Sun_Sep_27_21_20_32_2009_191)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="a.diff" Index: Makefile =================================================================== --- Makefile (revision 197373) +++ Makefile (working copy) @@ -14,11 +14,18 @@ SRCS+= opt_inet6.h opt_nfs.h .if !defined(KERNBUILDDIR) NFS_INET6?= 1 # 0/1 - requires INET6 to be configured in kernel +NFSCLIENT?= 1 # 0/1 - requires NFSCLIENT to be configured in kernel .if ${NFS_INET6} > 0 opt_inet6.h: echo "#define INET6 1" > ${.TARGET} .endif + +.if ${NFSCLIENT} > 0 +opt_nfs.h: + echo "#define NFSCLIENT 1" > ${.TARGET} .endif +.endif + .include ----Next_Part(Sun_Sep_27_21_20_32_2009_191)---- From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 13:10:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE6DE10656A4; Sun, 27 Sep 2009 13:10:28 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B4E8D8FC1F; Sun, 27 Sep 2009 13:10:27 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA14924; Sun, 27 Sep 2009 16:10:25 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1MrtWC-0004l8-OQ; Sun, 27 Sep 2009 16:10:24 +0300 Message-ID: <4ABF643D.1080705@freebsd.org> Date: Sun, 27 Sep 2009 16:10:21 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090823) MIME-Version: 1.0 To: Hans Petter Selasky References: <4ABA36B1.9070706@icyb.net.ua> <200909241651.47850.hselasky@c2i.net> <4ABC646D.4070604@icyb.net.ua> <200909250928.51515.hselasky@c2i.net> <4ABF57F5.1050106@icyb.net.ua> In-Reply-To: <4ABF57F5.1050106@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 13:10:29 -0000 on 27/09/2009 15:17 Andriy Gapon said the following: > Another idea of working around this: > 1) in pci fixup code disable USB SMI for these chipsets > 2) (optional) in ohci code skip takeover step > Sounds messy. BTW, just for the sake of experiment I did exactly what I suggested. I've got the following messages: kernel: ohci_controller_init:195: SMM active, request owner change kernel: usbus0: SMM does not respond, resetting kernel: ohci_controller_init:195: SMM active, request owner change kernel: usbus1: SMM does not respond, resetting kernel: ohci_controller_init:195: SMM active, request owner change kernel: usbus3: SMM does not respond, resetting kernel: ohci_controller_init:195: SMM active, request owner change kernel: usbus4: SMM does not respond, resetting kernel: ohci_controller_init:195: SMM active, request owner change kernel: usbus6: SMM does not respond, resetting And the register value stayed intact after initial programming, so no re-programming was needed. Here is the (dirty) hack: diff --git a/sys/dev/pci/fixup_pci.c b/sys/dev/pci/fixup_pci.c index 566e503..1463c24 100644 --- a/sys/dev/pci/fixup_pci.c +++ b/sys/dev/pci/fixup_pci.c @@ -53,6 +53,7 @@ static int fixup_pci_probe(device_t dev); static void fixwsc_natoma(device_t dev); static void fixc1_nforce2(device_t dev); static void fixrtc_piix4(device_t dev); +static void fixsmi_usb(device_t dev); static device_method_t fixup_pci_methods[] = { /* Device interface */ @@ -84,6 +85,9 @@ fixup_pci_probe(device_t dev) case 0x01e010de: /* nVidia nForce2 */ fixc1_nforce2(dev); break; + case 0x96001022: /* AMD SB700 */ + fixsmi_usb(dev); + break; } return(ENXIO); } @@ -124,6 +128,21 @@ } +/* Disable USB SMI */ +static void +fixsmi_usb(device_t dev) +{ + uint32_t features; + + dev = pci_find_device(0x1002, 0x4385); + features = pci_read_config(dev, 0x64, 4); + if (features & (1 << 15)) { + printf("Disabling USB SMI on SB7xx\n"); + features &= ~(1 << 15); + pci_write_config(dev, 0x64, features, 4); + } +} + /* * Set the SYSTEM_IDLE_TIMEOUT to 80 ns on nForce2 systems to work * around a hang that is triggered when the CPU generates a very fast -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 13:58:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19EBD1065672; Sun, 27 Sep 2009 13:58:30 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E71608FC23; Sun, 27 Sep 2009 13:58:28 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA15422; Sun, 27 Sep 2009 16:58:26 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1MruGg-0004p1-KL; Sun, 27 Sep 2009 16:58:26 +0300 Message-ID: <4ABF6F7F.4050101@freebsd.org> Date: Sun, 27 Sep 2009 16:58:23 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090823) MIME-Version: 1.0 To: Hans Petter Selasky References: <4ABA36B1.9070706@icyb.net.ua> <200909241651.47850.hselasky@c2i.net> <4ABC646D.4070604@icyb.net.ua> <200909250928.51515.hselasky@c2i.net> <4ABF57F5.1050106@icyb.net.ua> <4ABF643D.1080705@freebsd.org> In-Reply-To: <4ABF643D.1080705@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 13:58:30 -0000 on 27/09/2009 16:10 Andriy Gapon said the following: > kernel: ohci_controller_init:195: SMM active, request owner change > kernel: usbus0: SMM does not respond, resetting > kernel: ohci_controller_init:195: SMM active, request owner change > kernel: usbus1: SMM does not respond, resetting > kernel: ohci_controller_init:195: SMM active, request owner change > kernel: usbus3: SMM does not respond, resetting > kernel: ohci_controller_init:195: SMM active, request owner change > kernel: usbus4: SMM does not respond, resetting > kernel: ohci_controller_init:195: SMM active, request owner change > kernel: usbus6: SMM does not respond, resetting > > And the register value stayed intact after initial programming, so no > re-programming was needed. I think that I didn't finished what I was saying. I think that now we can be very sure what is the culprit here. Now we need to find the best strategy to work around the problem. (Of course, it would be just the second best with the best being fixing SMM code, but that's beyond our control). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 14:44:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EEA41065696; Sun, 27 Sep 2009 14:44:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B124E8FC21; Sun, 27 Sep 2009 14:44:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n8REiY6l036218; Sun, 27 Sep 2009 10:44:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n8REiYc4036212; Sun, 27 Sep 2009 14:44:34 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 27 Sep 2009 14:44:34 GMT Message-Id: <200909271444.n8REiYc4036212@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 14:44:36 -0000 TB --- 2009-09-27 14:29:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-27 14:29:29 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-09-27 14:29:29 - cleaning the object tree TB --- 2009-09-27 14:30:58 - cvsupping the source tree TB --- 2009-09-27 14:30:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-09-27 14:31:27 - building world TB --- 2009-09-27 14:31:27 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-27 14:31:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-27 14:31:27 - TARGET=sparc64 TB --- 2009-09-27 14:31:27 - TARGET_ARCH=sparc64 TB --- 2009-09-27 14:31:27 - TZ=UTC TB --- 2009-09-27 14:31:27 - __MAKE_CONF=/dev/null TB --- 2009-09-27 14:31:27 - cd /src TB --- 2009-09-27 14:31:27 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 27 14:31:28 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] sh /src/tools/install.sh -o root -g wheel -m 444 ca_ES.ISO8859-1.cat /obj/sparc64/src/tmp/usr/share/nls/ca_ES.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 de_DE.ISO8859-1.cat /obj/sparc64/src/tmp/usr/share/nls/de_DE.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 el_GR.ISO8859-7.cat /obj/sparc64/src/tmp/usr/share/nls/el_GR.ISO8859-7/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 es_ES.ISO8859-1.cat /obj/sparc64/src/tmp/usr/share/nls/es_ES.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 fi_FI.ISO8859-1.cat /obj/sparc64/src/tmp/usr/share/nls/fi_FI.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 fr_FR.ISO8859-1.cat /obj/sparc64/src/tmp/usr/share/nls/fr_FR.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 gl_ES.ISO8859-1.cat /obj/sparc64/src/tmp/usr/share/nls/gl_ES.ISO8859-1/libc.cat install: /obj/sparc64/src/tmp/usr/share/nls/gl_ES.ISO8859-1/libc.cat: No such file or directory *** Error code 71 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-27 14:44:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-27 14:44:34 - ERROR: failed to build world TB --- 2009-09-27 14:44:34 - 461.69 user 102.77 system 905.10 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 14:56:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA796106566B; Sun, 27 Sep 2009 14:56:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 585A58FC13; Sun, 27 Sep 2009 14:56:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n8REumkL099322; Sun, 27 Sep 2009 10:56:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n8REumnf099303; Sun, 27 Sep 2009 14:56:48 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 27 Sep 2009 14:56:48 GMT Message-Id: <200909271456.n8REumnf099303@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 14:56:49 -0000 TB --- 2009-09-27 14:43:59 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-27 14:43:59 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-09-27 14:43:59 - cleaning the object tree TB --- 2009-09-27 14:45:10 - cvsupping the source tree TB --- 2009-09-27 14:45:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-09-27 14:45:40 - building world TB --- 2009-09-27 14:45:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-27 14:45:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-27 14:45:40 - TARGET=sun4v TB --- 2009-09-27 14:45:40 - TARGET_ARCH=sparc64 TB --- 2009-09-27 14:45:40 - TZ=UTC TB --- 2009-09-27 14:45:40 - __MAKE_CONF=/dev/null TB --- 2009-09-27 14:45:40 - cd /src TB --- 2009-09-27 14:45:40 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 27 14:45:40 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] sh /src/tools/install.sh -o root -g wheel -m 444 ca_ES.ISO8859-1.cat /obj/sun4v/src/tmp/usr/share/nls/ca_ES.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 de_DE.ISO8859-1.cat /obj/sun4v/src/tmp/usr/share/nls/de_DE.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 el_GR.ISO8859-7.cat /obj/sun4v/src/tmp/usr/share/nls/el_GR.ISO8859-7/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 es_ES.ISO8859-1.cat /obj/sun4v/src/tmp/usr/share/nls/es_ES.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 fi_FI.ISO8859-1.cat /obj/sun4v/src/tmp/usr/share/nls/fi_FI.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 fr_FR.ISO8859-1.cat /obj/sun4v/src/tmp/usr/share/nls/fr_FR.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 gl_ES.ISO8859-1.cat /obj/sun4v/src/tmp/usr/share/nls/gl_ES.ISO8859-1/libc.cat install: /obj/sun4v/src/tmp/usr/share/nls/gl_ES.ISO8859-1/libc.cat: No such file or directory *** Error code 71 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-27 14:56:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-27 14:56:48 - ERROR: failed to build world TB --- 2009-09-27 14:56:48 - 456.25 user 98.91 system 768.94 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 15:02:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CA4C106566C for ; Sun, 27 Sep 2009 15:02:35 +0000 (UTC) (envelope-from simon@nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.freebsd.org (Postfix) with ESMTP id 0A84D8FC15 for ; Sun, 27 Sep 2009 15:02:35 +0000 (UTC) Received: from arthur.nitro.dk (arthur.bofh [192.168.2.3]) by mx.nitro.dk (Postfix) with ESMTP id 5B2202D4893 for ; Sun, 27 Sep 2009 15:02:34 +0000 (UTC) Received: by arthur.nitro.dk (Postfix, from userid 1000) id 496835C05; Sun, 27 Sep 2009 17:02:34 +0200 (CEST) Date: Sun, 27 Sep 2009 17:02:34 +0200 From: "Simon L. Nielsen" To: freebsd-current@freebsd.org Message-ID: <20090927150233.GH1495@arthur.nitro.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: mmap zero mapping disallowed (Re: svn commit: r197537 - head/sys/vm]) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 15:02:35 -0000 Hey, As mentioned in the commit message FreeBSD 9 / head now does not allow mmap'ing at zero by default, and this may break some apps. If anyone encounters applications which break because of this change, please let report it so we can see if it can be fixed. It might not be possible to fix some applications, but we at least would know which applications might need a special note in the documentation. ----- Forwarded message from "Simon L. Nielsen" ----- Date: Sun, 27 Sep 2009 14:49:51 +0000 (UTC) From: "Simon L. Nielsen" To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r197537 - head/sys/vm Author: simon Date: Sun Sep 27 14:49:51 2009 New Revision: 197537 URL: http://svn.freebsd.org/changeset/base/197537 Log: Do not allow mmap with the MAP_FIXED argument to map at address zero. This is done to make it harder to exploit kernel NULL pointer security vulnerabilities. While this of course does not fix vulnerabilities, it does mitigate their impact. Note that this may break some applications, most likely emulators or similar, which for one reason or another require mapping memory at zero. This restriction can be disabled with the security.bsd.mmap_zero sysctl variable. Discussed with: rwatson, bz Tested by: bz (Wine), simon (VirtualBox) Submitted by: jhb Modified: head/sys/vm/vm_mmap.c [...] ----- End forwarded message ----- -- Simon L. Nielsen Hat: FreeBSD Security Team From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 15:11:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C8B01065670 for ; Sun, 27 Sep 2009 15:11:50 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay2.uni-muenster.de (ZIVM-EXRELAY2.UNI-MUENSTER.DE [128.176.192.15]) by mx1.freebsd.org (Postfix) with ESMTP id 93BC68FC14 for ; Sun, 27 Sep 2009 15:11:48 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,461,1249250400"; d="scan'208";a="224766725" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 27 Sep 2009 17:11:35 +0200 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 6DC2A1B0750; Sun, 27 Sep 2009 17:11:35 +0200 (CEST) Date: Sun, 27 Sep 2009 17:11:35 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: ipv6 related warnings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 15:11:50 -0000 hi there, i'm getting these warnings running -current (r197533, i386 with world/kernel in sync): Additional TCP/IP options: rfc1323 extensions=NO no-ipv4-mapped-ipv6 sysctl: unknown oid 'net.inet6.ip6.v6only' and add net default: gateway 192.168.1.1 route: bad keyword: inet6 usage: route [-dnqtv] command [[modifiers] args] route: bad keyword: inet6 usage: route [-dnqtv] command [[modifiers] args] route: bad keyword: inet6 usage: route [-dnqtv] command [[modifiers] args] route: bad keyword: inet6 usage: route [-dnqtv] command [[modifiers] args] cheers. alex ps: i have WITHOUT_INET6=true in my /etc/src.conf From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 16:00:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0B69106566B for ; Sun, 27 Sep 2009 16:00:49 +0000 (UTC) (envelope-from mlobo@digiart.art.br) Received: from sv4.hmnoc.net (sv4.hmnoc.net [63.247.76.174]) by mx1.freebsd.org (Postfix) with ESMTP id 7B0CC8FC13 for ; Sun, 27 Sep 2009 16:00:49 +0000 (UTC) Received: from [187.78.189.90] (port=61932 helo=papi.localnet) by sv4.hmnoc.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MrwB6-0001Vl-Hs; Sun, 27 Sep 2009 13:00:48 -0300 From: Mario Lobo To: freebsd-current@freebsd.org Date: Sun, 27 Sep 2009 13:01:53 -0300 User-Agent: KMail/1.12.1 (FreeBSD/8.0-RC1; KDE/4.3.1; amd64; ; ) References: <200909261910.08635.mlobo@digiart.art.br> <4ABF27B3.9030507@restart.be> In-Reply-To: <4ABF27B3.9030507@restart.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909271301.53931.mlobo@digiart.art.br> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sv4.hmnoc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - digiart.art.br Cc: Henri Hennebert Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL (recap) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 16:00:49 -0000 On Sunday 27 September 2009 05:52:03 Henri Hennebert wrote: > > Maybe it is due to /sys/amd64/conf/DEFAULTS > > which contains: > > options GEOM_PART_BSD > options GEOM_PART_EBR > options GEOM_PART_EBR_COMPAT > options GEOM_PART_MBR > > Henri Not the case. I saw those and commented them out. What happened was that the Config program did not accept none of the "options GEOM_XXX", calling them "unknown". -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winedows FREE) From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 16:04:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FEB0106566C for ; Sun, 27 Sep 2009 16:04:34 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3C78FC20 for ; Sun, 27 Sep 2009 16:04:34 +0000 (UTC) Received: by gxk6 with SMTP id 6so1841555gxk.13 for ; Sun, 27 Sep 2009 09:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=Azf/QcUJckpfxLpCOGhaPfbx8nrAkIs7fBha3XEyr9s=; b=nGOg03OQpUzFbXavLelV78QKBFHljAURa3xGf64uYLjWtiXVXOWj9F6ey3Yaw9zmR6 5MSvtjIIJEkCk6+2wpeuG6eFL1OAWvArvLjqTO6kofJC0uEWLUlfJG1lFgFy6UW2UZ7X ZQI+8TNgy3QGg+3iZP0A4UIV66h0vIhCEs25w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Rk8VsVYEDNUKnyvCg4U3JUmlhloVndSoVaHEu558knfGvnPSbL4Kw9Ml1gYX52h1xb DwZ0wqmqcHEAWkisLUZ9HIzEgrnpr3CSi8O5145/uuENhY2Cv3Mw18EozF4qaSZME6xT QfX5UdTvMn8mnyt+TJHLVxvciLWQHD5A1ORbY= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.90.127.20 with SMTP id z20mr2277986agc.118.1254067473259; Sun, 27 Sep 2009 09:04:33 -0700 (PDT) In-Reply-To: References: Date: Sun, 27 Sep 2009 09:04:33 -0700 X-Google-Sender-Auth: 69c0fd5dde21eded Message-ID: From: Artem Belevich To: krad Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: make world on a zfs system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 16:04:34 -0000 Hi, On Sun, Sep 27, 2009 at 4:45 AM, krad wrote: > I have a pure zfs system at home, and was interested in how most others are > implementing theirs with regard to the os installation. Philipp Wuensche wrote a script to manage Solaris-like boot environment: http://lists.freebsd.org/pipermail/freebsd-current/2009-January/002789.html http://anonsvn.h3q.com/projects/freebsd-patches/browser/manageBE --Artem From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 16:35:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4F91106568B; Sun, 27 Sep 2009 16:35:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8F5B78FC18; Sun, 27 Sep 2009 16:35:21 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 1864B46B03; Sun, 27 Sep 2009 12:35:21 -0400 (EDT) Date: Sun, 27 Sep 2009 17:35:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Simon L. Nielsen" In-Reply-To: <20090927150233.GH1495@arthur.nitro.dk> Message-ID: References: <20090927150233.GH1495@arthur.nitro.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: mmap zero mapping disallowed (Re: svn commit: r197537 - head/sys/vm]) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 16:35:21 -0000 On Sun, 27 Sep 2009, Simon L. Nielsen wrote: > As mentioned in the commit message FreeBSD 9 / head now does not allow > mmap'ing at zero by default, and this may break some apps. > > If anyone encounters applications which break because of this change, please > let report it so we can see if it can be fixed. It might not be possible to > fix some applications, but we at least would know which applications might > need a special note in the documentation. There are probably some other ways to arrange mappings at 0x0, so we'll need to dig through the system to identify them. To mind, the various executable image activators are interesting (elf, a.out, etc), but we should check other things that call VM insertion routines -- things like the more interesting 3D device drivers. At the end of the day, this is a mitigation technique, so if there are edge case non-default compiled copmonents, etc, that's fine, but it would be nice to be thorough where we can. While our automatic address selection code ever pick 0x0 as a mapping address, btw? Robert N M Watson Computer Laboratory University of Cambridge > > ----- Forwarded message from "Simon L. Nielsen" ----- > > Date: Sun, 27 Sep 2009 14:49:51 +0000 (UTC) > From: "Simon L. Nielsen" > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > svn-src-head@freebsd.org > Subject: svn commit: r197537 - head/sys/vm > > Author: simon > Date: Sun Sep 27 14:49:51 2009 > New Revision: 197537 > URL: http://svn.freebsd.org/changeset/base/197537 > > Log: > Do not allow mmap with the MAP_FIXED argument to map at address zero. > This is done to make it harder to exploit kernel NULL pointer security > vulnerabilities. While this of course does not fix vulnerabilities, > it does mitigate their impact. > > Note that this may break some applications, most likely emulators or > similar, which for one reason or another require mapping memory at > zero. > > This restriction can be disabled with the security.bsd.mmap_zero > sysctl variable. > > Discussed with: rwatson, bz > Tested by: bz (Wine), simon (VirtualBox) > Submitted by: jhb > > Modified: > head/sys/vm/vm_mmap.c > > [...] > > ----- End forwarded message ----- > > -- > Simon L. Nielsen > Hat: FreeBSD Security Team > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 17:50:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40BA5106568F; Sun, 27 Sep 2009 17:50:15 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 986158FC1E; Sun, 27 Sep 2009 17:50:14 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=7H_uI1Jp-TAA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=I8vkOwftpKyv8B4xJjkA:9 a=7aerLU9yPSJS8G4woOYcLmZ0aGgA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1309035787; Sun, 27 Sep 2009 19:50:12 +0200 Received-SPF: softfail receiver=mailfe04.swip.net; client-ip=188.126.201.140; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sun, 27 Sep 2009 19:50:54 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200909251909.31503.hselasky@freebsd.org> <4ABD4EDF.4040807@acm.poly.edu> <4ABE2B4F.6080104@tomjudge.com> In-Reply-To: <4ABE2B4F.6080104@tomjudge.com> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909271950.55189.hselasky@freebsd.org> Cc: Tom Judge , freebsd-current@freebsd.org Subject: Re: Polling support for USB serial port adapters [patches] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 17:50:15 -0000 Hi, Here is a patchset which you can try. http://perforce.freebsd.org/chv.cgi?CH=168932 You need to download at least: usb_serial.h and usb_serial.c Download serial port drivers as needed. You need to at least recompile all USB serial modules. To enable you set: hw.usb.ucom.cons_unit=0 hw.usb.ucom.cons_baud=9600 In /boot/loader.conf NOTE: The patches have not been tested yet, only carefully reviewed. If you experience any problems, please debug and send patch to me. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 18:58:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 156CE106566B for ; Sun, 27 Sep 2009 18:58:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outd.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id F05C68FC18 for ; Sun, 27 Sep 2009 18:58:22 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 7EB71CEA2E; Sun, 27 Sep 2009 11:58:41 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 4233B2D6013; Sun, 27 Sep 2009 11:58:22 -0700 (PDT) Message-ID: <4ABFB5D1.4010408@elischer.org> Date: Sun, 27 Sep 2009 11:58:25 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Robert Watson References: <20090927150233.GH1495@arthur.nitro.dk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, "Simon L. Nielsen" Subject: Re: mmap zero mapping disallowed (Re: svn commit: r197537 - head/sys/vm]) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 18:58:23 -0000 Robert Watson wrote: > > On Sun, 27 Sep 2009, Simon L. Nielsen wrote: > >> As mentioned in the commit message FreeBSD 9 / head now does not allow >> mmap'ing at zero by default, and this may break some apps. >> >> If anyone encounters applications which break because of this change, >> please let report it so we can see if it can be fixed. It might not >> be possible to fix some applications, but we at least would know which >> applications might need a special note in the documentation. > > There are probably some other ways to arrange mappings at 0x0, so we'll > need to dig through the system to identify them. To mind, the various > executable image activators are interesting (elf, a.out, etc), but we > should check other things that call VM insertion routines -- things like > the more interesting 3D device drivers. At the end of the day, this is > a mitigation technique, so if there are edge case non-default compiled > copmonents, etc, that's fine, but it would be nice to be thorough where > we can. > > While our automatic address selection code ever pick 0x0 as a mapping > address, btw? > > Robert N M Watson > Computer Laboratory > University of Cambridge > > >> What they need to do now is find a fault where the offset is > 4096.. I wouldn't bet against it.. From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 19:01:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AD68106568B; Sun, 27 Sep 2009 19:01:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 73D8B8FC12; Sun, 27 Sep 2009 19:01:27 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 0B08046B06; Sun, 27 Sep 2009 15:01:27 -0400 (EDT) Date: Sun, 27 Sep 2009 20:01:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <4ABFB5D1.4010408@elischer.org> Message-ID: References: <20090927150233.GH1495@arthur.nitro.dk> <4ABFB5D1.4010408@elischer.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, "Simon L. Nielsen" Subject: Re: mmap zero mapping disallowed (Re: svn commit: r197537 - head/sys/vm]) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 19:01:27 -0000 On Sun, 27 Sep 2009, Julian Elischer wrote: > What they need to do now is find a fault where the offset is > 4096.. > > I wouldn't bet against it.. Oh, certainly -- this isn't a security policy, it's a vulnerability mitigation technique. It can be bypassed in the right (wrong?) circumstances, just like stack overflow protection, etc. However, it's also a potentially effective tool for limiting easier exploit paths. The kernel has a lot of 0x$smallnum failure modes, and probably significantly fewer 0x$arbitraryconstant ones, so limiting the former has benefit even if it doesn't limit the latter. To more thoroughly eliminate this type of exploit path, we'd need to move to independent kernel/user address spaces, which would increase robustness at signficant cost to performance. I think the current strategy offers some nice middle-ground benefits, and certainly makes it more tricky to exploit several reported vulnerabilities in the last year. Robert From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 19:06:29 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 869B8106566C for ; Sun, 27 Sep 2009 19:06:29 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 30F3F8FC1F for ; Sun, 27 Sep 2009 19:06:29 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 2C7276D41B; Sun, 27 Sep 2009 19:06:28 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id BCBB58448F; Sun, 27 Sep 2009 21:06:27 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jamie Gritton References: <4ABD4BB9.1030804@FreeBSD.org> Date: Sun, 27 Sep 2009 21:06:27 +0200 In-Reply-To: <4ABD4BB9.1030804@FreeBSD.org> (Jamie Gritton's message of "Fri, 25 Sep 2009 17:01:13 -0600") Message-ID: <86ab0g1a30.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: stable@FreeBSD.org, Marcel Moolenaar , "current@freebsd.org mailing list" Subject: Re: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 19:06:29 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jamie Gritton writes: > Index: kern/vfs_export.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- kern/vfs_export.c (revision 197506) > +++ kern/vfs_export.c (working copy) > @@ -122,6 +122,8 @@ > np->netc_anon->cr_uid =3D argp->ex_anon.cr_uid; > crsetgroups(np->netc_anon, argp->ex_anon.cr_ngroups, > argp->ex_anon.cr_groups); > + np->netc_anon->cr_prison =3D &prison0; > + prison_hold(np->netc_anon->cr_prison); > np->netc_numsecflavors =3D argp->ex_numsecflavors; > bcopy(argp->ex_secflavors, np->netc_secflavors, > sizeof(np->netc_secflavors)); You need to #include for prison0... See attached patch. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=nfslockd.diff Index: sys/kern/vfs_export.c =================================================================== --- sys/kern/vfs_export.c (revision 197539) +++ sys/kern/vfs_export.c (working copy) @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -122,6 +123,8 @@ np->netc_anon->cr_uid = argp->ex_anon.cr_uid; crsetgroups(np->netc_anon, argp->ex_anon.cr_ngroups, argp->ex_anon.cr_groups); + np->netc_anon->cr_prison = &prison0; + prison_hold(np->netc_anon->cr_prison); np->netc_numsecflavors = argp->ex_numsecflavors; bcopy(argp->ex_secflavors, np->netc_secflavors, sizeof(np->netc_secflavors)); @@ -206,6 +209,8 @@ np->netc_anon->cr_uid = argp->ex_anon.cr_uid; crsetgroups(np->netc_anon, argp->ex_anon.cr_ngroups, np->netc_anon->cr_groups); + np->netc_anon->cr_prison = &prison0; + prison_hold(np->netc_anon->cr_prison); np->netc_numsecflavors = argp->ex_numsecflavors; bcopy(argp->ex_secflavors, np->netc_secflavors, sizeof(np->netc_secflavors)); Index: sys/rpc/rpcsec_gss/svc_rpcsec_gss.c =================================================================== --- sys/rpc/rpcsec_gss/svc_rpcsec_gss.c (revision 197539) +++ sys/rpc/rpcsec_gss/svc_rpcsec_gss.c (working copy) @@ -449,6 +449,8 @@ cr->cr_uid = cr->cr_ruid = cr->cr_svuid = uc->uid; cr->cr_rgid = cr->cr_svgid = uc->gid; crsetgroups(cr, uc->gidlen, uc->gidlist); + cr->cr_prison = &prison0; + prison_hold(cr->cr_prison); *crp = crhold(cr); return (TRUE); --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 20:37:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0834F1065695 for ; Sun, 27 Sep 2009 20:37:24 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [78.111.72.186]) by mx1.freebsd.org (Postfix) with SMTP id 703398FC1B for ; Sun, 27 Sep 2009 20:37:23 +0000 (UTC) Received: (qmail 18248 invoked by uid 89); 27 Sep 2009 20:37:21 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (78.111.72.187) by avocado.salatschuessel.net with SMTP; 27 Sep 2009 20:37:21 -0000 Date: Sun, 27 Sep 2009 22:37:25 +0200 From: Oliver Lehmann To: freebsd-stable@freebsd.org Message-Id: <20090927223725.5893371f.lehmann@ans-netz.de> In-Reply-To: <20090927170244.0980d699.lehmann@ans-netz.de> References: <20090927170244.0980d699.lehmann@ans-netz.de> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; amd64-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 27 Sep 2009 21:25:36 +0000 Cc: freebsd-current@freebsd.org Subject: Re: glabel+gmirror (8.0-RC1 problem) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 20:37:24 -0000 Hi, that gmirror together with glabel cannot be used looks like a problem introduced with 8.0-RC1 to me. What I did: 2. Installation 3. reboot 4. mirror Root-hdd sysctl kern.geom.debugflags=17 gmirror label -vb round-robin gm0 da0 gmirror load echo 'geom_mirror_load="YES"' >> /boot/loader.conf echo 'geom_label_load="YES"' >> /boot/loader.conf 5. adjust fstab vi /etc/fstab :%s/ad/mirror\/gm/g 6. reboot 7. mirror Root-hdd gmirror insert gm0 da1 gmirror status 8. wait until gmirror is done 9. reboot 10. glabel status With 8.0-RC1 I see only da0s1a, da0s1d, da0s1e and da0s1f as Components shown by glabel(8). With 8.0-BETA3 I see mirror/gm0s1a, mirror/gm0s1d, mirror/gm0s1e and mirror/gm0s1f as Components which would be correct here. I use old IBM 2GB DFHS harddisks for that tests. I have a bunch of them so I used for both tries "fresh" drives. I can't see what has changed here between BETA3 and RC1 but something must have changed in a way which renders gmirror together with glabel on RC1 non-working. I just did that as testing the configuration I want to use for my fileserver when the new harddisks arrived but now I'm not sure If I should rely on gmirror+glabel.... Oliver Lehmann wrote: > Hi, > > I try to glabel (tunefs -L) my gmirror RAID-1. After labeling > the /usr, /tmp, /var partition, glabel status shows the labes are being > assigned to the mirror/gm0s1* partitions. > I then changed my /etc/fstab to use the ufs/