From pcc at gmx.net Tue Aug 18 22:24:04 2009 From: pcc at gmx.net (Peter Cornelius) Date: Tue Aug 18 22:24:11 2009 Subject: Vimage vs. jails Message-ID: <20090818215721.23230@gmx.net> Hi there, I just see the vimage changes going into RELENG_8 and I now am getting my hands dirty, finally. So thanks to all involved. Just to get my head around this the right way, I understand that there is no plan to merge vimage and jail into a single jail utility, right? I may want a large number of vimages "w/o" jails, or at least a number of jails "inside" a couple of vimages (reason being the default route issue raised a while ago). Thanks again, and All the best, Peter. --- PS. I see a couple of lock order reversals on RELENG_8 which I would like to report if the build currently running did not address them -- do we prefer them to a mailing list or to gnats? -- GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 From julian at elischer.org Tue Aug 18 22:53:10 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 18 22:53:16 2009 Subject: Vimage vs. jails In-Reply-To: <20090818215721.23230@gmx.net> References: <20090818215721.23230@gmx.net> Message-ID: <4A8B30D5.9000400@elischer.org> it's not Vimage vs Jails but Vimage as part of Jails. Peter Cornelius wrote: > Hi there, > > I just see the vimage changes going into RELENG_8 and I now am > getting my hands dirty, finally. So thanks to all involved. > > Just to get my head around this the right way, I understand that > there is no plan to merge vimage and jail into a single jail > utility, right? Actually it IS now all one utility... Add the 'vnet' option to jail to get it to create a new vnet withthe jail, otherwise it acts as before. > > I may want a large number of vimages "w/o" jails, or at least a > number of jails "inside" a couple of vimages (reason being the > default route issue raised a while ago). can you expand on that? example comand lines include: jail -c host.hostname=test path=/ vnet command=/bin/tcsh ( make a jail with the same root as normal but with a separate network stack.) jail -c host.hostname=test path=/ vnet children.max=4 \ command=/bin/tcsh (same as above, excep the jail made is in turn able to make up to 4 child jails > > Thanks again, and > > All the best, > > Peter. > > --- > > PS. I see a couple of lock order reversals on RELENG_8 which I > would like to report if the build currently running did not address > them -- do we prefer them to a mailing list or to gnats? From geekounet at poildetroll.net Tue Aug 18 23:09:11 2009 From: geekounet at poildetroll.net (Pierre Guinoiseau) Date: Tue Aug 18 23:09:23 2009 Subject: Vimage vs. jails In-Reply-To: <4A8B30D5.9000400@elischer.org> References: <20090818215721.23230@gmx.net> <4A8B30D5.9000400@elischer.org> Message-ID: <4A8B3495.7010304@poildetroll.net> Hi, Julian Elischer wrote: > it's not Vimage vs Jails > but > Vimage as part of Jails. > > > Peter Cornelius wrote: >> Hi there, >> >> I just see the vimage changes going into RELENG_8 and I now am >> getting my hands dirty, finally. So thanks to all involved. >> >> Just to get my head around this the right way, I understand that >> there is no plan to merge vimage and jail into a single jail >> utility, right? > > Actually it IS now all one utility... > Add the 'vnet' option to jail to get it to create a new vnet withthe > jail, otherwise it acts as before. > >> >> I may want a large number of vimages "w/o" jails, or at least a >> number of jails "inside" a couple of vimages (reason being the >> default route issue raised a while ago). > > can you expand on that? > > example comand lines include: > jail -c host.hostname=test path=/ vnet command=/bin/tcsh > ( make a jail with the same root as normal but with a separate > network stack.) > > > jail -c host.hostname=test path=/ vnet children.max=4 \ > command=/bin/tcsh > (same as above, excep the jail made is in turn able to make > up to 4 child jails > BTW, when will we be able to set those new parameters in rc.conf? The current jails rc script still uses the old way for setting up (or maybe did I missed something?), so it doesn't allow to add those new parameters. :( It may be a desirable feature for 8.0-RELEASE I think. > >> >> Thanks again, and >> >> All the best, >> >> Peter. >> >> --- >> >> PS. I see a couple of lock order reversals on RELENG_8 which I >> would like to report if the build currently running did not address >> them -- do we prefer them to a mailing list or to gnats? > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20090818/1b3b014a/signature.pgp From julian at elischer.org Tue Aug 18 23:28:47 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 18 23:29:04 2009 Subject: Vimage vs. jails In-Reply-To: <4A8B3495.7010304@poildetroll.net> References: <20090818215721.23230@gmx.net> <4A8B30D5.9000400@elischer.org> <4A8B3495.7010304@poildetroll.net> Message-ID: <4A8B392D.9080603@elischer.org> Pierre Guinoiseau wrote: > Hi, > > Julian Elischer wrote: >> it's not Vimage vs Jails >> but >> Vimage as part of Jails. >> >> >> Peter Cornelius wrote: >>> Hi there, >>> >>> I just see the vimage changes going into RELENG_8 and I now am >>> getting my hands dirty, finally. So thanks to all involved. >>> >>> Just to get my head around this the right way, I understand that >>> there is no plan to merge vimage and jail into a single jail >>> utility, right? >> Actually it IS now all one utility... >> Add the 'vnet' option to jail to get it to create a new vnet withthe >> jail, otherwise it acts as before. >> >>> I may want a large number of vimages "w/o" jails, or at least a >>> number of jails "inside" a couple of vimages (reason being the >>> default route issue raised a while ago). >> can you expand on that? >> >> example comand lines include: >> jail -c host.hostname=test path=/ vnet command=/bin/tcsh >> ( make a jail with the same root as normal but with a separate >> network stack.) >> >> >> jail -c host.hostname=test path=/ vnet children.max=4 \ >> command=/bin/tcsh >> (same as above, excep the jail made is in turn able to make >> up to 4 child jails >> > > BTW, when will we be able to set those new parameters in rc.conf? The > current jails rc script still uses the old way for setting up (or maybe > did I missed something?), so it doesn't allow to add those new > parameters. :( It may be a desirable feature for 8.0-RELEASE I think. The 8.0 vimage/vnet feature is a "feature test" facility. it allows you to test it out but no-one in their right mind would tell you to use it in production. It's been some time since I used the rc.conf method of starting jails so I can't speak to how much change would be required. possibly just the addition of "jail_xxx_extra_params". I forgot to mention the ifconfig vnet additions too, to allow an interface to be assigned to a particular jail. > >>> Thanks again, and >>> >>> All the best, >>> >>> Peter. >>> >>> --- >>> >>> PS. I see a couple of lock order reversals on RELENG_8 which I >>> would like to report if the build currently running did not address >>> them -- do we prefer them to a mailing list or to gnats? > > From pcc at gmx.net Thu Aug 20 12:13:14 2009 From: pcc at gmx.net (Peter Cornelius) Date: Thu Aug 20 12:13:20 2009 Subject: Vimage vs. jails Message-ID: <20090820121309.122740@gmx.net> Hi guys, Thanks for the response, so it wasn?t such a bad question after all :) I "have" to pay toll to wifey & kids for a couple of days and will go on after that (hoping that the kernels I then build actually to run ;-)). Regards, Peter. -------- Original-Nachricht -------- > Datum: Tue, 18 Aug 2009 16:28:45 -0700 > Von: Julian Elischer > An: Pierre Guinoiseau > CC: Peter Cornelius , freebsd-virtualization@freebsd.org, freebsd-jail@freebsd.org > Betreff: Re: Vimage vs. jails > Pierre Guinoiseau wrote: > > Hi, > > > > Julian Elischer wrote: > >> it's not Vimage vs Jails > >> but > >> Vimage as part of Jails. > >> > >> > >> Peter Cornelius wrote: > >>> Hi there, > >>> > >>> I just see the vimage changes going into RELENG_8 and I now am > >>> getting my hands dirty, finally. So thanks to all involved. > >>> > >>> Just to get my head around this the right way, I understand that > >>> there is no plan to merge vimage and jail into a single jail > >>> utility, right? > >> Actually it IS now all one utility... > >> Add the 'vnet' option to jail to get it to create a new vnet withthe > >> jail, otherwise it acts as before. > >> > >>> I may want a large number of vimages "w/o" jails, or at least a > >>> number of jails "inside" a couple of vimages (reason being the > >>> default route issue raised a while ago). > >> can you expand on that? > >> > >> example comand lines include: > >> jail -c host.hostname=test path=/ vnet command=/bin/tcsh > >> ( make a jail with the same root as normal but with a separate > >> network stack.) > >> > >> > >> jail -c host.hostname=test path=/ vnet children.max=4 \ > >> command=/bin/tcsh > >> (same as above, excep the jail made is in turn able to make > >> up to 4 child jails > >> > > > > BTW, when will we be able to set those new parameters in rc.conf? The > > current jails rc script still uses the old way for setting up (or maybe > > did I missed something?), so it doesn't allow to add those new > > parameters. :( It may be a desirable feature for 8.0-RELEASE I think. > > > The 8.0 vimage/vnet feature is a "feature test" facility. > it allows you to test it out but no-one in their right mind > would tell you to use it in production. > > It's been some time since I used the rc.conf method of starting jails > so I can't speak to how much change would be required. > possibly just the addition of "jail_xxx_extra_params". > > I forgot to mention the ifconfig vnet additions too, to allow an > interface to be assigned to a particular jail. > > > > > >>> Thanks again, and > >>> > >>> All the best, > >>> > >>> Peter. > >>> > >>> --- > >>> > >>> PS. I see a couple of lock order reversals on RELENG_8 which I > >>> would like to report if the build currently running did not address > >>> them -- do we prefer them to a mailing list or to gnats? > > > > -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser From jose.amengual at gmail.com Thu Aug 20 19:22:51 2009 From: jose.amengual at gmail.com (Jose Amengual) Date: Fri Aug 21 08:23:49 2009 Subject: Best practice to update jails In-Reply-To: <20090820121309.122740@gmx.net> References: <20090820121309.122740@gmx.net> Message-ID: <9C042ACE-8677-4104-BBB5-5F80C7EAFD3C@gmail.com> Hi guys. I have a dev server for our developers that holds around 40 jails, each jail has php, mysql, python etc. The server is now 7.0 and was wondering what is the best practice to maintain security patches and kernel updates and I came out with the following idea : 1.- freebsd-update fetch install ( host system) 2.- rebuild kernel ( I have a custom kernel ) 3.- ezjail-update -b ( update basejail for all jails ) 4.- run in cron portaudit on the jails for thirty party security updates 5.- run portupgrade in case of a security update or for apps upgrade on the jails. I red in some forums that if you run freebsd-update you will need to do a portuprade -fa to reinstall all the thirty party apps because freebsd-update could upgrade or remove some libraries linked to that programs, is this true ?, will be better to run a cvsup and instead ? That are some points of my idea but reading on internet I finished more confuse about how will be the best way to do this. any ideas will more appreciate. Thanks. From reddvinylene at gmail.com Thu Aug 20 20:34:25 2009 From: reddvinylene at gmail.com (Redd Vinylene) Date: Fri Aug 21 08:23:50 2009 Subject: Best practice to update jails In-Reply-To: <9C042ACE-8677-4104-BBB5-5F80C7EAFD3C@gmail.com> References: <20090820121309.122740@gmx.net> <9C042ACE-8677-4104-BBB5-5F80C7EAFD3C@gmail.com> Message-ID: On Thu, Aug 20, 2009 at 8:50 PM, Jose Amengual wrote: > Hi guys. > > I have a dev server for our developers that holds around 40 jails, each > jail has php, mysql, python etc. > > The server is now 7.0 and was wondering what is the best practice to > maintain security patches and kernel updates and I came out with the > following idea : > > 1.- freebsd-update fetch install ( host system) > 2.- rebuild kernel ( I have a custom kernel ) > 3.- ezjail-update -b ( update basejail for all jails ) > 4.- run in cron portaudit on the jails for thirty party security updates > 5.- run portupgrade in case of a security update or for apps upgrade on the > jails. > > I red in some forums that if you run freebsd-update you will need to do a > portuprade -fa to reinstall all the thirty party apps because freebsd-update > could upgrade or remove some libraries linked to that programs, is this > true ?, will be better to run a cvsup and instead ? > > That are some points of my idea but reading on internet I finished more > confuse about how will be the best way to do this. > > any ideas will more appreciate. > > Thanks. > _______________________________________________ > freebsd-jail@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-jail > To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org" > Hi, here's how I do it, hope it helps: http://pastie.org/590295 Redd Vinylene -- http://www.home.no/reddvinylene From reddvinylene at gmail.com Thu Aug 20 21:28:43 2009 From: reddvinylene at gmail.com (Redd Vinylene) Date: Fri Aug 21 08:23:50 2009 Subject: Best practice to update jails In-Reply-To: References: <20090820121309.122740@gmx.net> <9C042ACE-8677-4104-BBB5-5F80C7EAFD3C@gmail.com> Message-ID: On Thu, Aug 20, 2009 at 10:57 PM, Jose Amengual wrote: > any reason of why you do not use freebsd-update ? > > Thanks. I think most people prefer to build from source. I do, at least. -- http://www.home.no/reddvinylene From andrew.hotlab at hotmail.com Fri Aug 21 17:59:11 2009 From: andrew.hotlab at hotmail.com (Andrew Hotlab) Date: Fri Aug 21 21:03:59 2009 Subject: Best practice to update jails In-Reply-To: References: <20090820121309.122740@gmx.net> <9C042ACE-8677-4104-BBB5-5F80C7EAFD3C@gmail.com> Message-ID: > Date: Thu, 20 Aug 2009 23:28:39 +0200 > From: reddvinylene@gmail.com > To: jose.amengual@gmail.com; freebsd-jail@freebsd.org; freebsd-virtualization@freebsd.org > CC: > Subject: Re: Best practice to update jails > > On Thu, Aug 20, 2009 at 10:57 PM, Jose Amengual wrote: > >> any reason of why you do not use freebsd-update ? >> >> Thanks. > > > I think most people prefer to build from source. I do, at least. > We manage some jail host system both for production and development (since 6.2-RELEASE), and we found the best support in the "build-from-source" upgrade method. Here the main steps we follow for a release-step upgrade (since we have a few hosts to manage, we are using a dedicated build server, but the first three steps might be executed on the host machine itself): 1. sync sources from a local cvsup-mirror to the build host; 2. make binaries on the build host (once per architecture we are supporting); 3. mount /usr/src and /usr/obj via NFS on all systems to be upgraded; 4. run mergemaster in pre-buildworld mode (once for the host and once for each jail with the -D flag); 5. install the new kernel on the host we are upgrading; 6. reboot the host with the new kernel in single user mode; 7. install the new userland for the host and for the basejail (we are using the ezjail framework); 8. run mergemaster on the host to align its configuration files to the new release; 9. boot into multi user mode; 10. run mergemaster with the -D flag to update each jail?s configuration files; 11. run "make delete-old" and "make delete-old-libs" on both host and jail systems (using the DESTDIR variable). In our environment, this type of upgrade process has proved to be the most effective and reliable, both for tracking the errata branch and for upgrading between minor and major releases. Obviously it needs you quite knowledgeable about the build(7) process, but IMO time spent studying is always time spent well! :) Andrew _________________________________________________________________ With Windows Live, you can organize, edit, and share your photos. http://www.microsoft.com/middleeast/windows/windowslive/products/photo-gallery-edit.aspx From Alexander at Leidinger.net Sat Aug 22 16:57:52 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Aug 22 17:12:36 2009 Subject: Best practice to update jails In-Reply-To: <9C042ACE-8677-4104-BBB5-5F80C7EAFD3C@gmail.com> References: <20090820121309.122740@gmx.net> <9C042ACE-8677-4104-BBB5-5F80C7EAFD3C@gmail.com> Message-ID: <20090822184001.00006882@unknown> On Thu, 20 Aug 2009 11:50:49 -0700 Jose Amengual wrote: > The server is now 7.0 and was wondering what is the best practice to > maintain security patches and kernel updates and I came out with the > following idea : > > 1.- freebsd-update fetch install ( host system) > 2.- rebuild kernel ( I have a custom kernel ) > 3.- ezjail-update -b ( update basejail for all jails ) > 4.- run in cron portaudit on the jails for thirty party security > updates 5.- run portupgrade in case of a security update or for apps > upgrade on the jails. > > I red in some forums that if you run freebsd-update you will need to > do a portuprade -fa to reinstall all the thirty party apps because > freebsd-update could upgrade or remove some libraries linked to > that programs, is this true ?, will be better to run a cvsup and > instead ? Not if you stay with the same major version of FreeBSD. If you update from 7 to 8, this may be possible (I don't know, I don't use freebsd-update, as I either run patched systems, or at least compile my own kernels), but if you update from 7.x to 7.y, then this would be an ABI change, which is very very very very much a no no in a stable-branch (only an important security fix would be allowed to do something like this, and only if nobody finds another way to do such a fix without changing the ABI). So if you stay on the same major version you can use your procedure, but read the release notes before, such a big impact change is announced on a stable branch. It may be the case that we had something like this once, but I do not remember which major version was affected. Bye, Alexander. From nvass9573 at gmx.com Tue Aug 25 13:16:27 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Tue Aug 25 13:16:49 2009 Subject: interface name collisions Message-ID: <4A93E416.20200@gmx.com> Hello, It seems that there is no checking for name collisions, when an interface is claimed from a child vnet. create ngeth0 > lab# ngctl mkpeer eiface ether ether create test jail > lab# jail -c persist vnet name=test create ngeth0@test > lab# jexec test ngctl mkpeer eiface ether ether claim ngeth0@test > lab# ifconfig ngeth0 -vnet test > lab# ifconfig ngeth0 > ngeth0: flags=8802 metric 0 mtu 1500 > ether 00:00:00:00:00:00 > ether 00:00:00:00:00:00 > lab# Thanks in advance, Nikos From julian at elischer.org Tue Aug 25 18:09:20 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 25 18:09:31 2009 Subject: interface name collisions In-Reply-To: <4A93E416.20200@gmx.com> References: <4A93E416.20200@gmx.com> Message-ID: <4A9428CF.6050308@elischer.org> Nikos Vassiliadis wrote: > Hello, > > It seems that there is no checking for name collisions, > when an interface is claimed from a child vnet. > > create ngeth0 >> lab# ngctl mkpeer eiface ether ether > create test jail >> lab# jail -c persist vnet name=test > create ngeth0@test >> lab# jexec test ngctl mkpeer eiface ether ether > claim ngeth0@test >> lab# ifconfig ngeth0 -vnet test >> lab# ifconfig ngeth0 >> ngeth0: flags=8802 metric 0 mtu 1500 >> ether 00:00:00:00:00:00 >> ether 00:00:00:00:00:00 >> lab# > > Thanks in advance, Nikos > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org" you are correct (sort of) The current vnet infrastructure is still under construction and we have been focusing mostly on the functionality rather than error handling, so you will find many places where errors (that are hopefully non fatal) ar enot yet correctly handled. We are aware of this. You are of course also welcome to make suggestions as to what the correct behavior in these situations should be. Thank you for trying out our new little toy! comments and suggestions are always welcome. Note 8.0 vnet support is for demonstration purposes only and we do not suggest that it be used in situations where robust behavior in the face of external or malicios agents might be a factor. i.e. it's not at all hardened (that may be an understatement). From nvass9573 at gmx.com Tue Aug 25 21:13:20 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Tue Aug 25 21:13:27 2009 Subject: interface name collisions In-Reply-To: <4A9428CF.6050308@elischer.org> References: <4A93E416.20200@gmx.com> <4A9428CF.6050308@elischer.org> Message-ID: <4A9453D9.4020604@gmx.com> Julian Elischer wrote: > We are aware of this. You are of course also welcome to > make suggestions as to what the correct behavior in these > situations should be. > When an interface is moved from a parent to a child vnet a check is done. I tried to copy that behavior. Does it look correct? --- sys/net/if.c.orig 2009-08-24 15:52:05.000000000 +0300 +++ sys/net/if.c 2009-08-25 23:55:26.000000000 +0300 @@ -992,6 +992,13 @@ prison_hold_locked(pr); mtx_unlock(&pr->pr_mtx); + /* Make sure the named iface does not exist in the dst. prison/vnet. */ + ifp = ifunit(ifname); + if (ifp != NULL) { + prison_free(pr); + return (EEXIST); + } + /* Make sure the named iface exists in the source prison/vnet. */ CURVNET_SET(pr->pr_vnet); ifp = ifunit(ifname); /* XXX Lock to avoid races. */ > Thank you for trying out our new little toy! Well, thanks for creating this "little toy":) Nikos From bzeeb-lists at lists.zabbadoz.net Wed Aug 26 06:22:04 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Aug 26 06:22:10 2009 Subject: interface name collisions In-Reply-To: <4A9453D9.4020604@gmx.com> References: <4A93E416.20200@gmx.com> <4A9428CF.6050308@elischer.org> <4A9453D9.4020604@gmx.com> Message-ID: <20090826055308.C93661@maildrop.int.zabbadoz.net> On Wed, 26 Aug 2009, Nikos Vassiliadis wrote: Hi, > When an interface is moved from a parent to a child vnet > a check is done. I tried to copy that behavior. Does it > look correct? > > --- sys/net/if.c.orig 2009-08-24 15:52:05.000000000 +0300 > +++ sys/net/if.c 2009-08-25 23:55:26.000000000 +0300 > @@ -992,6 +992,13 @@ > prison_hold_locked(pr); > mtx_unlock(&pr->pr_mtx); > > + /* Make sure the named iface does not exist in the dst. prison/vnet. > */ > + ifp = ifunit(ifname); > + if (ifp != NULL) { > + prison_free(pr); > + return (EEXIST); > + } > + > /* Make sure the named iface exists in the source prison/vnet. */ > CURVNET_SET(pr->pr_vnet); > ifp = ifunit(ifname); /* XXX Lock to avoid races. */ I hope there would be a comment somewhere that vmomve should be re-done to fix all this... it was in the commit message: :: There is some duplicate interface name checking before actually moving :: the interface between network stacks without locking and thus race :: prone. Ideally if_vmove will correctly and automagically handle these :: in the future. So what you do above replicates this behaviour but doesn't really make it better as you still may run into the problem only less likely. Robert is currently fixing other if.c bugs for ifindex allocation (proper locking, reducing races,..), so I am satying away from there to not interfere with his work but hope to go back there next week, when the if.c code has settled. /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From nvass9573 at gmx.com Wed Aug 26 10:01:47 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Wed Aug 26 10:01:54 2009 Subject: interface name collisions In-Reply-To: <20090826055308.C93661@maildrop.int.zabbadoz.net> References: <4A93E416.20200@gmx.com> <4A9428CF.6050308@elischer.org> <4A9453D9.4020604@gmx.com> <20090826055308.C93661@maildrop.int.zabbadoz.net> Message-ID: <4A9507ED.4020207@gmx.com> Bjoern A. Zeeb wrote: > Robert is currently fixing other if.c bugs for ifindex allocation (proper > locking, reducing races,..), so I am satying away from there to not > interfere with his work but hope to go back there next week, when the if.c > code has settled. Ah I see, thanks for the information. Nikos From kris at FreeBSD.org Sun Aug 30 12:42:13 2009 From: kris at FreeBSD.org (Kris Kennaway) Date: Sun Aug 30 12:42:19 2009 Subject: 9.0 + vimage + nfs root = panic Message-ID: <4A9A73A3.7050007@FreeBSD.org> hwpmc: TSC/1/64/0x20 IAP/2/40/0x3ff IAF/0/0/0x61 Trying to mount root from nfs: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x28 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff804a1ff2 stack pointer = 0x28:0xffffff8000053130 frame pointer = 0x28:0xffffff8000053150 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1 (kernel) [thread pid 1 tid 100001 ] Stopped at ifunit_ref+0x32: movq 0x28(%rdx),%rax db> wh Tracing pid 1 tid 100001 td 0xffffff000185f000 ifunit_ref() at ifunit_ref+0x32 ifioctl() at ifioctl+0xb7 nfs_mountroot() at nfs_mountroot+0x94 nfs_mount() at nfs_mount+0x4d8 vfs_donmount() at vfs_donmount+0xc80 kernel_mount() at kernel_mount+0x88 vfs_mountroot_try() at vfs_mountroot_try+0x17d vfs_mountroot() at vfs_mountroot+0x37a start_init() at start_init+0x45 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000053d30, rbp = 0 --- From bz at FreeBSD.org Sun Aug 30 13:12:36 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Sun Aug 30 13:13:28 2009 Subject: 9.0 + vimage + nfs root = panic In-Reply-To: <4A9A73A3.7050007@FreeBSD.org> References: <4A9A73A3.7050007@FreeBSD.org> Message-ID: <20090830125000.U93661@maildrop.int.zabbadoz.net> On Sun, 30 Aug 2009, Kris Kennaway wrote: Hi, > Trying to mount root from nfs: > > > Fatal trap 12: page fault while in kernel mode known and I just pointed you at the patch (via OOB) to try. /bz -- Bjoern A. Zeeb What was I talking about and who are you again?