Bug 1009023 - PKG: on upgrade, systemd should drop the devpts entry from /etc/fstab, or patch mode= into it
PKG: on upgrade, systemd should drop the devpts entry from /etc/fstab, or pat...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
i686 Linux
unspecified Severity high
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-17 10:05 EDT by Nuno Lopes
Modified: 2015-02-18 16:42 EST (History)
21 users (show)

See Also:
Fixed In Version: systemd-219-3.fc22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-18 16:42:30 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nuno Lopes 2013-09-17 10:05:07 EDT
I have Fedora 19 plus all available updates as of today, and Konsole doesn't work.

The konsole in dolphin says only:
"Warning: Program '/bin/bash' crashed."

If I run Konsole directly from the menu, I get the Konsole window, without the prompt.

IIRC, Konsole worked when I did the upgrade to FC19.  It was some recent update that broke it.
Comment 1 Kevin Kofler 2013-09-17 19:44:11 EDT
I don't think it's Konsole's fault that bash is crashing.
Comment 2 Nuno Lopes 2013-09-18 03:28:12 EDT
On xterm, bash works just fine, though.
Comment 3 Nuno Lopes 2013-09-20 07:10:17 EDT
BTW, I get the following messages if I open konsole from xterm:

"
konsole(16236)/kdecore (KPty/K3Process) KPty::open: Can't open a pseudo teletype 
konsole(16236) Konsole::Pty::flowControlEnabled: Unable to get flow control status, terminal not connected. 
"
Comment 4 Nuno Lopes 2013-09-23 03:49:22 EDT
I fixed the problem.

I had these lines in my /etc/fstab:
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  defaults        0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

I removed all these lines and now konsole/bash works fine.  I assume the upgrade process should have removed these lines automatically, though.
Comment 5 Ole H 2013-11-13 15:23:56 EST
That might fix it, but it's not the right way to do it.

You need to change the devpts line to something like this:

devpts                          /dev/pts        devpts  gid=5,mode=620  0 0

Where gid=5 is the group id of the tty group entry. Check it on your system with:

grep tty /etc/group
Comment 6 Kevin Kofler 2013-11-14 15:06:46 EST
In any case, it looks like a configuration issue on the user's end, closing.
Comment 7 Nuno Lopes 2013-11-15 10:31:10 EST
No, it's not just a configuration issue.
The file was created by an old version of Fedora and I didn't change it.  Then, I upgraded to Fedora 19 and Konsole stopped working.  The upgrade process should update the file automatically or warn the user about it.
Comment 8 Kevin Kofler 2013-11-15 13:09:15 EST
/etc/fstab belongs to the "setup" package.
Comment 9 Ondrej Vasik 2013-11-17 16:28:42 EST
Although /etc/fstab is owned by setup package, this package doesn't touch it at all (ghosted ownership). TBH, I don't know, why setup package owns that file, I assume historical reasons. Anaconda creates this file, and if something was broken between the releases, probably fedup or some "upgrade guide" is the right place to handle it. Original anaconda bug was fixed by https://bugzilla.redhat.com/show_bug.cgi?id=506219 , so reassigning to fedup - feel free to close it if you don't think this is reasonable to fix (the old fstab must be more than 4 years old or created by something else than anaconda (or anaconda regressed meanwhile)).
Comment 10 Will Woods 2013-11-18 14:34:49 EST
This isn't how fedup works. If setup owns /etc/fstab, it's setup's job to make sure /etc/fstab is handled correctly on upgrades.

This is something that could be fixed in a %post script, e.g.:

# upgrade: remove old devpts line from /etc/fstab
if [ $1 -gt 1 ] && grep -q '\sdevpts\s\+defaults' /etc/fstab; then
    cp -f /etc/fstab /etc/fstab.rpmsave
    sed -i '/[^#].*\sdevpts\s\+defaults/d' /etc/fstab
fi
Comment 11 Ondrej Vasik 2013-11-19 07:10:21 EST
Will, setup can't use sed, can't use cp and other stuff due to dependency loop. Only thing I can use is lua scriptlet - and this is tricky anyway. 
Setup actually as far as I remember never touched /etc/fstab - it was always anaconda job - and the only reason why it is owned by setup and to have this file owned by something - as anaconda is not installed on the system after the installation.

It would be good to find out what's the package responsible for the wrong /etc/fstab creation. If it was user's modification - it is notabug. If it was anaconda, it is anaconda regression of #506219. 

It really has to be fedup, anaconda or WONTFIX - as it is not something I should handle in setup package. Setting needinfo to reporter - to see if he can find out what package recently modified his fstab entry. If you don't know, please close this bugzilla (insufficient data probably), it was probably some rare update issue (as otherwise it would generate much more reports if caused something general).
Comment 12 Will Woods 2013-11-19 11:41:24 EST
Ondrej: I see your point about the %pre/%post scripts. So "setup" wouldn't be the right place to fix this during system upgrades.

As for anaconda: In F15 and earlier, anaconda put devpts in fstab, but AFAICT it has *always* had "gid=5,mode=620" (except for bug #506219).

In F16 and later, systemd is responsible for mounting devpts, so anaconda doesn't put it in fstab - see bug 693926.

Since systemd is responsible for mounting devpts, it makes sense that it would also be responsible for checking for bad devpts entries in /etc/fstab during a system upgrade.

Anyway, the question remains: where did the bad fstab entry come from? Was it left over (or copied) from an old (F15 or earlier) system, or did some other package add it?
Comment 13 Nuno Lopes 2013-11-19 13:59:54 EST
This computer was originally installed with FC10 or FC11 and then upgraded successively to every release.
Comment 14 Will Woods 2013-11-20 13:47:16 EST
There you have it - it's almost certainly a side-effect of bug 506219 that never caused any problems until now. That's actually kind of amazing!

So if this is to be fixed, systemd (or something) should probably check for unnecessary/harmful entries in /etc/fstab and remove them during the upgrade.
Comment 15 Fedora End Of Life 2015-01-09 14:52:19 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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 19 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 16 Zbigniew Jędrzejewski-Szmek 2015-01-27 16:58:45 EST
OK, it's probably too late for people who hit this bug, but I added a cleanup sed invocation in systemd %post which removes /dev/pts, /dev/shm, /sys/proc entries which have just 'defaults' in options.

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