A computer components & hardware forum. HardwareBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HardwareBanter forum » General Hardware & Peripherals » General
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Can a weak CMOS battery prevent detection of a drive



 
 
Thread Tools Display Modes
  #1  
Old October 16th 20, 09:07 PM posted to alt.comp.hardware
Norm Why[_2_]
external usenet poster
 
Posts: 87
Default Can a weak CMOS battery prevent detection of a drive

I read that weak CMOS battery can prevent detection of a drive. I have two
SSD drives. One an old Samsung 500GB boots reliably. Drive D: is a new
Seagate Barracuda, 500GB that is not detected reliably. I've done everything
conceivable with the cables. I've read bad reviews on the Barracuda.

BIOS program says CMOS battery is 3V whereas 3.3V might have been when it
was new.

Is it worth my time to buy a new CMOS battery?

Thanks


  #2  
Old October 17th 20, 03:31 AM posted to alt.comp.hardware
Norm Why[_2_]
external usenet poster
 
Posts: 87
Default Can a weak CMOS battery prevent detection of a drive

CMOS battery? Crazy idea, I know.

It took me all day to solve this problem. My Samsung SATA 2.0 boot drive
always work. The Barracuda SATA 3.0 SSD is finicky. I thought maybe a SATA
3.0 cable would work. Wrong. SATA 2.0 and SATA 3.0 are electrically
identical. The SATA 3.0 cable I tried had an elbow that made it
troublesome. SATA 2.0 cable is not.

I thought why is Barracuda SATA 3.0 SSD is finicky? Maybe bigshot does not
want to be slave. I rearranged the cables in the six available SATA ports.
Then I renamed drive E: to drive D: in Win10 and everything worked.

I ran CrystalDiskInfo and CrystalDiskMark and everything was fantastic.

Saved me a bundle of money not buying a new PC workstation. 12GB of RAM
works good.


I read that weak CMOS battery can prevent detection of a drive. I have two
SSD drives. One an old Samsung 500GB boots reliably. Drive D: is a new
Seagate Barracuda, 500GB that is not detected reliably. I've done
everything conceivable with the cables. I've read bad reviews on the
Barracuda.

BIOS program says CMOS battery is 3V whereas 3.3V might have been when it
was new.

Is it worth my time to buy a new CMOS battery?

Thanks



  #3  
Old October 17th 20, 04:07 AM posted to alt.comp.hardware
Paul[_28_]
external usenet poster
 
Posts: 1,351
Default Can a weak CMOS battery prevent detection of a drive

Norm Why wrote:
CMOS battery? Crazy idea, I know.

It took me all day to solve this problem. My Samsung SATA 2.0 boot drive
always work. The Barracuda SATA 3.0 SSD is finicky. I thought maybe a SATA
3.0 cable would work. Wrong. SATA 2.0 and SATA 3.0 are electrically
identical. The SATA 3.0 cable I tried had an elbow that made it
troublesome. SATA 2.0 cable is not.

I thought why is Barracuda SATA 3.0 SSD is finicky? Maybe bigshot does not
want to be slave. I rearranged the cables in the six available SATA ports.
Then I renamed drive E: to drive D: in Win10 and everything worked.

I ran CrystalDiskInfo and CrystalDiskMark and everything was fantastic.

Saved me a bundle of money not buying a new PC workstation. 12GB of RAM
works good.


I read that weak CMOS battery can prevent detection of a drive. I have two
SSD drives. One an old Samsung 500GB boots reliably. Drive D: is a new
Seagate Barracuda, 500GB that is not detected reliably. I've done
everything conceivable with the cables. I've read bad reviews on the
Barracuda.

BIOS program says CMOS battery is 3V whereas 3.3V might have been when it
was new.

Is it worth my time to buy a new CMOS battery?

Thanks


While the cables may be the same for all the standards,
the hardware driving the cable may not like the signals
or signal levels coming from the drive. Digital signals
do have their analog aspects. Eye opening and so on.

Some of the VIA Southbridge ports had their problems, in
that they didn't negotiate rate properly. And then any
prospective drives had to use "Force 150" to get them
to work. VIA eventually figured this out, so there
*is* some VIA product that works just fine. But there
will also be just a few museum pieces out there with
that flaw. Mine appears to be OK, but I haven't extensively
tested with SATA III drives to see if they all negotiate
properly to SATA I with that motherboard. The motherboard
is "retired", but is a viable option if the thing I'm
typing on ever dies.

The CMOS battery need drop to 2.3V before it's no longer
compliant with what is expected of it. 3.0V is still fine.
The Southbridge RTC is generally rated 2.0V plus you add
0.3V for the drop across the BAT54 schottky in the path.
A battery creating 2.3V, after diode drop, delivers 2.0V
to the Southbridge. And the RTC is supposed to run at
that low level.

If you've been cloning drives, you should use a good
software for it. Macrium Reflect Free will change
the identifiers on the partitions when it clones,
such that if a drive and its clone are plugged into
the same computer, there is no confusion about
which partition is which. Using "dd" isn't quite
the same, and requires manual intervention to prevent
one drive from entering the "Offline" state. Use
diskmgmt.msc (Disk Management) if a drive "disappears"
to see if its row is still present in Disk Management,
but the left-hand square is labeled "Offline". A number
of disk identifiers are allowed to be the same, but
there's at least one disk identifier that the OS
won't allow to be the same, and then the second
drive to be probed is put "Offline" for safety.

When Macrium clones, it also only transfers the occupied
clusters, which is like a "free TRIM" in a sense. "dd"
transfers from SSD to SSD would transfer all blocks,
which burns up a lot of the free pool on the destination,
and can benefit from issuing a TRIM per partition
in the Optimize panel later.

Paul
  #4  
Old October 17th 20, 05:33 AM posted to alt.comp.hardware
David W. Hodgins
external usenet poster
 
Posts: 138
Default Can a weak CMOS battery prevent detection of a drive

On Fri, 16 Oct 2020 23:07:55 -0400, Paul wrote:
When Macrium clones, it also only transfers the occupied
clusters, which is like a "free TRIM" in a sense. "dd"
transfers from SSD to SSD would transfer all blocks,
which burns up a lot of the free pool on the destination,
and can benefit from issuing a TRIM per partition
in the Optimize panel later.


I manually create and format the new partitions, and then use rsync to transfer
the files. That's also how I do my primary backup of data. In run level 1, with
any remaining user processes killed I run ...
time nice -n 19 ionice -n 7 rsync -auvxSHXAP --specials --sparse --delete --exclude="lost+found" /home/dave/ /aback/home/dave/

Regards, Dave Hodgins

--
Change to for
email replies.
  #5  
Old October 17th 20, 06:30 AM posted to alt.comp.hardware
Paul[_28_]
external usenet poster
 
Posts: 1,351
Default Can a weak CMOS battery prevent detection of a drive

David W. Hodgins wrote:
On Fri, 16 Oct 2020 23:07:55 -0400, Paul wrote:
When Macrium clones, it also only transfers the occupied
clusters, which is like a "free TRIM" in a sense. "dd"
transfers from SSD to SSD would transfer all blocks,
which burns up a lot of the free pool on the destination,
and can benefit from issuing a TRIM per partition
in the Optimize panel later.


I manually create and format the new partitions, and then use rsync to
transfer
the files. That's also how I do my primary backup of data. In run level
1, with
any remaining user processes killed I run ...
time nice -n 19 ionice -n 7 rsync -auvxSHXAP --specials --sparse
--delete --exclude="lost+found" /home/dave/ /aback/home/dave/

Regards, Dave Hodgins


But being sans-automation, your UUIDs or BLKIDs aren't fit for
purpose until you put things back together again. At least
for boot materials, this is the case.

Macrium automates the treatment of Windows and its boot materials.
It gets most of the details right. It's a prototype of
what automation should be, because ordinary users don't
have to drop to command line afterwards.

Macrium can copy EXT4 as well, which is a feature I use. But
sadly, when cloning, it doesn't have the logic to properly
handle /etc/fstab. It doesn't tidy up.

Macrium reaches into the BCD file and edits it, which is
why cloned Windows drives behave themselves. But Macrium
lacks the feature of doing the same for Linux.

I'm still waiting to find even a commercial tool that
does this for the Linux ecosystem properly. The only reason
Macrium has Windows support, is there is at least one
Windows-provided utility that is capable of rebuilding
the BCD. But it doesn't work well enough in practice
to be useful. So the Macrium designers added their
own code to do this. And it isn't always 100%
successful. An attempt to have Win2K added to the
Win7 boot menu, there were some issues with what
it did. Still not perfect, but for a lot of the
users, they might never notice the rough
edges (because who would be running Win2K except
the guy I was helping the other day...).

There are a lot of rocky shoals in the Clone Sea,
and lots of places to run aground. There's still lots
of room for improvements.

Paul
  #6  
Old October 17th 20, 07:45 AM posted to alt.comp.hardware
David W. Hodgins
external usenet poster
 
Posts: 138
Default Can a weak CMOS battery prevent detection of a drive

On Sat, 17 Oct 2020 01:30:14 -0400, Paul wrote:
But being sans-automation, your UUIDs or BLKIDs aren't fit for
purpose until you put things back together again. At least
for boot materials, this is the case.


I'm fine with manually editing fstab, in which I use labels instead of uuid ...
$ grep x7 /etc/fstab
LABEL=x7b / ext4 defaults,noatime 1 1
LABEL=x7bboot /boot ext4 defaults,noatime 1 2
manually changing /boot/grub2/install.sh and if needed, /boot/grub/device.map,
and then using chroot or systemd-nspawn to update the grub2 boot loader,
either from another install on the same system or from a live iso.

I've done it enough times, it's pretty easy to remember the steps needed, or
debug and fix if I've missed one.

Regards, Dave Hodgins

--
Change to for
email replies.
  #7  
Old Yesterday, 02:36 PM posted to alt.comp.hardware
philo
external usenet poster
 
Posts: 1,306
Default Can a weak CMOS battery prevent detection of a drive

On 10/16/20 3:07 PM, Norm Why wrote:
I read that weak CMOS battery can prevent detection of a drive. I have two
SSD drives. One an old Samsung 500GB boots reliably. Drive D: is a new
Seagate Barracuda, 500GB that is not detected reliably. I've done everything
conceivable with the cables. I've read bad reviews on the Barracuda.

BIOS program says CMOS battery is 3V whereas 3.3V might have been when it
was new.

Is it worth my time to buy a new CMOS battery?

Thanks





Glad you got it figured out.

To answer your question though, a 3.0 volt CMOS battery is fine.

If the battery was too low, you'd simply lose your settings.

I did *once* have a battery around 2.6 volts that would not allow the
machine to post.


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Using software to prevent battery problems.... Mr. Man-wai Chang Homebuilt PC's 8 September 13th 16 06:28 PM
Bad CMOS Battery MrTsquare Homebuilt PC's 9 December 28th 14 11:45 AM
CMOS Battery Jake[_5_] Acer Computers 1 May 25th 08 09:26 AM
I need to know how to get to Armanda 7400 Cmos Battery to clear the Cmos. cen04543 Compaq Computers 4 February 20th 06 10:31 AM
cmos battery philo General 4 May 11th 04 12:46 PM


All times are GMT +1. The time now is 01:07 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright 2004-2020 HardwareBanter.
The comments are property of their posters.