Bug 1983051
| Summary: | zipl-switch-to-blscfg dies with "entry already exists" when having more than one "rescue" entry | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Renaud Métrich <rmetrich> |
| Component: | s390utils | Assignee: | Dan Horák <dhorak> |
| Status: | CLOSED MIGRATED | QA Contact: | Vilém Maršík <vmarsik> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.4 | CC: | pstodulk, rvr, smitterl |
| Target Milestone: | rc | Keywords: | MigratedToJIRA, Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | s390x | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-09-02 14:34:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
There is no structure defined for the section names in the classic zipl.conf file. Thus the conversion script can't make any conclusions about machine-ids or such. I am going to open an upstream PR to document the limit of a single "rescue" entry into the man page and will close this as a NOTABUG for s390utils. The issue not only happens with Rescue entries but also duplicated entries, e.g. you have an entry to boot the kernel "normally" and another entry to boot with "debug options":
/etc/zipl.conf:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
[defaultboot]
defaultauto
prompt=1
timeout=5
default=RHEL-Upgrade-Initramfs
target=/boot
[RHEL-Upgrade-Initramfs]
image=/boot/vmlinuz-upgrade.s390x
parameters="root=/dev/mapper/rootvg-root crashkernel=auto cio_ignore=all,!condev rd.lvm.lv=rootvg/root rd.dasd=0.0.0100 LANG=en_US.UTF-8 enforcing=0 rd.plymouth=0 plymouth.enable=0"
ramdisk=/boot/initramfs-upgrade.s390x.img
[3.10.0-1160.36.2.el7.s390x]
image=/boot/vmlinuz-3.10.0-1160.36.2.el7.s390x
parameters="root=/dev/mapper/rootvg-root crashkernel=auto cio_ignore=all,!condev rd.lvm.lv=rootvg/root rd.dasd=0.0.0100 LANG=en_US.UTF-8"
ramdisk=/boot/initramfs-3.10.0-1160.36.2.el7.s390x.img
[3.10.0-1160.36.2.el7.s390x_with_debugging]
image=/boot/vmlinuz-3.10.0-1160.36.2.el7.s390x
parameters="root=/dev/mapper/rootvg-root crashkernel=auto cio_ignore=all,!condev rd.lvm.lv=rootvg/root rd.dasd=0.0.0100 LANG=en_US.UTF-8 systemd.log_level=debug systemd.log_target=kmsg"
ramdisk=/boot/initramfs-3.10.0-1160.36.2.el7.s390x.img
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Execute the conversion script:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
$ zipl-switch-to-blscfg --bls-directory=/tmp/bls
BLS file /tmp/bls/93f56661c34a47d4b5fd516d87aae9e0-3.10.0-1160.36.2.el7.s390x.conf already exists
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Increasing priority/severity to 2 because systems getting upgraded using Leapp end up restarting on RHEL7 kernel but RHEL8 root.
This bug is scheduled for migration to Jira. When that happens, this bugzilla issue will be permanently closed with the status MIGRATED and all future interaction on this issue will need to happen in the Jira issue. The new issue will be part of the RHEL project (a project for Jira only issues, which will sync once, then close the bugzilla issue and all future updates will happen in Jira), not part of the RHELPLAN project (which is part of the automated bugzilla->Jira mirroring and which allows ongoing updates to the bugzilla bug and syncs those updates over to Jira). For making sure you have access to Jira in order to continue accessing this issue, follow one of the appropriate knowledge base articles: KB0016394 - https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016394 KB0016694 - https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016694 KB0016774 - https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016774 For general issues with Jira, open a ticket with rh-issues Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. Additional information on creating a Jira account to access the migrated issue can be found here: https://access.redhat.com/articles/7032570 |
Description of problem: When having more than one "rescue" entry in the /etc/zipl.conf file, the utility dies after printing "BLS file /boot/loader/entries/<MACHINEID>-0-rescue.conf already exists". This is due to having the file name "<MACHINEID>-0-rescue.conf" hardcoded, as soon as one "rescue" entry exists. Typically the tool will die if a system has been cloned and there exists already another "rescue" entry for a different machine id. Version-Release number of selected component (if applicable): s390utils-base-2.15.1-5.el8.s390x How reproducible: Always Steps to Reproduce: 1. Create a /etc/zipl.conf from a RHEL7 which contains 2 rescue entries -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- [defaultboot] defaultauto prompt=1 timeout=5 default=Red_Hat_Enterprise_Linux_Server_7.9_Rescue_7fef08a17f6a400db03b693a0ef30ba0 target=/boot [Red_Hat_Enterprise_Linux_Server_7.9_Rescue_7fef08a17f6a400db03b693a0ef30ba0] image=/boot/vmlinuz-0-rescue-7fef08a17f6a400db03b693a0ef30ba0 parameters="root=/dev/mapper/rootvg-root vmalloc=4096G user_mode=home console=ttyS0 crashkernel=auto rd.lvm.lv=rootvg/root LANG=en_US.UTF-8 ipv6.disable=1 transparent_hugepage=never vmhalt=LOGOFF vmpoff=LOGOFF" ramdisk=/boot/initramfs-0-rescue-7fef08a17f6a400db03b693a0ef30ba0.img [3.10.0-1160.25.1.el7.s390x] image=/boot/vmlinuz-3.10.0-1160.25.1.el7.s390x parameters="root=/dev/mapper/rootvg-root vmalloc=4096G user_mode=home console=ttyS0 crashkernel=auto rd.lvm.lv=rootvg/root LANG=en_US.UTF-8 ipv6.disable=1 transparent_hugepage=never vmhalt=LOGOFF vmpoff=LOGOFF" ramdisk=/boot/initramfs-3.10.0-1160.25.1.el7.s390x.img [linux-0-rescue-fbf2f10617024e97989bccd4d299ec21] image=/boot/vmlinuz-0-rescue-fbf2f10617024e97989bccd4d299ec21 ramdisk=/boot/initramfs-0-rescue-fbf2f10617024e97989bccd4d299ec21.img parameters="root=/dev/mapper/rootvg-root vmalloc=4096G user_mode=home console=ttyS0 crashkernel=auto rd.lvm.lv=rootvg/root ipv6.disable=1 transparent_hugepage=never vmhalt=LOGOFF vmpoff=LOGOFF" -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Adjust machine id "7fef08a17f6a400db03b693a0ef30ba0" to the system's one ideally. 2. Execute zipl-switch-to-blscfg after deleting /boot/loader/entries directory # rm -fr /boot/loader/entries # zipl-switch-to-blscfg Actual results: BLS file /boot/loader/entries/7fef08a17f6a400db03b693a0ef30ba0-0-rescue.conf already exists Expected results: A Warning that the entry couldn't be created and machine-id differs somehow. Additional info: The code responsible to create the file is shown below: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 168 if [ -n "${zipl_to_bls[$key]}" ]; then 169 if [[ $key = "image" && $version_name == true ]]; then 170 if [[ $val = *"vmlinuz-"* ]]; then 171 version="${val##*/vmlinuz-}" 172 else 173 version="${val##*/}" 174 fi 175 echo "version $version" >> ${OUTPUT} 176 if [[ $version = *"rescue"* ]]; then 177 FILENAME=${BLS_DIR}/${MACHINE_ID}0-rescue.conf : -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- On line 177 we can see that FILENAME is dependent on machine id, but not actually machine id found in rescue entry extracted from kernel image, here above "/boot/vmlinuz-0-rescue-fbf2f10617024e97989bccd4d299ec21".