Good morning,
I'm closing this thread. I think we've done what we realistically can
to determine what caused the fsck errors that led to the two boot
failures. I certainly learned a few things along the way. I've also
discovered a few things I should be doing that I wasn't doing before.
I
I think you're probably right on both counts. I thought so before my Thursday
night post, but really thought it best to check with the experts.
thanks,
Bill.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-
It's believed that the main problems were i-node problems identified by "fsck"
during boot. The first time, they were on sda6; the second time, they were on
sda7.
A few follow-up questions about the hard drive... I used the long but
non-destructive test options of both "badblocks" and "smartc
Allegedly, on or about 09 June 2017, William Mattison sent:
> * Hard drive? Somewhat unlikely. Two 4-hour non-destructive disk
> checks found no issues. System cleaned; cables dis- and re-connected;
> hard drive removed and put back in; no kinky cables seen. Destructive
> testing and replacing
On Fri, 2017-06-09 at 02:51 +, William Mattison wrote:
> I did my weekly patches this afternoon, and this time the system
> booted up fine. So I'm back to what caused the problems.
> * Motherboard battery? Quite unlikely, but not 100%
> certain. Battery replaced anyway.
> * Hard drive? Some
I did my weekly patches this afternoon, and this time the system booted up
fine. So I'm back to what caused the problems.
* Motherboard battery? Quite unlikely, but not 100% certain. Battery replaced
anyway.
* Hard drive? Somewhat unlikely. Two 4-hour non-destructive disk checks found
no is
Allegedly, on or about 03 June 2017, William Mattison sent:
> Before I took the system apart, I checked the CMOS clock and the
> voltages reported by the motherboard in the UEFI BIOS display:
> * CPU voltage varied, but was 0.98 +/- less than 0.01 volts.
> * "3.3V Voltage" was 3.392 volts.
> * "5V
Allegedly, on or about 03 June 2017, Louis Lagendijk sent:
> I have not followed this thread closely, but did you check the
> harddisk cable. They are often a source for problems...
That's certainly true. Not just badly plugged in leads, but also
ill-fitting connectors, and bent and folded SATA
The smartctl long test took about 4 hours (I think!). I wish it would notify
me when it was actually finished! As best as I could tell (by using "smartctl
-l error /dev/sda", it found no problems.
thanks,
Bill.
___
users mailing list -- users@lists.f
While changing the motherboard battery yesterday (Friday), most cables were
disconnected and then later re-connected. That included the hard drive
connection to the motherboard. I also disconnected and reconnected both the
power cable and the data cable where they plug in to the hard drive its
According to the man page, the "-n" option is non-destructive; the "-w" option
is what you described.
Regardless, it's too long.
Bill.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproje
On Sat, 2017-06-03 at 01:32 +, William Mattison wrote:
> I tried badblocks last night. I didn't realize how long it would
> take. After over 3 hours, I had to abort it to do something else.
>
> This morning, I retried it, this time with options to show its
> progress. It took between 3 1/2
On 06/02/2017 06:32 PM, William Mattison wrote:
> I tried badblocks last night. I didn't realize how long it would take.
> After over 3 hours, I had to abort it to do something else.
>
> This morning, I retried it, this time with options to show its progress. It
> took between 3 1/2 and 3 3/4
Well, the battery has been replaced this afternoon. It took between 2 and 2
1/2 hours. The system seems to be functioning ok so far, but I haven't yet
booted up in windows-7, and I haven't yet tried a "dnf upgrade".
Before I took the system apart, I checked the CMOS clock and the voltages
rep
I tried badblocks last night. I didn't realize how long it would take. After
over 3 hours, I had to abort it to do something else.
This morning, I retried it, this time with options to show its progress. It
took between 3 1/2 and 3 3/4 hours. Here are the results:
===
bash.3[~]:
Tim:
>> Yes, an update can be more stressful than other PC activities, for
>> *some* users. But for other users, they're always subjecting their
>> PC to a heavy workload, so a prolonged update session is nothing
>> different from normal use.
William Mattison:
> I don't understand what you're say
> Look up S.M.A.R.T., though be aware that some controllers may not
> co-operate, but that tends to be things like outboard USB interfaces, or
> RAID. Ordinary hard drives plugged straight into the motherboard are
> likely to be checkable. It's the hard drive, itself, that checks its
> health an
I did "smartctl --all /dev/sda > smartctl_out.txt". I got over 200 lines of
output. The most recent error reported in the output file is this one:
===
Error 66 occurred at disk power-on lifetime: 13741 hours (572 days + 13 hours)
When the command that caused the error occurred, th
Allegedly, on or about 31 May 2017, William Mattison sent:
> I recall hearing and reading that the output of lithium batteries is
> almost flat (better than any other type of battery), but then very
> quickly drops (faster than any other type of battery) as it reaches
> end-of-life.
I can't say th
On 05/30/2017 09:09 PM, William Mattison wrote:
> I wasn't fully convinced these problems are due to the battery. That's why I
> listed the four things I found "odd". On the other hand, I recall hearing
> and reading that the output of lithium batteries is almost flat (better than
> any other
Bill,
Power supplies can fail at any time, and they are less reliable than any
other parts in my PC's.
PC's are more reliable if you leave them on, configured to go into sleep
mode when left unused (this statement will spark a discussion).
Most spinning disk drives these days support smartd
I wasn't fully convinced these problems are due to the battery. That's why I
listed the four things I found "odd". On the other hand, I recall hearing and
reading that the output of lithium batteries is almost flat (better than any
other type of battery), but then very quickly drops (faster th
On Tue, 2017-05-30 at 02:42 +, William Mattison wrote:
> The fix on Thursday, May 18 did not last. This past Thursday, my
> workstation again failed to boot. This time, it dropped me into an
> emergency shell, not the dracut shell. This time, the log file was
> almost twice as long. But it
On 05/29/2017 07:42 PM, William Mattison wrote:
The clock was about 5 seconds slow compared to my "atomic" clock. I adjusted
that. This morning, the clock seemed barely noticeably slow compared to that atomic
clock, but by less than a second. So I'm agreeing with your suspicions that the bat
Good evening,
Hardware problems have seriously tied me up for about a week now. My apologies
for my silence on this topic. The hardware issue is not really fixed yet. I
likely will be forced off-line again for several days to a few weeks. If I'm
not responding; assume that that's what's hap
On 05/26/2017 04:52 AM, Tim wrote:
I'm still not convinced with the cargo-cult idea that the BIOS clock is
actually designed to run slow, rather than that simply being a common
side-effect. I've certainly had a motherboard where that effect did not
happen.
I've had several slow-clock issues ov
On 05/26/2017 10:48 AM, Tom Killian wrote:
> Some years ago I had an IBM ThinkPad that one day failed to boot, and
> every subsystem diagnostic that ran at power-up (keyboard, memory, disk
> controller, ...) reported a problem. On a whim I put in a new clock
> battery and everything was fine. Now
Some years ago I had an IBM ThinkPad that one day failed to boot, and every
subsystem diagnostic that ran at power-up (keyboard, memory, disk
controller, ...) reported a problem. On a whim I put in a new clock
battery and everything was fine. Now any time a machine suddenly goes
flakey, the clock
On Thu, 2017-05-25 at 12:47 -0700, Rick Stevens wrote:
> Otherwise, with a weak battery the BIOS will usually revert to default
> settings which are generally considered conservative and "safe".
I'm not so sure that's the case. In many PCs, the BIOS clock, BIOS
memory, and perhaps other BIOS hard
On 05/24/2017 11:40 PM, Joe Zeff wrote:
> On 05/24/2017 09:20 PM, William Mattison wrote:
>> The clock (and the CMOS battery) got some attention while trying to
>> fix the boot problem. I have not yet replaced the battery, but I'm
>> not seeing any problems. What is the likelihood that the batter
On 05/24/2017 09:20 PM, William Mattison wrote:
The clock (and the CMOS battery) got some attention while trying to fix the
boot problem. I have not yet replaced the battery, but I'm not seeing any
problems. What is the likelihood that the battery or the clock caused the boot
failure?
If t
Thank-you Sam and Rick.
For the next 2 questions, I'm not looking for numerical answers. Qualitative
probability terms on a scale going from "highly improbably" to "almost
certainly" would be great.
The clock (and the CMOS battery) got some attention while trying to fix the
boot problem. I h
On 05/24/2017 08:38 AM, William wrote:
> Good morning,
>
> The "f24 boot fails; need help" problem set me back a week. I'm still
> catching up. I seriously believe it would be foolish for me to just
> forget it. I should for the benefit of others try to get at the real
> cause and possible prev
William writes:
A few hours before the failure, I received and looked at an e-mail that I'm
almost certain was at least a spoof, and possibly malicious. I know it
contained html and links. I did *** not ***
click any of the links. I looked at it, and deleted it. It was viewed in
Thunder
34 matches
Mail list logo
