How worried should I be about my hard drive?

beachboy2 · 10-25-2023, 02:45 AM

hazel,

There is no need to panic.

Simply reduce the existing swappiness value (60?) to 1 by modifying the following file with:

Code:

sudo gedit /etc/sysctl.conf

Add the following lines, at the very end of the existing text in that file:

Code:

# Sharply reduce swap inclination
vm.swappiness=1

Save & Close.

EDIT

Also:
A swap partition can affect the durability of an SSD, but it is not likely to cause a significant reduction in the overall lifespan of the drive. When a system uses a swap partition, it can cause more frequent read and write operations to occur on the SSD, which can lead to more wear and tear on the drive.

However, most modern SSDs have a large number of write cycles before they start to degrade, so the impact of a swap partition on the durability of an SSD is likely to be minimal.

Additionally, many SSDs have built-in wear levelling features that help to distribute the wear and tear evenly across the drive, further reducing the impact of a swap partition on the durability of the SSD.

hazel · 10-25-2023, 03:33 AM

Thank you beachboy! Actually I don't currently have a sysctl.conf file but of course I can quite easily create one and I will certainly do so for the new drive.

As I said above, I don't do much that is memory-intensive apart from building software and I don't know how much of that I shall be doing in the future. I don't any longer build a full working LFS with FF and so on, just a basic system to prove to myself that I can. I don't play games or edit videos or run virtual machines, and I seldom have more than 4-5 tabs open on FF.

fatmac · 10-25-2023, 04:34 AM

I was dubious about SSD when they first appeared, but a lot has changed, just use them as normal, they will still last for years, something like 10 years in a busy business environment, I think it is.

beachboy2 · 10-25-2023, 05:40 AM

hazel,

FWIW, this is my sysctl.conf file in Linux Mint:

Code:

#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#

#kernel.domainname = example.com

# Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3

###################################################################
# Functions previously found in netbase
#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1


###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
#net.ipv4.conf.all.accept_redirects = 0
#net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
#net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
#

###################################################################
# Magic system request Key
# 0=disable, 1=enable all, >1 bitmask of sysrq functions
# See https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
# for what other values do
#kernel.sysrq=438
# Sharply reduce swap inclination
vm.swappiness=1

hazel · 10-25-2023, 06:19 AM

I notice that you aren't using any of those options except the swappiness.

OK, I'll follow my original plan. But not this afternoon, as someone I know is in hospital and I want to visit her.

Tomorrow.

I'll keep you posted.

rokytnji · 10-25-2023, 09:40 AM

might want to look to using zram in your gear hazel

shotgun link

I usually ignore the smart messages during install. My motorcycle shop computer finally died when the sata connector plastic crumbled in my fingers.

Hopefully a new sata connector, and new drive will fix it. If not. Oh well.

hazel · 10-25-2023, 09:54 AM

Code:

sudo smartctl -t long /dev/sda
sudo smartctl -a /dev/sda

Quote:

Originally Posted by beachboy2

Those figures for items #5 and #197 do not make for pretty reading.

The Current Pending Sector Count of 343 and Reallocated Sector Count of 1063 indicate imminent drive failure!

It does not matter if SMART says PASSED, those 2 figures are the ones which tell the true state of your drive.

This is what I'm going on. Better safe than sorry.

beachboy2 · 10-25-2023, 11:38 AM

hazel,

You can be rest assured that your WD Blue HDD was on the point of failure.

From your smartctl.log.txt, the Multi_Zone_Error_Rate (#200) value should be zero.

Your HDD’s was 2023.

In addition, the extended test highlighted numerous read failures which is a clear indication that the hard drive was failing.

The antiX installer was right in flagging up a warning initially and the extended SMART test confirmed the problem.

hazel · 10-26-2023, 05:24 AM

OK, there's good news and bad news. The good news is that I was able to put in the new disk without much trouble. The old one that I took out was four times as large and heavy with it. It has a label with the date 1st July 2014, which I assume means that it is ten years old.

Today I booted SystemRescue and was pleased to see /dev/sda in the kernel messages. I partitioned the drive using gparted and was able to mount the partitions and copy over the archived stuff. But I can't boot the new drive. I can boot from CD and from a memory stick (I am running FF out of live AntiX) but not from the new disk. It goes through POST, gives the usual bleep and then goes into a loop, printing out a message repeatedly. It's too fast to really read but it's something like "system ... not found", probably "system partition not found". In other words, it can't find the ESP.

But the ESP is there on partition sda2, where it was before. I gave it a fat32 filesystem and copied over the contents of the old ESP. Then I set the esp flag on it (and gparted automatically set the boot flag alongside it). I can mount it and look at the contents, fdisk says it's EFI System, but I can't boot from it.

What do I do now??

beachboy2 · 10-26-2023, 05:53 AM

hazel,

You could try running Boot Repair and see what the output gives.

https://sourceforge.net/projects/boot-repair-cd/files/

https://help.ubuntu.com/community/Boot-Repair

hazel · 10-26-2023, 06:06 AM

Quote:

Originally Posted by beachboy2

You could try running Boot Repair and see what the output gives.

None of the options in that are suitable for this problem

Code:

Reinstall GRUB bootloader
Repair GRUB configuration file
Backup mbr
Restore mbr

But I need to find a lost ESP. I'm not using GRUB anyway. I've got elilo on the ESP, but the damned UEFI can't find it!

beachboy2 · 10-26-2023, 06:20 AM

hazel,

I would usually make the FAT32 efi system partition the first partition on the drive (sda1), flagged as boot/esp.

hazel · 10-26-2023, 06:27 AM

It was sda2 before so that's what I made it again. It carries both those flags and gdisk shows it with the correct EFI code EF00.

I've been looking at this: https://unix.stackexchange.com/quest...ooting-options.
It looks like I might have to use efibootmgr. Anyway, I'm logging off now. I'll log in later in the day and see what suggestions other people might make.

mrmazda · 10-26-2023, 07:56 AM

This really deserves its own thread with appropriate title.

Knowing what efibootmgr reports is important for diagnosis and success. Are you trying to boot while the installation media still attached, or some rescue media? If /etc/fstab uses device names rather than LABELs or UUIDs, and if USB storage support is included in initrd, having done so could be an issue after the bootloader has completed its task.

The content of the old ESP can't just be copied from backup. IIRC, it needs to be "reinstalled" to account for the difference in ESP UUIDs. With Grub, update-bootloader --reinit is part of this process. IIRC, the BIOS needs the entry for the old disk replaced by one specifically for the new disk's ESP's UUID. Furthermore, old initrds may need to be regenerated via chroot, unless possibly the workarounds rd.hostonly=0 and/or rd.auto=1 are used on kernel cmdline until it/they have been. I haven't done very many disk replacements via backup/restore rather than cloning with UEFI systems to have the quirks firmly planted in my memory.

Also I've never used any Slackware bootloader. My systems are all multiboot. Those on UEFI/GPT all boot everything via Tumbleweed's Grub, including Slackware.

hazel · 10-26-2023, 10:47 AM

Quote:

Originally Posted by mrmazda

Knowing what efibootmgr reports is important for diagnosis and success. Are you trying to boot while the installation media still attached, or some rescue media? If /etc/fstab uses device names rather than LABELs or UUIDs, and if USB storage support is included in initrd, having done so could be an issue after the bootloader has completed its task.

I can boot with an AntiX installation stick or with a SystemRescue CD, no problem, but I can't boot directly from the hard drive. It should be possible to boot into LFS but first the UEFI has to find the ESP to load the elilo bootloader, and that's where it fails. I have actually altered LFS's /etc/fstab to reflect the new partitions, but because that only comes into focus when you actually have a running kernel, it's not relevant to this problem.

Quote:

The content of the old ESP can't just be copied from backup. IIRC, it needs to be "reinstalled" to account for the difference in ESP UUIDs. With Grub, update-bootloader --reinit is part of this process. IIRC, the BIOS needs the entry for the old disk replaced by one specifically for the new disk's ESP's UUID.

Yes, I thought it was something like that. Apparently some UEFIs scan for valid ESPs but some need to be told the GUID to use and then store the data in nvram. If I have one of those, it will still be looking for the old GUID and not finding it.

Quote:

Furthermore, old initrds may need to be regenerated via chroot, unless possibly the workarounds rd.hostonly=0 and/or rd.auto=1 are used on kernel cmdline until it/they have been. I haven't done very many disk replacements via backup/restore rather than cloning with UEFI systems to have the quirks firmly planted in my memory.

Also I've never used any Slackware bootloader. My systems are all multiboot. Those on UEFI/GPT all boot everything via Tumbleweed's Grub, including Slackware.

That's worth knowing too. If I get a crash at the initrd stage, I'll know why. But we haven't got there yet.#

If I install AntiX with GRUB included, passing the correct ESP partition to the installer, will that fix the problem? I don't really want GRUB (I much prefer elilo) but if that's the only way to get my ESP recognised, I'll have to bite the bullet.