RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1346231 - unbootable after removing swap partition
Summary: unbootable after removing swap partition
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dracut
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-14 10:28 UTC by Martin Steigerwald
Modified: 2020-12-15 07:42 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-15 07:42:10 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
screenshot of boot failure when removing swap from /etc/fstab, regenerating initrd and booting (67.21 KB, image/png)
2016-06-14 10:28 UTC, Martin Steigerwald 		no flags Details
rdsosreport for booting without swap (73.42 KB, text/plain)
2016-06-14 10:54 UTC, Martin Steigerwald 		no flags Details
View All

Description Martin Steigerwald 2016-06-14 10:28:08 UTC 
Created attachment 1167823 [details]
screenshot of boot failure when removing swap from /etc/fstab, regenerating initrd and booting

Reporting here, cause I think this issue will be there with RHEL 7 as well.

Description of problem:
On CentOS installation Anaconda insisted on created a swap volume, even tough I had 512 MiB RAM in the VM.


Version-Release number of selected component (if applicable):
7.2


How reproducible:
Always


Steps to Reproduce:
1. Install with LVM and logical volume for swap
2. Remove swap line from /etc/fstab
3. Remove logical volume for swap
4. Optional rebuild initrd with dracut --force (doesn´t make a difference regarding the result)
5. Reboot.



Actual results:

Booting breaks. Dracut drops to an almost unusable shell, without clearly explaining why it thinks it cannot boot.


Expected results:

System boots – a robust boot process. If swap is not there, it is nothing critical.

Well, unless there would be a resume memory image stored on swap, but hey I have just removed it from fstab I know what I am doing.



Additional info:

I was able to get system booting again by

1) removing rd.lvm.lv=sys0/swap from /etc/default/grub

2) grub2-mkconfig > /boot/grub2/grub.cfg

3) dracut --force (might have been unnecessary)



Related bug report:
Bug 991692 - Fedora become unbootable after swap partition reformat 


Other bug reports related to fragile boot process:
- Bug 1213781 - does not start ssh service if a filesystem in /etc/fstab cannot be mounted 
- Bug 1213778 - drops into emergency mode without any error message if it cannot find a filesystem in /etc/fstab 

I didn´t think you could make booting even more fragile, but obviously you could.


Again my reasoning is: Booting, bringing up the system is valuable. Don´t break it needlessly.

(Of course you are free to do what you want, but I do not have to endorse it when speaking about distros in my trainings. Again luckily this is just a training VM, so no critical and costly downtime involved.)
Comment 1 Martin Steigerwald 2016-06-14 10:54:14 UTC 
Created attachment 1167831 [details]
rdsosreport for booting without swap

One additional note:

To have the system booting again I just recreated the swap volume and did a swap on it, and correctly the booted system did not have swap mounted, cause I removed it from /etc/fstab already.

So it could not be used for hibernation anyway anymore.

But yet, for the hibernation case:

I think a system may *never* *ever* boot an outdated hibernation image, as it can create severe data loss (been there, recovered from it via xfs_repair years ago). It may be a challenge to make sure of that, but I think storing a hibernation id both in the hibernation image and in /boot/something would enable to initrd to check whether the hibernation image is still valid. On any boot, be it a boot with resuming or a successful resume remove hibernation id from /boot/something again. And if the hibernation id in /boot/something is not there or does not match the hibernation id in the image, then do *not* resume.

So in case of a accidentally non working swap, it may not resume, but the that is not more severe than a sudden power loss.
Comment 2 Martin Steigerwald 2016-06-14 10:55:23 UTC 
"a boot without resuming or a successful resume" of course
Comment 7 RHEL Program Management 2020-12-15 07:42:10 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Note You need to log in before you can comment on or make changes to this bug.