Re: A New FreeBSD Server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wow! First I want to thank all of you who responded for the great information! As I read it all, I became more and more excited about my decision to switch to FreeBsd! And became more and more impatient with US Postal Mail! So! I went and downloaded the floppy Install Set from freebsd.org, and created the floppy install set. I set up the Dell server thus: 19GB Drives 1 through 4 in a RAID 1/0 IE 2 sets of Mirrors, in a striped array, making up the first (and bootable) container on the PERC 2 controller. The last 2 19GB Drives. I simply Mirrored into a second 19GB container. So, from the BIOS percpective I had a APROX 33GB Drive, and an additional 19GB drive available for the OS. Pretty much more than I need! (for now) So! I boot the box from boot disk, and boot is OK asked for Kernel 1 floppy, the Kernel 2 Floppy. all A-OK! Install starts, and I proceed. I run through the FDISK portion of the install; Allocate the entire first "drive" to FreeBsd, and say "AUTO". it allocates what appears to be a reasonable slice to each mount-point, and I proceed, with a "full Install" Via FTP. FreeBsd, was intelligent enough to find/use the DHCP server, and connected to "freebsd.org", and downloaded a mess of stuff!. OK; Install "successfully" completed, want to add APPS? Sure! Why not! So I picked out some editors and shells I use all the time, and PORTS went out to get them. at this point, my DSL connecton went down! Damn! I reset the router, and back up. BUT An IP change occurred and the download from the FTP site never continued! I could do nothing except "ABORT" the install! So fine! I aborted. Since I had received the "Congratulations" on an Install message, I "ASSUMED" all I had to do was re-boot from HD and go to SYSINSTALL and complete the install. NOT! On Boot, the boot-loader complained bitterly "Can't find a Kernel to boot", and dropped me to an "OK" prompt. Damn says I! Murpheys law in effect! So I just booted from the floppies again, and started the install again NOT SO! Even after another FDISK, the system knew I had data on the drives, and simply went ahead and finished what it had not completed. On end, I "exited" Install, the system re-booted, and again, it could not find a Kernel to boot! The slice/allocation was percerved, even after another "AUTO" Fdisk! Now I was upset! (BSD Damn well be more smart than LINUX!) The FDISK never wiped out all the old data. Someone NEVER thought-out this particular scenario! What do I do? Re-Format the RAID Array? and for-sure wipe out the privious install attempt? Any sugestions as to where to start again? TIA Bob -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEoGrTeoERI/Lb/ZwRAgZ8AJ9vbzhVf1Z0SmZy1AkR7XDV6+56+wCZARld SUEuIU9b9lQ1W5kswb1xCg4= =TqmE -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
New architecture support
Hi, If I have to add support for a new architecture, how do I start? I guess I need to get the build system and 'config' utility in place? How do I go about it? -aditya ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: checking zip file corruption
I found it. zip -T file.zip Thanks anyways. On 6/26/06, Ashok Shrestha <[EMAIL PROTECTED]> wrote: Hi all, I am writing code to check if incoming zip files are corrupt and the client is not willing to send a digest (like md5) of the file. I need to check if a zip file is corrupt. A Perl API is preferable but anything you can suggest is cool. I was unable to find anything on google. Perhaps one of you have done this before. I apologize for posting this on a freebsd hackers mailing list but you guys tend to be extremely intelligent. Plus I am using a bsd server :) -- Ashok Shrestha -- Ashok Shrestha ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Database on 6.1/AMD64 ?
Hi list, I'm considering switching a database server to FreeBSD 6.1/AMD64. The Opteron processor I am interested in is a dual core. I would like to know about any stories using FreeBSD/AMD64, MySQL 5.0, and two dual core processors. Will I have stability/performance issues ? Will the two dual cores kick ass, or will they give me trouble ? Any insight into this matter would be most useful. Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A New FreeBSD Server
On Mon, Jun 26, 2006 at 10:10:28AM -0400, Mike Meyer wrote: > In <[EMAIL PROTECTED]>, Dmitry Morozovsky <[EMAIL PROTECTED]> typed: > > On Sat, 24 Jun 2006, Mike Meyer wrote: > > MM> The other constraint on swap is that if you want the system to save a > > MM> core dump if it panics, you need a device to dump on that's 64Kb > > MM> bigger than ram. That's one device, not all of swap. > > This is not quite true, as there always are some unused memory regions, > > hence > > you need not add 64k to RAM size. At least, I had no trouble using swap == > > RAM > > for last 5 years or so... > > Or memory areas that aren't needed when doing the post mortem. The > question is, how do you guarantee that those are what's not going to > make it out to the dump device? The core dump routine won't even attempt to write if the swap space is too small, so there's no ambiguity as to what makes it into the core file. FreeBSD 5.x and previous try to write all of memory out so the extra 64Kb or so is necessary. Also, -CURRENT uses "minidumps" on i386 and amd64, so only memory regions of use are written out and you can get by with swap smaller than RAM. -ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: checking zip file corruption
On Mon, Jun 26, 2006 at 09:18:31AM -0400, Ashok Shrestha wrote: > Hi all, > > I am writing code to check if incoming zip files are corrupt and the > client is not willing to send a digest (like md5) of the file. Why don't you just use InfoZip's "unzip -t" flag which tests the integrity of a zip file? You can call "unzip -t" from Perl. InfoZip is in ports, archivers/unzip and archivers/zip. -- Craig Rodrigues [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ENOMEM @ RELENG_6 graid3
Dmitry Morozovsky wrote: Dear colleagues, turning on bootverbose reveals additional info to ad10: FAILURE - out of memory in start under load this machine (5 ata disks, most of their space allocated for 2 graid3's) many messages like ENOMEM 0xc6e834a4 on 0xc493c080(ad8) ENOMEM 0xc703fdec on 0xc4960480(ad10) ENOMEM 0xc6b49528 on 0xc4901400(ad0) ENOMEM 0xc6c378c4 on 0xc493ca80(ad4g) ENOMEM 0xc662b210 on 0xc4900b00(ad0f) ENOMEM 0xc6b33630 on 0xc493c380(ad4) ENOMEM 0xc7320d68 on 0xc4901400(ad0) ENOMEM 0xc6bd6948 on 0xc493c380(ad4) ENOMEM 0xc7299dec on 0xc493c200(ad6) ENOMEM 0xc6d91528 on 0xc495f700(ad6g) ENOMEM 0xc47b07bc on 0xc4960480(ad10) ENOMEM 0xc7c22bdc on 0xc493c080(ad8) Machine is rather stable; however, it panics two or three times on /ftp: bad dir ino 3454117 at offset 444: mangled entry panic: ufs_dirbad: bad dir Any hints to debug? Are you sure the filesystem is clean? Can you try unmounting it, and running an fsck_ffs on it? Also, I think this has been discussed before on freebsd-geom@, did you check the archives? Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
checking zip file corruption
Hi all, I am writing code to check if incoming zip files are corrupt and the client is not willing to send a digest (like md5) of the file. I need to check if a zip file is corrupt. A Perl API is preferable but anything you can suggest is cool. I was unable to find anything on google. Perhaps one of you have done this before. I apologize for posting this on a freebsd hackers mailing list but you guys tend to be extremely intelligent. Plus I am using a bsd server :) -- Ashok Shrestha ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ENOMEM @ RELENG_6 graid3
Dear colleagues, turning on bootverbose reveals additional info to ad10: FAILURE - out of memory in start under load this machine (5 ata disks, most of their space allocated for 2 graid3's) many messages like ENOMEM 0xc6e834a4 on 0xc493c080(ad8) ENOMEM 0xc703fdec on 0xc4960480(ad10) ENOMEM 0xc6b49528 on 0xc4901400(ad0) ENOMEM 0xc6c378c4 on 0xc493ca80(ad4g) ENOMEM 0xc662b210 on 0xc4900b00(ad0f) ENOMEM 0xc6b33630 on 0xc493c380(ad4) ENOMEM 0xc7320d68 on 0xc4901400(ad0) ENOMEM 0xc6bd6948 on 0xc493c380(ad4) ENOMEM 0xc7299dec on 0xc493c200(ad6) ENOMEM 0xc6d91528 on 0xc495f700(ad6g) ENOMEM 0xc47b07bc on 0xc4960480(ad10) ENOMEM 0xc7c22bdc on 0xc493c080(ad8) Machine is rather stable; however, it panics two or three times on /ftp: bad dir ino 3454117 at offset 444: mangled entry panic: ufs_dirbad: bad dir Any hints to debug? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A New FreeBSD Server
In <[EMAIL PROTECTED]>, Dmitry Morozovsky <[EMAIL PROTECTED]> typed: > On Sat, 24 Jun 2006, Mike Meyer wrote: > MM> The other constraint on swap is that if you want the system to save a > MM> core dump if it panics, you need a device to dump on that's 64Kb > MM> bigger than ram. That's one device, not all of swap. > This is not quite true, as there always are some unused memory regions, hence > you need not add 64k to RAM size. At least, I had no trouble using swap == > RAM > for last 5 years or so... Or memory areas that aren't needed when doing the post mortem. The question is, how do you guarantee that those are what's not going to make it out to the dump device? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A New FreeBSD Server
On Sat, 24 Jun 2006, Mike Meyer wrote: MM> The other constraint on swap is that if you want the system to save a MM> core dump if it panics, you need a device to dump on that's 64Kb MM> bigger than ram. That's one device, not all of swap. This is not quite true, as there always are some unused memory regions, hence you need not add 64k to RAM size. At least, I had no trouble using swap == RAM for last 5 years or so... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mmap() vs. character special file
Stanislav Sedov <[EMAIL PROTECTED]> writes: > You cannot mmap ata devices (as well as scsi ones), since mmap functions > was not implemented. This has nothing to do with ata or scsi; it's a GEOM issue. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
