Physical Volumes not OK (Bad) [SOLVED]

[diapason]

I am on a clean install of Linux Mint 19 Cinnamon. Everything is working absolutely fine. However, I chanced to notice in the System State Report under LVM state:
Physical Volumes not OK (Bad)
Volume Groups OK (good)

Using a live bootable USB stick, I have run fdisk -l and then fsck on both my SSDs

/dev/sda (dos partition table) and /dev/sda1 [this is the disk where Linux is installed]
/dev/sdb (dos partition table) and /dev/sdb1 [this is the disk where I store all my files, backups and Timeshift images]

/dev/sda1 appeared to have bad blocks so I then ran e2fsck -b starting at the suggested block. This seemed to correct things and a re-run of fsck came up clean.

However, on checking LVM State, it still says Physical Volumes not OK (Bad).

I have not uploaded lots of system information at this stage as I think I may just be looking the wrong way at fixing the physical volume error and a nudge in the right direction will probably suffice.

[WharfRat]

Could it be https://bugs.launchpad.net/ubuntu/+sour ... ug/1790468

The script runs pvck so you can do that with sudo pvs --no-headings|awk '{print $1}'|xargs sudo pvck -v

[Joe2Shoe]

IMHO, when a HDD/SSD shows signs (Bad) of going south, I back-up the data on the drive, then I reformat the drive, then run diagnostics on the drive. If in my opinion the drive is OK, I may use it as a backup drive, or if still under warranty, return it for a replacement. But, I would never trust that drive again.

[diapason]

Hello, WharfRat
Thanks for that. I read the article but I could not make the command you suggested run. I'm probably misunderstanding something.

However, in the meantime, I re-formatted the disk and did a clean install of Mint 19 and the result is still the same so I ran the SMART test from gnome-disk-utility and that has confirmed 2 bad sectors on sda1 with uncorrectable errors on 10 sectors so it seems the System State report is accurate after all.

I have been in touch with the folks who built the computer and they said that is pretty much normal for a drive of that age (I have had it for just over 4 years and the up-time is just over 1 year) so not to worry too much about it but to be sure to keep good backups as SSDs usually fail hard with no warning. I am not too concerned about a sudden failure of sda1 as I only have the Linux OS on that but all my data is on a second SSD of the same age (which has no errors) so I think it would be wise to start taking a regular backup copy of that disk onto an external HDD. It's easy to forget that the storage SSD works just as hard as the main disk.

Thanks also to Joe2Shoe who also chipped in. Years ago, there was a common saying , back up, back up and then back up again. Holds good today, I think.

[WharfRat]

Comprehensive backups are always good

I don't know why that check didn't work for you, but for me this is what I get:

Code: Select all

[bill@slvm] ~ $ sudo pvs --no-headings|awk '{print $1}'|xargs sudo pvck -v
    Scanning /dev/sda2
  Found label on /dev/sda2, sector 1, type=LVM2 001
  Found text metadata area: offset=4096, size=1044480
    Found LVM2 metadata record at offset=11776, size=2560, offset2=0 size2=0
    Found LVM2 metadata record at offset=9728, size=2048, offset2=0 size2=0
    Found LVM2 metadata record at offset=7680, size=2048, offset2=0 size2=0
    Found LVM2 metadata record at offset=6144, size=1536, offset2=0 size2=0
    Scanning /dev/sdb2
  Found label on /dev/sdb2, sector 1, type=LVM2 001
  Found text metadata area: offset=4096, size=1044480
    Found LVM2 metadata record at offset=11776, size=2560, offset2=0 size2=0
    Found LVM2 metadata record at offset=9728, size=2048, offset2=0 size2=0
    Found LVM2 metadata record at offset=7680, size=2048, offset2=0 size2=0
    Found LVM2 metadata record at offset=6144, size=1536, offset2=0 size2=0
    Scanning /dev/sdc2
  Found label on /dev/sdc2, sector 1, type=LVM2 001
  Found text metadata area: offset=4096, size=1044480
    Found LVM2 metadata record at offset=11776, size=2560, offset2=0 size2=0
    Found LVM2 metadata record at offset=9728, size=2048, offset2=0 size2=0
    Found LVM2 metadata record at offset=7680, size=2048, offset2=0 size2=0
    Found LVM2 metadata record at offset=6144, size=1536, offset2=0 size2=0
[bill@slvm] ~ $ 

[diapason]

It might be a syntax thing which is beyond my terminal skills. When I run the command I get the following:

ian@Galago:~$ sudo pvs --no-headings|awk '{print $1}'|xargs sudo pvck -v
[sudo] password for ian:
No command with matching syntax recognised. Run 'pvck --help' for more information.
Correct command syntax is:
pvck PV ...

Wiping internal VG cache
ian@Galago:~$

I looked at pvck --help and the inference is that the correct syntax is: sudo pvs --no-headings|awk '{print $1}'|xargs sudo pvck PV ... -v so I tried using:
sudo pvs --no-headings|awk '{print $1}'|xargs sudo pvck PV /dev/sda1 -v but it returns "device not found (same if I just put /sda1 without /dev

As I have now confirmed that there is a problem on the disk, I am going to mark this post [SOLVED]. However, establishing why this command won't run for me is of academic interest but please don't spend time on it if you have more pressing demands on your skills.

Many thanks.

Ian

[WharfRat]

I copied and pasted your line sudo pvs --no-headings|awk '{print $1}'|xargs sudo pvck -v

Code: Select all

[bill@lv] ~ $ sudo pvs --no-headings|awk '{print $1}'|xargs sudo pvck -v
    Scanning /dev/sda2
  Found label on /dev/sda2, sector 1, type=LVM2 001
  Found text metadata area: offset=4096, size=1044480
    Found LVM2 metadata record at offset=8704, size=2048, offset2=0 size2=0
    Found LVM2 metadata record at offset=7168, size=1536, offset2=0 size2=0
    Found LVM2 metadata record at offset=5632, size=1536, offset2=0 size2=0
    Scanning /dev/sdb
  Found label on /dev/sdb, sector 1, type=LVM2 001
  Found text metadata area: offset=4096, size=1044480
    Found LVM2 metadata record at offset=8704, size=2048, offset2=0 size2=0
    Found LVM2 metadata record at offset=7168, size=1536, offset2=0 size2=0
    Found LVM2 metadata record at offset=5632, size=1536, offset2=0 size2=0
    Scanning /dev/sdc
  Found label on /dev/sdc, sector 1, type=LVM2 001
  Found text metadata area: offset=4096, size=1044480
[bill@lv] ~ $ 

Just out of curiosity what do you get for sudo pvdisplay -C

[diapason]

It prompts for my password and, after I enter it, drops to a blinking cursor which, after a few seconds goes steady and nothing further happens.

[WharfRat]

Are you choosing to enter recovery from grub or are you ending up there due to system problems

[diapason]

Hello, again

There's a bit of a story there but to answer your question, it is not system problems which are putting me into GRUB. The system boots quite normally (about 30 seconds from pressing the power button). Entering GRUB and recovery mode was a deliberate action.

A couple of weeks ago, I decided to have a little flirtation with the UKuu kernel manager. It all seemed fine and I had installed several kernel upgrades as they were notified, without problems, up to 4.19.4. When the alert for 4.19.5 popped up a few days ago, I accepted the invitation to install and I think that was the origin of the problem. The installation did not go as usual and I noticed that there were 3 or 4 files rejected (in red) as not being legitimate Debian format.

The kernel appeared in the UKuu app list of available kernels and it was also showing in Update Manager but it was not in GRUB which was still booting 4.19.4 but I could not remove the failed 4.19.5 from UKuu or Update Manager.

That's when I thought to boot into recovery mode and see if the tools there might be of any help. I was able to run fsck and it seemed to repair some bad blocks which surprised me a little as the disk would have been mounted and I did not think fsck would run under those conditions. It was while doing that exercise that I looked at the System State option and saw the bad PV message.

I have since reverted to booting the latest "official" kernel from Update Manager (4.15.0-39) and I removed all the later kernels from UKuu and completely uninstalled that package. I also then managed to remove the unwanted 4.19.x kernels from Update Manager so I'm back where I should be kernel-wise.

Along the way, in trying to sort the PV problem, I reformatted sda1 and did a clean install of Mint 19 with a mount point of / and everything is running pretty much as I would expect although GParted shows only one partition on sda1 ie there is no swap and I'm sure there was before so I may have to address that. The second SSD (sdb1) where all my data is stored and which has a mount point of /media/ian/Samsung, is accessible and reading and writing normally but is showing some erratic behaviour in that once mounted, it sometimes becomes inaccessible and has to be unmounted and remounted. In order to do the unmount, the system asks for my password. It's just irritating and I'll get to the bottom of it eventually. It may be as simple as just taking ownership of it again if that got upset by the reformatting of sda1.

[WharfRat]

Along the way, in trying to sort the PV problem, I reformatted sda1 and did a clean install of Mint 19 with a mount point of / and everything is running pretty much as I would expect although GParted shows only one partition on sda1 ie there is no swap

From what I've heard. 19 sets up a /swapfile instead of a swap partition - don't know why

I was able to run fsck and it seemed to repair some bad blocks

Fsck doesn't repair bad blocks. Unless you used the -c or -cc option badblocks was never involved.
And what happens is if any bad blocks are found, they are added to a bad block inode to prevent them from being allocated.

The second SSD (sdb1) where all my data is stored and which has a mount point of /media/ian/Samsung, is accessible and reading and writing normally but is showing some erratic behaviour in that once mounted, it sometimes becomes inaccessible and has to be unmounted and remounted.

Can't explain that one, but it certainly shouldn't happen.

Check dmesg and /var/log/syslog for any clues to why it keeps taking it off-line.

Good luck

[diapason]

dmsg and the syslog show a number of entries which read EXT4 -fs (sdb1): mounted file system with ordered data mode. Opts: (null).
That does not mean anything to me. Otherwise there is nothing which looks related.

I took ownership of the drive again and that seems to have cured the problem.

Now, as I think I have probably exhausted my credit on this issue, I'm going to let it rest before I outstay my welcome!

Many thanks for all your input.

Ian