how does gmirror start up?
I am running a 6.3 system and have had various problems with disk reliability on a key filesystem, probably down to SCSI hardware or drivers. I'm intending to replace that SCSI disk with a pair of SATA disks ad6/7, using gmirror as gm0 (while keeping ad4 as our boot disk). I have set up the mirror and right now I'm part-way through using rsync to transfer the data. But I have a question concerning the underlying operation of GEOM, which is troubling me. I have read the various man pages and handbook pages relating to GEOM and gmirror, but they don't seem to answer this. When I reboot the system, gmirror comes up (because of the line in /boot/loader.conf) and gm0 appears, backed by ad6/7. Where is this configuration information stored? That is, how does the system know to make gm0, with ad6/7 as the backing store. I would expect there to be a file somewhere in /etc with this config information, but I don't see it in the documentation. From reading gmirror(8), I understand that there is a label sector at the ends of ad6 and ad7, identifying them as parts of gm0. But that config information is back-to-front: at boot time the system knows from /etc/fstab that it needs gm0; how does it find the underlying disks? Does the system search the ends of all physically-attached disks, looking for GEOM labels, and automatically make any corresponding GEOM devices? Surely not (that would mean, for instance, that if I took one of these disks out of this machine and put it into another FreeBSD system then that machine would automatically set up gm0 with this disk). Possibly I'm just being dense. Can someone enlighten me? Nick Barnes Ravenbrook Limited ___ 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: Root exploit for FreeBSD
At 2009-12-11 11:29:44+, $witch writes: > but i look in syslogs of some FreeBSD internet server and there is a great > evidence that some "botnets" are (again) tryng simple combination of > uid/pwd. # always, everywhere: PasswordAuthentication No Nick B ___ 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: editing a binary file
If your Fortran file has the same word size and enddian-ness as your
C, this simple program convert.c will strip all the record length
fields. I just knocked it up now, no warranty, etc, but it works for
me. Use as a pipe:
$ ls
convert.c test.f
$ gcc -Wall -Werror -ansi -pedantic convert.c -o convert
$ gfortran44 test.f -o test
$ ./test
$ ls -l test-output
-rw-r--r-- 1 nb nb 2460 Dec 18 11:17 test-output
$ ./convert < test-output > test-converted
$ ls -l test-converted
-rw-r--r-- 1 nb nb 2420 Dec 18 11:18 test-converted
$
The code does a fair amount of checking; if you get one of the error
messages, let us know. The most obvious unchecked problem is a short
read, which will complain about mismatched lengths.
If your Fortran has different word sizes or enddian-ness (e.g. most of
the Fortran output files I use on the Clear Climate Code project
<http://clearclimatecode.org/> are generated on big-endian machines),
you will need to add code to tweak the 'size' value after reading it,
and when checking the record-end marker.
Nick B
/* convert.c: remove record length fields from Fortran output file. */
/* Nick Barnes, Ravenbrook Limited, 2009-12-18 */
#include
#include
#include
#include
int main(void)
{
long size;
char *buf;
ssize_t bytes;
assert(sizeof(size) == 4);
while(bytes = read(0, (void*)&size, sizeof(size))) {
if (bytes < 0) {
fprintf(stderr, "read() returned %ld\n", bytes);
exit(1);
}
if (size <= 0) {
fprintf(stderr, "Read bad record length %ld\n", size);
exit(1);
}
buf = (char*)malloc(size + sizeof(size));
if (!buf) {
fprintf(stderr, "Couldn't allocate buffer of %ld
bytes\n",
size + sizeof(size));
exit(1);
}
bytes = read(0, buf, size + sizeof(size));
if (bytes <= 0) {
fprintf(stderr, "read() returned %ld\n", bytes);
exit(1);
}
if ((*(long*)(buf+size)) != size) {
fprintf(stderr, "Mismatched record lengths: %ld, %ld\n",
size, *(long*)(buf+size));
exit(1);
}
write(1, buf, size);
free(buf);
}
return 0;
}
___
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: editing a binary file
At 2009-12-18 16:33:49+, Warren Block writes: > per...@pluto.rain.com wrote: > > Greg Larkin wrote: > > > ... > > > > truncate -4 myfile should get rid of the last four bytes. Maybe > > > > there's a similar efficient way to truncate the start of a file. > > > > > > This should do it: > > > > > > dd if=oldfile of=newfile bs=1 skip=4 > > > > Or, perhaps marginally more efficient: > > > > dd if=oldfile of=newfile bs=4 skip=1 > > It would be nice to avoid the file copy, but maybe there's no way to do > that. The small buffer size for dd will probably make copies of > multi-gig files slow. This might be faster: > > tail -c +5 myfile > outfile > truncate -4 outfile > > (Has anyone mentioned that you can edit binary files interactively with > vi yet? No? Well, it's horrific and surely has interesting failure > modes. And there are probably disadvantages also.) All very interesting, but the OP is wanting to lose all the Fortran record markers, not just the first (and last) four bytes of the file. The record markers precede and follow each record, and give the record's length. The size and enddian-ness of the record marker itself depends on the Fortran implementation. Nick B ___ 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: Where is gfortran in FreeBSD 7.2 Release (i386)?
At 2009-12-21 23:31:13+, Erik Trulsson writes: > Install the lang/gcc44 port which includes Fortran support. The Fortran > compiler will be installed as gfortran44. Somewhat frustrating that the lang/gcc42 port used to include Fortran, and no longer does, and (ISTR) the same goes for lang/gcc43. This means that portupgrade may automagically remove Fortran. If you find your Fortran installation has mysteriously vanished, this may well be the cause. It was for me. Nick B ___ 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: clicky driver
At 2009-12-26 09:36:14+, Matthew Seaman writes: > Uh, it was done years ago. Look at the xset(1) manual page -- there are > options there to turn on key-click. They've been there since before the > millennium as I recall. Most people find key-click intensely annoying (even > more so if it's on someone else's machine) so it's turned off by default. I seem to recall an irritating colleague who had click turned on, circa 1990. Nick B ___ 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"
better disk reliability on a desktop machine
I've been running FreeBSD on servers and on my desktop since about 2.2.2. My current desktop machine is set up for cvsup, although I haven't done 'make buildworld' for a while (uname says 4.9-RELEASE). I don't have any good backup system in place for this machine. I was thinking "it's just a desktop". But these days it does have a boatload of personal data on it (e.g. digital photos). So shoot me. My main disk (ad0: 114473MB ) is having hard errors. Shoddy rubbish: I've only had it a couple of years. Past experience suggests that it's going to take me three or four days to sort this out (get a new disk, recover what I can from the old one, repair the OS installation with cvsup/buildworld/installworld, repair packages and ports in a similar fashion, figure out what's missing from my files and scratch around in my inadequate personal backups to recover what I can). I don't want to have to do all that ever again, after this iteration. So I'm thinking I probably want to move to a RAID mirror filesystem, and keep some sort of quality backups offsite. 1. RAID mirror filesystem questions: 1a: should this be vinum? I have read and can follow the handbook instructions for a vinum root filesystem. 1b: Will it help to upgrade to 5.x, to get this to go smoothly? 2. taking backups offsite. Seems to me that the best route is a number of external firewire hard disks. This machine doesn't have motherboard firewire, so I'll need to get a PCI firewire board. 2a: Recommendations for an affordable PCI firewire board? 2b: Should I upgrade to 5.x for the better firewire hardware support? 3c: Opinions on using firewire hard disks for this at all? Would I be better off writing DVDs? 3. making backups. 3a: I'm used to dump/restore, but it seems to me that rsync might be a better tool for this, as it would allow me to mount and browse the backup. Opinions? Nick Barnes ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
identifying filesystem blocks (was Re: better disk reliability on a desktop machine)
At 2005-07-15 17:01:18+, Chuck Swiger writes: > Nick Barnes wrote: > [ ... ] > > I don't want to have to do all that ever again, after this iteration. > > You've had a learning experience, I see. :-) Yeah, and I've had them before, and this time enough is enough. On a related subject, the last time I lost a disk, or maybe the time before, I asked on one of these lists whether there is a tool which will identify the files (or inodes, or other filesystem metadata) which are affected by one or more bad blocks. At the time I was told that there is no such tool, and started to write my own. Maybe this time around I'll finish the tool and distribute it. Semi-automated binary-chop use of dd tells me that the following blocks in my filesystem are broken: 65255940, 65255941, 65255942, 65255943, 65255944, 65255954, 65255965, 65256256, 65257133, 65257134, 65257514, 66713152, 66713158, 66713164, 66713536, 66713537, 66714306, 66714308, 66715648, 66715650 but without a suitable tool this information is useless. Incidentally, two weeks ago I recovered a broken filesystem on a 4.10 server machine by dd'ing the working sectors (i.e. all but 2) onto a freshly newfs'ed partition. The broken filesystem wouldn't fsck at all: some metadata was lost to a bad sector and fsck borked out in phase 2. But after the dd's (i.e. with those bad sectors replaced with metadata fresh from newfs), fsck told me that the recovered filesystem was fine. As it happens, the filesystem was the repository for an SCM system (Perforce) with internal checksums: after recovery we checked those out and they all passed. One interesting aspect of that war story is that I got one of the dd commands wrong the first time, and tried to fsck a filesystem which was partly Just Plain Missing. The whole system went down: network connections dropped and completely unresponsive at console, including ctrl-C, ctrl-T, alt-Fn, and ctrl-alt-del. It seems to me that fsck shouldn't be able to do that Nick Barnes ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: better disk reliability on a desktop machine
At 2005-07-15 17:01:18+, Chuck Swiger writes: > Nick Barnes wrote: > [ ... ] > > I don't want to have to do all that ever again, after this iteration. > > You've had a learning experience, I see. :-) Here are my previous questions on the related subject, some 4 years ago now: <http://docs.freebsd.org/cgi/getmsg.cgi?fetch=872461+0+archive/2001/freebsd-questions/20010617.freebsd-questions> Nick B ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: better disk reliability on a desktop machine
At 2005-07-15 19:35:55+, Chuck Swiger writes: > As someone else suggested, you can also stick things like config > files into version control (like CVS, subversion, etc), and then > back that up via the mechanism above. We do this; all our system config files (except /etc/passwd) are in Perforce. Nick B ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: better disk reliability on a desktop machine
At 2005-07-15 23:58:27+, Alex Zbyslaw writes: > Nick Barnes wrote: > > >Here are my previous questions on the related subject, some 4 years > >ago now: > > > ><http://docs.freebsd.org/cgi/getmsg.cgi?fetch=872461+0+archive/2001/freebsd-questions/20010617.freebsd-questions> > > > > > Shame no-one answered your badsect question. Did you ever figure it out? No. I hope to have enough time to code this up myself this time. It's a Small Matter of Programming to grovel over the filesystem to figure out what a particular sector does. I'm a little disappointed that fsdb doesn't do this. Maybe I should start by hacking on fsdb. I have recently discovered the "conv=noerror,sync" option to dd. In combination with a background shell script which repeatedly runs "atacontrol mode 0 udma6 udma6", this lets me recover all the readable bits from a broken filesystem quite fast. Nick B ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
