Re: boot sector f*ed
An update on the problems of the boot sector disks. So far, I have not found any errors on the guilty disks from one computer... the Seagate Tools for checking their ( other) disks show no errors on the disks themselves. I haven't finished with them all, yet as I am trying to set up a couple of FBSD 7.2 servers for various functions and will have a better idea when thatis done. :-) ___ 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: boot sector f*ed
On Thu, 13 Aug 2009, PJ wrote: Subject: Re: boot sector f*ed Roland Smith wrote: On Wed, Aug 12, 2009 at 03:54:31PM -0400, PJ wrote: Well, I've been looking at the disk(s) and I have found some interesting shei**e that doesn't make sense. 1. The fbsd minimal installation that I had set up for recovery of the previous crash does not boot... Now, why in Hades is that? I hadn't touched the disk since last using it to look at the corrupted disk through an usb connection. The current crashed installetion was done afterwards and the only change was in the bios to set the boot disk to the new installation. The installation was finally completed with all the programs working fine... and then BOOM! 2. I tried booting from all the disks on the machine (4 disks) and only the current crashed one booted!... so, it's not the boot sector at all... something is screwy on this machine; either the motherboard is buggered (which I doubt, but not entirely), the disks are finished or theres some kind of gremlin lurking in the confines of the box. This sounds more and more like hardware troubles. Indeed it does, more and more since. A few things to check (in order of decreasing likelyness IMHO): - Cables to the harddisks: Make sure they are properly connected. A machine of mine suddenly started getting disk read errors after I put in another graphics card. It turned out that the SATA connector to that drive had come partially loose. - Powersupply: check the voltages (preferably under load) with a monitoring app like mbmon. If that's not possible, check in the BIOS. A failing powersupply can give weird unreproducable errors. If you have ever heard a popping noise from the machine it could be a short in the powersupply caused by dust. I've seen that fry motherboards. - PCI cards: check that they are seated properly. Although in this case I'd say this seems the least likely. I usually bet first on the power supply .. but it's not my money :) I apologize for the lengthy explanation below, but perhaps it will give some insight on what is see from this end: Chomping heavily; some useful background but a bit much, no disrespect. machine. The troubles began when I tried to install flashplayer on the 7.1 machine. Or could be a hardware issue that became evident around the same time? bash4 and fluxbox for X. Everything seemed to work fine. I ran all the programs and saw that all the files I had recovered from the crash were recovered and working. Man, was I ever happy! I shut down for the night and looked forward to getting bask to normal development of my current projects. In the morning, I boot up and WHAM!... the system is f**cked. And so am I. Have you tried swapping the power supply? I assume you've swapped the cables, removed cleaned and replaced cards, checked CPU temperature etc? Now, the problem is that it is imperative to be able to figure out what exactly is going on. Well, the problem with that is that I do not seem to be in a position to do what is required. For one thing, I do not know how I can save testing output to an external file when I am working on a temporary shell on the problem machine. Perhaps you could indicate what I should be doing or where to look for information. Steve Bertrand has most recently addressed those issues, good advice, especially don't panic :) Another problem is rather a strange quirk or I don't know what - The problems I am having are on two very similar machines: 1 is a MSI 6758 875P NeoFisr motherboard running on a Pentium 3.0ghz CPU; the other is the identical board with a Pentium 2.4ghz CPU. The strange thing is that even with identical bios, the bios does not act the same on both machines. The final install that was so promising was on the 2.4 ghz machine. Except for being somewhat slower (I find it rather slow compared to the the 3ghz, but maybe that's normal) it always worked without problems. Have you tried putting the HD from the problem 2.4GHz machine in the 3GHz box, to see if it behaves properly there? Have you tried running various hardware diagnostic programs over the flakey box? Overnight memtesting can reveal other problems even if memory is fine. There are quite a few diagnostic CDs around; some boot some Linux, some DOS even, it doesn't really matter if they can prove/disprove the hardware. anyway - I tried booting a minimal installation on the 2.4ghz machine from a disk that was set up before the crashed disk was installed and that boot did not work... there was no reason for it to not work... all Smells like flakey hardware .. intermittent, inexplicable glitches. It might survive hours on one workload, minutes on another, no sense to it? All that I am seeing is that there is either a problem with the bios (which I even reinstalled and that changed
Re: boot sector f*ed
On Fri, 14 Aug 2009 13:41:48 +1000 (EST), Ian Smith smi...@nimnet.asn.au wrote: Smells like flakey hardware .. intermittent, inexplicable glitches. It might survive hours on one workload, minutes on another, no sense to it? I could guess defective RAM here... I suggest running memtest for some hours, just to be sure. It's really a bad situation when you're searching for a software problem when there's none, instead it is explainable by a hardware problem. Sometimes, quite often in fact, I've found just disassembling, thorough cleaning, fresh heatsink paste maybe, and reassembly solves many issues, without ever knowing what exactly did the trick. Life's like that .. This is called doing nothing. :-) From my own experience, if sometimes really works. -- Polytropon From 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: boot sector f*ed
Ian Smith wrote: [snip] Smells like flakey hardware .. intermittent, inexplicable glitches. It might survive hours on one workload, minutes on another, no sense to it? All that I am seeing is that there is either a problem with the bios (which I even reinstalled and that changed nothing in the functioning) or something is going on with the OS. After you've thoroughly proven the hardware is AOK under sustained and varied pressure, then you can suspect software issues - which tend to be far more consistent and repeatable - but if the hardware's acting flakey then you likely won't see any consistency in software issues, which does seem to concur with your descriptions to date. In my experience, hardware problems can quite possibly show little pattern to where and when in the usage of said machine they cause the box to flake. One that is malfunctioning all the time is relatively easy to find. The intermittent is the bane of all troubleshooting. I hate the intermittent more than I hate anything. One pattern an intermittent will show is eventually as the bad part gets worse the period between flakes will get shorter, and ultimately at some point die completely. Initially the period can be quite large so proper troubleshooting is difficult as you can't troubleshoot during the 'in between' when it's not malfunctioning. I also have an 80/20 rule about hardware as to whether it is a hot or cold failure. The 80% part is that most hardware problems occur when very dense VLSI chips heat up. So a machine may not show any problem until it's been powered up for a while. The other 20% is the cold start. Turn the box on and there is immediately some kind of problem early on in the course of booting. Leave it powered on, walk away for 20 minutes to get a coffee, and reset it after it's had a chance to warm up and now it works fine the rest of the day. These patterns are indicative of a typical pattern in hardware trouble behavior. A software error, on the other hand, most of the time shows itself as a well defined repeatable sequence of steps that cause the problem every time the sequence is executed. This can also usually be easily reproduced by others running the same, or similar enough, platform(s) by executing said sequence. This can get quite sticky as even the BIOS code is software! Bad buggy BIOS code having a bad reaction to the compiled boot loader binary, even though probably quite rare, is not totally outside the realm of possibility. Somewhere very near the root of the geometric logic tree of troubleshooting you need to be able to drive a wedge between hardware and software in a divide and conquer kind of way. Making any arbitrary assumptions as to which side is the problem early on will blind the troubleshooter to avenues of hypothesis this and test that. Assume that the hardware is 100% OK so it must be a software problem without proof is a mistake, and vice versa. And it might be as simple as installing another OS such as a Linux distro or Windows to the box. If it is truly a hardware problem it may continue to malfunction and cause trouble no matter what the choice of OS. Or it may not, as sometimes buggy hardware design failures are compensated for with workarounds in drivers, thus hiding the flaw. It's the old 'have a insert brand name box with xyz hardware' with a known problem and the fix is to download and install insert brand name driver revision such and such from the OEM. Since these kinds of things are not generally propagated far and wide an OS such as FreeBSD may not be privy to such bad hardware details. Sometimes the developers do incorporate hacks for hardware. If you can accurately identify such a situation the most likely way to get it fixed for the long run is to file a proper PR. If done well enough and it catches the eye of a dev who may be interested and actually possess the piece of hardware a workaround may get coded and become a part of FreeBSD. Just a lot of generalizations here. As always, there is the YMMV clause. :-) [snip] -Mike ___ 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: boot sector f*ed
Roland Smith wrote: [sni[p] - Powersupply: check the voltages (preferably under load) with a monitoring app like mbmon. If that's not possible, check in the BIOS. A failing powersupply can give weird unreproducable errors. If you have ever heard a popping noise from the machine it could be a short in the powersupply caused by dust. I've seen that fry motherboards. A marginal to beginning to fail power supply will have more ripple when under heavy load. In the earliest stages it may only manifest when load is extremely heavy, but as time wears on it will get worse. You would have to be looking at it with an oscilloscope to see this. A simple voltage check with something like a VOM that averages power may show voltages within the correct range, but is totally blind to the filtering quality (ripple). It can also account for very weird behaviors. At boot time the current required to spin up the drive is huge relative to the current used during normal operation. If the power supply is only marginal it may only be slipping out of spec during this period and seem to be fine the rest of the time. Easiest way to eliminate is to simply substitute a known good from a working machine that has at least the minimum wattage needed. An example: A WD800JB takes 2.2 amps on the 12 volt rail to spin up, but during normal ops read/write/idle is 350ma with seek being 900ma. The 5 volt rail will use 525ma on spin up, read/write/idle is 800ma with seek at 675 ma. A lot of slightly earlier generations of drives used 2.5 amps or more. Easy to see the 12 volt rail being insufficient wattage and/or out of spec ripple-wise can be a problem. A lot of older cheap power supplies on the market do not have a lot of capacity on the 12 volt rail. [snip] -Mike ___ 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: boot sector f*ed
Roland Smith wrote: On Wed, Aug 12, 2009 at 03:54:31PM -0400, PJ wrote: Well, I've been looking at the disk(s) and I have found some interesting shei**e that doesn't make sense. 1. The fbsd minimal installation that I had set up for recovery of the previous crash does not boot... Now, why in Hades is that? I hadn't touched the disk since last using it to look at the corrupted disk through an usb connection. The current crashed installetion was done afterwards and the only change was in the bios to set the boot disk to the new installation. The installation was finally completed with all the programs working fine... and then BOOM! 2. I tried booting from all the disks on the machine (4 disks) and only the current crashed one booted!... so, it's not the boot sector at all... something is screwy on this machine; either the motherboard is buggered (which I doubt, but not entirely), the disks are finished or theres some kind of gremlin lurking in the confines of the box. This sounds more and more like hardware troubles. A few things to check (in order of decreasing likelyness IMHO): - Cables to the harddisks: Make sure they are properly connected. A machine of mine suddenly started getting disk read errors after I put in another graphics card. It turned out that the SATA connector to that drive had come partially loose. - Powersupply: check the voltages (preferably under load) with a monitoring app like mbmon. If that's not possible, check in the BIOS. A failing powersupply can give weird unreproducable errors. If you have ever heard a popping noise from the machine it could be a short in the powersupply caused by dust. I've seen that fry motherboards. - PCI cards: check that they are seated properly. Although in this case I'd say this seems the least likely. Roland I apologize for the lengthy explanation below, but perhaps it will give some insight on what is see from this end: Ok, I've had all night to (subliminally) think about all this and actually, I am tending more toward problems in FreeBSD... (this is not an apology or a defense of my lack of knowledge or capacities, just a clarification so you know what kind of a dummy you're dealing with) First, let me explain that everything that we have been talking about - the recovery methods, installation, hardware problems, etc. are all extremely, and I mean extremely, subject to an awful lot of variables. Therefore, determining what exactly has or is going wrong is almost a complete impossibility. Let me explain and you will get an idea of what I mean (and of the difficulties I am facing). First, I am not an experienced programmer or expert on anything in the area of computers... however, I am probably one of the most, I would say not typical but most llikely users of FreeBSD (or any BSD) systems. I have been usiing FBSD for more than 10 years on and off and not heavily. I have installed quite a few instances of FBSD. I still have 1 system v. 4.10 as an archive of a couple of older websites I had some 12 years ago - (too complicated to migrate from postgresql to mysql and to newer versions because of IP host configurations); another v. 6.4 (or .2 - whatever) and they work fine. I had v. 7 installed on the machine I am working on now (on XP as it was multi-boot) and another 7.1 on another machine. The troubles began when I tried to install flashplayer on the 7.1 machine. At the same time I did manage to arrange my daughters portable Acer Travelmate 4400 running on AMD Turion 64bit; it was a low end snail paced horrow with XP so I got rid of that in installed FBSD 64bit and got it work just fine with X Windows, Firefox and even flashplayer under Linux emulation. This was a few weeks ago... it's still running fine. But upgrading to 7.2 and installing flashplayer was pretty much an impossibility on both of my machines - after extremely time-consuming (easily several days of long waits for compilation) setups, installs, reinstallsand portupgrades, all the programs I need finally came together in a very satisfying configuration. What I needed - Samba, apache22, php5.1, mysql, phpMyAdmin, Xorg, java, firefox, flashplayer, cups, NetBeans and Openoffice.org along with a few small proggies like bash4 and fluxbox for X. Everything seemed to work fine. I ran all the programs and saw that all the files I had recovered from the crash were recovered and working. Man, was I ever happy! I shut down for the night and looked forward to getting bask to normal development of my current projects. In the morning, I boot up and WHAM!... the system is f**cked. And so am I. Now, the problem is that it is imperative to be able to figure out what exactly is going on. Well, the problem with that is that I do not seem to be in a position to do what is required. For one thing, I do not know how I can save testing output to an external file when I am working on a temporary shell on the problem machine. Perhaps you could
Re: boot sector f*ed
On Thu, Aug 13, 2009 at 09:53:06AM -0400, PJ wrote: I apologize for the lengthy explanation below, but perhaps it will give some insight on what is see from this end: Ok, I've had all night to (subliminally) think about all this and actually, I am tending more toward problems in FreeBSD... (this is not an apology or a defense of my lack of knowledge or capacities, just a clarification so you know what kind of a dummy you're dealing with) First, let me explain that everything that we have been talking about - the recovery methods, installation, hardware problems, etc. are all extremely, and I mean extremely, subject to an awful lot of variables. I don't understand? I must confess that I find your explanations sometimes a bit vague. You're sitting in front of the machine with the problems. We (on the mailing list) see only what you say. It is difficult for me at least to piece together what exactly happened. If you are reporting errors, try to be as specific as possible. E.g. don't say I updated the machine and it doesn't boot anymore. Start with something like: After running freebsd-update with the options blabla or after updating the machine from the 7.2 CD making the following choices And then say I got stuck in the FreeBSD logo screen, or I got stuck on a screen showing the lines 'Default: 0:ad(0,a)/boot/loader' and 'boot:'. That gives us at least a chance to see what has gone wrong. I must say that I have never used the method of updating from CD. I tend to update the system sources with csup(8), and then rebuild the kernel and applications from source as explained in the Handbook. This hase never failed me yet. Therefore, determining what exactly has or is going wrong is almost a complete impossibility. Let me explain and you will get an idea of what I mean (and of the difficulties I am facing). snip The troubles began when I tried to install flashplayer on the 7.1 machine. I guess I missed that? Can't remember. At the same time I did manage to arrange my daughters portable Acer Travelmate 4400 running on AMD Turion 64bit; it was a low end snail paced horrow with XP so I got rid of that in installed FBSD 64bit and got it work just fine with X Windows, Firefox and even flashplayer under Linux emulation. This was a few weeks ago... it's still running fine. But upgrading to 7.2 and installing flashplayer was pretty much an impossibility on both of my machines - after extremely time-consuming (easily several days of long waits for compilation) setups, installs, reinstallsand portupgrades, all the programs I need finally came together in a very satisfying configuration. What I needed - Samba, apache22, php5.1, mysql, phpMyAdmin, Xorg, java, firefox, flashplayer, cups, NetBeans and Openoffice.org along with a few small proggies like bash4 and fluxbox for X. Everything seemed to work fine. I ran all the programs and saw that all the files I had recovered from the crash were recovered and working. Man, was I ever happy! I shut down for the night and looked forward to getting bask to normal development of my current projects. In the morning, I boot up and WHAM!... the system is f**cked. And so am I. Did you use 'nextboot' by any chance? Now, the problem is that it is imperative to be able to figure out what exactly is going on. Well, the problem with that is that I do not seem to be in a position to do what is required. For one thing, I do not know how I can save testing output to an external file when I am working on a temporary shell on the problem machine. Perhaps you could indicate what I should be doing or where to look for information. Insert a USB thumbdrive and mount it. Copy the files to it, unmount. The GENERIC kernel on the CD should have all the necessary drivers for this to work. Assuming that you're logged in as root, and that your USB drive is recognized as /dev/da0s1: mkdir /usbdrive mount_msdosfs -m 644 -M 755 -l -o noatime -o sync /dev/da0s1 /usbdrive # copy the files you need... umount /usbdrive Another problem is rather a strange quirk or I don't know what - The problems I am having are on two very similar machines: 1 is a MSI 6758 875P NeoFisr motherboard running on a Pentium 3.0ghz CPU; the other is the identical board with a Pentium 2.4ghz CPU. The strange thing is that even with identical bios, the bios does not act the same on both machines. I don't understand what you mean by that? What do you mean by doesn't act the same? The final install that was so promising was on the 2.4 ghz machine. Except for being somewhat slower (I find it rather slow compared to the the 3ghz, but maybe that's normal) it always worked without problems. CPU speed is not the only factor, and probably not the dominating factor in overall performance. The speed of the RAM and especially the harddisk(s) can have a much larger inpact because they are several orders of magnitude slower than the CPU. And in checking the disks with fdisk,
Re: boot sector f*ed
Roland Smith wrote: On Thu, Aug 13, 2009 at 09:53:06AM -0400, PJ wrote: I apologize for the lengthy explanation below, but perhaps it will give some insight on what is see from this end: Ok, I've had all night to (subliminally) think about all this and actually, I am tending more toward problems in FreeBSD... (this is not an apology or a defense of my lack of knowledge or capacities, just a clarification so you know what kind of a dummy you're dealing with) First, let me explain that everything that we have been talking about - the recovery methods, installation, hardware problems, etc. are all extremely, and I mean extremely, subject to an awful lot of variables. I don't understand? I must confess that I find your explanations sometimes a bit vague. You're sitting in front of the machine with the problems. We (on the mailing list) see only what you say. It is difficult for me at least to piece together what exactly happened. If you are reporting errors, try to be as specific as possible. E.g. don't say I updated the machine and it doesn't boot anymore. Start with something like: After running freebsd-update with the options blabla or after updating the machine from the 7.2 CD making the following choices And then say I got stuck in the FreeBSD logo screen, or I got stuck on a screen showing the lines 'Default: 0:ad(0,a)/boot/loader' and 'boot:'. That gives us at least a chance to see what has gone wrong. I must say that I have never used the method of updating from CD. I tend to update the system sources with csup(8), and then rebuild the kernel and applications from source as explained in the Handbook. This hase never failed me yet. 1. Reporting the errors is a little difficult because more often than not, the errors fly by too fast to be fully understandable. 2. I usually and never (since way, way back) do not update from a CD, except to boot up; I do the rest over ftp from the main source at freebsd.org. and I use cvsup-without-gui. :-) Therefore, determining what exactly has or is going wrong is almost a complete impossibility. Let me explain and you will get an idea of what I mean (and of the difficulties I am facing). snip The troubles began when I tried to install flashplayer on the 7.1 machine. I guess I missed that? Can't remember. At the same time I did manage to arrange my daughters portable Acer Travelmate 4400 running on AMD Turion 64bit; it was a low end snail paced horrow with XP so I got rid of that in installed FBSD 64bit and got it work just fine with X Windows, Firefox and even flashplayer under Linux emulation. This was a few weeks ago... it's still running fine. But upgrading to 7.2 and installing flashplayer was pretty much an impossibility on both of my machines - after extremely time-consuming (easily several days of long waits for compilation) setups, installs, reinstallsand portupgrades, all the programs I need finally came together in a very satisfying configuration. What I needed - Samba, apache22, php5.1, mysql, phpMyAdmin, Xorg, java, firefox, flashplayer, cups, NetBeans and Openoffice.org along with a few small proggies like bash4 and fluxbox for X. Everything seemed to work fine. I ran all the programs and saw that all the files I had recovered from the crash were recovered and working. Man, was I ever happy! I shut down for the night and looked forward to getting bask to normal development of my current projects. In the morning, I boot up and WHAM!... the system is f**cked. And so am I. Did you use 'nextboot' by any chance? Don't know what that is; never heard of it, thus never used it. Now, the problem is that it is imperative to be able to figure out what exactly is going on. Well, the problem with that is that I do not seem to be in a position to do what is required. For one thing, I do not know how I can save testing output to an external file when I am working on a temporary shell on the problem machine. Perhaps you could indicate what I should be doing or where to look for information. Insert a USB thumbdrive and mount it. Copy the files to it, unmount. The GENERIC kernel on the CD should have all the necessary drivers for this to work. Assuming that you're logged in as root, and that your USB drive is recognized as /dev/da0s1: mkdir /usbdrive mount_msdosfs -m 644 -M 755 -l -o noatime -o sync /dev/da0s1 /usbdrive # copy the files you need... umount /usbdrive I'll try that; oddly, I was able to use my SanDisk 4gb cruzer before. Chuck it into usb, mount /dev/cd0 to /mnt and go to it. But now, for some strange reason it just wont mount. I'm getting messages that it's not readable - g_vfs_done input output error and attempt to query device size failed, medium may have changed. But the stick is fully insertable, readable, removable from XP; as it was on FBSD. Weird. Another problem is rather a
Re: boot sector f*ed
On Thu, Aug 13, 2009 at 03:58:33PM -0400, PJ wrote: Roland Smith wrote: On Thu, Aug 13, 2009 at 09:53:06AM -0400, PJ wrote: I apologize for the lengthy explanation below, but perhaps it will give some insight on what is see from this end: Ok, I've had all night to (subliminally) think about all this and actually, I am tending more toward problems in FreeBSD... (this is not an apology or a defense of my lack of knowledge or capacities, just a clarification so you know what kind of a dummy you're dealing with) First, let me explain that everything that we have been talking about - the recovery methods, installation, hardware problems, etc. are all extremely, and I mean extremely, subject to an awful lot of variables. I don't understand? I must confess that I find your explanations sometimes a bit vague. You're sitting in front of the machine with the problems. We (on the mailing list) see only what you say. It is difficult for me at least to piece together what exactly happened. If you are reporting errors, try to be as specific as possible. E.g. don't say I updated the machine and it doesn't boot anymore. Start with something like: After running freebsd-update with the options blabla or after updating the machine from the 7.2 CD making the following choices And then say I got stuck in the FreeBSD logo screen, or I got stuck on a screen showing the lines 'Default: 0:ad(0,a)/boot/loader' and 'boot:'. That gives us at least a chance to see what has gone wrong. I must say that I have never used the method of updating from CD. I tend to update the system sources with csup(8), and then rebuild the kernel and applications from source as explained in the Handbook. This hase never failed me yet. 1. Reporting the errors is a little difficult because more often than not, the errors fly by too fast to be fully understandable. Error messages that have happened after the kernel has booted are still saved inside the kernel message buffer. With the 'dmesg' command you can have a good look at them. Additionally, a snapshot of this message buffer is written to /var/run/dmesg.boot after the filesystems are mounted. 2. I usually and never (since way, way back) do not update from a CD, except to boot up; I do the rest over ftp from the main source at freebsd.org. and I use cvsup-without-gui. :-) I got the impression from one of your previous mails that you tried updating from CD. Insert a USB thumbdrive and mount it. Copy the files to it, unmount. The GENERIC kernel on the CD should have all the necessary drivers for this to work. Assuming that you're logged in as root, and that your USB drive is recognized as /dev/da0s1: mkdir /usbdrive mount_msdosfs -m 644 -M 755 -l -o noatime -o sync /dev/da0s1 /usbdrive # copy the files you need... umount /usbdrive I'll try that; oddly, I was able to use my SanDisk 4gb cruzer before. Chuck it into usb, mount /dev/cd0 to /mnt and go to it. But now, for some strange reason it just wont mount. I'm getting messages that it's not readable - g_vfs_done input output error and attempt to query device size failed, medium may have changed. But the stick is fully insertable, readable, removable from XP; as it was on FBSD. Weird. You shouldn't be using the /dev/cd0 device. It is a virtual CD and should be read-only. I don't understand what you mean by that? What do you mean by doesn't act the same? When turning on the computer, hit del and the bios setup comes on almost immediately on the 3ghz machine. On the 2.4 machine it takes much, much longer to start up (the monitor is Hitachi superScan Elite 812 on the 3ghz machine, hitachi CM751 on the 2.4ghz) and when del is pressed the bios goes through the entire scanniing process and then restarts before finally going into the bios... and the versions of the bios and the setup are both identical in nubers but, if I recall correctly, there are some minor differences in some of the more arcane options that I never even look at. And in general it always ran a bit sluggish. If the battery keeping the CMOS memory of the 2.4ghz machine has run out, the bios won remember its settings and e.g. has to scan for harddisks etc. And settings like boot sequence, memory timing etc. can have a lot of influence on boot time. I don't want to be rude, but you could have made a mistake somewhere. If you're futzing around with disks and partitions it is quite easy to screw something up. Even for people with lots of experience it is sometimes a case of PEBKAC. :-) I understand what you are saying and I don't take it to be rude at all... actually, I don't screw around with the disks and the partitions... I only try to read them to recover any files I may have lost. So far, I have had 100% success on recovering lost data that was important. Up to now, when I had problems with
Re: boot sector f*ed
Roland Smith wrote: On Thu, Aug 13, 2009 at 03:58:33PM -0400, PJ wrote: Roland Smith wrote: On Thu, Aug 13, 2009 at 09:53:06AM -0400, PJ wrote: I apologize for the lengthy explanation below, but perhaps it will give some insight on what is see from this end: Ok, I've had all night to (subliminally) think about all this and actually, I am tending more toward problems in FreeBSD... (this is not an apology or a defense of my lack of knowledge or capacities, just a clarification so you know what kind of a dummy you're dealing with) First, let me explain that everything that we have been talking about - the recovery methods, installation, hardware problems, etc. are all extremely, and I mean extremely, subject to an awful lot of variables. I don't understand? I must confess that I find your explanations sometimes a bit vague. You're sitting in front of the machine with the problems. We (on the mailing list) see only what you say. It is difficult for me at least to piece together what exactly happened. If you are reporting errors, try to be as specific as possible. E.g. don't say I updated the machine and it doesn't boot anymore. Start with something like: After running freebsd-update with the options blabla or after updating the machine from the 7.2 CD making the following choices And then say I got stuck in the FreeBSD logo screen, or I got stuck on a screen showing the lines 'Default: 0:ad(0,a)/boot/loader' and 'boot:'. That gives us at least a chance to see what has gone wrong. I must say that I have never used the method of updating from CD. I tend to update the system sources with csup(8), and then rebuild the kernel and applications from source as explained in the Handbook. This hase never failed me yet. 1. Reporting the errors is a little difficult because more often than not, the errors fly by too fast to be fully understandable. Error messages that have happened after the kernel has booted are still saved inside the kernel message buffer. With the 'dmesg' command you can have a good look at them. Additionally, a snapshot of this message buffer is written to /var/run/dmesg.boot after the filesystems are mounted. I'll note that and try to get to them. 2. I usually and never (since way, way back) do not update from a CD, except to boot up; I do the rest over ftp from the main source at freebsd.org. and I use cvsup-without-gui. :-) I got the impression from one of your previous mails that you tried updating from CD. You have to start somewhere... ;-) As I recall it, I was trying to see what was to be found on the disk and I did not want to change or commit before getting that information... but, likeOBSD, I think it decided to do some writing to the disk - and I even got out of there fast by turning off the computer thinking that would abort things... stopping is sometimes rather slow. :-[ Insert a USB thumbdrive and mount it. Copy the files to it, unmount. The GENERIC kernel on the CD should have all the necessary drivers for this to work. Assuming that you're logged in as root, and that your USB drive is recognized as /dev/da0s1: mkdir /usbdrive mount_msdosfs -m 644 -M 755 -l -o noatime -o sync /dev/da0s1 /usbdrive # copy the files you need... umount /usbdrive I'll try that; oddly, I was able to use my SanDisk 4gb cruzer before. Chuck it into usb, mount /dev/cd0 to /mnt and go to it. But now, for some strange reason it just wont mount. I'm getting messages that it's not readable - g_vfs_done input output error and attempt to query device size failed, medium may have changed. But the stick is fully insertable, readable, removable from XP; as it was on FBSD. Weird. You shouldn't be using the /dev/cd0 device. It is a virtual CD and should be read-only. But that is what is shown when the memory stick is inserted. And I did try da0 (if I recall correctly). Ok, I just did your little mount suggestion above, and glory be, Massah, it shore did work. :-) I really don't know how I ever got this far... I don't understand what you mean by that? What do you mean by doesn't act the same? When turning on the computer, hit del and the bios setup comes on almost immediately on the 3ghz machine. On the 2.4 machine it takes much, much longer to start up (the monitor is Hitachi superScan Elite 812 on the 3ghz machine, hitachi CM751 on the 2.4ghz) and when del is pressed the bios goes through the entire scanniing process and then restarts before finally going into the bios... and the versions of the bios and the setup are both identical in nubers but, if I recall correctly, there are some minor differences in some of the more arcane options that I never even look at. And in general it always ran a bit sluggish. If the battery keeping the CMOS memory of the 2.4ghz machine has run out, the bios won
Re: boot sector f*ed
For your systems that are running well, get an external harddisk that is at least as big as the one in the machine. On my website I have explained how to prepare this disk in somewhat greater detail: http://www.xs4all.nl/~rsmith/freebsd/index.html#usb Then use the dump(8) command to make backups of the internal harddisk partitions and write them to the external harddisk. Say that you have mounted the external harddisk at /mnt/backups. The following command makes a backup of the entire root partition, and compresses it to save space: dump -0 -a -C 8 -L -u -f - / |gzip -1 /mnt/backups/root-20090813.gz How about 7zip instead of gzip? does better compression, from what I learned ??? ___ 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: boot sector f*ed
Hi PJ, On Thu, Aug 13, 2009 at 09:53:06AM -0400, PJ typed: I apologize for the lengthy explanation below, but perhaps it will give some insight on what is see from this end: You probably won't get much helpfull response. When troubleshooting, it's allways best to try to break down the problem in tiny bits and solve them one by one, asking specific questions when you get stuck. snip to be in a position to do what is required. For one thing, I do not know how I can save testing output to an external file when I am working on a temporary shell on the problem machine. Perhaps you could indicate what I should be doing or where to look for information. What kind of temporary shell? You mean the fixit console or livecd? You can allways redirect the output to some file in /tmp for example and then scp it to another computer. Or mount_nfs or even mount_smbfs a windows share and save the output there. And in checking the disks with fdisk, fsck, and even running that weird regenerate progam... I wasn't able to come up with anything significant... that is, the configuration of the disks seemed to be ok, the boot sector was ok as it was able to boot but the when the system was being mounted something went wrong... and looking back, I vaguely recall something about a soft update or something like that which seems to indicate some stumbling block in the software and not hardware. soft updates inconsistencies perhaps? They can be caused by faulty hardware. Or by power failure. What did you do about them? In such a situation the system will drop you into single user mode where you can do an fsck. All that I am seeing is that there is either a problem with the bios (which I even reinstalled and that changed nothing in the functioning) or something is going on with the OS. How exactly did you see this? And you reinstalled the BIOS ??? I now have set up another instance of 7.2 on a different disk on the 2.4ghz machine and I already find something strange... after installing the minimum configuration, I installed the packages - samba3.3.3, cvsup-without-gui, and smartmontools. I tried to run smartctl and cvsup but nothing worked. The path variable was correct but the shell just would not pick up on it. I had to start the programs from their directories. That just doesn't make sense. It does if your shell is csh (the default shell for root). You must issue the rehash command to re-read everything in your path after installing new software. Ruben ___ 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: boot sector f*ed
Ruben de Groot wrote: Hi PJ, On Thu, Aug 13, 2009 at 09:53:06AM -0400, PJ typed: I apologize for the lengthy explanation below, but perhaps it will give some insight on what is see from this end: You probably won't get much helpfull response. When troubleshooting, it's allways best to try to break down the problem in tiny bits and solve them one by one, asking specific questions when you get stuck. snip to be in a position to do what is required. For one thing, I do not know how I can save testing output to an external file when I am working on a temporary shell on the problem machine. Perhaps you could indicate what I should be doing or where to look for information. What kind of temporary shell? You mean the fixit console or livecd? You can allways redirect the output to some file in /tmp for example and then scp it to another computer. Or mount_nfs or even mount_smbfs a windows share and save the output there. And in checking the disks with fdisk, fsck, and even running that weird regenerate progam... I wasn't able to come up with anything significant... that is, the configuration of the disks seemed to be ok, the boot sector was ok as it was able to boot but the when the system was being mounted something went wrong... and looking back, I vaguely recall something about a soft update or something like that which seems to indicate some stumbling block in the software and not hardware. soft updates inconsistencies perhaps? They can be caused by faulty hardware. Or by power failure. What did you do about them? In such a situation the system will drop you into single user mode where you can do an fsck. All that I am seeing is that there is either a problem with the bios (which I even reinstalled and that changed nothing in the functioning) or something is going on with the OS. How exactly did you see this? And you reinstalled the BIOS ??? I now have set up another instance of 7.2 on a different disk on the 2.4ghz machine and I already find something strange... after installing the minimum configuration, I installed the packages - samba3.3.3, cvsup-without-gui, and smartmontools. I tried to run smartctl and cvsup but nothing worked. The path variable was correct but the shell just would not pick up on it. I had to start the programs from their directories. That just doesn't make sense. It does if your shell is csh (the default shell for root). You must issue the rehash command to re-read everything in your path after installing new software. Ruben Thanks Ruben, Frankly, I don't know an;ymore what I'm doing nor what is going on... it used to be so easy to set up FBSD even if it took a lot of time to compile... but it seems to be getting less and less intuitive and user friendly. How can I break thinkgs up into little bits and pieces without just smashing the whole show to bits and pieces ;-) There are so many problems, I have not idea where to begin. Oh, yes, csh ? I always set up bash and it never gave me such problems. Did the same just now and again, no problems with the shell. Right now I'm just fixing up a new set up of 7.2 on another disk and we'll see what that does. Then I will re-setup the files I had recoverd, see if they work and then do a last and final install of everything and see if that works. And if there is a problem then, then I will know for sure that it is not a hardware problem. In using computers, in general, over the past 20 plus years I have only had maybe 6 crashes... mostly Winbloz and about 3 with FBSD - and only 1 was because of defective hardware (a disk)... the rest was power outs and 1 erroneous shutdown... not bad ... and I never lost irreplaceable files. :-) Took some time to recover them, but recover did as recover should. Oh, well, before I give it all up, I'm giving it one final shot. PJ ___ 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: boot sector f*ed
On Thu, 13 Aug 2009 18:22:23 -0400, PJ af.gour...@videotron.ca wrote: How about 7zip instead of gzip? does better compression, from what I learned ??? Possible, but gzip is part of the OS, while 7zip needs to be installed manually. On a live system CD (FreeBSD, FreeSBIE) is is usually not present. Always keep in mind that maintenance is often done in a minimalist environment. -- Polytropon From 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: boot sector f*ed
Right now I'm just fixing up a new set up of 7.2 on another disk and we'll see what that does. Then I will re-setup the files I had recoverd, see if they work and then do a last and final install of everything and see if that works. And if there is a problem then, then I will know for sure that it is not a hardware problem. In using computers, in general, over the past 20 plus years I have only had maybe 6 crashes... mostly Winbloz and about 3 with FBSD - and only 1 was because of defective hardware (a disk)... the rest was power outs and 1 erroneous shutdown... not bad ... and I never lost irreplaceable files. :-) Took some time to recover them, but recover did as recover should. Oh, well, before I give it all up, I'm giving it one final shot. PJ observation+ If I may . . . (again ;-), why is it not a hardware issue? You're a self-proclaimed, long-time fBSD user experiencing unforeseen circumstances and the folks attempting to help aren't noobs. So, it surely can't be a user/software issue ;-) . . . It sounds like you can get the files that you need/want and then go get some new stuff. It's not expensive anymore and frankly, it seems that this thread is doomed. I apologize, but I don't have time to read the lengthy explanations/rants/responses, but I think a new chapter in PJ's life is developing and I think that you/he/she should turn the page (I know, you're trying . . .). o+ P.S. -- trim responses so we can get to the good stuff! ___ 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 ___ 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: boot sector f*ed
PJ wrote: Ruben de Groot wrote: Hi PJ, On Thu, Aug 13, 2009 at 09:53:06AM -0400, PJ typed: I apologize for the lengthy explanation below, but perhaps it will give some insight on what is see from this end: You probably won't get much helpfull response. When troubleshooting, it's allways best to try to break down the problem in tiny bits and solve them one by one, asking specific questions when you get stuck. snip to be in a position to do what is required. For one thing, I do not know how I can save testing output to an external file when I am working on a temporary shell on the problem machine. Perhaps you could indicate what I should be doing or where to look for information. What kind of temporary shell? You mean the fixit console or livecd? You can allways redirect the output to some file in /tmp for example and then scp it to another computer. Or mount_nfs or even mount_smbfs a windows share and save the output there. And in checking the disks with fdisk, fsck, and even running that weird regenerate progam... I wasn't able to come up with anything significant... that is, the configuration of the disks seemed to be ok, the boot sector was ok as it was able to boot but the when the system was being mounted something went wrong... and looking back, I vaguely recall something about a soft update or something like that which seems to indicate some stumbling block in the software and not hardware. soft updates inconsistencies perhaps? They can be caused by faulty hardware. Or by power failure. What did you do about them? In such a situation the system will drop you into single user mode where you can do an fsck. All that I am seeing is that there is either a problem with the bios (which I even reinstalled and that changed nothing in the functioning) or something is going on with the OS. How exactly did you see this? And you reinstalled the BIOS ??? I now have set up another instance of 7.2 on a different disk on the 2.4ghz machine and I already find something strange... after installing the minimum configuration, I installed the packages - samba3.3.3, cvsup-without-gui, and smartmontools. I tried to run smartctl and cvsup but nothing worked. The path variable was correct but the shell just would not pick up on it. I had to start the programs from their directories. That just doesn't make sense. It does if your shell is csh (the default shell for root). You must issue the rehash command to re-read everything in your path after installing new software. Ruben Thanks Ruben, Frankly, I don't know an;ymore what I'm doing nor what is going on... it used to be so easy to set up FBSD even if it took a lot of time to compile... but it seems to be getting less and less intuitive and user friendly. Perhaps you are becoming a bit anxious due to frustration. The intuition part of FreeBSD hasn't changed. For those who still like to do things the 'old' way, it still works the same way it always has. For those who like the new/updated tools, they work too. How can I break thinkgs up into little bits and pieces without just smashing the whole show to bits and pieces ;-) There are so many problems, I have not idea where to begin. Pen and paper. Write down the big problem, even if it's simply it doesn't work. From there, have a coffee, have a smoke, or do what you like to do in order to clear your mind to the point where you are facing the situation from scratch; in a calm, non-biased manner. Then focus on the first issue that crops up...write it down. If this initial problem is a show-stopper, start there. If it is not, continue despite the problems, and jot down the next roadblock. When I'm faced with a seemingly insurmountable aggregated bunch of problems, I prefer to halve the issue until I can recognize where the issue(s) are, and at the same time, I usually make notes on what works. Right now I'm just fixing up a new set up of 7.2 on another disk and we'll see what that does. ...now stop, and take a little break and reflect on what the strategy should be for the next step. Then I will re-setup the files I had recoverd, see if they work ...now take another little break, and reflect again. Reflect on what you have done, and about what you are about to do. This brainstorming may help develop different tactics. and then do a last and final install of everything and see if that works. ...break. And if there is a problem then, then I will know for sure that it is not a hardware problem. You can *never* know for *sure* that hardware isn't an issue. Things such as minor electrical damage (for instance) can be exceptionally intermittent, slowly progressive, extremely hard to troubleshoot, and may disappear for months before it rears it's head again. Another hard-to-troubleshoot aspect of hardware are the edge cases. I've run into issues in the past where I knew there was a problem, but it
Re: boot sector f*ed
On Thu, Aug 13, 2009 at 03:12:27PM -0400, PJ typed: Ruben de Groot wrote: Hi PJ, On Thu, Aug 13, 2009 at 09:53:06AM -0400, PJ typed: I apologize for the lengthy explanation below, but perhaps it will give some insight on what is see from this end: You probably won't get much helpfull response. When troubleshooting, it's allways best to try to break down the problem in tiny bits and solve them one by one, asking specific questions when you get stuck. snip to be in a position to do what is required. For one thing, I do not know how I can save testing output to an external file when I am working on a temporary shell on the problem machine. Perhaps you could indicate what I should be doing or where to look for information. What kind of temporary shell? You mean the fixit console or livecd? You can allways redirect the output to some file in /tmp for example and then scp it to another computer. Or mount_nfs or even mount_smbfs a windows share and save the output there. And in checking the disks with fdisk, fsck, and even running that weird regenerate progam... I wasn't able to come up with anything significant... that is, the configuration of the disks seemed to be ok, the boot sector was ok as it was able to boot but the when the system was being mounted something went wrong... and looking back, I vaguely recall something about a soft update or something like that which seems to indicate some stumbling block in the software and not hardware. soft updates inconsistencies perhaps? They can be caused by faulty hardware. Or by power failure. What did you do about them? In such a situation the system will drop you into single user mode where you can do an fsck. All that I am seeing is that there is either a problem with the bios (which I even reinstalled and that changed nothing in the functioning) or something is going on with the OS. How exactly did you see this? And you reinstalled the BIOS ??? I now have set up another instance of 7.2 on a different disk on the 2.4ghz machine and I already find something strange... after installing the minimum configuration, I installed the packages - samba3.3.3, cvsup-without-gui, and smartmontools. I tried to run smartctl and cvsup but nothing worked. The path variable was correct but the shell just would not pick up on it. I had to start the programs from their directories. That just doesn't make sense. It does if your shell is csh (the default shell for root). You must issue the rehash command to re-read everything in your path after installing new software. Ruben Thanks Ruben, Frankly, I don't know an;ymore what I'm doing nor what is going on... it used to be so easy to set up FBSD even if it took a lot of time to compile... but it seems to be getting less and less intuitive and user friendly. How can I break thinkgs up into little bits and pieces without just smashing the whole show to bits and pieces ;-) There are so many problems, I have not idea where to begin. I did a little bit of that for you. You could start by answering the specific questions I asked you above right below where I asked them instead of trying to answer all in just one paragraph and failing that. Oh, yes, csh ? I always set up bash and it never gave me such problems. Did the same just now and again, no problems with the shell. Right now I'm just fixing up a new set up of 7.2 on another disk and we'll see what that does. Then I will re-setup the files I had recoverd, see if they work and then do a last and final install of everything and see if that works. And if there is a problem then, then I will know for sure that it is not a hardware problem. In using computers, in general, over the past 20 plus years I have only had maybe 6 crashes... mostly Winbloz and about 3 with FBSD - and only 1 was because of defective hardware (a disk)... the rest was power outs and 1 erroneous shutdown... not bad ... and I never lost irreplaceable files. :-) Took some time to recover them, but recover did as recover should. Oh, well, before I give it all up, I'm giving it one final shot. PJ ___ 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: boot sector f*ed
On Tue, 11 Aug 2009 17:52:29 +0200 Polytropon free...@edvax.de wrote: On Tue, 11 Aug 2009 09:34:13 -0400, PJ af.gour...@videotron.ca wrote: I've got another disk about the same size on the machine and I'm wonderiing how could I transfer the whole shebang to it? Maybe an 1:1 copy using dd with a bs=1m would work. Maybe it would, if the new disk size is = the old one. Would doing a minimum 7.2 install be enough, followed by copying all the slices to the corresponding slices on the new disk? I'm thinking of mounting the broken drive on the new one and then copying... does that sound about right? No. Does not. :-) The proper way of doing this - or at least ONE of the proper ways - is to use the intended tools for this task. These are dump and restore. First of all, you use a FreeBSD live system (such as FreeSBIE) or the livefs CD of the FreeBSD OS to run the OS. The goal is: Most minimal interaction with the drives. Good principles, but .. Let's assume ad0 is your source disk and ad1 the target disk. You can use the sysinstall tool to slice and partition the target disk. You can create the same layout as on the source disk. Of course, using tools like bsdlabel and newfs is valid, too. If you're done, things go like this: 1. Check the source. # fsck /dev/ad0s1a /dev/ad0s1e /dev/ad0s1f /dev/ad0s1g /dev/ad0s1h Er, from PJ's original message (and the subject line) the boot sector, sector 0, is hosed. So the partition/slice table is hosed, or at least untrustworthy. So what then can /dev/ad0s1a and the others refer to? dd may indeed be the best way to at least get a raw copy of the existing disk. After which perhaps the boot sector can be rewritten with the right values (if available?) so that such as fsck and dump can proceed. cheers, Ian ___ 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: boot sector f*ed
Ian Smith wrote: On Tue, 11 Aug 2009 17:52:29 +0200 Polytropon free...@edvax.de wrote: On Tue, 11 Aug 2009 09:34:13 -0400, PJ af.gour...@videotron.ca wrote: I've got another disk about the same size on the machine and I'm wonderiing how could I transfer the whole shebang to it? Maybe an 1:1 copy using dd with a bs=1m would work. Maybe it would, if the new disk size is = the old one. Would doing a minimum 7.2 install be enough, followed by copying all the slices to the corresponding slices on the new disk? I'm thinking of mounting the broken drive on the new one and then copying... does that sound about right? No. Does not. :-) The proper way of doing this - or at least ONE of the proper ways - is to use the intended tools for this task. These are dump and restore. First of all, you use a FreeBSD live system (such as FreeSBIE) or the livefs CD of the FreeBSD OS to run the OS. The goal is: Most minimal interaction with the drives. Good principles, but .. Let's assume ad0 is your source disk and ad1 the target disk. You can use the sysinstall tool to slice and partition the target disk. You can create the same layout as on the source disk. Of course, using tools like bsdlabel and newfs is valid, too. If you're done, things go like this: 1. Check the source. # fsck /dev/ad0s1a /dev/ad0s1e /dev/ad0s1f /dev/ad0s1g /dev/ad0s1h Er, from PJ's original message (and the subject line) the boot sector, sector 0, is hosed. So the partition/slice table is hosed, or at least untrustworthy. So what then can /dev/ad0s1a and the others refer to? dd may indeed be the best way to at least get a raw copy of the existing disk. After which perhaps the boot sector can be rewritten with the right values (if available?) so that such as fsck and dump can proceed. cheers, Ian Thanks, Ian... I'm actually at the stage of doing the save/copy/transfer or whatever you can call it: here's what I am thinking and on which I need clarification. I ran HDD regenerator and it immediately flagged the very first sector as being Bad. On bootint, just before the crash, the boot process started... hesitated, lurched forward, hesitated and then proceeded to load only some minutes later closing down with a 177mb dump. I knew then there was a problem.. :-) I have a 2nd disk just checked (with the regenerator - 12 hrs waiting on 2.4ghz cpu). If, indeed, the boot sector is the only thing mucked up, I should be able to copy the rest onto the 2nd(target) disk NP. The question, then, is how to deal with the boot sector. As I understand it, the boot sector has the partition information needed to run things for the rest of the disk. So, copying the damaged source disk will not give me the boot sector needed. I happen to have a another instance of 7.2 installed on a smaller disk but that boot sector, obviously will not be quite right, right? I presume that I can just boot up the spare 7.2 disk, do the dd stuff from source to target and we have stage 1 done. I get the impression to get this second stage (the boot stuff) I should do a minimal setup of the original configuration on a third disk the same size as the source and then copy the boot sector to the tartget. If for some reason, I haven't got the slices/partitions right, then I can just redo the whole shebang until I've got it right. A little tortured, but could work, or have I got it wrong? Of course, if there is a more elegant and simpler solution, shoot ! TIA PJ ___ 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: boot sector f*ed
On Wed, 12 Aug 2009, PJ wrote: Ian Smith wrote: On Tue, 11 Aug 2009 17:52:29 +0200 Polytropon free...@edvax.de wrote: [..] Let's assume ad0 is your source disk and ad1 the target disk. You can use the sysinstall tool to slice and partition the target disk. You can create the same layout as on the source disk. Of course, using tools like bsdlabel and newfs is valid, too. If you're done, things go like this: 1. Check the source. # fsck /dev/ad0s1a /dev/ad0s1e /dev/ad0s1f /dev/ad0s1g /dev/ad0s1h Er, from PJ's original message (and the subject line) the boot sector, sector 0, is hosed. So the partition/slice table is hosed, or at least untrustworthy. So what then can /dev/ad0s1a and the others refer to? dd may indeed be the best way to at least get a raw copy of the existing disk. After which perhaps the boot sector can be rewritten with the right values (if available?) so that such as fsck and dump can proceed. Thanks, Ian... I'm actually at the stage of doing the save/copy/transfer or whatever you can call it: here's what I am thinking and on which I need clarification. I ran HDD regenerator and it immediately flagged the very first sector as being Bad. On bootint, just before the crash, the boot process started... hesitated, lurched forward, hesitated and then proceeded to load only some minutes later closing down with a 177mb dump. I knew then there was a problem.. :-) The dump, presumably from a panic, may be related or a consequence of whatever hardware issue may have clobbered your boot sector, or it may not. Your disk may be really in trouble, or it may just need its boot sector rewriting, if not a 'hard' sector error. But first, backup .. I have a 2nd disk just checked (with the regenerator - 12 hrs waiting on 2.4ghz cpu). I don't know of this regenerator. dd'ing a drive to /dev/null is a pretty good way to surface test a disk, not taking a fraction that long. If, indeed, the boot sector is the only thing mucked up, I should be able to copy the rest onto the 2nd(target) disk NP. The question, then, Read man dd carefully, do some practice runs. You'll want conv=noerror to copy all but any bad sectors, or dd may fail. For any section with bad sectors, you may need to use bs=512 and maybe skip (source) and seek (destination) to keep things aligned. I'm no expert on dd, have't had to do that for years, nor am I so hot on fdisk, bsdlabel or boot0cfg on FreeBSD 7, but there are plenty of folks here that are. is how to deal with the boot sector. As I understand it, the boot sector has the partition information needed to run things for the rest of the disk. So, copying the damaged source disk will not give me the boot sector needed. That's right, and no, but if you salvage everything else, and you know which slice/s were used and how big its partition/s are, you should be ok. Once back up, apart from normal backups, having a copy of your boot sector plus fdisk / bsdlabel output on another disk - or even on paper - can be very handy :) I happen to have a another instance of 7.2 installed on a smaller disk but that boot sector, obviously will not be quite right, right? No, you don't want to copy another disk's boot sector; you'll want to use fdisk to make a new one that fits. If there's a jumper for it, write protect the bad drive first, and move it away from being ad0. Seek expert help on the commands, as above .. I presume that I can just boot up the spare 7.2 disk, do the dd stuff from source to target and we have stage 1 done. If the disk sizes match, should be good. I get the impression to get this second stage (the boot stuff) I should do a minimal setup of the original configuration on a third disk the same size as the source and then copy the boot sector to the tartget. If for some reason, I haven't got the slices/partitions right, then I can just redo the whole shebang until I've got it right. A little tortured, but could work, or have I got it wrong? Of course, if there is a more elegant and simpler solution, shoot ! Again, I wouldn't copy a boot sector (though on identical disks, that should work). fdisk will write a new boot sector, and if you've got the slice sizes right, then your old bsdlabels should still be there for your various BSD partitions. Now .. exit the clown and bring on the fdisk / bsdlabel experts, please. Good luck, Ian ___ 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: boot sector f*ed
On Wed, Aug 12, 2009 at 07:34:49AM -0400, PJ wrote: I'm actually at the stage of doing the save/copy/transfer or whatever you can call it: here's what I am thinking and on which I need clarification. I ran HDD regenerator and it immediately flagged the very first sector as being Bad. Is this the program you're talking about? http://store3.esellerate.net/store/ProductInfo.aspx?StoreIDC=STR793615240SkuIDC=SKU9923428806pc= I'm not an expert on harddisks, but the claims that this program makes seem too good to be true. I wonder what other on the list think of it? You may also find the following link about data recovery enlightening: http://www.mjmdatarecovery.co.uk/data-recovery-articles/bad-sector-errors.html Information encoding techniques on harddisks have changed dramatically over the years to help enable the ever increasing densities. The link to HDD regenerator talks about bad sectors showing. Current harddisks have a number of spare sectors available so that they can remap the data from unreadable sectors, using the error correction bits to restore unreadable data. All this is done in the harddisk itself, without even being visible to the user. AFAIK, a harddisk will only start showing re-allocated sectors in the SMART information after its spare sectors are exhausted. See [http://en.wikipedia.org/wiki/Bad_sector] If this is the case, the common advice it to decommission this drive ASAP. You should use 'smartctl' from the sysutils/smartmontools port to check if your harddisk is healthy or failing. 'smartctl -a /dev/diskname' should give complete information. Look at a line containing the text 'Reallocated_Sector_Ct'. If the last number on this line is greater than zero, the disk has run out of spare sectors, and it is time to get a new disk. On bootint, just before the crash, the boot process started... hesitated, lurched forward, hesitated and then proceeded to load only some minutes later closing down with a 177mb dump. I knew then there was a problem.. :-) Yes. But probably not a problem with the boot sector. Because the machine found and executed the boot code (because it booted). And it succeeded in finding and loading the kernel (because it wrote a dump). Now it is important to know _why_ the kernel dumped core. It could be that the kernel image was corrupted on disk, pointing to a disk problem. But it can also be something else. So try and see if you can read the slice table with fdisk as described below. If that works, the slice table should be OK. I have a 2nd disk just checked (with the regenerator - 12 hrs waiting on 2.4ghz cpu). If, indeed, the boot sector is the only thing mucked up, I should be able to copy the rest onto the 2nd(target) disk NP. The question, then, is how to deal with the boot sector. As I understand it, the boot sector has the partition information needed to run things for the rest of the disk. So, copying the damaged source disk will not give me the boot sector needed. If your boot sector is truly buggered, read the manual pages for the following utilities: - fdisk(8) - boot0cfg(8) You can re-install the boot code in sector 0 easily with FreeBSD's fdisk. E.g. if you are booting from the /dev/ad4 drive: 'fdisk -B /dev/ad4'. If you can boot from a FreeBSD livecd, try if you can read the slicetable correctly with fdisk to check if it is really damaged. Again assuming the bad drive is /dev/ad4, save the output of the following command to a file, and post the contents here. 'fdisk /dev/ad4'. A tip for the future. If you have a newly sliced disk, save the slice table to a file with 'fdisk -p /dev/ad4 slicetable-ad4.txt', and save this file away from the computer. If you ever damage the slice table, you can restore it using the file that you saved with 'fdisk -f slicetable-ad4.txt -i /dev/ad4'. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgptY6t3LYWFW.pgp Description: PGP signature
Re: boot sector f*ed
Roland Smith wrote: On Wed, Aug 12, 2009 at 07:34:49AM -0400, PJ wrote: I'm actually at the stage of doing the save/copy/transfer or whatever you can call it: here's what I am thinking and on which I need clarification. I ran HDD regenerator and it immediately flagged the very first sector as being Bad. Is this the program you're talking about? http://store3.esellerate.net/store/ProductInfo.aspx?StoreIDC=STR793615240SkuIDC=SKU9923428806pc= It sure looks like it. Don't recall the version. I'm not an expert on harddisks, but the claims that this program makes seem too good to be true. I wonder what other on the list think of it? You may also find the following link about data recovery enlightening: http://www.mjmdatarecovery.co.uk/data-recovery-articles/bad-sector-errors.html I'll look at it for sure. Information encoding techniques on harddisks have changed dramatically over the years to help enable the ever increasing densities. The link to HDD regenerator talks about bad sectors showing. Current harddisks have a number of spare sectors available so that they can remap the data from unreadable sectors, using the error correction bits to restore unreadable data. All this is done in the harddisk itself, without even being visible to the user. AFAIK, a harddisk will only start showing re-allocated sectors in the SMART information after its spare sectors are exhausted. See [http://en.wikipedia.org/wiki/Bad_sector] If this is the case, the common advice it to decommission this drive ASAP. You should use 'smartctl' from the sysutils/smartmontools port to check if your harddisk is healthy or failing. 'smartctl -a /dev/diskname' should give complete information. Look at a line containing the text 'Reallocated_Sector_Ct'. If the last number on this line is greater than zero, the disk has run out of spare sectors, and it is time to get a new disk. Will try it, too. On bootint, just before the crash, the boot process started... hesitated, lurched forward, hesitated and then proceeded to load only some minutes later closing down with a 177mb dump. I knew then there was a problem.. :-) Yes. But probably not a problem with the boot sector. Because the machine found and executed the boot code (because it booted). And it succeeded in finding and loading the kernel (because it wrote a dump). Now it is important to know _why_ the kernel dumped core. It could be that the kernel image was corrupted on disk, pointing to a disk problem. But it can also be something else. So try and see if you can read the slice table with fdisk as described below. If that works, the slice table should be OK. Well, I've been looking at the disk(s) and I have found some interesting shei**e that doesn't make sense. 1. The fbsd minimal installation that I had set up for recovery of the previous crash does not boot... Now, why in Hades is that? I hadn't touched the disk since last using it to look at the corrupted disk through an usb connection. The current crashed installetion was done afterwards and the only change was in the bios to set the boot disk to the new installation. The installation was finally completed with all the programs working fine... and then BOOM! 2. I tried booting from all the disks on the machine (4 disks) and only the current crashed one booted!... so, it's not the boot sector at all... something is screwy on this machine; either the motherboard is buggered (which I doubt, but not entirely), the disks are finished or theres some kind of gremlin lurking in the confines of the box. So, I will proceed to do some more reading and research on all this and then check out the procedures you've suggested below. I may not be able to respond too quickly as I've got a few other devils circling my head... like organizing and adjusting normal living conditions which include garbage, house repairs, sometimes sleeping and often running around the city getting stuff for just plain survival... :-( ;-) :'( I appreciate your response and have already learned quite a lot... it's rather heavy for my little brain, but I'll try to deal with it.. :-) I have a 2nd disk just checked (with the regenerator - 12 hrs waiting on 2.4ghz cpu). If, indeed, the boot sector is the only thing mucked up, I should be able to copy the rest onto the 2nd(target) disk NP. The question, then, is how to deal with the boot sector. As I understand it, the boot sector has the partition information needed to run things for the rest of the disk. So, copying the damaged source disk will not give me the boot sector needed. If your boot sector is truly buggered, read the manual pages for the following utilities: - fdisk(8) - boot0cfg(8) You can re-install the boot code in sector 0 easily with FreeBSD's fdisk. E.g. if you are booting from the /dev/ad4 drive: 'fdisk -B /dev/ad4'. If you can boot from a FreeBSD livecd, try if you can read the slicetable
Re: boot sector f*ed
On Wed, Aug 12, 2009 at 03:54:31PM -0400, PJ wrote: Well, I've been looking at the disk(s) and I have found some interesting shei**e that doesn't make sense. 1. The fbsd minimal installation that I had set up for recovery of the previous crash does not boot... Now, why in Hades is that? I hadn't touched the disk since last using it to look at the corrupted disk through an usb connection. The current crashed installetion was done afterwards and the only change was in the bios to set the boot disk to the new installation. The installation was finally completed with all the programs working fine... and then BOOM! 2. I tried booting from all the disks on the machine (4 disks) and only the current crashed one booted!... so, it's not the boot sector at all... something is screwy on this machine; either the motherboard is buggered (which I doubt, but not entirely), the disks are finished or theres some kind of gremlin lurking in the confines of the box. This sounds more and more like hardware troubles. A few things to check (in order of decreasing likelyness IMHO): - Cables to the harddisks: Make sure they are properly connected. A machine of mine suddenly started getting disk read errors after I put in another graphics card. It turned out that the SATA connector to that drive had come partially loose. - Powersupply: check the voltages (preferably under load) with a monitoring app like mbmon. If that's not possible, check in the BIOS. A failing powersupply can give weird unreproducable errors. If you have ever heard a popping noise from the machine it could be a short in the powersupply caused by dust. I've seen that fry motherboards. - PCI cards: check that they are seated properly. Although in this case I'd say this seems the least likely. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpqOXQsb1Yl7.pgp Description: PGP signature
Re: boot sector f*ed
In response to PJ af.gour...@videotron.ca: I just finished setting up 7.2 with all my programs installed, configured working fine with recovered files all working fine and just as I boot up to start backing up everything... WHAM... the boot-up kind-of hobbles and boots up. I am called away from the computer and when I return - goodie, goodie, there is a dump of some 177 mbs and the poor computer is trying to r eboot... but that's it. And the I scan the guilty drive and it's the very first, boot, sector that is Baad. And the regenerator program doesn't go any further. :-( Other than booting up with livefs and trying to copy everything to another disk, is there something else that I should do? I think it should work if I connect the drive to USB ... But before, I thought I should listen to some sage advice... :-) Anyone? TIA I think you've got the right idea. If the drive is funky, get your data off it while you can. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ 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: boot sector f*ed
Bill Moran wrote: In response to PJ af.gour...@videotron.ca: I just finished setting up 7.2 with all my programs installed, configured working fine with recovered files all working fine and just as I boot up to start backing up everything... WHAM... the boot-up kind-of hobbles and boots up. I am called away from the computer and when I return - goodie, goodie, there is a dump of some 177 mbs and the poor computer is trying to r eboot... but that's it. And the I scan the guilty drive and it's the very first, boot, sector that is Baad. And the regenerator program doesn't go any further. :-( Other than booting up with livefs and trying to copy everything to another disk, is there something else that I should do? I think it should work if I connect the drive to USB ... But before, I thought I should listen to some sage advice... :-) Anyone? TIA I think you've got the right idea. If the drive is funky, get your data off it while you can. I've got another disk about the same size on the machine and I'm wonderiing how could I transfer the whole shebang to it? Would doing a minimum 7.2 install be enough, followed by copying all the slices to the corresponding slices on the new disk? I'm thinking of mounting the broken drive on the new one and then copying... does that sound about right? I haven't looked at the broken one yet; I'll have to see what theat 177mg dump was.. -- Andrea Jourdan e-mail: af.gour...@videotron.ca http://www.chiccantine.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: boot sector f*ed
On Tue, 11 Aug 2009 09:34:13 -0400, PJ af.gour...@videotron.ca wrote: I've got another disk about the same size on the machine and I'm wonderiing how could I transfer the whole shebang to it? Maybe an 1:1 copy using dd with a bs=1m would work. Would doing a minimum 7.2 install be enough, followed by copying all the slices to the corresponding slices on the new disk? I'm thinking of mounting the broken drive on the new one and then copying... does that sound about right? No. Does not. :-) The proper way of doing this - or at least ONE of the proper ways - is to use the intended tools for this task. These are dump and restore. First of all, you use a FreeBSD live system (such as FreeSBIE) or the livefs CD of the FreeBSD OS to run the OS. The goal is: Most minimal interaction with the drives. Let's assume ad0 is your source disk and ad1 the target disk. You can use the sysinstall tool to slice and partition the target disk. You can create the same layout as on the source disk. Of course, using tools like bsdlabel and newfs is valid, too. If you're done, things go like this: 1. Check the source. # fsck /dev/ad0s1a /dev/ad0s1e /dev/ad0s1f /dev/ad0s1g /dev/ad0s1h Add -f (and dangerous -y) if intended. 2. You don't mount the source disk. Instead, you first prepare the target disk which you mount. Then you use dump and restore to transfer the data from the unmounted source partition to the mounted target partition. # mount /dev/ad1s1a /mnt # cd /mnt # dump -0 -f - /dev/ad0s1a | restore -r -f - Keep an eye on where you mount it. Maybe the live system you use already employs /mnt for its own purposes. Create /target instead, or anything else you like. 3. After transferting /, continue with /tmp /var /usr and /home. # mount /dev/ad1s1a /mnt # cd /mnt # dump -0 -f - /dev/ad0s1a | restore -r -f - # mount /dev/ad1s1e /mnt/tmp # cd /mnt/tmp # dump -0 -f - /dev/ad0s1e | restore -r -f - # mount /dev/ad1s1f /mnt/var # cd /mnt/var # dump -0 -f - /dev/ad0s1f | restore -r -f - # mount /dev/ad1s1g /mnt/usr # cd /mnt/usr # dump -0 -f - /dev/ad0s1g | restore -r -f - # mount /dev/ad1s1h /mnt/home # cd /mnt/home # dump -0 -f - /dev/ad0s1h | restore -r -f - Of course, triplepluscheck the commands before running them! 4. Unmount the target disks. # cd / # umount /mnt/home # umount /mnt/usr # umount /mnt/var # umount /mnt/tmp # umount /mnt # sync # halt Replace the disks and start using your target. I haven't looked at the broken one yet; I'll have to see what theat 177mg dump was.. Kernel image? -- Polytropon From 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: boot sector f*ed
2009/8/11 Polytropon free...@edvax.de On Tue, 11 Aug 2009 09:34:13 -0400, PJ af.gour...@videotron.ca wrote: I've got another disk about the same size on the machine and I'm wonderiing how could I transfer the whole shebang to it? Maybe an 1:1 copy using dd with a bs=1m would work. Would doing a minimum 7.2 install be enough, followed by copying all the slices to the corresponding slices on the new disk? I'm thinking of mounting the broken drive on the new one and then copying... does that sound about right? No. Does not. :-) The proper way of doing this - or at least ONE of the proper ways - is to use the intended tools for this task. These are dump and restore. First of all, you use a FreeBSD live system (such as FreeSBIE) or the livefs CD of the FreeBSD OS to run the OS. The goal is: Most minimal interaction with the drives. Let's assume ad0 is your source disk and ad1 the target disk. You can use the sysinstall tool to slice and partition the target disk. You can create the same layout as on the source disk. Of course, using tools like bsdlabel and newfs is valid, too. If you're done, things go like this: 1. Check the source. # fsck /dev/ad0s1a /dev/ad0s1e /dev/ad0s1f /dev/ad0s1g /dev/ad0s1h Add -f (and dangerous -y) if intended. 2. You don't mount the source disk. Instead, you first prepare the target disk which you mount. Then you use dump and restore to transfer the data from the unmounted source partition to the mounted target partition. # mount /dev/ad1s1a /mnt # cd /mnt # dump -0 -f - /dev/ad0s1a | restore -r -f - Keep an eye on where you mount it. Maybe the live system you use already employs /mnt for its own purposes. Create /target instead, or anything else you like. 3. After transferting /, continue with /tmp /var /usr and /home. # mount /dev/ad1s1a /mnt # cd /mnt # dump -0 -f - /dev/ad0s1a | restore -r -f - # mount /dev/ad1s1e /mnt/tmp # cd /mnt/tmp # dump -0 -f - /dev/ad0s1e | restore -r -f - # mount /dev/ad1s1f /mnt/var # cd /mnt/var # dump -0 -f - /dev/ad0s1f | restore -r -f - # mount /dev/ad1s1g /mnt/usr # cd /mnt/usr # dump -0 -f - /dev/ad0s1g | restore -r -f - # mount /dev/ad1s1h /mnt/home # cd /mnt/home # dump -0 -f - /dev/ad0s1h | restore -r -f - Of course, triplepluscheck the commands before running them! 4. Unmount the target disks. # cd / # umount /mnt/home # umount /mnt/usr # umount /mnt/var # umount /mnt/tmp # umount /mnt # sync # halt Replace the disks and start using your target. I haven't looked at the broken one yet; I'll have to see what theat 177mg dump was.. Kernel image? -- Polytropon From 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 Dumping is all very well and good. However if you want daily or hourly backups etc it is very costly. Thats why our in house system at work is based around rsync and zfs Basically we rsync the file to the x4500 with ~ 36 TB and then snapshot the backup. You then have incremental forever. On large systems that dont have much % change of content the benefits are huge ___ 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: boot sector f*ed
On Tue, 11 Aug 2009 17:09:38 +0100, chris scott kra...@googlemail.com wrote: Dumping is all very well and good. However if you want daily or hourly backups etc it is very costly. Thats why our in house system at work is based around rsync and zfs That's of course true. Another option is using cpdup from ports, especially if your hardware is not good enough to keep ZFS usable. -- Polytropon From 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: boot sector f*ed
Polytropon wrote: On Tue, 11 Aug 2009 09:34:13 -0400, PJ af.gour...@videotron.ca wrote: I've got another disk about the same size on the machine and I'm wonderiing how could I transfer the whole shebang to it? Maybe an 1:1 copy using dd with a bs=1m would work. Sorry for my ignorance, but what language is that? :-) What's dd with a bs=1m? Would doing a minimum 7.2 install be enough, followed by copying all the slices to the corresponding slices on the new disk? I'm thinking of mounting the broken drive on the new one and then copying... does that sound about right? No. Does not. :-) The proper way of doing this - or at least ONE of the proper ways - is to use the intended tools for this task. These are dump and restore. First of all, you use a FreeBSD live system (such as FreeSBIE) or the livefs CD of the FreeBSD OS to run the OS. The goal is: Most minimal interaction with the drives. Let's assume ad0 is your source disk and ad1 the target disk. You can use the sysinstall tool to slice and partition the target disk. You can create the same layout as on the source disk. I'm being ultra careful and checking/regenerating the target disk and that will t ake another 4 or 5 hours. I don't expect any difficulties, but would like to triple check the procedure... Ok - boot up livefs, slice partition the target disk; but how do I continue? Do I go to the shell? If that is all it is, then I don't see much difficulty. I'll read the man pages to check all the commands below so I am clear on everything. Of course, using tools like bsdlabel and newfs is valid, too. If you're done, things go like this: 1. Check the source. # fsck /dev/ad0s1a /dev/ad0s1e /dev/ad0s1f /dev/ad0s1g /dev/ad0s1h Add -f (and dangerous -y) if intended. 2. You don't mount the source disk. Instead, you first prepare the target disk which you mount. Then you use dump and restore to transfer the data from the unmounted source partition to the mounted target partition. # mount /dev/ad1s1a /mnt # cd /mnt # dump -0 -f - /dev/ad0s1a | restore -r -f - Keep an eye on where you mount it. Maybe the live system you use already employs /mnt for its own purposes. Create /target instead, or anything else you like. 3. After transferting /, continue with /tmp /var /usr and /home. # mount /dev/ad1s1a /mnt # cd /mnt # dump -0 -f - /dev/ad0s1a | restore -r -f - # mount /dev/ad1s1e /mnt/tmp # cd /mnt/tmp # dump -0 -f - /dev/ad0s1e | restore -r -f - # mount /dev/ad1s1f /mnt/var # cd /mnt/var # dump -0 -f - /dev/ad0s1f | restore -r -f - # mount /dev/ad1s1g /mnt/usr # cd /mnt/usr # dump -0 -f - /dev/ad0s1g | restore -r -f - # mount /dev/ad1s1h /mnt/home # cd /mnt/home # dump -0 -f - /dev/ad0s1h | restore -r -f - Of course, triplepluscheck the commands before running them! 4. Unmount the target disks. # cd / # umount /mnt/home # umount /mnt/usr # umount /mnt/var # umount /mnt/tmp # umount /mnt # sync # halt Replace the disks and start using your target. I haven't looked at the broken one yet; I'll have to see what theat 177mg dump was.. Kernel image? If it is, do I need it or what do I do with it? It is obviously(?) saved somewhere like /tmp ... ___ 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: boot sector f*ed
On Tue, 11 Aug 2009 13:31:52 -0400, PJ af.gour...@videotron.ca wrote: Sorry for my ignorance, but what language is that? :-) What's dd with a bs=1m? That's English + UNIX, at least it should be. :-) I could have written dd with a bs of 1m, which does simply mean that the program dd should be called with the parameter bs=1m, representing a blocksize of 1 MB. The command would then be: # dd if=/dev/ad0 of=/dev/ad1 bs=1m given the suggestion that ad0 is the source disk, ad1 the target disk. It's worth mentioning that the MBR - if intact - should be copied with this command (afterwards I think): # dd if=/dev/ad0 of=/dev/ad1 bs=512 count=1 Smart dd users will suggest omiting bs=512 because that's the default value. :-) Finally, commands can be used as verbs, such as you then dd the ad0 onto ad1 or can you grep that in /etc/something? :-) I'm being ultra careful and checking/regenerating the target disk and that will t ake another 4 or 5 hours. That's the usual amount of time. I think you said approx. 100 GB disks? It may work faster if you don't run the transfer in master / slave mode (same cable), but in master / master mode (each drive on own cable); this affects (P)ATA only, as far as I know. I don't expect any difficulties, but would like to triple check the procedure... Ok - boot up livefs, slice partition the target disk; but how do I continue? Do I go to the shell? Yes. You can either use the shell of FreeBSD's live system, or use FreeSBIE, it has sysinstall on it, too, as far as I remember. But nobody stops you from not using sysinstall, but bsdlabel and newfs instead. Keep an eye on newfs options, especially if you want to enable soft updates or with to init the disks with a certain optimization, or a non-default inode ratio. If that is all it is, then I don't see much difficulty. I'll read the man pages to check all the commands below so I am clear on everything. That's a good idea. I copied the command line examples from a procedure I once wrote for how to clone OS disks. If it is, do I need it or what do I do with it? It is obviously(?) saved somewhere like /tmp ... The kernel image is saved in /var/crash directory. It can be used for examination, in order to find out what caused the crash. Usually, the kernel debugger is employed to do this. If you don't care any further, you can safely delete the core files. -- Polytropon From 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: boot sector f*ed
On Tue, Aug 11, 2009 at 08:19:24PM +0200, Polytropon wrote: On Tue, 11 Aug 2009 13:31:52 -0400, PJ af.gour...@videotron.ca wrote: Sorry for my ignorance, but what language is that? :-) What's dd with a bs=1m? That's English + UNIX, at least it should be. :-) I could have written dd with a bs of 1m, which does simply mean that the program dd should be called with the parameter bs=1m, representing a blocksize of 1 MB. The command would then be: # dd if=/dev/ad0 of=/dev/ad1 bs=1m given the suggestion that ad0 is the source disk, ad1 the target disk. It's worth mentioning that the MBR - if intact - should be copied with this command (afterwards I think): # dd if=/dev/ad0 of=/dev/ad1 bs=512 count=1 Smart dd users will suggest omiting bs=512 because that's the default value. :-) Finally, commands can be used as verbs, such as you then dd the ad0 onto ad1 or can you grep that in /etc/something? :-) Nice response, but don't forget to have the OP read the man page -- egman dd jerry I'm being ultra careful and checking/regenerating the target disk and that will t ake another 4 or 5 hours. That's the usual amount of time. I think you said approx. 100 GB disks? It may work faster if you don't run the transfer in master / slave mode (same cable), but in master / master mode (each drive on own cable); this affects (P)ATA only, as far as I know. I don't expect any difficulties, but would like to triple check the procedure... Ok - boot up livefs, slice partition the target disk; but how do I continue? Do I go to the shell? Yes. You can either use the shell of FreeBSD's live system, or use FreeSBIE, it has sysinstall on it, too, as far as I remember. But nobody stops you from not using sysinstall, but bsdlabel and newfs instead. Keep an eye on newfs options, especially if you want to enable soft updates or with to init the disks with a certain optimization, or a non-default inode ratio. If that is all it is, then I don't see much difficulty. I'll read the man pages to check all the commands below so I am clear on everything. That's a good idea. I copied the command line examples from a procedure I once wrote for how to clone OS disks. If it is, do I need it or what do I do with it? It is obviously(?) saved somewhere like /tmp ... The kernel image is saved in /var/crash directory. It can be used for examination, in order to find out what caused the crash. Usually, the kernel debugger is employed to do this. If you don't care any further, you can safely delete the core files. -- Polytropon From 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 ___ 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
