Anyone used rsync scriptology for incremental backup?
I've seen some stuff online that made it look like using hard-link trees and then doing some rsync worked, but some of this appears to be obsoleted by new rsync features. If anyone has a pointer, that would be much appreciated. Thanks, -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
What could be causing unexpected reads to acd0?
I'm seeing this sometimes before my machine dies: Oct 26 03:28:00 belle kernel: acd0: WARNING - READ_TOC taskqueue timeout - completing request directly Oct 26 03:28:00 belle kernel: acd0: WARNING - READ_TOC freeing taskqueue zombie request Oct 26 03:30:00 belle kernel: acd0: WARNING - READ_TOC taskqueue timeout - completing request directly Oct 26 03:30:00 belle kernel: acd0: WARNING - READ_TOC freeing taskqueue zombie request Oct 26 03:32:00 belle kernel: acd0: WARNING - READ_CAPACITY taskqueue timeout - completing request directly Oct 26 03:32:00 belle kernel: acd0: WARNING - READ_CAPACITY freeing taskqueue zombie request I run the gnome desktop environment. Could it be that? I do not have this mounted. The only thing that's running around this time is /sbin/dump. I'm never at the machine when this happens. FreeBSD belle.0lsen.net 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun May 25 21:55:57 PDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Thanks, -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with dump stalling
On Oct 08, Kevin Oberman wrote: I had a system that was showing these exact symptoms David described. It did this both with -L and without. I went for about 3 months without a successful dump. I did at least two full system re-installs to no avail. Then, about 3 weeks ago, when I was about to start some serious debugging, it started working again. Nothing was touched between the last failure and the first success. I'm completely baffled! I had a lengthy discussion with Jeremy about this where he lowered the boom on my expectations with UFS2 and dump. I find the lack of a real incremental backup solution with the default filesystem in FreeBSD to be an alarming problem. Thanks, -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
More diagnostics trying to dump filesystem
This is all /really/ helpful: mksnap_ffs: Cannot create /home/.snap/dump_snapshot: Resource temporarily unavailable dump: Cannot create /home/.snap/dump_snapshot: No such file or directory From /var/log/messages: fsync: giving up on dirty 0xc524b330: tag devfs, type VCHR usecount 1, writecount 0, refcount 642 mountedhere 0xc5063a00 flags () v_object 0xc1432000 ref 0 pages 2556 lock type devfs: EXCL (count 1) by thread 0xc5e58600 (pid 5531) dev ad0s1d -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
Sep 21 08:57:54 belle fsck: /dev/ad4s1d: 1 DUP I=190 Sep 21 08:57:54 belle fsck: /dev/ad4s1d: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. Ok, so I ran fsck manually (even with -y), but yet it refuses to clear/fix whatever to the questions posed as fsck runs. What does this all mean? Thanks, -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
On Sep 21, Jeremy Chadwick wrote: Re-adding mailing list to the CC list. No, I don't think that is the case, assuming the filesystems are UFS2 and are using softupdates. When booting multi-user, fsck is run in the background, meaning the system is fully up + usable even before the fsck has started. The last time things crashed hard, the boot sequence was halted in order to run fsck. Consider using background_fsck=no in /etc/rc.conf if you prefer the old behaviour. Otherwise, boot single-user then do the fsck. Yes, I'll do this. You could also consider using clri(8) to clear the inode (190). Do this in single-user while the filesystem is not mounted. After using clri, run fsck a couple times. Ok, thanks. Also, are there any kernel messages about ATA/SCSI disk errors or other anomalies? None. In fact smartctl will not do anything now. It just prints out the quick banner message and exits immediately with no error. -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
On Sep 21, Jeremy Chadwick wrote: You could also consider using clri(8) to clear the inode (190). Do this in single-user while the filesystem is not mounted. After using clri, run fsck a couple times. Booting single-user and running fsck again seems to have corrected these errors. For some reason it said another disk was not properly dismounted (/dev/ad0s1d - /home) and so it's running fsck in the background since I booted. -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
On Sep 21, Jeremy Chadwick wrote: With regards to this specific item: can you provide the full smartctl command you're using (including device), and all of the output? I have an idea of what the problem is, but I'd need to see the output first. # smartctl /dev/ad6 smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
On Sep 21, Jeremy Chadwick wrote: The tool is behaving how it should. Try using the -a flag. Ok, I feel dumb now :) Thanks, -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Help debugging DMA_READ errors
Ok, I've had some flakiness with my 6.3-STABLE (Sun May 25 21:55:57 PDT 2008) box. I assume that these errors are indicative of a system-level problem rather than a single disk: Event 1 --- Sep 14 05:12:54 belle kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=216477719 Result: Hard reset required Event 2 --- Sep 16 02:11:09 belle kernel: ad4: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=172088735 Sep 16 02:13:08 belle kernel: acd0: WARNING - READ_TOC taskqueue timeout - completing request directly Sep 16 02:13:09 belle kernel: acd0: timeout waiting for ATAPI ready Sep 16 02:13:09 belle kernel: acd0: error issuing ATA PACKET command Sep 16 02:13:09 belle kernel: acd0: WARNING - READ_TOC freeing taskqueue zombie request Sep 16 02:13:09 belle kernel: acd0: timeout waiting for ATAPI ready Sep 16 02:13:09 belle kernel: acd0: error issuing ATA PACKET command ...last two repeating until reset... Result: Hard reset required Disk configuration: ad0: 114473MB WDC WD1200JB-32EVA0 15.05R15 at ata0-master UDMA100 ad4: 114473MB WDC WD1200JD-00GBB0 02.05D02 at ata2-master SATA150 ad6: 476940MB Seagate ST3500641AS 3.AAJ at ata3-master SATA150 I'm using one of those eSATA converter brackets in the back of the machine for ad6. I'm guessing this doesn't have to do with this problem since that disk wasn't mentioned. Any advice you can offer will be much appreciated. Thanks, -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help debugging DMA_READ errors
Hi Jeremy: Thanks for your detailed response. Here are the answers I have thus far: On Sep 16, Jeremy Chadwick wrote: acd0 is a CD/DVD drive. ad4 is a hard disk. What exactly were you doing with the system at the time these errors appeared? Were you using the CD/DVD drive? Was there a disc in the drive that was mounted? If none of these things, I'm baffled as to what would read acd0 and cause what you see here. I was not at the system at the time. I never have had a disk in the drive nor is /cdrom mounted currently. I have dump backups that run in the middle of the night on the various filesystems. Can you please provide full details of what these disks are connected to? I'd like to see dmesg output for ata0, ata2, and ata3, as well as the atapci devices those ataX devices are attached to, ditto with vmstat -i output. Are there any other errors in your logs around that time (e.g. watchdog timeouts of any kind on network devices, etc.?) # dmesg | grep -i ata atapci0: Intel ICH5 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 atapci1: Intel ICH5 SATA150 controller port 0xeff0-0xeff7,0xefe4-0xefe7,0xefa8-0xefaf,0xefe0-0xefe3,0xef60-0xef6f irq 18 at device 31.2 on pci0 ata2: ATA channel 0 on atapci1 ata3: ATA channel 1 on atapci1 I skipped the disks, of course. Additionally, it would be very useful if you could install ports/sysutils/smartmontools and provide the following output: # smartctl -a /dev/ad0 # smartctl -a /dev/ad4 See attached. http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting The bottom line is that, if the problems you're seeing are the same thing others are seeing, then you are not alone. As I said initially, finding the source of these problems is difficult, and they are often unique to each individual's machine. For some, replacing cables, the entire motherboard, disk controller, or just the PSU helped; for others, the problem disappeared on its own; in other cases, the problem was so severe that they ended up switching to Linux. I'll take a look at this page. Thanks, -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Western Digital Caviar SE family Device Model: WDC WD1200JB-32EVA0 Serial Number:WD-WMAEL1302890 Firmware Version: 15.05R15 User Capacity:120,034,123,776 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 6 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Tue Sep 16 11:11:04 2008 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (3801) seconds. Offline data collection capabilities:(0x79) SMART execute Offline immediate. No Auto Offline data collection support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities:(0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability:(0x01) Error logging supported. No General Purpose Logging support. Short self-test routine recommended polling time:( 2) minutes. Extended self-test routine recommended polling time:( 53) minutes. Conveyance self-test routine recommended polling time:( 5) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b
Re: Help debugging DMA_READ errors
On Sep 16, Mike Tancsa wrote: Would not bad cables (or trays) be consistent with symptoms like that ? i.e. the OS sees errors, but when we ask the drive, it says, what errors. I am sure there are other things that could cause this, but in the past I would start with the cables and or trays. Interestingly enough, here are the results for the disk that has the poor-man's eSATA. I would assume those read errors have something to do with cabling. -Clint smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.9 family Device Model: ST3500641AS Serial Number:3PM0Y73G Firmware Version: 3.AAJ User Capacity:500,107,862,016 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Tue Sep 16 13:41:46 2008 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED See vendor-specific Attribute list for marginal Attributes. General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 430) seconds. Offline data collection capabilities:(0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities:(0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability:(0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time:( 1) minutes. Extended self-test routine recommended polling time:( 255) minutes. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 114 096 006Pre-fail Always - 80481549 3 Spin_Up_Time0x0003 087 087 000Pre-fail Always - 0 4 Start_Stop_Count0x0032 100 100 020Old_age Always - 6 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 085 060 030Pre-fail Always - 341147812 9 Power_On_Hours 0x0032 095 095 000Old_age Always - 5037 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020Old_age Always - 9 187 Reported_Uncorrect 0x0032 100 100 000Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 050 043 045Old_age Always In_the_past 50 (Lifetime Min/Max 32/53) 194 Temperature_Celsius 0x0022 050 057 000Old_age Always - 50 (0 21 0 0) 195 Hardware_ECC_Recovered 0x001a 053 049 000Old_age Always - 154508649 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 0 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always - 0 200 Multi_Zone_Error_Rate 0x 100 253 000Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_DescriptionStatus Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error
Re: Help debugging DMA_READ errors
On Sep 16, Jeremy Chadwick wrote: That's very strange then. Something definitely tried to utilise acd0 at that hour of the night. What is acd0 connected to, ATA-wise? Again, I assume it's PATA, but I'd like to know the primary/secondary and master/slave organisation, since you are using a PATA disk too. What's the best way to give you this? Generally with disks I try to separate them from DVD/CD drives, so I don't think they are on the same chain. Is the question whether or not the DVD/CD is a slave to the PATA disk? acd0: CDRW Hewlett-Packard DVD Writer 100/1.37 at ata1-master UDMA33 Looks fine, although I swore ATA controllers listed their IRQs. atapci0 doesn't appear to have an IRQ associated with it (should be 14 or 15), so that's a little odd to me. vmstat -i would help here. interrupt total rate irq1: atkbd0 14 0 irq6: fdc0 1 0 irq12: psm0 1624 0 irq14: ata0 410187 14 irq15: ata1 225418 7 irq18: uhci2+ 111881 3 irq22: skc0 260062 9 cpu0: timer 56551841 1999 Total 57561028 2035 Okay, there are some problems with your disks, but it's going to be impossible for me to determine if the below problems caused what you saw. First, ad0: I just freed up a 300G SATA disk, so I can swap out the PATA drive if you think it's worth the effort. 1) Run smartctl -t short on /dev/ad0 and /dev/ad4. You can safely use the disks during this time. After a few minutes (depends on how much disk I/O is happening; the more I/O, the longer the test takes to complete), you should see an entry in the SMART self-test log saying Completed. Once you see that, you should run smartctl -a on the disk again, and see if the attributes labelled Offline are different than they were before. 2) Consider running smartd. I do not normally advocate this, but in your case, it may be the only way to see which attribute values are actually changing on you if/when the issue happens again. Any time a value changes, it'll be logged via syslog. You can set up smartd.conf to ignore certain attributes (e.g. temperature, since that has a tendency to fluctuate up and down a degree). I'm looking at that. The sample conf file that comes with it isn't the easiest on the eyes, so I haven't figure out what configuration I want or how to set it up yet. My external hard drive is running around 50 in that small external enclosure. That sounds bad. 190 Airflow_Temperature_Cel 0x0022 050 043 045Old_age Always In_the_past 50 (Lifetime Min/Max 32/53) 194 Temperature_Celsius 0x0022 050 057 000Old_age Always - 50 (0 21 0 0) If/when this happens again, you should be able to look at your logs and see what counters have changed. For example if you see something like Power_Cycle_Count or Stop_Start_Count increase, you have disks which are losing power. Welcome to the pain of debugging disk problems. :-) Thanks :) -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.X potentially has messed up sk0
Hi: Since upgrading from 5.4-STABLE to 6.2-RELEASE and now 6.3-STABLE, I've noticed that occasionally sk0 goes weird. I don't quite get it. I was able to connect to it via my local network, but routes to my WAN were completely hosed. So, the machine becomes unable to ping or contact anything that crosses 192.168.1.X. Taking down the interface and bringing it back up via ifconfig fixed it. However, I've seen other cases where the machine can eventually get wedged to the point that nothing can bring it back to life. So, the question is, how can I provide the FreeBSD team something tangible in the way of logs or debug information to prove this is a bug? Thanks, -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ok, so now what? Binary upgrade to 6.2-RELEASE fails
On Nov 11, Chris H. wrote: It's as simple as making your swap slice available for dumping, and adding a line in your rc.conf file. Of course you'll need to lift the information of interest from the vmcore, for the dump to be of any value. :) http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html It's really a simple process. Heh, simple is relative :) But it doesn't look that bad -- thanks for the information. I'll likely need this at some point. Unfortunately I did not have the luxury to embroil myself in debug hell with this problem since this is my mail/web machine and others depend on it. I can tolerate some downtime, but this was just getting to be too much. I just backed up the system, and installled FreeBSD 6.2-RELEASE from scratch and most things are back up and running after a night until 3am. Yuck, I don't ever want to have to deal with something like this again. Hopefully after I get brave enough I /might/ entertain jumping onto a STABLE branch again... Thanks, -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ok, so now what? Binary upgrade to 6.2-RELEASE fails
On Nov 11, [LoN]Kamikaze wrote: That's strange, I've gone right from 5.3 through to RELENG_7 without ever doing the reboots during the install process (I know that's not recommended) and I never ran into trouble. Did you accidently turn off compat6x in the kernel before you built? Did your remember to install the misc/compat6x port? Well, I wasn't upgrading to RELENG_7, so compat6x shouldn't have been an issue. And any compatibility library should not have been necessary when doing a binary upgrade. I was trying to boot a GENERIC kernel in the upgrade process. My 5.5 kernel is only slightly customized as a superset of the original 5.X kernel. I don't have the misc/compat5x installed on my system. I don't remember seeing that in the upgrading section of the handbook, so I didn't do that. I can see this as being necessary for running certain legacy applications, but I should still be able to boot the kernel. Thanks, -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ok, so now what? Binary upgrade to 6.2-RELEASE fails
On Nov 11, Dimitry Andric wrote: Any chance you could post some of these error messages? And if possible, backtraces, etc? The messages amounted to page fault while in kernel mode or similar. The problem is the system attempts to reboot itself within 15 seconds. I know there is a way to postpone that, but how do I get more information from the crash other than the screen dump? I know in some crash instances it's possible to get a kernel image dump, but I've never seen this as far as I know. Thanks, -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ok, so now what? Binary upgrade to 6.2-RELEASE fails
On Nov 02, [LoN]Kamikaze wrote: I think you might have no choice but to omit the reboots, because the world contains lots of stuff that has to do with the kernel (like mounting). So just go into single user mode and do the usual stuff: # make installkernel # mergemaster -p # make installworld # mergemaster # shutdown -r now and pray to your deity of choice. If the reason for your problem is something else however you're stuck with a system that can not run with your old kernel. So better backup before you try. I attempted to just do a binary upgrade, assuming that I botched the source upgrade somehow. After installing FreeBSD 6.2-RELEASE, I was left with a system that would not boot (similar errors on boot as before). Reverting the kernel of course was of limited help because userland was all expecting 6.2. So, I had a couple of tarballs from my last backup and I attempted to bandage up / and /usr and was able to resurrect my 5.5-STABLE image. This is f'n scary. I've never had this much trouble upgrading a system before. Does anyone have any idea what remnant could be remaining after a binary upgrade that would keep it from booting yet I can boot from the 6.2-RELEASE iso's just fine? I am very apprehensive to do a newfs and wipe the drives now that I've failed both source and binary upgrade paths. -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Source upgrade from 5.5 to 6.X not safe?
On Nov 04, Robert Watson wrote: When I upgrade a remote systems, I'll actually almost always run a few days with the new kernel and the old user space to make sure everything has settled nicely before doing the user space upgrade, which is harder to revert. Reverting to an old kernel is easy, and leaving the door open is likewise easy -- as long as you don't installworld. This is sort of what I was hoping to try, but alas I crashed and burned before I could even get the new kernel up and running. I never answered another question posed, and that was whether or not I rebooted in single-user mode - I did not. I also did not install the kernel while in single-user mode because, well, I'm the only user :) Your comment seemed to imply that it can be a safe operation to reboot and run the machine regularly after make installkernel. Am I reading that correctly? In general, is it possible that the installkernel did /not/ complete correctly before I shut down? Is it ever possible that the machine could get put into an indeterminate state when doing installkernel on a running machine? HP-UX used to behave horribly when a binary got clobbered for a process that was running, but I have no idea how FreeBSD copes with changing disk images of a running process. Thanks, -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Source upgrade from 5.5 to 6.X not safe?
On Nov 02, LI Xin wrote:
So we get:
- 5.5-STABLE works well on your box
- 6.2-RELEASE stock GENERIC works fine
- 6.3-PRERELEASE failed for some reason.
So far as I am aware I have no clue why this could happen. Could you
check if you have any special configuration in your /etc/make.conf,
especially special CFLAGS? I usually simply remove my /usr/src /usr/obj
and build a new world without make.conf to make sure.
No special configs in my system:
X11BASE=${LOCALBASE}
# added by use.perl 2007-08-24 03:20:32
PERL_VER=5.8.8
PERL_VERSION=5.8.8
Unless something in here could be construed as dangerous?
-Clint
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Source upgrade from 5.5 to 6.X not safe?
I just attempted a source upgrade from 5.5-STABLE to 6.3-PRERELEASE, and it was a disaster, more than likely because I forgot to do something. Normally I'm saved by the fact that the operations are not so scary as to cause problems. Well, in this case after running 'make installkernel' and rebooting, the system did not come back up because it got kernel fatals on reboot (fatal trap 12: page fault while in kernel mode). It appears that my filesystems got marked dirty in the reboot loop that ensued, and I had to manually fsck them. I figured after that it might boot, but alas problems remained, so after grabbing a disc1 image of 6.2 on CDROM I moved kernel.old back and kernel to kernel.bad. Now, sometimes I work fast and loose with the rules of upgrading, but I was surprised that I managed to royally screw up things. Any pointers would be appreciated before I shave off a few years of my life again. Thanks, -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Upgrading 5.5-STABLE to 6-STABLE
Hi: I bet this is documented /somewhere/, so if the response is in the form of a single URL, I'm cool with that. I'm trying to buildkernel and I'm getting config(8) errors: ERROR: version of config(8) does not match kernel! config version = 500013, version required = 63 What's the process of building from source a new version of FreeBSD? Thanks, -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is syslog() reentrant? Was: OpenBSD's spamd.
On Dec 19, Christopher Hilton wrote: Awesome. Then all I have to do to get the fresher code is either wrap the openlog_r and syslog_r calls in the spamd.c or write local functions which do the same. From the point of style which is preferable? Is it even possible to #define a C function to get around an argument? E.g. The openbsd syslog_r function has this call sequence: void syslog_r(int priority, struct syslog_data *data, const char *message, ...); IIRC there isn't a way to get around the '...' argument with #define and deal with the extra argument. Only C99 allows macros with variable arguments. But you can attempt to just replace the function identifier (name) if the function's arguments are otherwise in the same order. -Clint -- Clint Olsen. -- . clint at NULlsen dot net .' ,-. `. ;_,' ( ; I am Dick Lexic of Borg. Prepare to be ass-laminated. `.``;' -- Styx Allum ` -- ' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How can I know which files a proccess is accessing?
On Jun 06, Eduardo Meyer wrote: I need to know which files under /var a proccess (httpd here) is acessing. It is not logs because I have a different partition for logs. gstat tells me that slice ad0s1h (my /var) is 100% frequently, and in fact with fstat I can see a number of httpd proccesses running accesing that. But fstat only shows me inodes and the mount point. I need to know which files the proccesses are acessing. Linux has a cool program: lsof (list open files). Does FreeBSD have something similar? -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Mar 28, Pyun YongHyeon wrote: and sparc64(SMP) and I never see above errors. The only issue known to me is occasional watchdog timeout error which I really want to fix. But the watchdog timeout error is hard to reproduce and I couldn't reproduce the error on my system. I'm still seeing the watchdog timeout on 5.5-PRERELEASE (uni-processor): Mar 22 14:47:04 belle kernel: sk0: watchdog timeout Mar 24 08:37:19 belle kernel: sk0: watchdog timeout Mar 27 04:09:15 belle kernel: sk0: watchdog timeout But at least the driver doesn't wedge the interface now. -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Data transfer from one HD to another
On Mar 26, Remo Lacho wrote: dump and restore are your friends. Try something like this for each new slice (partition): Create your new slice on the new disk. newfs the new slice - newfs -U /dev/[new_slice] mount the new slices - mount /dev/[new_slice] /mnt dump and restore from the old slice to the new slice - dump -L -0 -f- /[old_slice] | (cd /mnt; restore -r -v -f-) If you want to ensure that the system is quiescent before doing the copy, you should actually boot from an alternative media and do the copy using those utilities. I actually needed to do this for Windows XP and I was too cheap to pay for any of the commercial software, so I used g4u: http://www.feyrer.de/g4u It's based on NetBSD and worked great for my Windows PC. I was cloning from a smaller to larger HD, so I had to use another utility to extend the partitions without formatting. Good luck, -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
