Bug 1299099

Summary: systemd, kexec: Boot failure if kdump device unavailable
Product: Red Hat Enterprise Linux 7 Reporter: George Beshers <gbeshers>
Component: kexec-toolsAssignee: kdump team <kdump-team-bugs>
Status: CLOSED WORKSFORME QA Contact: Qiao Zhao <qzhao>
Severity: medium Docs Contact:
Priority: high    
Version: 7.3CC: framsay, framsay, gbeshers, gbeshers, gcase, jkachuck, lilu, randerso, rja, ruyang, tee
Target Milestone: rcKeywords: OtherQA
Target Release: 7.4   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-09-29 16:27:13 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:
Bug Depends On:    
Bug Blocks: 1366034    

Description George Beshers 2016-01-15 23:08:15 UTC
Description of problem:

    We have observed that when kdump is pointed at non-root disk drive
    and later that drive is removed the kernel won't complete booting.
    [Non-root because it was on a 32TB machine and there wasn't enough
     space on the root drive.)


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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Dave Young 2016-01-19 06:51:06 UTC
George:

System does not boot means the normal kernel can not boot?

Have you add it to /etc/fstab or somewhere else? I guess systemd is waiting for the mount happens and timeout, is this your case and do you have a console log?

Thanks
Dave

Comment 3 George Beshers 2016-01-27 19:27:35 UTC
Sorry to say that the log got deleted in a cleanup sweep.
I will work on reproducing this and provide a log.

However, the kernel booted and was doing systemd-udevd stuff
and my memory is that it was hung trying to start kdump.
That said, I've seen kdump fail to start many times without
causing the boot to hang (we get to login); so I am begining
to suspect myself of user error.

Comment 4 Russ Anderson 2016-09-22 19:22:51 UTC
Update fields so properly tracked.

Comment 5 Russ Anderson 2016-09-22 19:24:46 UTC
Not a showstopper for 7.3.
Needs additional information from George.

Comment 6 George Beshers 2016-09-29 16:27:13 UTC
Tested this with snap3 and its no longer an issue.