[ZFS] recover destroyed zpool - what are the available options?
I had a second pool on another partition of the same HDD, which was in the same degraded state as the bsdr pool. The data on that pool had been backed-up previously. I decided to try the export & re-import method on that pool (-Z gives message: invalid option 'Z'). Result: # zpool export oldpool # zpool import -D -f -R /mnt -N -F -n oldpool Now the pool just disappears. # zpool list -> does not show oldpool # zpool import -> no pools available to import So the export & re-import method is NOT the way to do this. -- View this message in context: http://freebsd.1045724.n5.nabble.com/ZFS-recover-destroyed-zpool-what-are-the-available-options-tp5800299p5801470.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
9.1-release bridge config at startup not working
Hello list After pretty much of googling I was able to make this bridge setup up and running: cloned_interfaces="bridge0" ifconfig_bridge0="addm igb6 addm igb7" ifconfig_bridge0_alias0="inet x.x.x.x netmask x.x.x.x" ifconfig_igb6="up" ifconfig_igb7="up" however I'm running xorp pim multicast router on the box as well and it complains about not being able to get the primary IP address of bridge0. And I need xorp running on that subnet. (after manually assigning an IP to bridge0, bridge0 becomes unresponsive) I tried autobridge according to some sparse "documentation" found, but autobridge with setup: cloned_interfaces="bridge0" autobridge_interfaces="bridge0" autobridge_bridge0="igb6 igb7" ifconfig_bridge0="inet x.x.x.x netmask x.x.x.x" ifconfig_igb6="up" ifconfig_igb7="up" does not start at all. I end up with having only igb6 added in bridge0 without an IP address. Well, I would gladly live without a bridge ;) if somebody could give me a hit how to protect a group of servers on the same subnet as the router is. Without a need of NAT or IP changes. I need a DMZ, so I thought I'd simply put the boxes behind a filtered bridge. Seems like it's not that easy as it sound. Thank you very much for any kind of help/advice Peter Huncar ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Restaging from scratch
On Thu, 4 Apr 2013, Polytropon wrote: On Wed, 3 Apr 2013 17:16:35 -0400, Grant Peel wrote: If anyone is willing to explain step by step, how to boot, create the filesystems, and make the disk bootable using 9.1 & gpart etc I would appreciate it! Obtain a CD or DVD image, or a USB stick image, and create the media as explained in The FreeBSD Handbook. Booting should not be harder than inserting the media into the appropriate slot of the machine. :-) For initializing disks with gpart I found Warren Block's article very helpful: http://www.wonkity.com/~wblock/docs/html/disksetup.html There are also sections covering the topic both in The FreeBSD Handbook and the FAQ, but this article is a very good "concentrate". Aw shucks; thanks. For a USB bootable FreeBSD, mfsBSD is more capable than the install CD/USB: http://mfsbsd.vx.sk/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Restaging from scratch
On Wed, 3 Apr 2013 17:16:35 -0400, Grant Peel wrote: > If anyone is willing to explain step by step, how to boot, create the > filesystems, and make the disk bootable using 9.1 & gpart etc I would > appreciate it! Obtain a CD or DVD image, or a USB stick image, and create the media as explained in The FreeBSD Handbook. Booting should not be harder than inserting the media into the appropriate slot of the machine. :-) For initializing disks with gpart I found Warren Block's article very helpful: http://www.wonkity.com/~wblock/docs/html/disksetup.html There are also sections covering the topic both in The FreeBSD Handbook and the FAQ, but this article is a very good "concentrate". -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Restaging from scratch
On Wed, Apr 3, 2013 at 4:16 PM, Grant Peel wrote: > > If anyone is willing to explain step by step, how to boot, create the > filesystems, and make the disk bootable using 9.1 & gpart etc I would > appreciate it! > The easiest way is to boot off of USB memstick image and use the installer to partition and install the OS. Instructions are in the handbook as always. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Restaging from scratch
Hi all, I have now completed creating a new server from scratch using FreeBSD 9.1 and ports. The new setup uses: /, /usr, /var and /home. These filesystems have been dumped to a memory stick (root.dump, var.dump etc). The plan now is to completely zero out the drives on the other servers and use these file systems to build anew. The way I would have done it with pre 9.1 (i.e. 8.x) would have been to boot using a live cd based filesystem, zero out the drive, create the 4 needed filesystems using the graphical fdisk and disklable, mount the memstick and rebuild the filesystems using the dumps. I am at a bit of a loss as to how to do this using gpart. If anyone is willing to explain step by step, how to boot, create the filesystems, and make the disk bootable using 9.1 & gpart etc I would appreciate it! Fyi the disk would be da0 (SCSI 74G ULTRA 320). -G ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Recipie for CPU souffle'
On Wed, 03 Apr 2013 08:51:21 -0700, Carl Johnson wrote:
> Polytropon writes:
>
> > On Tue, 02 Apr 2013 12:55:20 -0700, Ronald F. Guilmette wrote:
> >
> > No, that does not work. Read the manpage to recognize clearly
> > _what_ kind of input the /dev/speaker device accepts. It does
> > not understand WAV files.
> >
> > However, try this example (cw.sh):
> >
> > #!/bin/sh
> >
> > read -p "CW ===> " TEXT
> > echo ${TEXT} | morse | awk '{
> > if(length($0) == 0)
> > printf("P4\n");
> > else {
> > gsub(" dit", "P32L32E", $0);
> > gsub(" di", "P32L32E", $0);
> > gsub(" dah", "P32L8E", $0);
> > printf("%sP16\n", $0);
> > }
> > }' | dd bs=256 of=/dev/speaker > /dev/null 2>&1
> >
> > This script doesn't require any non-OS components. You can use
> > it as a basis to build a program that will send you system messages
> > in an audible way in morse code... :-)
>
> Have you looked at the morse man page lately, specifically the -p
> option? :-) Just try 'morse -p sos' to test it.
That's actually quite cool, didn't know about that - but the
script shown is already old, so _maybe_ I have written it
when -p hasn't been introduced yet. And note -p does have
a better "space and pausing melody".
A nice means to transmit system messages! :-)
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Recipie for CPU souffle'
Polytropon writes:
> On Tue, 02 Apr 2013 12:55:20 -0700, Ronald F. Guilmette wrote:
>
> No, that does not work. Read the manpage to recognize clearly
> _what_ kind of input the /dev/speaker device accepts. It does
> not understand WAV files.
>
> However, try this example (cw.sh):
>
> #!/bin/sh
>
> read -p "CW ===> " TEXT
> echo ${TEXT} | morse | awk '{
> if(length($0) == 0)
> printf("P4\n");
> else {
> gsub(" dit", "P32L32E", $0);
> gsub(" di", "P32L32E", $0);
> gsub(" dah", "P32L8E", $0);
> printf("%sP16\n", $0);
> }
> }' | dd bs=256 of=/dev/speaker > /dev/null 2>&1
>
> This script doesn't require any non-OS components. You can use
> it as a basis to build a program that will send you system messages
> in an audible way in morse code... :-)
Have you looked at the morse man page lately, specifically the -p
option? :-) Just try 'morse -p sos' to test it.
--
Carl Johnsonca...@peak.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: [ZFS] recover destroyed zpool - what are the available options?
Volodymyr, thank you very much for answering. A strange problem is that ZFS thinks the pool is on-line: # zpool list NAMESIZE ALLOC FREECAP DEDUP HEALTH ALTROOT bsdr - - - - - FAULTED - So when I try to import, it objects. I can think of 2 things to do: a- export the pool first, then re-import b- Disconnect the original hdd / create pool bsdr on another hdd@s small gpt partition / re-connect the original hdd / somehow force the import or add the original pool to the newly created bsdr pool, and maybe the original data will come back on line?? What would you suggest? Thanks again. -- View this message in context: http://freebsd.1045724.n5.nabble.com/ZFS-recover-destroyed-zpool-what-are-the-available-options-tp5800299p5801356.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: [ZFS] recover destroyed zpool - what are the available options?
2013-04-03 18:17, Beeblebrox wrote: If anyone has ideas, zdb -C is now giving me detailed output. zpool status is: You are mostly out of luck. The worst thing about ZFS is that when something happens ZFS just gives you NO. I posted this before, you can try this too: zpool import -D -f -R /bsdr -N -F -n -Z bsdr -D work on deleted pools -f force import -R custom root folder to not interfer with your mounts -N do not mount filesystems -F recovery mode - tries last transactions to find a good one -n doesn't modify data on disk while in recovery mode -Z (undocumented) verify transactions in recovery mode by doing a partial scrub (?). I hope this will help you... Anyway you can try any other ZFS implementation. For example FreeBSD loader can read files too while booting. -- Sphinx of black quartz, judge my vow. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
[ZFS] recover destroyed zpool - what are the available options?
If anyone has ideas, zdb -C is now giving me detailed output. zpool status is: NAMESTATE READ WRITE CKSUM bsdrUNAVAIL 0 0 0 12606749387939346898 UNAVAIL 0 0 0 was /dev/ada0p2 zdb -C gives: bsdr: version: 5000 name: 'bsdr' state: 0 txg: 41845 pool_guid: 17852168552651762162 hostid: 2739729201 hostname: '' vdev_children: 1 vdev_tree: type: 'root' id: 0 guid: 17852168552651762162 create_txg: 4 vdev_stats[0]: 348476133 vdev_stats[1]: 4 vdev_stats[2]: 3 vdev_stats[3]: 0 vdev_stats[4]: 0 vdev_stats[5]: 0 vdev_stats[6]: 0 vdev_stats[7]: 0 vdev_stats[8]: 0 vdev_stats[9]: 0 vdev_stats[10]: 0 vdev_stats[11]: 0 vdev_stats[12]: 0 vdev_stats[13]: 0 vdev_stats[14]: 0 vdev_stats[15]: 0 vdev_stats[16]: 0 vdev_stats[17]: 0 vdev_stats[18]: 0 vdev_stats[19]: 0 vdev_stats[20]: 0 vdev_stats[21]: 0 vdev_stats[22]: 0 vdev_stats[23]: 0 vdev_stats[24]: 0 vdev_stats[25]: 0 children[0]: type: 'disk' id: 0 guid: 12606749387939346898 path: '/dev/ada0p2' phys_path: '/dev/ada0p2' whole_disk: 1 metaslab_array: 30 metaslab_shift: 31 ashift: 9 asize: 287855869952 is_log: 0 create_txg: 4 vdev_stats[0]: 348476133 vdev_stats[1]: 4 vdev_stats[2]: 1 vdev_stats[3]: 0 vdev_stats[4]: 0 vdev_stats[5]: 0 vdev_stats[6]: 287767527424 vdev_stats[7]: 18446743785853681664 vdev_stats[8]: 0 vdev_stats[9]: 0 vdev_stats[10]: 0 vdev_stats[11]: 0 vdev_stats[12]: 0 vdev_stats[13]: 0 vdev_stats[14]: 0 vdev_stats[15]: 0 vdev_stats[16]: 0 vdev_stats[17]: 0 vdev_stats[18]: 0 vdev_stats[19]: 0 vdev_stats[20]: 0 vdev_stats[21]: 0 vdev_stats[22]: 0 vdev_stats[23]: 0 vdev_stats[24]: 0 vdev_stats[25]: 0 features_for_read: -- View this message in context: http://freebsd.1045724.n5.nabble.com/ZFS-recover-destroyed-zpool-what-are-the-available-options-tp5800299p5801335.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Recipie for CPU souffle'
On Wed, 03 Apr 2013 12:35:49 +0100, Arthur Chance wrote: > I'm not sure even the music industry's > paranoid lawyers would worry about something that sounds that bad, and > any half way sane judge would throw it out as "de minimis". They care about the crappy glaring sound of 8 bit, 11 kHz, mono, with low bitrate and ugly "quality" which comes out of almost any smartphone these days. And you don't even need a judge to bully people or scare them into paying money (at least in Germany a lawyer can work "for your" and have you pay money even if you've never met him), de impera et virtutibus loquitur, as the lawman would say. ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Recipie for CPU souffle'
On Tue, 02 Apr 2013 19:10:59 -0700, Ronald F. Guilmette wrote:
> See how the entire ioctl() interface for these device types is completely
> documented IN THE MAN PAGE? That's the way it should be... None of this
> rooting around in the sources for something that should have been documented
> properly, external to the kernel sources.
I agree that especially to developers, that sounds logical
and very helpful. Seems that manpages do not aim for that
goal anymore...
> It doesn't have to cover "everything". But it _should_ completely describe
> the programatic interface.
At least is leaves questions, like stating "use the syscalls
in order to...", and the reader is left with the most obvious
question: _which_ syscalls?
> But like I said, somewher along the line, a lot of man page writers
> apparently got lazy... VERY lazy.
But keep in mind they're still alive! Judging from the manpages
of... *cough* can I say this? YOu know, more prominent open
source operating systems for desktops... they're usually much
worse _if_ there is a manpage. In most cases, there's none.
> >> Second order question: Why can't I just pipe a .wav file to the
> >> /dev/speaker device file and have it play? Wouldn't that make quite
> >> a lot of sense?
> >
> >No, that does not work.
>
> Apparently not.
>
> Why it doesn't work (or couldn't work) is less clear.
The speaker interface to the _PC speaker_ is not a DSP. It's
programming is much simpler. The "note language" that it
uses on FreeBSD is much more than other interfaces offer.
Better ones have stuff like pitch, duration, turn off.
Worse ones only can emit ^G (BEL character) and have
some terminal driver make a "beep" and nothing more.
> >However, try this example (cw.sh):
> >
> >#!/bin/sh
> >
> >read -p "CW ===> " TEXT
> >echo ${TEXT} | morse | awk '{
> > if(length($0) == 0)
> > printf("P4\n");
> > else {
> > gsub(" dit", "P32L32E", $0);
> > gsub(" di", "P32L32E", $0);
> > gsub(" dah", "P32L8E", $0);
> > printf("%sP16\n", $0);
> > }
> >}' | dd bs=256 of=/dev/speaker > /dev/null 2>&1
>
> Ummm
>
> % /tmp/beeps.sh
> CW ===> x
> /tmp/beeps.sh: morse: not found
Seems your OS is installed incompletely?
% which morse
/usr/games/morse
This is on my home 8.2 system. The "morse" program is part of
the "games" distribution. Maybe you've decided to leave it out
when installing your system?
Just in case, you can easily install it from the source tree,
cd /usr/src/games/morse/ and make install.
> >But probably not required, because the simplest test you could
> >construct is something like
> >
> > % echo "c" > /dev/speaker
>
> Humm... now _that_ is both interesting and enlightening.
I actually remember having used something comparable on
BASIC, when my brain wasn't fully developed yet. :-)
echo "cdefgab>c" > /dev/speaker
It's still a nice interface to "generate attention sounds"
in case you want to make an audible alarm or signal for
some specific action, like a program which has aborted,
an unverified backup or the successful completition of
a task.
> >Can you hear a sound?
>
> Yes.
This means two things: Your speaker is present and works, and
the /dev/speaker mechanism also works.
> >> I wonder if whoever write and distributed this realized that he/she could
> >> be sued for copyright infringement for about 5 of the simple tunes that are
> >> embedded in that thing. Sad but true.
> >> :-(
> >
> >Is it really that bad already?
>
> Haven't you noticed?
I _try_ not to notice it, because in some cases, it's totally
insane what's happenning on that front...
> In the future, there will be no more engineers... only lawyers.
Two lawyers, three opinions. ;-)
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Recipie for CPU souffle'
On 04/02/13 20:55, Ronald F. Guilmette wrote: In message <515aae16.9030...@qeng-ho.org>, you wrote: On 04/02/13 04:02, Ronald F. Guilmette wrote: [Overheating CPU war story snipped.] ... I've had a fan jam that way. Cable ties are your friends. Yes. P.P.S. I have a (relatively) monster sized heatsink in this system, and it sits atop a quite modest 2.7GHz single-core Athlon, so it is not at all surprising that the ``stable'' CPU temp is around 30c (86f). I tend to use Intel processors so I'm not familiar with your exact processor, but does the amdtemp kernel module work for it? I dunno. This is the first I have ever heard of that. Is there any specific advantage to using that, relative to using mbmon? Only that it's in the base system without needing any ports. If so, you could write a shell script that loops doing "sysctl -n dev.cpu..temperature" Right, but I can do something similar also with mbmon. ..."man speaker"... Humm... I'm looking at that now and it raises more questions that it answers. First order question: Why is it that in FreeBSD there are so many man pages like this one, _purporting_ to describe some low level interface to some sort of hardware, and the man page _doesn't_ include a clear and explicit description of the relevant ioctls ? At least in this case the man page does sort of describe, in just prose, what the relevant ioctls are, but it doesn't actually show the calls explicitly. But look at the man pages for usb(4) or uart(4) or tty(4) or essentially anything you find in /usr/share/man/man4. Maybe I'm just spoiled or something, but I do seem to remember, back in the old old OLD days, that device file man pages always explicitly listed the relevant ioctls. (But then I suppose that that was SystemV I'm thinking of.) It's worth remembering that in the old**3 days the people programming Unix were doing it as part of their paid employment. These days I suspect many people hacking on FBSD have jobs, families and real lives contending with their open source work. "The job's not done until the documentation is written" is a great principle, but difficult in practice for anyone whose FBSD coding is done in snatched time. Second order question: Why can't I just pipe a .wav file to the /dev/speaker device file and have it play? Wouldn't that make quite a lot of sense? You're thinking of /dev/audio, which is a Sparc sound system workalike that plays IIRC mu-law sound (not .wav, that's got headers mixed up with the data). However, you specifically asked for something that would use the motherboard speaker, whereas /dev/audio sits over the /dev/dsp* stuff, which drives the normal external speaker audio. (man snd for that.) Historically the "type the notes" interface to /dev/speaker goes back a long way. Back in the mid 80s I worked on a Symbolics Lisp Machine that had the same interface. /usr/sbin/spkrtest might be useful Humm... well... it is at least mildly entertaining. I meant useful to look at for ideas, not use. :-) I wonder if whoever write and distributed this realized that he/she could be sued for copyright infringement for about 5 of the simple tunes that are embedded in that thing. Sad but true. Have you actually tried it? I'm not sure even the music industry's paranoid lawyers would worry about something that sounds that bad, and any half way sane judge would throw it out as "de minimis". ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
ipfw+natd port forward does not work as intended
Hi all
I'm on 192.168.1.62, the server running on 192.168.1.3 and listen to port 1234.
I want any connection going out of my machine to port 1234 to port forward to
192.168.1.3:1234.
But when I attempt to connect to 192.168.1.1:1234 , natd shows following
verbose message:
natd[2051]: Aliasing to 192.168.1.62, mtu 1500 bytes
Out {default}[TCP] [TCP] 192.168.1.62:45642 -> 192.168.1.1:1234 aliased to
[TCP] 192.168.1.62:45642 -> 192.168.1.1:1234
This is FreeBSD 8.1-RELEASE and the kernel is built with following options:
options IPFIREWALL # Enable ipfw
options IPFIREWALL_FORWARD # Enable ipfw forward
options IPDIVERT
/etc/rc.conf
--
# Enable ipfw firewall
firewall_enable="YES"
firewall_script="/etc/rc.firewall.test"
# Natd
gateway_enable="YES"
natd_enable="YES"
natd_interface="msk0"
natd_flags="-f /etc/natd.conf"
sysctl net.inet.ip.forwarding=1
/etc/rc.firewall.test
---
#!/bin/sh
IFACE=msk0
IPFW=/sbin/ipfw
${IPFW} -f flush
${IPFW} add 100 divert natd ip from any to any 1234 via ${IFACE}
${IPFW} add 6 permit ip from any to any
/etc/natd.conf
-
port 8668
log
verbose
interface msk0
redirect_port tcp 192.168.1.3:1234 1234
Is there any configuration error above?
Best regards
Unga
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
