Bug 1380512 - devmode fails to start successfully after deploying 7.2.7 from 7.3
Summary: devmode fails to start successfully after deploying 7.2.7 from 7.3
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: atomic-devmode
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jonathan Lebon
QA Contact: Micah Abbott
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-29 19:34 UTC by Micah Abbott
Modified: 2019-03-06 02:45 UTC (History)
0 users

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-29 21:14:24 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.