[bug #64167] grub fails to parse LVM information from PV

[Torsten Hilbrich]

URL:
  <https://savannah.gnu.org/bugs/?64167>

                 Summary: grub fails to parse LVM information from PV
                   Group: GNU GRUB
               Submitter: myrkr_el
               Submitted: Tue 09 May 2023 06:28:02 AM UTC
                Category: Booting
                Severity: Major
                Priority: 5 - Normal
              Item Group: Software Error
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Torsten Hilbrich
        Originator Email: torsten.hilbrich@secunet.com
             Open/Closed: Open
                 Release: Git master
                 Release: 
         Discussion Lock: Any
         Reproducibility: Every Time
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Tue 09 May 2023 06:28:02 AM UTC By: Torsten Hilbrich <myrkr_el>
Grub version 2.06

I have a test system with the following partition layout:

/dev/nvme0n1: Partitioned as GPT
/dev/nvme0n1p3: A boot partition, partition type "EFI System"
  On that partition boot as installed as EFI binary
/dev/nvme0n1p5: Partition type "Linux LVM"

The PV contains a volume group named "sinavw", it has a number of LV where
SYS1 and SYS2 can then be used for booting.

The system is the following, whenever to load the kernel from the LV the
following error is output:


error: no server is specified


Using the user-space grub-fstest tool I was able to diagnose the problem a bit
more. The failure is happening while parsing the LVM meta data from the PV. I
have extracted the first about 1 MiB from the /dev/nvme0n1p5 partition, with
the call of:


grub-fstest --verbose start-of-pv-with-error cat '(lvm/sinavw-SYS1)/VERSION'


I could reproduce the problem.

The error occurs when trying to parse the name of the LV "ISO-EMSIFDBO", it
seems that the mda_end previously determined points to the newline after that
name. So the following code block from grub-core/disk/lvm.c, function
grub_lvm_detect (around line 459) determines that the condition "q == mda_end"
is true.


              lv = grub_zalloc (sizeof (*lv));

              q = p;
              while (*q != ' ' && q < mda_end)
                q++;

              if (q == mda_end)
                goto lvs_fail;


Here is some debugger output around that code:


456                   while (*q != ' ' && q < mda_end)
1: q = 0x7fcfd76b9004 "ISO-EMSIFDBO {\nid =
\"Ze7l6L-hS8k-QPYf-VPTz-OuLD-bNxO-iRC5mP\"\nstatus = [\"READ\", \"WRITE\",
\"VISIBLE\"]\nflags = []\ncreation_time = 1600763824\ncreation_host =
\"hilbrich.torsten.2016.at.secunet.de\"\nsegment_c"...
(gdb) p mda_end
$1 = 0x7fcfd76b9010 " {\nid =
\"Ze7l6L-hS8k-QPYf-VPTz-OuLD-bNxO-iRC5mP\"\nstatus = [\"READ\", \"WRITE\",
\"VISIBLE\"]\nflags = []\ncreation_time = 1600763824\ncreation_host =
\"hilbrich.torsten.2016.at.secunet.de\"\nsegment_count = 1\n\nse"...


The same PV can be used within the linux system without any problem. I use a
current kernel (currently 6.1.28) and the lvm2 tools in version 2.02.180.

I also noticed that when performing some LVM operation on linux the problem
happened to disappear in the past, only the reappear later on. I assume that
the position of the current copy of the meta data changes and influences the
problem.








    _______________________________________________________
File Attachments:


-------------------------------------------------------
Date: Tue 09 May 2023 06:28:02 AM UTC  Name: start-of-pv-with-error  Size:
1MiB   By: myrkr_el

<http://savannah.gnu.org/bugs/download.php?file_id=54713>

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64167>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/