Bug 1889674 - vi is the editor used when reporting anaconda bugs from text mode, instead of nano
Summary: vi is the editor used when reporting anaconda bugs from text mode, instead of...
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 36
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: F33FinalFreezeException 1854444
TreeView+ depends on / blocked
Reported: 2020-10-20 11:10 UTC by Kamil Páral
Modified: 2022-02-08 21:31 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)

Description Kamil Páral 2020-10-20 11:10:55 UTC
Description of problem:
Nano should be the default editor in the whole Fedora 33:

However, when reporting an anaconda crash from the text mode, "vi" is started instead. Here's a reproducer:

I verified that nano is present on the image, and it's even set as $EDITOR:

> [anaconda root@fedora /]# echo $EDITOR
> /usr/bin/nano

It seems that anaconda (or libreport) invoke "vi" directly, instead of using the default editor. 

Version-Release number of selected component (if applicable):
anaconda 33.25.4-1.fc33

Comment 1 Kamil Páral 2020-10-20 11:11:45 UTC
Probably not a blocker, but proposing as a freeze exception.

Comment 2 Vladimír Slávik 2020-10-20 12:26:54 UTC
I think libreport should just work as-is? See: https://github.com/abrt/libreport/blob/84ed0489731418c8cadc51321f294ea68661d585/src/cli/cli-report.c#L305

That probably means the variable is not what you think when/where anaconda actually runs. FWIW normally (not on Live) we have a systemd unit that starts anaconda in tmux. No idea if you expect EDITOR to be set there? (I do not, but that's just a guess.)

Anyway, if that's it, the fix involves setting EDITOR here: https://github.com/rhinstaller/anaconda/blob/master/data/systemd/anaconda.service#L8 ...and in some other files in that directory probably too. Alternatively, there is one more opportunity here: https://github.com/rhinstaller/anaconda/blob/master/anaconda.py#L198 But I think that's not the right place for that, rather for a fallback if EDITOR is not set.

(Unfortunately everything is stuck on metacity right now, or I'd try that immediately.)

Comment 3 Vladimír Slávik 2020-10-20 12:27:49 UTC
Oops, sorry, assigning back to us, that was a mistake.

Comment 4 Chris Murphy 2020-10-20 14:32:44 UTC
Possibly similar to bug 1889576.

Anaconda runs as root. I'm not sure whether it runs literally under root user or via sudo; but it's likely that environment doesn't have nano set as the default editor and that's why. I agree it's probably not a feature blocker, but it's not good UX and should be considered a bug to be fixed. If anaconda runs with sudo then maybe it's possible for a drop-in file to sudoers, as I mention in 1889576.

Comment 5 Chris Murphy 2020-10-20 22:18:19 UTC
13:03:36  adamw | cmurf: on live images the launcher runs a smallish wrapper called liveinst which sets up some environment stuff then runs anaconda as root, iirc                                                                    
13:05:01  adamw | oh, right, liveinst is wrapped in consolehelper, that's how it gets to be root
13:05:24  adamw | of course this is all super old and hasn't been touched in forever

Comment 6 Adam Williamson 2020-10-20 23:19:01 UTC
Kamil was testing an installer image, though, so that's not relevant. On installer images there is no (interactive) user but root, I don't think, everything runs as root.

Comment 7 Kamil Páral 2020-10-21 07:56:57 UTC
# pgrep -a anaconda
1712 /usr/bin/python3 /sbin/anaconda

# cat /proc/1712/environ | tr '\0' '\n' | sort

No EDITOR, no VISUAL. Yes, the actual anaconda environment doesn't have nano configured.

Please note I'm talking here about the DVD environment here, not Live. I don't think it makes sense to run anaconda in text mode on Live (not even sure if that's possible, but even if it was).

Comment 8 Adam Williamson 2020-10-21 21:40:22 UTC
I think /etc/profile.d probably isn't read in the installer env. lorax runtime-postinstall.tmpl does this:

install ${configdir}/profile root/.profile

that file is I think lorax share/templates.d/99-generic/config_files/common/profile , which just has this:

PS1="[anaconda \u@\h \W]\\$ "
export PATH PS1

in an installed system, the chain by which profile.d stuff is used for a typical user shell is that ~/.bashrc sources /etc/bashrc , which sources everything in /etc/profile.d . But that profile used in the installer environment doesn't source /etc/bashrc , or source /etc/profile.d contents itself.

Comment 9 Adam Williamson 2020-10-21 21:41:33 UTC
+3 votes for FE in https://pagure.io/fedora-qa/blocker-review/issue/186 , accepting. This isn't that critical, but it *is* in the installer environment and can't be fixed with a post-release update.

Comment 10 Chris Murphy 2020-10-21 21:57:11 UTC
Sorry about my suboptimal reading comprehension :P

Maybe because it runs from within tmux?

man tmux:
     When tmux is started, it inspects the following environment variables:

     EDITOR    If the command specified in this variable contains the string ‘vi’ and VISUAL is unset, use vi-style key bindings.  Overridden by the mode-keys and
               status-keys options.

ps aux shows this which might be related...

/usr/bin/tmux -u -f /usr/share/anaconda/tmux.conf start

That conf file has a comment at the top:
# tmux.conf for the anaconda environment

And it isn't explicitly setting $EDITOR

Comment 11 Adam Williamson 2020-10-21 22:22:56 UTC
I think the explanation is just what I wrote in comment #8. We're not sourcing the thing nano-default-editor installs.

Comment 12 Ben Cotton 2021-11-04 17:27:49 UTC
This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 13 Vladimír Slávik 2021-11-08 14:07:52 UTC
Still valid.

Comment 14 Ben Cotton 2022-02-08 21:31:12 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

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