upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
apt-cdrom. Thanks.
With kind regards,
Didier.
---
PhD student
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
Website: http://ssls.nus.edu.sg
1 year, 10 months
kernel/accounting question ...
by William W. Austin
(I know that this question might be more reasonable on a kernel list,
but a while back I posted the question twice and got no answers.)
The acct struct is defined in /usr/include/sys/acct.h includes both
ac_io and ac_rw for bytes transferred and blocks read or written,
respectively. Fair and good - works (on paper) similarly to unix,
solaris, hp-ux, etc.
However, in the kernel code [kernel/acct.c], ac_io (char) and ac_rw
(blocks) are always set to 0 by these two lines:
ac.ac_io = encode_comp_t(0 /* current->io_usage */);
ac.ac_rw = encode_comp_t(ac.ac_io / 1024);
For most purposes, this probably wouldn't be an issue, but I also do
extensive performance analysis on several platforms and have written a
fairly compresive accounting package (as a wraparound for psacct or as
a standalone) including both an improved acctcom and a built-in
reporter for it.
Does anyone know wby the kernel zero's out the bytes transferred data?
(Overhead comes to mind.) Not that it makes a huge differnce for my
purposes (I had to write some wraparound code to make a
"best-guestimate" about the data I'm missing), but curiosity is bugging
me now. When I compile my program on other OS's I get useful data for
char and block i/o and I'd like to find out whether there is something
obvious that I'm just totally missing here...).
Thanks
--
william w. austin waustin(a)speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."
13 years, 11 months
acctcom for linux
by William W. Austin
I recently made several updates to a Linux version of of acctcom
(actually another accounting add-on package) which I've been using for
several years, and one of the people testing it asked a question which
I cannot answer. I'm hoping that someone on this list can give me some
info.
I have previously (over a year ago) asked on both this and a couple of
kernel lists (several times there) about this issue, but nobody has
ever answered. So if you have any info about this, I'd really
appreciate it.
As in many (all?) previous Linux kernels, the struct acct (defined in
/usr/include/sys/acct.h) has members ac_io and ac_rw which are
presumably counts of characters transferred and blocks read/written
respectively.
However, in the kernel code, the ac_io is set to 0 and the ac_rw gets
set to (ac_io/512) or some such - it is set to 0 as well (and thus
these are always reported as 0 in process accounting records. not good
if you're trying to measure them...).
Does anybody know why this is done that way? A long time ago (IIRC
late 2.2 and an early 2.4 kernel) I looked into "fixing" this in the
kernel code but was not successful (I finally produced a bootable
kernel, but it was unstable. Then I changed jobs, got swamped at work,
and eventually gave up).
As I said above, I have previously asked about this issue without
success, and I have essentially given up changing or "fixing" it.
But if anyone knows __WHY__ it is this way (I'm hypothesizing that it's
just too much work for too little added value), I'd really appreciate
knowing the reason. Curiosity and the cat and all that ...
Thanks
- Bill
--
william w. austin waustin(a)speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."
13 years, 11 months
Packages looking for new owners
by Trond Danielsen
Hi everyone,
it is becoming clear to me that I can no longer provide the collection
of packages I maintain the love and care that they deserve. If only
there were more hours in a day, but the current situation does no
leave much room for volunteer work on free software :-(. Hopefully I
will find time in the future to return to Fedora related work
The list if packages I maintain is available here:
https://admin.fedoraproject.org/pkgdb/users/packages/trondd?acls=owner
I don't mind keeping libopenraw, avrdude and uisp unless anyone
_really_ want to maintain these packages.
Best regards,
--
Trond Danielsen
13 years, 12 months
ctrlproxy-3.0.6
by Bernie Innocenti
Ciao,
I updated ctrlproxy to 3.0.6, and the resulting packages are here:
http://www.codewiz.org/pub/fedora/pkgs/
Patch follows. Can I commit it to CVS?
diff -u -p -r1.15 ctrlproxy.spec
--- ctrlproxy.spec 19 Feb 2008 07:31:45 -0000 1.15
+++ ctrlproxy.spec 25 May 2008 14:25:14 -0000
@@ -1,12 +1,18 @@
+%define ctrlproxy_homedir %{_var}/lib/ctrlproxy
+%define ctrlproxy_logdir %{_var}/log/irc
+%define ctrlproxy_service ctrlproxy
+%define ctrlproxy_user ctrlproxy
+
Summary: ctrlproxy
Name: ctrlproxy
-Version: 3.0.5
-Release: 2%{?dist}
+Version: 3.0.6
+Release: 1%{?dist}
License: GPLv2+
Group: Applications/Internet
Source: http://jelmer.vernstok.nl/releases/ctrlproxy-%{version}.tar.gz
Url: http://jelmer.vernstok.nl/ctrlproxy/
-Patch0: ctrlproxy-fix-ansi-build.patch
+Source100: ctrlproxy.init
+Source101: ctrlproxy.config
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: glib2-devel, popt, gnutls-devel
@@ -31,7 +37,6 @@ ctrlproxy development headers
%prep
%setup -q
-%patch0 -p1
%build
%configure
@@ -45,6 +50,23 @@ mkdir $RPM_BUILD_ROOT
make DESTDIR=$RPM_BUILD_ROOT install
make DESTDIR=$RPM_BUILD_ROOT -C doc install
chmod 0644 ${RPM_BUILD_ROOT}%{_datadir}/ctrlproxy/motd
+install -D -m 0755 %{SOURCE100} $RPM_BUILD_ROOT/%{_sysconfdir}/init.d/ctrlproxy
+install -D -m 0640 %{SOURCE101} $RPM_BUILD_ROOT/%{ctrlproxy_homedir}/config
+install -D -d -m 0750 $RPM_BUILD_ROOT/%{ctrlproxy_logdir}
+
+
+%pre
+/usr/sbin/useradd -s /sbin/nologin -M -r -d %{ctrlproxy_homedir} \
+ -c "ctrlproxy IRC daemon" %{ctrlproxy_user} &>/dev/null || :
+
+%post
+/sbin/chkconfig --add %{ctrlproxy_service}
+
+%preun
+if [ $1 = 0 ]; then
+ /sbin/service %{ctrlproxy_service} stop > /dev/null 2>&1 || :
+ /sbin/chkconfig --del %{ctrlproxy_service}
+fi
%clean
[ -d "$RPM_BUILD_ROOT" -a "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
@@ -59,12 +81,24 @@ chmod 0644 ${RPM_BUILD_ROOT}%{_datadir}/
%dir %{_docdir}/ctrlproxy
%{_docdir}/ctrlproxy/*
+%{_sysconfdir}/init.d/ctrlproxy
+%attr(0750, ctrlproxy, ctrlproxy) %dir %{ctrlproxy_logdir}
+%attr(0750, ctrlproxy, ctrlproxy) %dir %{ctrlproxy_homedir}
+%attr(0750, ctrlproxy, ctrlproxy) %config(noreplace) %{ctrlproxy_homedir}/config
+
+
%files devel
%defattr(-,root,root)
%{_includedir}/ctrlproxy-3.0/*
%{_libdir}/pkgconfig/ctrlproxy.pc
%changelog
+* Sun May 25 2008 Bernardo Innocenti <bernie(a)codewiz.org> 3.0.6-1
+- Update to latest upstream
+- Drop ctrlproxy-fix-irssi-log.patch
+- Add initscript
+- Create a ctrlproxy user to run ctrlproxy as a daemon
+
* Tue Feb 19 2008 Fedora Release Engineering <rel-eng(a)fedoraproject.org> - 3.0.5-2
- Autorebuild for GCC 4.3
--
\___/
_| X | Bernie Innocenti - http://www.codewiz.org/
\|_O_| "It's an education project, not a laptop project!"
14 years, 5 months
Maintainer Responsibility Policy
by Brian Pepple
Hi all,
I'm looking for some feedback on what I've got so far for the Maintainer
Responsibility Policy.
http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
--
== Maintainer Responsibility Policy ==
=== How long to maintain? ===
13 months from initial release.
=== Belong to the appropriate low-traffic mailing list ===
* Package maintainers will receive important announcements through
the moderated fedora-devel-announce mailing list. Maintainers
will be automatically subscribed to this list. Everyone that is
a primary maintainer of a package in Fedora is also strongly
encouraged to subscribe to the fedora-devel list, though this is
not mandatory.
* http://www.redhat.com/mailman/listinfo/fedora-devel-announce
* http://www.redhat.com/mailman/listinfo/fedora-devel-list
=== Manage security issues ===
* Package maintainer should handle security issues quickly, and if
they need help they should contact the Security Response Team.
* http://fedoraproject.org/wiki/Security/ResponseTeam
=== Deal with reported bugs in a timely manner ====
* 'Nuff said.
=== Maintain stability for users ===
* Package maintainers should limit updates within a single Fedora
release to those which do not require special user action. Many
users update automatically, and if their applications stop
working from no action of their own then they will be upset.
This goes doubly for services which may break overnight.
=== Track dependency issues in a timely manner ===
* In the development tree, and to a small degree in the release
trees as well, updates to packages may cause other packages to
have broken dependencies. Maintainers will be alerted when this
happens, and should work to rebuild their packages with all due
haste. Broken dependencies may leave end user systems in a state
where no updates will be applied. In order to keep the
distribution in a reasonable state, someone will step in and
rebuild packages that have had dependency issues for some time,
but package maintainers should not rely on these rebuilds.
=== Notify others of changes that may affect their packages ===
* Some packages are depended upon by others; in this case, changes
to one package may cause issues for others. Maintainers should
be aware of the effects that changes to their packages may have,
and should alert to the fedora-devel-announce mailing list of
updates which contain ABI or API changes which may cause
dependency problems for other packages. The announcement should
occur a week before the packages update, so all maintainers
affected are notified. The announcement should include the
following information:
* Nature of the change.
* Branches (devel, F9, etc.) which will be affected by the
change.
* Expected date of the change.
* List of packages which are affected by the change.
Generally, this is merely the list of packages which
depend directly on the package which is being updated,
and can be found with "repoquery --whatrequires package"
where "package" is the package being updated.
* If your package upgrade breaks other packages in Rawhide, you
should try to help fix the packages affected. For example, when
Python-2.5 was integrated into Rawhide, Jeremy Katz at least
fixed the important packages and queued a rebuild for all the
other packages affected.
=== Miscellaneous Items ===
* Maintainers need to maintain an upgrade path for their
packages.
* F(current-1) -> F(current) -> Rawhide
* Packages should be pushed to the Rawhide branch first. If it
builds and works fine for a few days, then it can be pushed to
F(current). If there is a good reason to push it to
F(current-1), it should be done after a few days of being in
F(current).
---
Thanks,
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
14 years, 6 months
preupgrade F9 -> rawhide?
by Camilo Mesias
Is preupgrade from F9 to rawhide supposed to work at the moment, and
where can I report problems?
I've tried to run it and got a few depsolving problems for packages
from livna... but when it gets to the boot images stage there are
problems:
Traceback (most recent call last):
File "/usr/share/preupgrade/preupgrade-gtk.py", line 198, in
on_assistant_apply
self._do_main()
File "/usr/share/preupgrade/preupgrade-gtk.py", line 206, in _do_main
self.main_preupgrade()
File "/usr/share/preupgrade/preupgrade-gtk.py", line 349, in main_preupgrade
self.pu.retrieve_treeinfo()
File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line
395, in retrieve_treeinfo
self.instimage = cp.get('stage2', 'instimage')
File "/usr/lib/python2.5/ConfigParser.py", line 520, in get
raise NoOptionError(option, section)
ConfigParser.NoOptionError: No option 'instimage' in section: 'stage2'
Any ideas?
-Cam
14 years, 8 months
Fedora User Certificates
by Dennis Gilmore
Effective immediately we have replaced the CA that is in use for
cvs.fedoraproject.org and koji.fedoraproject.org This effects uploading to
lookaside cache and building packages.
There are some manual steps that everyone needs to do to be able to use the
systems again.
they are
login to https://admin.fedoraproject.org/accounts/ and click on the "Download
a client-side certificate" link at the bottom of the home page. save the
output to ~/.fedora.cert
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert
fedora-packager-setup
then open your browser got to Edit -> Preferences -> Advanced -> Encryption ->
View Certificates -> Your Certificates
Select your existing Certificate and remove it
then import the new one from ~/fedora-browser-cert.p12 you will be able to
log in to koji
* Please note that you can only have one client side certificate at a time.
when you download a new one your old one is revoked. Please also only click
on the "Download a client-side certificate" link once as it makes multiple
requests and revokes all the transient certs.
the CRL is at https://admin.fedoraproject.org/ca/crl.pem
Thanks for your understanding and patience.
Dennis
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
14 years, 9 months
Confirmed premature hard disk failure
by Callum Lerwick
Now one occurrence doesn't prove it was the Load_Cycle_Count problem
that killed the drive, but this drive is definitely prematurely failed.
This is going to be spammy, I think it is important to document this so
we can all learn from it...
The drive I posted about a while back:
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00426.html
Is now definitely failing as of about 3-4 weeks ago. It's at the stage
where the drive still seems to be mostly readable, but IO bandwidth has
dropped like a rock. Booting Fedora takes like 20 minutes. Same thing
two previous failed drives did.
The drive has a manufacture date of May 2007. I have no reason to
believe the drive has been mistreated, no more than typical laptop wear
and tear. It is a "desktop replacement" laptop and is rarely
transported.
Fortunately /home seems to be readable. Media errors show up in the
syslog, but no IO errors are turning up in user space. The WinXP
partition seems to be trashed, however. So much for my wife's Half Life
2 and Spore savegames...
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x25
ata1.00: cmd 25/00:00:00:58:08/00:04:00:00:00/e0 tag 0 dma 524288 in
res 51/40:0f:f1:59:08/40:02:00:00:00/e0 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x25
ata1.00: cmd 25/00:00:00:58:08/00:04:00:00:00/e0 tag 0 dma 524288 in
res 51/40:0f:f1:59:08/40:02:00:00:00/e0 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x25
ata1.00: cmd 25/00:00:00:58:08/00:04:00:00:00/e0 tag 0 dma 524288 in
res 51/40:0f:f1:59:08/40:02:00:00:00/e0 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x25
ata1.00: cmd 25/00:00:00:58:08/00:04:00:00:00/e0 tag 0 dma 524288 in
res 51/40:0f:f1:59:08/40:02:00:00:00/e0 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x25
ata1.00: cmd 25/00:00:00:58:08/00:04:00:00:00/e0 tag 0 dma 524288 in
res 51/40:0f:f1:59:08/40:02:00:00:00/e0 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x25
ata1.00: cmd 25/00:00:00:58:08/00:04:00:00:00/e0 tag 0 dma 524288 in
res 51/40:0f:f1:59:08/40:02:00:00:00/e0 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/100
sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
00 08 59 f1
sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
end_request: I/O error, dev sda, sector 547313
ata1: EH complete
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Full smartctl -a output, after salvaging some data:
smartctl version 5.38 [x86_64-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Scorpio family
Device Model: WDC WD600VE-11KWT0
Serial Number: WD-WXEY06009078
Firmware Version: 01.03K01
User Capacity: 60,011,642,880 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 7
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Tue Dec 30 17:09:36 2008 CST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 121) The previous self-test completed having
the read element of the test failed.
Total time to complete Offline
data collection: (3180) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
No General Purpose Logging support.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 44) minutes.
Conveyance self-test routine
recommended polling time: ( 6) minutes.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 198 198 051 Pre-fail Always - 5472
3 Spin_Up_Time 0x0003 150 119 021 Pre-fail Always - 1466
4 Start_Stop_Count 0x0032 097 097 000 Old_age Always - 3359
5 Reallocated_Sector_Ct 0x0033 197 197 140 Pre-fail Always - 19
7 Seek_Error_Rate 0x000f 200 200 051 Pre-fail Always - 0
9 Power_On_Hours 0x0032 092 092 000 Old_age Always - 6564
10 Spin_Retry_Count 0x0012 092 085 051 Old_age Always - 22
11 Calibration_Retry_Count 0x0012 100 100 051 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 359
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 350
193 Load_Cycle_Count 0x0032 061 061 000 Old_age Always - 419536
194 Temperature_Celsius 0x0022 087 071 000 Old_age Always - 56
196 Reallocated_Event_Count 0x0032 196 196 000 Old_age Always - 4
197 Current_Pending_Sector 0x0012 192 190 000 Old_age Always - 86
198 Offline_Uncorrectable 0x0010 100 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0009 200 200 051 Pre-fail Offline - 3
SMART Error Log Version: 1
ATA Error Count: 2803 (device log contains only the most recent five errors)
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.
Error 2803 occurred at disk power-on lifetime: 6563 hours (273 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 18 f1 41 e8 e2 Error: UNC 24 sectors at LBA = 0x02e841f1 = 48775665
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
c8 00 40 c9 41 e8 02 08 01:07:07.212 READ DMA
27 00 00 00 00 00 00 08 01:07:07.211 READ NATIVE MAX ADDRESS EXT
ec 00 00 00 00 00 00 0a 01:07:07.208 IDENTIFY DEVICE
ef 03 45 00 00 00 00 0a 01:07:07.206 SET FEATURES [Set transfer mode]
27 00 00 00 00 00 00 08 01:07:07.205 READ NATIVE MAX ADDRESS EXT
Error 2802 occurred at disk power-on lifetime: 6563 hours (273 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 18 f1 41 e8 e2 Error: UNC 24 sectors at LBA = 0x02e841f1 = 48775665
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
c8 00 40 c9 41 e8 02 08 01:07:04.430 READ DMA
27 00 00 00 00 00 00 08 01:07:04.429 READ NATIVE MAX ADDRESS EXT
ec 00 00 00 00 00 00 0a 01:07:04.427 IDENTIFY DEVICE
ef 03 45 00 00 00 00 0a 01:07:04.427 SET FEATURES [Set transfer mode]
27 00 00 00 00 00 00 08 01:07:04.426 READ NATIVE MAX ADDRESS EXT
Error 2801 occurred at disk power-on lifetime: 6563 hours (273 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 18 f1 41 e8 e2 Error: UNC 24 sectors at LBA = 0x02e841f1 = 48775665
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
c8 00 40 c9 41 e8 02 08 01:07:01.254 READ DMA
27 00 00 00 00 00 00 08 01:07:01.254 READ NATIVE MAX ADDRESS EXT
ec 00 00 00 00 00 00 0a 01:07:01.251 IDENTIFY DEVICE
ef 03 45 00 00 00 00 0a 01:07:01.248 SET FEATURES [Set transfer mode]
27 00 00 00 00 00 00 08 01:07:01.248 READ NATIVE MAX ADDRESS EXT
Error 2800 occurred at disk power-on lifetime: 6563 hours (273 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 18 f1 41 e8 e2 Error: UNC 24 sectors at LBA = 0x02e841f1 = 48775665
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
c8 00 40 c9 41 e8 02 08 01:06:58.277 READ DMA
27 00 00 00 00 00 00 08 01:06:58.277 READ NATIVE MAX ADDRESS EXT
ec 00 00 00 00 00 00 0a 01:06:58.274 IDENTIFY DEVICE
ef 03 45 00 00 00 00 0a 01:06:58.271 SET FEATURES [Set transfer mode]
27 00 00 00 00 00 00 08 01:06:58.271 READ NATIVE MAX ADDRESS EXT
Error 2799 occurred at disk power-on lifetime: 6563 hours (273 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 18 f1 41 e8 e2 Error: UNC 24 sectors at LBA = 0x02e841f1 = 48775665
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
c8 00 40 c9 41 e8 02 08 01:06:55.684 READ DMA
27 00 00 00 00 00 00 08 01:06:55.684 READ NATIVE MAX ADDRESS EXT
ec 00 00 00 00 00 00 0a 01:06:55.681 IDENTIFY DEVICE
ef 03 45 00 00 00 00 0a 01:06:55.678 SET FEATURES [Set transfer mode]
27 00 00 00 00 00 00 08 01:06:55.678 READ NATIVE MAX ADDRESS EXT
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 90% 6564 789370
# 2 Conveyance offline Completed: read failure 90% 6564 789370
# 3 Extended offline Completed: read failure 90% 6562 789370
# 4 Extended offline Completed: read failure 90% 6562 789369
# 5 Extended offline Completed: read failure 90% 6560 85755114
# 6 Extended offline Completed without error 00% 6455 -
# 7 Extended offline Interrupted (host reset) 60% 6455 -
# 8 Extended offline Completed without error 00% 4402 -
# 9 Extended offline Completed without error 00% 0 -
#10 Short offline Completed without error 00% 0 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
Self tests 1-4 were done just today. Test 5 was done when the drive
first started failing 3-4 weeks ago, after which the machine was kept
off until now. 6 and 7 are from when I first noticed
Current_Pending_Sector was nonzero, maybe a month or two ago. 8 is from
my post in July. 9 and 10 are from when the drive was new.
Things to note:
1) The SMART health status is PASSED. Just like every other failed drive
I've had...
2) None of the attributes are failed.
3) By the time the self tests start failing, it is too late, you are
already losing data.
We can not trust the drive to assess itself properly. If we ever get a
SMART desktop alert thing going, we MUST look directly at the
attributes, and come to our own conclusion.
Any questions before I RMA the drive?
14 years, 9 months