Re: Does / Is anyone maintaining CVS for FreeBSD?
There has been some discussion about removing CVS from the base system now it is no longer used. No concensus was reached, so it's not going away immediately (and would not be removed from 9.x or earlier branches in any case). CVS is (and will remain) available in ports (devel/cvs). -- Peter Jeremy Now CVS may be no longer used for FreeBSD servers, but NetBSD servers still use it for system source and pkgsrc. I like to keep up with NetBSD 6-STABLE and HEAD, maybe a final try for NetBSD 5.2, and that includes pkgsrc. If somebody could persuade NetBSD to switch to svn, I would surely not quarrel. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
On 2 Jan 2013 11:08, Thomas Mueller muelle...@insightbb.com wrote: There has been some discussion about removing CVS from the base system now it is no longer used. No concensus was reached, so it's not going away immediately (and would not be removed from 9.x or earlier branches in any case). CVS is (and will remain) available in ports (devel/cvs). -- Peter Jeremy Now CVS may be no longer used for FreeBSD servers, but NetBSD servers still use it for system source and pkgsrc. I like to keep up with NetBSD 6-STABLE and HEAD, maybe a final try for NetBSD 5.2, and that includes pkgsrc. If somebody could persuade NetBSD to switch to svn, I would surely not quarrel. To clarify, no-one wants to remove CVS completely, the suggestion was to move it out of the base system. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: NFS-exported ZFS instability
Hiroki Sato wrote: Hello, I have been in a trouble about my NFS server for a long time. The symptom is that it stops working in one or two weeks after a boot. I could not track down the cause yet, but it is reproducible and only occurred under a very high I/O load. It did not panic, just stopped working---while it responded to ping, userland programs seemed not working. I could break it into DDB and get a kernel dump. The following URLs are a log of ps, trace, and etc.: http://people.allbsd.org/~hrs/FreeBSD/pool.log.20130102 http://people.allbsd.org/~hrs/FreeBSD/pool.dmesg.20130102 Does anyone see how to debug this? I guess this is due to a deadlock somewhere. I have suffered from this problem for almost two years. The above log is from stable/9 as of Dec 19, but this have persisted since 8.X. Well, I took a quick glance at the log and there are a lot of processes sleeping on pfault (in vm_waitpfault() in sys/vm/vm_page.c). I'm no vm guy, so I'm not sure when/why that will happen. The comment on the function suggests they are waiting for free pages. Maybe something as simple as running out of swap space or a problem talking to the disk(s) that has the swap partition(s) or ??? (I'm talking through my hat here, because I'm not conversant with the vm side of things.) I might take a closer look this evening and see if I can spot anything in the log, rick ps: I hope Alan and Kostik don't mind being added to the cc list. -- Hiroki ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
On 2 January 2013 06:26, Chris Rees utis...@gmail.com wrote: To clarify, no-one wants to remove CVS completely, the suggestion was to move it out of the base system. As the developer responsible for this: CVS will be removed from base. It already exists as a port in devel/cvs -- Eitan Adler ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
Am 02.01.2013 06:31, schrieb Erich Dollansky: Hi, Thank God! I'd hate to think that after unwinding years accumulated CVS process, to rewind it for SVN, only to have to do it again for GIT, just seems a bit masochistic. do not worry. It will come. Seriously, I do not understand many changes especially when there is a system in place which does not affect a running system at all but things inside the OS still could be improved. The migration was made in order to get things inside the OS ... improved at all. Developers were fed up wasting too much time struggling with CVS itself rather than working on the things inside the OS. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
Eitan Adler li...@eitanadler.com wrote: On 2 January 2013 06:26, Chris Rees utis...@gmail.com wrote: To clarify, no-one wants to remove CVS completely, the suggestion was to move it out of the base system. As the developer responsible for this: CVS will be removed from base. It already exists as a port in devel/cvs Will svn be added to the base? Not long ago I run into an issue when trying to downgrade my system to 9.0. After I noticed how majority of ports were broken due to changes in the libc I decided to back out by fetching 9.1 release just to learn that svn does not work as well. There were a lot of dependencies I decided to use portupgrade which required me to recompile ruby. After that it was a lot of compiling (for example Apache because apr was broken). Having svn in the base would save tons of time in my situation. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: RELENG_9 panic with PERC 6/i (mfi)
No, it remains an outstanding issue. We've begun moving services to a spare server to give us more time to investigate it. From: Wiley, Glen [gwi...@verisign.com] Sent: Wednesday, January 02, 2013 9:52 AM To: Sean Kelly; Daniel Braniss Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_9 panic with PERC 6/i (mfi) Did you guys end up identifying the cause of that panic? -- Glen Wiley Systems Architect Verisign Inc. On 12/23/12 12:56 PM, Sean Kelly smke...@flightaware.com wrote: Greetings. All I have to do to panic it is boot it. As you can see from the dump, it died after about 30 seconds without me doing anything. I can't provide those sysctl values easily, as it panics too quickly. I suppose I can convince it to drop to DDB and pick them out if that would be helpful. Here they are from the working 8.2-R kernel. vm.kmem_map_free: 49870348288 vm.kmem_map_size: 68964352 This box, unlike most of our others, doesn't even utilizing ZFS. root@papa:~# gpart show =63 1141899192 mfid0 MBR (545G) 63 1141884072 1 freebsd [active] (544G) 1141884135 15120 - free - (7.4M) = 0 1141884072 mfid0s1 BSD (544G) 0 83886081 freebsd-ufs (4.0G) 8388608167772164 freebsd-ufs (8.0G) 25165824335544325 freebsd-ufs (16G) 58720256671088642 freebsd-swap (32G) 125829120671088647 freebsd-swap (32G) 192937984671088648 freebsd-swap (32G) 260046848 8818372246 freebsd-ufs (420G) From: Daniel Braniss [da...@cs.huji.ac.il] Sent: Sunday, December 23, 2012 1:43 AM To: Sean Kelly Subject: Re: RELENG_9 panic with PERC 6/i (mfi) btw: sysctl -a | grep kmem_map vm.kmem_map_free: 8859570176 vm.kmem_map_size: 6037008384 danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
On 2 January 2013 16:05, Derek Kulinski tak...@takeda.tk wrote: Eitan Adler li...@eitanadler.com wrote: On 2 January 2013 06:26, Chris Rees utis...@gmail.com wrote: To clarify, no-one wants to remove CVS completely, the suggestion was to move it out of the base system. As the developer responsible for this: CVS will be removed from base. It already exists as a port in devel/cvs Will svn be added to the base? Not long ago I run into an issue when trying to downgrade my system to 9.0. After I noticed how majority of ports were broken due to changes in the libc I decided to back out by fetching 9.1 release just to learn that svn does not work as well. There were a lot of dependencies I decided to use portupgrade which required me to recompile ruby. After that it was a lot of compiling (for example Apache because apr was broken). Having svn in the base would save tons of time in my situation. It certainly wouldn't, it would mean that instead of only building when you installed the port, it would build with every buildworld :) http://svnweb.FreeBSD.org/base/user/des/svnsup/ needs fixing if you're feeling brave. It won't be easy, however. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
On 1/2/13 8:05 AM, Derek Kulinski wrote: Eitan Adler li...@eitanadler.com wrote: On 2 January 2013 06:26, Chris Rees utis...@gmail.com wrote: To clarify, no-one wants to remove CVS completely, the suggestion was to move it out of the base system. As the developer responsible for this: CVS will be removed from base. It already exists as a port in devel/cvs Will svn be added to the base? Not long ago I run into an issue when trying to downgrade my system to 9.0. After I noticed how majority of ports were broken due to changes in the libc I decided to back out by fetching 9.1 release just to learn that svn does not work as well. There were a lot of dependencies I decided to use portupgrade which required me to recompile ruby. After that it was a lot of compiling (for example Apache because apr was broken). Having svn in the base would save tons of time in my situation. Sorry, you needed to fetch 9.0 packages then*. Putting all of that in base is not likely to happen. * I wish doing this was somewhat more intuitive/easy -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_9 panic with PERC 6/i (mfi)
Did you guys end up identifying the cause of that panic? -- Glen Wiley Systems Architect Verisign Inc. On 12/23/12 12:56 PM, Sean Kelly smke...@flightaware.com wrote: Greetings. All I have to do to panic it is boot it. As you can see from the dump, it died after about 30 seconds without me doing anything. I can't provide those sysctl values easily, as it panics too quickly. I suppose I can convince it to drop to DDB and pick them out if that would be helpful. Here they are from the working 8.2-R kernel. vm.kmem_map_free: 49870348288 vm.kmem_map_size: 68964352 This box, unlike most of our others, doesn't even utilizing ZFS. root@papa:~# gpart show =63 1141899192 mfid0 MBR (545G) 63 1141884072 1 freebsd [active] (544G) 1141884135 15120 - free - (7.4M) = 0 1141884072 mfid0s1 BSD (544G) 0 83886081 freebsd-ufs (4.0G) 8388608167772164 freebsd-ufs (8.0G) 25165824335544325 freebsd-ufs (16G) 58720256671088642 freebsd-swap (32G) 125829120671088647 freebsd-swap (32G) 192937984671088648 freebsd-swap (32G) 260046848 8818372246 freebsd-ufs (420G) From: Daniel Braniss [da...@cs.huji.ac.il] Sent: Sunday, December 23, 2012 1:43 AM To: Sean Kelly Subject: Re: RELENG_9 panic with PERC 6/i (mfi) btw: sysctl -a | grep kmem_map vm.kmem_map_free: 8859570176 vm.kmem_map_size: 6037008384 danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 minimal ram requirements
On Mon, 24 Dec 2012 04:50:22 +1100, Ian Smith wrote:
[following up my own message with a later report]
On Sun, 23 Dec 2012 15:21:23 +0300, Sergey Kandaurov wrote:
On 23 December 2012 10:22, Ian Smith smi...@nimnet.asn.au wrote:
On Sun, 23 Dec 2012 03:45:39 +0300, Sergey Kandaurov wrote:
This (i.e. the kmem_map too small message seen with kernel memory
shortage) could be due to CAM CTL ('device ctl' added in 9.1), which
is
quite a big kernel memory consumer.
Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish
boot.
I've just added that, thanks Sergey, but it's sadly not an option for
installation. I guess it's too late for the release notes - which at
RC3 made no mention of CAM CTL at all - but it's not yet clear to me
whether even 256MB is enough to boot, install and run 9.1 GENERIC?
If you perform clean installation (e.g. from ISO), you can escape to the
loader prompt and set the tunable there w/o the need for
/boot/loader.conf.
I experimented with Vbox and AFAIK 256MB was enough even with CAM CTL.
Ah right; I'd booted and installed from memstick, where escape to loader
prompt is not an option. I'll burn a disc1 and try that with the 128MB
again, and make sure that 256MB is comfortable - after holiday madness.
So I tried again with the 128MB RAM, from a disc1 boot, from loader set
kern.cam.ctl.disable=1, installed all distributions, no problems; with
sshd, powerd, no ntpd (laptop had broken NIC then, now fixed), loaded
acpi_ibm (working well, and suspend and resume finally work reliably out
of the box, excellent!), top showing 77MB free. Ran it for over a day
doing nothing much - resume, browse some stuff, suspend - 77MB free.
With 256MB instead, installed as above _without_ disabling kern.cam.ctl,
no problems, to another slice. As an aside, bsdinstall didn't update my
boot0, leaving the previously installed slice selected on boot, but I'm
more relieved it didn't mess with it :) top showed 167MB free, steady.
256MB as above but with kern.cam.ctl.disabled=1, top shows 202MB free.
202 - 167 = 35MB extra by cam.ctl. Without cam.ctl, 128 - 77 = 51MB
used, 256 - 202 = 54MB used, unsure where 3MB went but I'm not worried.
So I'm happy to say that 128MB RAM, with kern.cam.ctl.disabled=1, boots,
installs and runs 9.1-R fine. I might even try it on my ancient but so
far unstoppable 10yrs x24x7 Compaq Armada 1500c, maxed out at 160MB :)
I notice that my previous 202MB free is now down to 6.4MB, with swap
touched at 336K, that's likely normal; I'll work it a bit harder soon.
It'd be nice if booting from memstick allowed dropping to loader.
cheers, Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: NFS-exported ZFS instability
On Wed, Jan 02, 2013 at 08:24:39AM -0500, Rick Macklem wrote: Hiroki Sato wrote: Hello, I have been in a trouble about my NFS server for a long time. The symptom is that it stops working in one or two weeks after a boot. I could not track down the cause yet, but it is reproducible and only occurred under a very high I/O load. It did not panic, just stopped working---while it responded to ping, userland programs seemed not working. I could break it into DDB and get a kernel dump. The following URLs are a log of ps, trace, and etc.: http://people.allbsd.org/~hrs/FreeBSD/pool.log.20130102 http://people.allbsd.org/~hrs/FreeBSD/pool.dmesg.20130102 Does anyone see how to debug this? I guess this is due to a deadlock somewhere. I have suffered from this problem for almost two years. The above log is from stable/9 as of Dec 19, but this have persisted since 8.X. Well, I took a quick glance at the log and there are a lot of processes sleeping on pfault (in vm_waitpfault() in sys/vm/vm_page.c). I'm no vm guy, so I'm not sure when/why that will happen. The comment on the function suggests they are waiting for free pages. Maybe something as simple as running out of swap space or a problem talking to the disk(s) that has the swap partition(s) or ??? (I'm talking through my hat here, because I'm not conversant with the vm side of things.) I might take a closer look this evening and see if I can spot anything in the log, rick ps: I hope Alan and Kostik don't mind being added to the cc list. What I see in the log is that the lock cascade rooted in the thread 100838, which owns system map mutex. I believe this prevents malloc(9) from making a progress in other threads, which e.g. own the ZFS vnode locks. As the result, the whole system wedged. Looking back at the thread 100838, we can see that it executes smp_tlb_shootdown(). It is impossible to tell from the static dump, is the appearance of the smp_tlb_shootdown() in the backtrace is transient, or the thread is spinning there, waiting for other CPUs to acknowledge the request. But, since the system wedged, most likely, smp_tlb_shootdown spins. Taking this hypothesis, the situation can occur, most likely, due to some other core running with the interrupts disabled. Inspection of the backtraces of the processes running on all cores does not show any which could legitimately own a spinlock or otherwise run with the interrupts disabled. One thing you could try to do is to enable WITNESS for the spinlocks, to try to catch the leaked spinlock. I very much doubt that this is the case. Another thing to try is to switch the CPU idle method to something else. Look at the machdep.idle* sysctls. It could be some CPU errata which blocks wakeup due the interrupt in some conditions in C1 ? pgpE8MByHmYh5.pgp Description: PGP signature
Upgrade of RELENG_8 ZFS boot pool leads to unbootable system
Yesterday, I updated my RELENG_8 ZFS-only system that has worked like a champ
for ages. After a successful install{kernel,world} and reboot, I noticed the
20121130 entry in /usr/src/UPDATING and upgraded my ZFS pool via zfs upgrade
-a. I also upgraded my boot blocks as requested, and as per the ZFS notes
section of /usr/src/UPDATING.
Unfortunately rebooting with the upgraded pool failed. The windmill boot
spinner spins for a tiny amount of time and then stops dead. :-( I don't get
to the boot loader menu at all.
I downloaded a very recent RELENG_8 snapshot
(FreeBSD-8.3-RELENG_8-r244923-JPSNAP-amd64-amd64-memstick.img) from
pub.allbsd.org and was able to boot successfully from USB using that. I
entered Fixit Mode and tried to write the boot blocks on the memstick image
onto my hard drives but the resultant system still wouldn't boot. The commands
I used (from Fixit Mode) are these:
gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad4
gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad6
(ad4 and ad6 are my two hard drives.)
If I load zfs before booting the USB memstick then I can see my old pool
listed when I do zfs import. I haven't tried importing the pool because I'm
not sure if that would make the problem worse.
Does anyone have any advice in restoring this system to bootability? I
followed the standard root on ZFS recipe using a two drive mirror when
installing the system initially. Each drive uses GPT with three partitions:
freebsd-boot, freebsd-swap, and freebsd-zfs in that order. Like I said at the
start, all this worked for a long time until just now when I upgraded the pool
to enable feature flags support. :-(
Any help is appreciated.
Cheers,
Paul.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
On 1/1/13, m...@freebsd.org m...@freebsd.org wrote: On Tue, Jan 1, 2013 at 1:18 PM, Alfred Perlstein bri...@mu.org wrote: git-svn is somewhat problematic: http://wiki.freebsd.org/GitWorkflow - Using git-svn (FreeBSD committers only) - Things to keep in mind: * Never git merge branches, unless you know what you're doing. * Always git rebase your work on top of master, then git svn dcommit can push the top commits to svn. * Always double-check with git svn dcommit -n to see what would happen. * While you can use git add for new files just fine, you won't be able to push those upstream, you can however use the patch, apply it to some subversion checkout and do the commit there. This is a shortcoming of our very own Subversion hacks, but hey, it's better than nothing! * While git-svn now allows you to set svn:mergeinfo when committing, this is so fragile that the FreeBSD projects discourages its use. Please use svn(1) for merging, sorry. It's very poor (at least according to the wiki). Seems like you can't do much except pull a patch from git, apply to subversion and then commit upstream. Eck... You can do normal code with git-svn just fine. You can't merge svn branches with git. Due to svn: properties on the files, you can't create new files with git. Everything else (i.e., in my experience 90% of the code I do) can be done in git. Because git svn dcommit pushes *all* patches, the recommendation is to look carefully at what will be pushed. But it's a quick git checkout branch; git rebase -i HEAD~N; git svn dcommit; git checkout master; git svn fetch; git rebase; git delete branch to push only selected patches. In this page you can find some example of aliasing in git: https://git.wiki.kernel.org/index.php/Aliases Now that was a lot of typing, but heck, it could be scripted too. Cheers, matthew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
On Tue, Jan 1, 2013 at 9:30 PM, Doug Hardie bc...@lafn.org wrote: Is the cvs code going away? If you mean, /usr/bin/cvs.. then you should be aware that there is an identical version in ports/devel/cvs. Having a single version in ports has the advantage that the same bug fixes are available to all branches of FreeBSD. A number of folks have expressed a desire to see the transition from src to ports be as seamless and painless as possible. I think its a fairly safe bet that it'll happen for FreeBSD-10. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade of RELENG_8 ZFS boot pool leads to unbootable system
On 02/01/2013 17:49, Paul Mather wrote:
Yesterday, I updated my RELENG_8 ZFS-only system that has worked like a champ
for ages. After a successful install{kernel,world} and reboot, I noticed the
20121130 entry in /usr/src/UPDATING and upgraded my ZFS pool via zfs upgrade
-a. I also upgraded my boot blocks as requested, and as per the ZFS notes
section of /usr/src/UPDATING.
Unfortunately rebooting with the upgraded pool failed. The windmill boot
spinner spins for a tiny amount of time and then stops dead. :-( I don't get
to the boot loader menu at all.
I downloaded a very recent RELENG_8 snapshot
(FreeBSD-8.3-RELENG_8-r244923-JPSNAP-amd64-amd64-memstick.img) from
pub.allbsd.org and was able to boot successfully from USB using that. I
entered Fixit Mode and tried to write the boot blocks on the memstick image
onto my hard drives but the resultant system still wouldn't boot. The
commands I used (from Fixit Mode) are these:
gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad4
gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad6
(ad4 and ad6 are my two hard drives.)
If I load zfs before booting the USB memstick then I can see my old pool
listed when I do zfs import. I haven't tried importing the pool because
I'm not sure if that would make the problem worse.
Does anyone have any advice in restoring this system to bootability? I
followed the standard root on ZFS recipe using a two drive mirror when
installing the system initially. Each drive uses GPT with three partitions:
freebsd-boot, freebsd-swap, and freebsd-zfs in that order. Like I said at
the start, all this worked for a long time until just now when I upgraded the
pool to enable feature flags support. :-(
Any help is appreciated.
I think you may be running into problems with zpool.cache. This has
been fixed in current, which now has the ability to find the root zpool
without a valid zpool.cache, but that I suspect is faint comfort for you.
To recover from a toasted zpool.cache, you need to boot from alternate
media and then import your root zpool. It's easiest to do that to a
temporary directory. The important bit is to copy the zpool.cache onto
your actual zroot device:
-- Boot from install media to 'Live CD' and log in as root (no password)
# kldload zfs -- should load opensolaris.ko automatically
# cd /tmp -- this should be a writable MFS; you'll
need to arrange something similar if
not.
# zpool import -o cachefile=/tmp/zpool.cache -R /tmp/zroot zroot
-- this should create a zpool.cache file
# cp zpool.cache /tmp/zroot/boot/zfs/
# zfs umount -a
# shutdown -r
Eject the install media, and the system should boot up from your root zpool.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matt...@infracaninophile.co.uk
signature.asc
Description: OpenPGP digital signature
Re: Does / Is anyone maintaining CVS for FreeBSD?
On Mon, Dec 31, 2012 at 2:39 PM, Chris H chris#@1command.com wrote: On 31 December 2012 15:40, Chris H chris#@1command.com wrote: Are there _any_ CVS servers/trunks/tree's left? If so, how _current_ are they? Ports and Source currently have CVS trees. Ports has an explicit EoL on February 28th (2 months from today) Source does not have an explicit EoL though it *is* considered deprecated. Thank you for providing this information, and my apologies, for not having better researched it myself. I'll make an effort to provide a permanent CVS repo for both src ports. At the risk of a late reply stirring things up. doc and www were converted from cvs - svn in May 2012. There was *never* a svn-cvs exporter for the doc/www trees - it was a clean break and switch over, and the cvs tree was closed. However, a stale orphaned copy of the doc/www files were in the cvsup network. If you were using those, you were using stale, out of date files. I've been rebuilding *.freebsd.org machines over the last 3-4 months and came across these stale files on a machine that was being decommissioned. When I was building the replacement I didn't include them. The cvs exporter was running on a machine that was broken into. The entire machine, code, exporters and cvs repository were considered tainted. As the exported src cvs tree has been deprecated for years, we should have just turned it off, Instead we salvaged and reviewed what we could, threw together a really quick and dirty exporter replacement and made it run for a little longer. It really is on its last legs. Note that there is no practical way to audit a cvs tree after an incident like that, especially a deprecated tree at that. cvs for /usr/src was deprecated in October 2008. The original plan for running the exporter for 2-3 months as a transition aide ran a little longer than planned. The branch support timeline is listed here: http://www.freebsd.org/security/ As things stand right now, this is the exporter's run schedule: * RELENG_6: Updates once a day, probably turning off on Feb 28th. * RELENG_7: Updates hourly, probably turning off on Feb 28th at EOL * RELENG_7_4: Updates hourly, probably turning off on Feb 28th at EOL * RELENG_8: Updates hourly * RELENG_8_3: Updates hourly * RELENG_9: Updates hourly * RELENG_9_0: Updates hourly * src-HEAD: Updates daily, probably turning off on Feb 28th. * ports-HEAD: Updates hourly, definitely turning off on Feb 28th. That's about what the limit of what the machine can handle. When folks go on a commit spree, the poor thing runs its disks white-hot for a few hours to catch up. No new branches will ever make it into cvs. eg: no RELENG_9_2. You'll have to get them from svn, just like getting updates to the older branches. Its also worth noting that all of the RELENG_9 series were released from the subversion tree - cvs was never involved. If there's an 8.4, it'll have to be built from svn as well. We have some significant problems with both ezm3 and cvsup itself (which is written in Modula-3). It basically is an inverse compatability binary.. The runtime code uses the oldest available versions of syscalls that it can, mostly the FreeBSD-4 versions. Emulation for some of the more exotic functionality - particularly signals - has become ... problematic .. lately. It has memory corruption problems. The cvsup/cvsupd servers break regularly when they corrupt their checkouts files and fetch the same data over and over and over again, crashing each time. And worse.. cvsup/cvsupd doesn't understand the version of cvs we have in the freebsd tree. *Every* *single* *commit* causes a checksum error and re-fetch. For the cvs/rcs ,v files, it degenerates into the old sup(1) mode - not even rsync. It is more efficient to transport the src cvs repository with rsync + rsyncd these days than cvsup/cvsupd. I'm sorry, but it is time to move on. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade of RELENG_8 ZFS boot pool leads to unbootable system
On Jan 2, 2013, at 2:10 PM, Matthew Seaman m.sea...@infracaninophile.co.uk
wrote:
On 02/01/2013 17:49, Paul Mather wrote:
Yesterday, I updated my RELENG_8 ZFS-only system that has worked like a
champ for ages. After a successful install{kernel,world} and reboot, I
noticed the 20121130 entry in /usr/src/UPDATING and upgraded my ZFS pool via
zfs upgrade -a. I also upgraded my boot blocks as requested, and as per
the ZFS notes section of /usr/src/UPDATING.
Unfortunately rebooting with the upgraded pool failed. The windmill boot
spinner spins for a tiny amount of time and then stops dead. :-( I don't
get to the boot loader menu at all.
I downloaded a very recent RELENG_8 snapshot
(FreeBSD-8.3-RELENG_8-r244923-JPSNAP-amd64-amd64-memstick.img) from
pub.allbsd.org and was able to boot successfully from USB using that. I
entered Fixit Mode and tried to write the boot blocks on the memstick image
onto my hard drives but the resultant system still wouldn't boot. The
commands I used (from Fixit Mode) are these:
gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad4
gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad6
(ad4 and ad6 are my two hard drives.)
If I load zfs before booting the USB memstick then I can see my old pool
listed when I do zfs import. I haven't tried importing the pool because
I'm not sure if that would make the problem worse.
Does anyone have any advice in restoring this system to bootability? I
followed the standard root on ZFS recipe using a two drive mirror when
installing the system initially. Each drive uses GPT with three partitions:
freebsd-boot, freebsd-swap, and freebsd-zfs in that order. Like I said at
the start, all this worked for a long time until just now when I upgraded
the pool to enable feature flags support. :-(
Any help is appreciated.
I think you may be running into problems with zpool.cache. This has
been fixed in current, which now has the ability to find the root zpool
without a valid zpool.cache, but that I suspect is faint comfort for you.
To recover from a toasted zpool.cache, you need to boot from alternate
media and then import your root zpool. It's easiest to do that to a
temporary directory. The important bit is to copy the zpool.cache onto
your actual zroot device:
-- Boot from install media to 'Live CD' and log in as root (no password)
Given the above, does this need to be a -CURRENT Live CD? I've been using the
RELENG_8 snapshot memstick.img mentioned in my original message above.
# kldload zfs -- should load opensolaris.ko automatically
# cd /tmp -- this should be a writable MFS; you'll
need to arrange something similar if
not.
# zpool import -o cachefile=/tmp/zpool.cache -R /tmp/zroot zroot
-- this should create a zpool.cache file
I tried this and it complained about the pool being in use by another
system---the original system that won't boot any more. I expected this, and
added -f to force an import.
# cp zpool.cache /tmp/zroot/boot/zfs/
This part also failed for me. My zroot fileset has a mountpoint property set
to legacy. I had to mount this manually, via mount -t zfs zroot /tmp/zroot
to make the /tmp/zroot/boot/zfs directory accessible.
# zfs umount -a
# shutdown -r
Eject the install media, and the system should boot up from your root spool.
Unfortunately, it didn't boot from the root pool. I get the same thing
happening: the windmill spins for a very short time and then stops dead. I
don't even make it to the BTX Loader output, let alone the boot loader menu
options. :-(
Thank you for the suggestions.
Cheers,
Paul.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
Greetings Peter, and thank you _very_ much for the thoughtful, and very informative reply -- _greatly_ appreciated. On Mon, Dec 31, 2012 at 2:39 PM, Chris H chris#@1command.com wrote: On 31 December 2012 15:40, Chris H chris#@1command.com wrote: Are there _any_ CVS servers/trunks/tree's left? If so, how _current_ are they? Ports and Source currently have CVS trees. Ports has an explicit EoL on February 28th (2 months from today) Source does not have an explicit EoL though it *is* considered deprecated. Thank you for providing this information, and my apologies, for not having better researched it myself. I'll make an effort to provide a permanent CVS repo for both src ports. At the risk of a late reply stirring things up. doc and www were converted from cvs - svn in May 2012. There was *never* a svn-cvs exporter for the doc/www trees - it was a clean break and switch over, and the cvs tree was closed. However, a stale orphaned copy of the doc/www files were in the cvsup network. If you were using those, you were using stale, out of date files. I've been rebuilding *.freebsd.org machines over the last 3-4 months and came across these stale files on a machine that was being decommissioned. When I was building the replacement I didn't include them. The cvs exporter was running on a machine that was broken into. The entire machine, code, exporters and cvs repository were considered tainted. As the exported src cvs tree has been deprecated for years, we should have just turned it off, Instead we salvaged and reviewed what we could, threw together a really quick and dirty exporter replacement and made it run for a little longer. It really is on its last legs. Note that there is no practical way to audit a cvs tree after an incident like that, especially a deprecated tree at that. cvs for /usr/src was deprecated in October 2008. The original plan for running the exporter for 2-3 months as a transition aide ran a little longer than planned. The branch support timeline is listed here: http://www.freebsd.org/security/ As things stand right now, this is the exporter's run schedule: * RELENG_6: Updates once a day, probably turning off on Feb 28th. * RELENG_7: Updates hourly, probably turning off on Feb 28th at EOL * RELENG_7_4: Updates hourly, probably turning off on Feb 28th at EOL * RELENG_8: Updates hourly * RELENG_8_3: Updates hourly * RELENG_9: Updates hourly * RELENG_9_0: Updates hourly * src-HEAD: Updates daily, probably turning off on Feb 28th. * ports-HEAD: Updates hourly, definitely turning off on Feb 28th. That's about what the limit of what the machine can handle. When folks go on a commit spree, the poor thing runs its disks white-hot for a few hours to catch up. No new branches will ever make it into cvs. eg: no RELENG_9_2. You'll have to get them from svn, just like getting updates to the older branches. Its also worth noting that all of the RELENG_9 series were released from the subversion tree - cvs was never involved. If there's an 8.4, it'll have to be built from svn as well. We have some significant problems with both ezm3 and cvsup itself (which is written in Modula-3). It basically is an inverse compatability binary.. The runtime code uses the oldest available versions of syscalls that it can, mostly the FreeBSD-4 versions. Emulation for some of the more exotic functionality - particularly signals - has become ... problematic .. lately. It has memory corruption problems. The cvsup/cvsupd servers break regularly when they corrupt their checkouts files and fetch the same data over and over and over again, crashing each time. And worse.. cvsup/cvsupd doesn't understand the version of cvs we have in the freebsd tree. *Every* *single* *commit* causes a checksum error and re-fetch. For the cvs/rcs ,v files, it degenerates into the old sup(1) mode - not even rsync. It is more efficient to transport the src cvs repository with rsync + rsyncd these days than cvsup/cvsupd. I'm sorry, but it is time to move on. Understood. --Chris -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
Hi, On Wed, 02 Jan 2013 17:02:11 +0100 Matthias Andree mand...@freebsd.org wrote: Am 02.01.2013 06:31, schrieb Erich Dollansky: Hi, Thank God! I'd hate to think that after unwinding years accumulated CVS process, to rewind it for SVN, only to have to do it again for GIT, just seems a bit masochistic. do not worry. It will come. Seriously, I do not understand many changes especially when there is a system in place which does not affect a running system at all but things inside the OS still could be improved. The migration was made in order to get things inside the OS ... improved at all. Developers were fed up wasting too much time struggling with CVS itself rather than working on the things inside the OS. I hightly doubt that the efforts spent now are worth this. It would have been so much easier and smoother to make the change with 10.0. A normal user does not expect any changes of this kind in a x.1 release. But it also makes one other problem obvious. The ports tree has no version numbers. So, even if the switch would have been made with the 10.0 release, it would have been the same problem for the ports tree. Even today, the handbook states only two sites for SVN and a long list for CVS. Wouldn't it have been a bit more practical to build the infrastructure first and then pull the plug? What will happen to the two SVN servers when no others come up soon? Is the user base so small that two servers are able to handle the traffic? Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: stable 9.1, bge and ipmi not cooperating
On Wed, Jan 02, 2013 at 08:33:41AM +0200, Daniel Braniss wrote: Hi, the last batch of changes to bge caused the ipmi to stop working on a Sun Fire X2200 M2, and bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x009003 mem 0xfdff-0xfdff,0xfdfe-0xfdfe irq 17 at device 4.0 on pci6 bge0: CHIP ID 0x9003; ASIC REV 0x09; CHIP REV 0x90; PCI-X 133 MHz miibus2: MII bus on bge0 bge1: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x009003 mem 0xfdfc-0xfdfc,0xfdfb-0xfdfb irq 18 at device 4.1 on pci6 bge1: CHIP ID 0x9003; ASIC REV 0x09; CHIP REV 0x90; PCI-X 133 MHz miibus3: MII bus on bge1 Could you narrow down which revision broke IPMI? And what problems are you seeing? I don't have IPMI-capable controller to test. IPMI support for old controllers(pre-5717 controllers) was not complete and it was luck if it worked on a couple of controllers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: stable 9.1, bge and ipmi not cooperating
On Wed, Jan 02, 2013 at 08:33:41AM +0200, Daniel Braniss wrote: Hi, the last batch of changes to bge caused the ipmi to stop working on a Sun Fire X2200 M2, and bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x009003 mem 0xfdff-0xfdff,0xfdfe-0xfdfe irq 17 at device 4.0 on pci6 bge0: CHIP ID 0x9003; ASIC REV 0x09; CHIP REV 0x90; PCI-X 133 MHz miibus2: MII bus on bge0 bge1: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x009003 mem 0xfdfc-0xfdfc,0xfdfb-0xfdfb irq 18 at device 4.1 on pci6 bge1: CHIP ID 0x9003; ASIC REV 0x09; CHIP REV 0x90; PCI-X 133 MHz miibus3: MII bus on bge1 Could you narrow down which revision broke IPMI? And what problems are you seeing? I don't have IPMI-capable controller to test. IPMI support for old controllers(pre-5717 controllers) was not complete and it was luck if it worked on a couple of controllers. first approximation: kernels upto Oct 5th work OK. so it must be one of these: changeset: 16420:855e9b949c7a branch: 9 user:yongari date:Mon Nov 26 04:39:41 2012 + summary: MFC r242426: changeset: 16419:5fa365c1dcdb branch: 9 user:yongari date:Mon Nov 26 04:34:05 2012 + summary: MFC r241983-241985: changeset: 16418:b69de3b6a9e8 branch: 9 user:yongari date:Mon Nov 26 04:25:41 2012 + summary: MFC r241438: changeset: 16416:564dcb92a91e branch: 9 user:yongari date:Mon Nov 26 04:10:27 2012 + summary: MFC r241436: changeset: 16414:a49ee7f76f76 branch: 9 user:yongari date:Mon Nov 26 02:41:30 2012 + summary: MFC r241388-241393: changeset: 16413:0f885258cea4 branch: 9 user:yongari date:Mon Nov 26 02:31:28 2012 + summary: MFC r241215-241216,241219-241220,241341,241343: changeset: 16308:27fd493a855c branch: 9 user:dim date:Mon Nov 12 07:34:05 2012 + summary: MFC r242625: changeset: 16169:e292988ae112 branch: 9 user:gavin date:Wed Oct 24 19:04:17 2012 + summary: Merge r240680 from head: btw, if you send me patches I can try them out cheers, danny PS: I'm sorry I caught this now, but these machines are production, and I didn't want to touch them :-( ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Does / Is anyone maintaining CVS for FreeBSD?
Am 03.01.2013 01:50, schrieb Erich Dollansky: Hi, On Wed, 02 Jan 2013 17:02:11 +0100 Matthias Andree ...@FreeBSD.org wrote: Please do not quote addresses. Not all web archives and copies hide them properly. The migration was made in order to get things inside the OS ... improved at all. Developers were fed up wasting too much time struggling with CVS itself rather than working on the things inside the OS. I hightly doubt that the efforts spent now are worth this. It would have been so much easier and smoother to make the change with 10.0. Regarding versions, please read the relevant information: the relevant decision was made years ago, and the version number you slap at the switch is a moot point. A security incident pushed things forward in an unscheduled way, and prompted the project to expedite some infrastructure works that had been pending, because work was required to rebuild major parts of it anyways. A normal user does not expect any changes of this kind in a x.1 release. A normal user does not care about what happens in between releases beyond security updates and other errata corrections, but uses freebsd-update to upgrade from one pre-compiled release to a newer, and I have also observed that people need to recompile custom kernels less often than with older FreeBSD releases. Anything else is talking about doing FreeBSD development. But it also makes one other problem obvious. The ports tree has no version numbers. So, even if the switch would have been made with the 10.0 release, it would have been the same problem for the ports tree. That, too, was discussed, and dismissed due to lack of manpower to look after a versioned tree, on the relevant -ports list. This item crops up every so often, but stable@ is not the right list to discuss this on. For users, again, portsnap is the tool to use. Anything else is talking about doing FreeBSD development. Even today, the handbook states only two sites for SVN and a long list for CVS. Wouldn't it have been a bit more practical to build the infrastructure first and then pull the plug? What will happen to the two SVN servers when no others come up soon? A long list [of sites] for CVS is required to overcome load problems. I have not yet found SVN servers lacking in performance, whether I was checking out FreeBSD 9 sources, or the ports tree. Updates are much quicker IMO than they ever were with CVS, even with a local c[v]sup copy of the CVS sources on the same computer. You would not provision more servers unless there is a need to. I suppose more would be added should the need arise. And it is really recommended that users read the existing material on the list archives before re-iterating. (We should possibly just respond with a list of URLs :)) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
