Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1380512

Summary: devmode fails to start successfully after deploying 7.2.7 from 7.3
Product: Red Hat Enterprise Linux 7 Reporter: Micah Abbott <miabbott>
Component: atomic-devmodeAssignee: Jonathan Lebon <jlebon>
Status: CLOSED CANTFIX QA Contact: Micah Abbott <miabbott>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.3Keywords: Extras
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: 2016-09-29 21:14:24 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:

Description Micah Abbott 2016-09-29 19:34:25 UTC
Using atomic-devmode-0.3.5-1.el7.noarch in the RHELAH 7.3 Snap5 compose:

After using 'rpm-ostree deploy 7.2.7' and rebooting into devmode, the devmode experience fails to start properly.

The root user is logged in on the console, but there is no tmux session started or cockpit container started.

Comment 2 Jonathan Lebon 2016-09-29 21:10:24 UTC
Right, this is because 7.3 includes:

https://code.engineering.redhat.com/gerrit/gitweb?p=spin-kickstarts.git;a=commitdiff;h=c8e803e3f7c3c464a78fc5c451c6c4c5bdec256d

Which means that there is now a .bash_profile in /root. The way atomic-devmode started up before that was to have a .bash_login which automatically executed on login. However, in 7.3, .bash_profile has priority over .bash_login, so atomic-devmode had to be adapted:

https://github.com/projectatomic/atomic-devmode/commit/8abf921f5a18eebc812885809ed12a39c58b7d6f

But obviously, that fix is not in the old 7.2.7 tree.

I don't think there's much we can do about this. A workaround would be `rm /root/.bash_profile && reboot` (with the caveat it carries). But in the big picture, devmode is just supposed to help you try out the cloud image easily without setting anything else up. If you want to keep re-using the same VM, you're better off just going the whole way and writing a cloud-config.

Or is there a valid use case I'm not considering here? What do you think?

Comment 3 Micah Abbott 2016-09-29 21:14:24 UTC
This is a perfectly reasonable explanation.  I just wanted to make sure I wasn't missing anything.

I agree with your statement about devmode being a way to try things out, so we shouldn't be investing too much effort in handling these scenarios.

I'll close this as CANTFIX.