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.hilbr...@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/