William writes: You are correct. You are correct, again.

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 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? The boot failure occurred right after doing my weekly "dnf upgrade". What is the likelihood that the "dnf upgrade" (or one of the patches installed by it) caused the problem? thanks, Bill.

On 05/24/2017 11:40 PM, Joe Zeff wrote: I agree with Joe. I'd imagine the battery would only cause issues if the BIOS got messed up somehow. A slow clock wouldn't necessarily cause a boot issue--but you might get a lot of weird "file date is in the future" errors caused by the OS looking at the clock (which is slow) and comparing it against file dates (which were set using the correct time). This can also cause strangeness with LDAP and Kerberos authentication or Samba operations as they're time-sensitive. Otherwise, with a weak battery the BIOS will usually revert to default settings which are generally considered conservative and "safe". If it only managed to partially set up the defaults, weird stuff can happen. Note that if you had modified the boot order from the BIOS-based defaults, then you'd usually see the boot stall at the device selection point. If you set some other things (disk caches, memory timings, wait states and other items which gamers tend to mess with) then it could cause additional funkiness. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Admitting you have a problem is the first step toward getting - - medicated for it. -- Jim Evarts (http://www.TopFive.com) - ----------------------------------------------------------------------

On 05/26/2017 04:52 AM, Tim wrote: I've had several slow-clock issues over the decades solved by changing the battery, and I've never had it not work. Just because you don't believe it doesn't make it "cargo-cult."

On 05/29/2017 07:42 PM, William Mattison wrote: If your battery is getting low, it's just barely starting. Usually, when it becomes an issue, you see a change of minutes per day, not one or two seconds. Still, changing it can't hurt. However, your hard disk issues are making me wonder if either the disk or the controller aren't at fault. It's clearly a hardware issue to me, but there are still several possibilities for just what's gone bad.

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 than any other type of battery) as it reaches end-of-life. Back to diagnosing the real cause of the problems... Is there a Fedora command that I can use to check the hard drive (not the file systems) for bad blocks, sectors, tracks, etc? Is there a Fedora command that I can use to check the controller? Both problems occurred immediately after doing a "dnf upgrade". What is that telling us? Does "dnf upgrade" access the hard drive or the controller in a way that normal daily use does not? Is there something different about the first boot after a "dnf upgrade" vs other boots? I shut down every night, and boot up every morning. When I bought the system 4+ years ago, I bought separate parts. This is a DIY desktop. I was advised to buy more power supply than needed. I did so. So unless the power supply is failing, I would think it's not a good candidate for the cause of the two problems. There have been no problems until this month, and I've been doing weekly patches since I got the system in 2013. I was/am not in the mood to change the battery! Since I've already bought the new one and have no other use for it, and since the old one is 4+ years old, I plan to change the battery either Friday or Saturday. But you know what they say: "If you want to make God laugh, tell Him your plans!". I did watch the youtube that Tim provided. I don't recall seeing screws on the underside of the motherboard. I'll look again Friday or Saturday (God willing!). Thanks, Bill.

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, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 08 ff ff ff 4f 00 00:05:43.747 READ FPDMA QUEUED 61 00 08 ff ff ff 4f 00 00:05:43.746 WRITE FPDMA QUEUED ea 00 00 00 00 00 a0 00 00:05:43.746 FLUSH CACHE EXT ef 10 02 00 00 00 a0 00 00:05:43.746 SET FEATURES [Enable SATA feature] 27 00 00 00 00 00 e0 00 00:05:43.745 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3] =============== I can't really make heads or tails of this. I also notice in my system e-mail these 2 messages, bot on Thursday, May 25: (1st message) Device: /dev/sda [SAT], 8 Currently unreadable (pending) sectors (2nd message, 1 minute later) Device: /dev/sda [SAT], 8 Offline uncorrectable sectors I also tried "smartctl -t short /dev/sda", followed later by "smartctl -l selftest /dev/sda". The result: =============== SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 13813 - =============== If I understand the "-all" output correctly, the "-long" test would take about 4 hours, so I'm not trying that until later this week. What else from the "smartctl" output should I post here? What other "smartctl" functionality should I try or use? Thank-you. Bill.

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[~]: badblocks -s -v /dev/sda Checking blocks 0 to 1953514583 Checking for bad blocks (read-only test): done Pass completed, 0 bad blocks found. (0/0/0 errors) bash.4[~]: =============== I don't think this completely rules out the hard drive as the villain, but it's now less of a suspect. Am I correct in guessing that the non-destructive read-write option (option "-n") would take over twice as long (7 1/2 or more hours)? Thanks, Bill.

According to the man page, the "-n" option is non-destructive; the "-w" option is what you described. Regardless, it's too long. Bill.

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 itself. The hard drive was removed, vacuumed, and put back into its place. No problems since, but I haven't done a "dnf upgrade" since then. thanks, Bill.

Allegedly, on or about 31 May 2017, William Mattison sent: I can't say that I'm familiar with their discharge pattern, but I have read that an in-use lifespan of three years is considered normal. So, you're at the time it might be worth replacing, even if it's not the cause of current problems. At the very least, you stop this being a potential problem in another year or so. 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 and produces the stats, smartctl just gives you an interface. That you ought to try rebooting using a previous kernel, and see if problems persist. There are two red flags about problems after doing an update: 1. That a new kernel has changed hardware drivers, or created other incompatibilities. 2. That your hard drive had some bad spots that hadn't been used before, but as you filled it up with more files (the recent downloads and installs), you hit the problem area. Those are the two things that immediately jump to mind. 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. I would say not. It's just files in and out, under the control of some program, onto storage system in the usual way. Power supplies do fail, sometimes gradually, sometimes spontaneously combusting, sometimes just randomly glitching. It can be complete coincidence that some technical failure happens at the same time as you did something you considered more special than it merely sitting there. I agree with the concept of getting bigger than you think you need, but it's hard to work out the criteria. Few devices specify their power requirements, at all, or specify them adequately. i.e. A graphics card may say it needs a 100 watt power supply. That claim may be bogus, they may be overestimating so you buy an adequate one, it may be accurate. It doesn't specify how many watts it requires from the different supplies in your PC (12 volt, 5 volt, 3.3 volt, etc). So it could require a lot from a 12 volt supply, less from the 5 volt, and your power supply could be inadequate in one of those areas. Then there's the power supply specs. Do they list the power it can continuously supply, the momentary higher peaks that it can supply? And there's a similar thing with the devices, does a graphic card's power supply requirements specify continuous and momentary peaks. The momentary peaks, as something suddenly needs more power, as it turns on, or changes modes, etc., can be the kind of thing that cause enough trouble to make a system unstable. If you have a simple system, e.g. motherboard, graphics card, hard drive, optical drive, it's not too hard to ensure you put in a sufficiently beefy supply. If you have a PC loaded with gadgets, it's harder to estimate the requirements. But what type of power supply did you put in? Did you match the wattage your supplier said you needed, did you overcompensate by an extra 100 watts? Did you get some generic Chinese thing, or something that had a reputation? As an opposing example: I stripped apart a friend's Mac, it has a ridiculously beefy power supply, with large fat bus bars that bolt to the motherboard, rather than those multi-pin molex connectors you see on the average PC. And that system is designed as a whole, so the manufacturer ought to know the full system specs, as opposed to a PC assembled from multiple different vendors who never collaborated. I could see them on one of the videos, quite small silver ones, underneath the motherboard (you had to completely remove the board). But maybe they've switched to black ones, that need careful inspection to find. I agree with the comments that ASUS made a prize design goof by burying the CMOS battery with that plating. I understand the value of covering the whole board (forcing cooling across it, making it harder for accidentally dropped things to land on exposed conductors, etc), but they should have left a way to easily access the battery. -- [tim@localhost ~]$ uname -rsvp Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64 (always current details of the computer that I'm writing this email on) Boilerplate: All mail to my mailbox is automatically deleted, there is no point trying to privately email me, I only get to see the messages posted to the mailing list. Long ago I gave up on using Windows (TM) [Tantrum Machine], and I've never regretted it.

Tim: William Mattison: You mentioned that the problems happened straight after doing a dnf update, and wondered if *that* process could have been the cause of the problems. I was pointing out that an update is no different than any other medium-duty processing the computer might do (a bit of heavy thinking when it processes dependencies, idling along as new files get downloaded, a bit of slighly heavy thinking as the packages are decompressed for a few moments before they get saved to disc). I would have thought 600 watts is more than sufficient for a general PC. If you look at what gamers do to their boxes (with their high end graphics cards and virtually a CPU farm in a box), it's staggering the amount of power that some PCs (allegedly) use. I'm sure they don't really use all that, but the short term peaks as things fire up, change modes, etc., can be a heck of a lot higher than their nominal power usage - those transients can trip up cheap and nasty supplies. Thermaltake TR2 600W specs Maximum output capability 600 watts (no surprise, considering the model name, and I think they've got a good reputation). ASUS Sabertooth Z77 Looks nice, but I see no power specs on their site. Though I see a review of that board with your processor that suggests up to 183 watts normally, add another 100 watts if overclocked. GeForce GTX 660 specs Maximum power used by the card 140 watts Minimum system power supply recommendation 450 watts Hmm, yeah, love their thinking there. Well, I supposed they're making an estimation of the likely power requirement of the rest of your system. ASUS Xonar Essence STX Looks nice, a card without those wonky 3.5 mm jacks, and designed for sound quality. The kind of thing I might have gone for if I were buying new parts. No power specs, but I wouldn't think it's a major power hog. Hard drives under 10 watts Blu-ray drives about 30 watts Yes, sounds like a 600 watt supply should be fine. And your friend obviously has the background to figure that out, too. So, if it's a power problem, that might be down to a fault rather than being an insufficient supply, in general. Noting your other messages about hard drive errors, it may be that the drive itself is failing. Unrecoverable errors doesn't sound good, and have never bode well for the couple of drives I had with them. Though some people say that they can carry on using a drive with such bad sectors, if there's not many of them, and they're not increasing. Faults with "unrecoverable, uncorrectable, unreadable" types of errors are a big red flag. The simple test is to try and write to the entire drive (which is easiest to do when wiping the entire contents, rather than filling up the space of an in-use drive), and see if that changes the error condition. Such as, if it couldn't read the contents of something that was an interrupted write (such as a system crash, power failure, etc), on an undamaged portion of the drive, but could wipe and re-use that bit, suggests the drive will be okay. The error being caused externally. But if it can't write and read those sectors, with a fresh attempt, that points the finger at the drive being at fault. There are long and short SMART self tests that do these kinds of things. If you can afford to wipe the drive and test it, that may be the best way forward. If you go to your drive's manufacturer's site, they probably have a self-booting disc image to burn to test your drive (Seagate and Western Digital, at least, used to when I've done this in the dim and distant past). If you can't do that, my suggestion is to buy a new hard drive, install a fresh OS onto it, and test drive your PC for a week or so. -- [tim@localhost ~]$ uname -rsvp Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64 (always current details of the computer that I'm writing this email on) Boilerplate: All mail to my mailbox is automatically deleted, there is no point trying to privately email me, I only get to see the messages posted to the mailing list. The mindset of software designers: You know that feature that you, and many thousands of other users, found useful? We removed it, because we didn't like it. We also hard-coded the default settings that you keep customising.

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.

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 issues. System cleaned; cables dis- and re-connected; hard drive removed and put back in; no kinky cables seen. Destructive testing and replacing the hard drive are not options for me at this time. Circumstances suggest such would be over-kill. * Somehow caused by the "dnf upgrade"? I can't assess this. After the second failure (May 25), I backed up all user data, and then upgraded from f24 to f25. I did not see any problems. This afternoon's patches were f25; the failures were f24. So I can no longer test whether f24 patching is at fault. But if it were, I'd be surprised if I were the only person to be hit by it. So my leaning is that it wasn't the patching that caused the problems. * Power supply? Somewhat unlikely. I know of no way to test this. But Tim's analysis and other circumstances suggest it's not worth pursuing this possibility any further. Two questions: 1. Are there any other theories I should consider? 2. Should I submit a bugzilla? (If yes, against what?) thanks, Bill.

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.

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 "smartctl". They each scan the entire hard drive, right? If "dnf upgrade" were writing to new areas of the disk, and those areas were bad, 1. those writes would have failed, and in turn have caused the "dnf upgrade" to fail, right? 2. the "smartctl" and "badblocks" tests would have found and reported those bad areas right? I only have one system, and only one hard drive, and no money to buy. The hardware work was done between fixing the second occurrence of the problem and the upgrade from f24 to f25. That upgrade would have done a lot more disk writing (and reading?) than did the two f24 weekly patches that preceded the boot failures. This suggests - merely suggests - to me that the hardware work (re-doing cable connections, cleaning, etc.) fixed the problem rather than it being a problem within the hard drive. thanks, Bill.