Description of problem: After creating a VM with rawhide iso Fedora-Server-dvd-ppc64le-Rawhide-20180218.n.0.iso, I got curious behaviour on pty (bad char encoding) when I do some commands. let's see a sample: I do a simple command like this one below several time [root@vm55 ~]# ls | grep sample [root@vm55 ~]# some time the command is not working correctly [root@vm55 ~]# ls | grep sample -bash: grep: command not found if a do a copy paste of each command behind in a file and look at it in hexa, I got the following: [root@vm55 ~]# echo 'ls | grep sample' > sample.ko [root@vm55 ~]# echo 'ls | grep sample' > sample.ok [root@vm55 ~]# hexdump -C sample.ok 00000000 6c 73 20 7c 20 67 72 65 70 20 73 61 6d 70 6c 65 |ls | grep sample| 00000010 0a |.| 00000011 [root@vm55 ~]# hexdump -C sample.ko 00000000 6c 73 20 7c c2 a0 67 72 65 70 20 73 61 6d 70 6c |ls |..grep sampl| 00000010 65 0a |e.| 00000012 The command having the problem have a bad blank coding char just after the pipe ok: blank is 20 ko: blank is c2 a0 (note that we can still the 2 and 0 but on different bytes) This is always reproductible. I tried it with different english languages (gb, us ...) installations with different qemu versions. [root@vm55 ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: us X11 Layout: us [root@vm55 ~]# uname -r 4.16.0-0.rc1.git4.1.fc28.ppc64le
Guy, do you see this behaviour in a ssh session or in the graphical console in eg. PowerKVM/Kimchi or RHEV?
Problem is on ssh and screen sessions of a VM qemu machine (as for openqa). We did not see the problem on PowerKVM so far (even thru ssh). I run this kind of command to create the VM machine. /usr/bin/qemu-system-ppc64 -name f28_55 -enable-kvm -M pseries -smp 4 -m 8G -nographic -nodefaults -monitor stdio -serial pty -device virtio-net-pci,netdev=net10095,mac=c0:ff:ee:00:00:01 -netdev bridge,br=br0,id=net10095 -cdrom isole -drive file=hd1.qcow2 -drive file=hd2.qcow2 -S then, ssh on the IP address or a screen command on the char device redirected by qemu (ex: screen /dev/pts/1) and the problem appears after running several time the same command.
This problem is no more present on last f28 and rawhide isos I checked on Fedora-Server-dvd-ppc64le-28-20180312.n.0.iso and Fedora-Server-dvd-ppc64le-Rawhide-20180312.n.0.iso openqa is working again without char problem too.