Bug 1070557
| Summary: | RHEL7 ISCSI boot fail | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | vincent_chen <vincent.y.chen> | ||||||||||
| Component: | NetworkManager | Assignee: | Rashid Khan <rkhan> | ||||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Desktop QE <desktop-qa-list> | ||||||||||
| Severity: | urgent | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 7.0 | CC: | agrover, dcbw, vincent.y.chen | ||||||||||
| Target Milestone: | rc | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2014-03-12 15:05:09 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
vincent_chen
2014-02-27 05:20:02 UTC
Created attachment 868330 [details]
RHEL7_ISCSI_Boot_GRUB_2
Created attachment 868331 [details]
RHEL7_ISCSI_Boot_stuck
Created attachment 868332 [details]
RHEL7_ISCSI_Boot_GRUB_1
*** Bug 1070556 has been marked as a duplicate of this bug. *** I see the boot hang at the point of starting network.service with the message "A start job is running for LSB: Bring up/down networking" Shortly after the iSCSI session reports a connection error, looking like the network interface has gone down. There are two workarounds that work for me 1) Break into an initrd shell with rd.break and add NM_CONTROLLED=no to the /run/initramfs/state/etc/sysconfig/network-scripts/ifcfg-* file before continuing. This has to be done at every boot. 2) Mask the network.service unit with systemctl mask network.service. This can be done after booting once with the NM_CONTROLLED=no workaround or from the initrd rd.break shell by remounting /sysroot rw, chroot into /sysroot, and then run systemctl mask network.service before exiting to continue booting. As this change lives on the filesystem, it only has to be done once. how to Break into an initrd shell with rd.break ? i add rd.break into kernel option, but it is still struck as before. i google the rd.break, seems it could add parameter to define break point
"rd.break={cmdline|pre-udev|pre-trigger|initqueue|pre-mount|mount|pre-pivot|cleanup}
"
should i define a break point?
Hi chris I can boot os with NM_CONTROLLED=no workaround. when i go into initrd shell. remount /sysroot rw and chroot /sysroot run well. but i can't mask network.service. it fail to connect service manager sh-4.2: systemctl Failed to get D-bus connection: No connection to service manager. when i boot into OS. i mask network.service with systemctl. the network connection lost. now i can't restore network with unmask. the error message is "Fail to issue method call: Access denied". please let me know how to make network service alive. Created attachment 873203 [details]
network service fail to unmask
If you see "disconnecting for new activation request" in /var/log/messages during startup, then this bug is likely to be a dupe of bug 1068621. Are you able to get /var/log/messages on the machine, and do you see the "disconnecting for new activation request" message? yes, williams. i see the message in syslog. localhost Networkmanager <info> (eno1): disconnecting for new activation request" is there any way to start network service? yes, williams. i see the message in syslog. localhost Networkmanager <info> (eno1): disconnecting for new activation request" is there any way to start network service? Hi Chris I create a new initrd image after i add "NM_CONTROLLED=no " into nic configuration file. it resolve this issue. We believe this issue is fixed by a new initscripts package from bug #1068621. NM_CONTROLLED=no is not required and is not a suggested workaround. You can install: http://people.redhat.com/dcbw/initscripts-9.49.15-1.el7.x86_64.rpm to test if this package update fixes the issue, but when you do so, please remove the NM_CONTROLLED=no. Let us know if this initscripts package fixes the issue. *** This bug has been marked as a duplicate of bug 1068621 *** i have installed fix package. it work well without NO_CONTROLLED workround. |