gene heskett posted on Thu, 14 Apr 2011 23:54:39 -0400 as excerpted:
> Well, I hitched a ride over to seacrates site and picked up the latest
> firmware updating iso, this about 3 days ago, maybe 4, time has been a
> blur here since.
Seeing the below, I can certainly understand why.
> Following their instructions, I pulled the cables on the other drives
> and booted the cd I burnt. It updated the firmware on that drive, to
> cc49, from some version in the late 20's.
>
> So now the drive is stable, but the write speeds are running about 2
> megs/sec. I replaced the SATA cable with another and doubled the from
> platter read speeds, but they still don't match the other nearly
> identical drive. But its working with no errors now.
Sounds like they made it try more times before resetting, and possibly,
now use a more complex ECC mechanism that can recover data that it would
return an error on before. You get stable, as data that's difficult to
read correctly gets read many more times before it gives up, but slow, as
the retry and/or ecc-recover take time. (It may be that data that had
been written with the new firmware would have better ecc and could be
recovered faster, but it's dealing with data written with the old
firmware, so...)
But the 2 MB/sec rate sounds like a failing drive too. Unfortunately...
FWIW, my experience in this are goes back to the event I believe I
mentioned earlier, the system left running when the AC failed in the heat
of a Phoenix summer, overheating the drive resulting in a head-crash. In
the aftermath of that, I used IIRC dd-rescue on it. On the parts of the
disk that weren't damaged, it comparatively flew, but when it got to the
parts that were damaged and was trying and trying to read them, and dd-
rescue tries until it can't read in one direction, then tries from the
other end until it can't read, then tries spots in the middle to see if
the whole area is damaged or just some and if it can read any, it expands
what it can read in both directions from there until it can't read again,
so it spends a **LOT** of time trying to read damaged sectors...
It was as you say below, like watching paint dry!
So I know the feeling! Unfortunately!
> What pulled the plug and flushed the whole system was when I plugged in
> the cable to /dev/sda and booted the cd, it updated the firmware on it
> too, and somehow managed to also do the MBR on the drive so that even
> selecting it as the boot device in the F8 bios menu, it simply hung with
> a blank screen deadlock. It is still that way despite fdisk showing it
> as bootable, and I have mounted the individual partitions and have the
> majority of the data recovered now. But, that drives partition labels
> are meaningless & scrambled so that the partition bearing the sea-slash
> label, is actually, from its contents, the old /opt partition. Other
> labels are similarly miss-placed. Entirely possible since all the
> distros have fallen in love with the UUID numbers because they are
> supposedly more unique than a human generated label.
Sounds like the firmware update on it redid the way it handles the data
areas that store critical partition data, thus scrambling some of it. The
vast majority of the drive is fine, the partition layout map itself is
apparently fine (tho I'd be careful with it as it's possible the
partitions overlap now and writing to one might damage another, inspect
the partition data with fdisk or the like to be sure...). But the data
about those partitions, the UUIDs, labels, etc... not so fine.
FWIW, this is one reason I switched here to GPT based partitions, from the
legacy MBR based system. GPT stores two copies of the partition data, one
at the beginning of the drive and one at the end, and unlike mbr,
checksums the data. If it gets corrupted, the checksum is bad and it can
try reading the other table to see if it's good. Even if it can't do so
directly (the onboard logic must be small and simple), there's a good
chance that gptfdisk (formerly gdisk, one gpt form of fdisk/sfdisk, etc,
tho there are other tools available) or other gpt disk partitioning tools
can recover the partitions. Ever since that bad AC triggered head-crash
event, I've been rather more paranoid about data integrity than I used to
be, and this seemed to cover one of the gaps left by my 4-way md/RAID-1
setup rather well.
The other big advance of GPT is that it does away with the primary/
secondary/logical partition distinction. All partitions are treated the
same, with the minimal reserved area specified by the spec allowing 128
such partitions and expansion from that (if anyone were to actually find a
reason 128 partitions isn't enough, here, I find that simply tracking them
starts getting difficult after about two dozen or so, even with the help
of the GPT partition-level labels (*NOT* filesystem level, actual
partition level, readable/settable in gpt partitioning tools even before
the filesystem is made).
(I'm interested in btrfs for much the same reason; it has built-in
checksumming so will know immediately if the data it gets from the disk is
bad, and can for instance request it from another disk using its built-in
RAID-1, if it was configured for that, but as I've explained in previous
btrfs discussion, that filesystem is still experimental at present --
they're only now developing an fsck for it, for instance! I'm eagerly
anticipating, but the day I decide it's ready for me isn't likely to be
for another couple kernel releases, anyway, but almost certainly sometime
next year, if not second half of this year. We'll see.)
GPT is part of the new EFI transition from legacy BIOS-based systems, but
at least on Linux, doesn't require EFI hardware, since the kernel has an
option that can be enabled for it, grub can understand it (grub-2
directly, apparently, and there's patches for grub-0.97 or whatever, which
is what I'm still using, the patches being built-in for gentoo's grub) and
I believe current lilo does too (tho I'm not sure of that), and a number
of the partitioning tools do as well (I already mentioned gptfdisk, and
libparted based partitioners do as well). That's the bootloader, the
kernel, and the tools all three, so Linux is good to go, even on BIOS-
based hardware systems. (FWIW, Apple's already EFI, and for MS, it
depends on the version, but at least some require EFI based hardware to
handle GPT on the boot device, but handle it on data devices fine with
just BIOS.)
> Anyway, I installed a freshly burnt version of pclos, and have been
> watching paint dry at 2megs/sec while mc gets my data back.
"Watching paint dry". Yeah, that's about accurate when the disk is having
to reread the data several times to get it correct, due to damage or
whatever. As I said, I've been there.
> And yes, I run amanda, so it ought to be easy, but my next outgoing msg
> will be to the amanda-users list because I can't get it to build,
> missing includes bailouts. With zero clues as to what the package name
> that would fix it. And since the rpm packages are a totally different
> setup, I'll wait till the local build problems get sorted, its one of
> the few programs that I have been building and using the svn versions of
> since back in the late 90's.
Well, at least the rpm metadata should tell you what the direct
dependencies are, giving you /some/ clue as to what packages it needs.
And the same for the srpm, which should give you the build-time
dependencies as well.
Of course, when you're building it on your own, you may not enable all the
options the rpm versions do, so you might not actually need /all/ those
packages, but that's the list I'd start checking against if I ran into
build-time header errors on a normally rpm based system. (It's what I
used to do back in the early '00s, on Mandrake, anyway.)
FWIW, rpmfind is a great resource for this sort of thing. Try the
following link, click on the html-page link for a version that looks close
to what you're trying to build (rpm and srpm, the rpm for run-time deps,
the srpm for build-time deps), and take a look at the dependencies it
lists.
Or download the srpm from pclinuxos or rpmfind, and use rpm's "install
dependencies only, dryrun" functionality, to see what it thinks it needs
that you don't already have installed. You can then do it without the
dryrun if you think it looks right, and that should set you up for
building. (Unfortunately, it's been years since I worked with rpm, and
the switches for the above, even if I did remember them, may well have
changed by now. But the functionality is there, with the manpage
explaining if you need it, I should think.)
Or maybe you're already doing that, having taken for granted that you
didn't have to actually spell it out, and it's still throwing missing
headers errors.
Meanwhile, as they say, /test/ your recovery plan, because those backups
are only as good as your ability to recover them. =:^)
IOW, if you're going to use self-built backup software, be sure to keep
copies of it off-disk somewhere, that you can quick-copy back if
necessary, for recovery. And test that those copies work on a clean-
install.
Either that, or don't use backup software, but instead, simple copies, as
I do. I copy whole partitions at a time, for root, by bind-mounting it
without overmounts elsewhere, so I can copy the root partition itself, and
only the root partition. I use normal copying, either cp in archive mode
or filemanager copying (mc used to do this well, but the new version
copies sparse files un-sparse, making them take FAR more room on the new
partition than they did on the old one, so I don't use it for that any
more), old working partition to the new, freshly mkfsed partition.
To test the backups at a grub-and-/boot-still-available level, I simply
reboot and feed grub a different kernel append line root= parameter,
pointing it at the backup root partition (same disk or external, I have
both, just in case...).
To test the grub-and-/boot-eaten scenario, I boot to the grub enabled
/boot I installed on a thumb drive, feeding it parameters as needed. The
same thumb drive grub installation has kernels and sample grub menu
options that I can modify as needed, for both my main 64-bit workstation,
and my 32-bit netbook, and in all /boot locations (netbook, main
workstation, and thumbdrive) I keep a grubnotes file listing various
additional kernel append parameters that I've found useful over the years,
while testing live-git kernels, etc. I can cat that file from grub if I
need to, thus reminding me whether it's for instance noapic or apic=off,
if I suspect I'm having problems with it.
So I don't worry about backup software at all, because my backup software
is mkfs, mount and cp, with the recovery software being grub and/or mount,
depending on whether it's the root/system or a data partition. =:^)
What's great about it is that since the backup is a snapshot of my working
system just as it was when I made the copy, I have a fully functional
rescue partition too. No limited function thing, the real deal, including
all the software I had installed when I made the backup, everything. So
if my main working copy doesn't run, I can simply boot the backup, google
a solution if I need to, and fix the working copy. If it takes awhile, no
big deal, I have the usual /home (or a backup if it was lost too) mounted,
and can do all the usual stuff I'd normally do, checking mail and
newsgroups, keep up on my rss feeds, all that, in the mean time. And if
the former main working copy isn't recoverable, I simply update from the
backup I'm already running, no problem.
> Anyway, I haven't fallen over, yet, just occupied trying to get a new
> install that didn't use the partitions I gave it, sorted, but now I have
> /home, /opt, /root, and /var back on their proper partitions.
>
> One positive side effect seems to be that a lot of my kde4 problems have
> vanished too. And I think I have it all back to 4.6.2 now too. As I've
> rebooted 20+ times as I get the data moved & the only time I lost any
> config was when I mounted the new /home partition over the top of the
> install directory and rebooted after fixing fstab. But give me time,
> I'm sure I can screw it up again. :-)
Gotta make it on topic! =:^)
Glad it did seem to fix things up for you, kde-wise.
> Cheers, Duncan & now to see if my recovered kmailrc can still send an
> email.
Seems it worked. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
