Create duplicate link for /dev/mapper devices - Consequences

S. Nixon

11/8/23, 11:14 PM

I have an Ubuntu 18.04 server that is not able to perform "sudo apt upgrade" at the moment. It is receiving this message whenever we try to update any packages:

/usr/sbin/grub-probe: error: failed to get canonical path of `/dev/mapper/rootvg-rootlv'.
run-parts: /etc/kernel/postrm.d/zz-update-grub exited with return code 1

The server is still fully functional, and in fact hosts a PostgreSQL environment that is being used regularly. Because of that, I cannot simply shut it down without knowing if it will come back up. For now, we've just been making sure that we have all our data backed up regularly while we plan out how to fix this.

Today, I believe I discovered why the error message is being displayed. The volume group name seems to be missing a letter (rootv instead of rootvg) for some of the mounted filesystems.

$ vgs
  VG     #PV #LV #SN Attr   VSize    VFree
  datavg   1  69   0 wz--n-    4.36t   <2.32t
  rootvg   1   6   0 wz--n- <891.25g <717.25g

$ cd /dev/mapper; ls -l rootv*
lrwxrwxrwx 1 root root 7 Jan 24  2022 rootv-homelv -> ../dm-2
lrwxrwxrwx 1 root root 7 Jan 24  2022 rootv-rootlv -> ../dm-0
lrwxrwxrwx 1 root root 7 Jan 24  2022 rootv-swaplv -> ../dm-1
lrwxrwxrwx 1 root root 7 Jan 24  2022 rootv-tmplv -> ../dm-3
lrwxrwxrwx 1 root root 8 Jun 27 13:43 rootvg-chrootlv -> ../dm-46
lrwxrwxrwx 1 root root 8 Aug 13 10:54 rootvg-inbacklv -> ../dm-74

I am not sure what happened and how this managed to get this way, as I am sure we initially created them with the full name, but regardless it is what it is now. So how to fix it is the next question.

Here's my thought:
Can I create a second link to the same device ?

Example: If I issued the command: ln -f -s /dev/dm-0 /dev/mapper/rootvg-rootlv I would then have two links to the same dm device file

lrwxrwxrwx 1 root root 7 Jan 24  2022 rootv-rootlv -> ../dm-0
lrwxrwxrwx 1 root root 7 Nov 08 16:43 rootvg-rootlv -> ../dm-0

Would it be possible to do this, then remove the incorrect link, and then reboot? Or (in your opinion or knowledge), would the system crash or have more serious issues doing this? Has anyone ever had a similar issue?

I'd love to know how the VG name in the /dev/mapper may have gotten changed from its original value, but I'd be happy just to come up with a solution that does not involve re-installing from scratch.

Thx.

Steve N.

1 + 0

apt

grub2

devices

Score:0

Ubuntu

S. Nixon

11/30/23, 8:20 PM

Some feedback regarding this problem that I had with my Ubuntu Server 18.04 system. As indicated, I created a duplicate link in the /dev/mapper directory for the "rootvg" volume group links that were missing and/or somehow renamed to "rootv" instead. Still not sure what caused that, but we created the extra links in an attempt to get around the problem and try to get this server working. The extra links did indeed fix the immediate problem... I was able to use apt update and apt upgrade to apply all of the available package fixes.

The big question mark was whether this would cause any problems at boot time. The answer to that was "yes and no". Yes we had an issue rebooting the server, but no it does not appear to be related to the dual links that were created.

Turns out this server had some other issues, probably related to the original problem (where the volume group name was somehow changed from rootvg to rootv while the server was booted). Checking the /etc/fstab using findmnt and blkid commands, we could see that the UUID values were all mixed up. To give an example, see below. The UUID for root (/) was pointing to a different volume group altgether.

/
   [ ] target exists
   [ ] UUID=b134557d-89d0-4270-ae6d-5c9a8b4c1598 translated to /dev/mapper/datavg-applv
   [ ] source /dev/mapper/datavg-applv exists
   [ ] FS type is ext4

During the subsequent reboot, the server was giving errors and would not even boot into a maintenance shell. We ended up re-installing Ubuntu 18.04 on a rootvg volume group, and then using vgchange to import the datavg area properly.

After the re-install of Ubuntu, the contents of various system files were lost and had to be recreated, such as /etc/hosts. Users and groups were gone and had to be rebuilt. CUPS printers were still there and unaffected.

Long story short, in this case, it does not appear that we were able to save the system setup using the extra links indicated. But we are using it as a learning experience to determine what to do the next time, if this happens again.

Hopefully others can learn by example here, or maybe have suggestions on what may have gone wrong. My only thoughts on this is that it may have been something related to a chroot area that we created and used bind mounts to be able to share data from the original location (eg. /home/UserA bind mounted to /var/chroot/home/UserB/homedirA)

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Create duplicate link for /dev/mapper devices - Consequences

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.