Bug 1346231

Summary: unbootable after removing swap partition
Product: Red Hat Enterprise Linux 7 Reporter: Martin Steigerwald <martin.steigerwald>
Component: dracutAssignee: Lukáš Nykrýn <lnykryn>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: dracut-maint-list
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-12-15 07:42:10 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:
Attachments:
Description Flags
screenshot of boot failure when removing swap from /etc/fstab, regenerating initrd and booting
none
rdsosreport for booting without swap none

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.