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.
I don't think it's Konsole's fault that bash is crashing.
On xterm, bash works just fine, though.
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. "
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.
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
In any case, it looks like a configuration issue on the user's end, closing.
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.
/etc/fstab belongs to the "setup" package.
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)).
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
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).
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?
This computer was originally installed with FC10 or FC11 and then upgraded successively to every release.
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.
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.
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.