I get the same result whether it’s from the Gnome terminal or a tty.
I’ve exercised my Google fu but after a few hours, I can’t crack it.
Some 2+ yr old threads suggest that the problem may be related to ruby, or some yast binding files. yast2-ycp-ui-bindings ??
Using the yast GUI I downgraded a couple of these which I found when searching for yast, but it hasn’t appeared to help.
If you want to launch the graphical YaST, then from an elevated console (su, su -, or you can prepend “sudo”)
yast2
And, if you want to launch ncurses (text) YaST, then
yast
In other words, remove that “2” from yast…
And, of course if you’re in a non-graphical environment, you can’t launch graphical YaST (yast2) which looks to be tje cause of your errors…
I’m running it correctly…
From within Gnome terminal yast2 launches the YaST GUI perfectly, but yast gives the output in the OP.
I’m familiar with using yast (ncurses) for years, but this is the first time I’ve seen this issue.
the Gnome terminal now shows no input if I type, the characters are invisible, but pressing does respond correctly to ls for instance. A tty gives the same result. I regularly work in the terminal, and all other aspects of my PC appear to work perfectly fine.
Pls post output when you invoke yast and include a description what console environment it’s run, Your posts only describe invoking yast2 which won’t work for instance in an init3 tty.
You may have just missed my previous post by a couple of minutes. But this time I have tested as suggested and dropped to runlevel 3 and I still get the same results. As they say, a picture is worth a thousand words. Here is the outcome…
The terminal session is now messed up, with the command prompt drifting across as if the EOL char doesn’t function.
Output after typing additional commands (marked in red). The actual commands don’t appear on the screen anymore, just the output. The only way I can recover is to exit the root session back to my user login. https://drive.google.com/file/d/18JAYN8QWVNby0Vj7pPP2PEuoFv2MNubF/view?usp=sharing
I get the same result whether it’s from the Gnome terminal or a tty.
I’ve exercised my Google fu but after a few hours, I can’t crack it.
Some 2+ yr old threads suggest that the problem may be related to ruby,
or some yast binding files. yast2-ycp-ui-bindings ??
Using the yast GUI I downgraded a couple of these which I found when
searching for yast, but it hasn’t appeared to help.
Any suggestions of how to sort this out?
Can the core dump file help?
Hi
So the system is all up to date?
Also check there are no missing patches;
zypper -f ref
zypper up -t patch
zypper se -i libyui
S | Name |
Summary | Type
--+---------------------+-----------------------------------------------------------+--------
i | libyui-ncurses-pkg7 | Libyui - yast2 package selector widget for the ncurses UI | package
i | libyui-ncurses7 | Libyui - Character Based User Interface | package
i | libyui7 | Libyui - GUI-abstraction library | package
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-25.28-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
An up to date libyui may be important.
Also, note that you cannot specify $DISPLAY for a non-graphical environment, the following is the Project page lfor libyui
Am also curious whether your problem happens for YaST modules, and not only YaST,
Try this…
Don’t run in runlevel 3, run the following in 2 windowed consoles…
Console 1
Read your system log in real time
journalctl -f
Console 2
With Console 1 open and running,
Run the following which opens the Network Settings YaST module in ncurses mode
yast lan
If the Network Settings module opens without error, that’s telling…
If an error is thrown, hopefully it will throw and error displayed in the system log (Console 1)
Hopefully. you’ll see something meaningful.
Post the results if you’re not sure what you’re seeing.
[FONT=arial]
Just prior to obtaining the above repo list I disabled some repos that I thought could be part of the issue. Maybe for this exercise I should have left then as they were…
[/FONT]
The -si switch got me reading, and I thought it might be a way to fix the issue so I ran this:
s1:~ # zypper si libyui
Reading installed packages...
Loading repository data...
Resolving package dependencies...
The following 5 NEW packages are going to be installed:
cmake gcc-c++ gcc48-c++ make site-config
The following source package is going to be installed:
libyui
5 new packages to install, 1 source package.
Overall download size: 10.4 MiB. Already cached: 0 B. After the operation, additional 38.1 MiB will be used.
Continue? [y/n/...? shows all options] (y):
l
I proceeded with the above and all completed OK, but the issue persists.
Source packages can be copied from the installation medium to the hard disk and unpacked with YaST. They are not, however, marked as installed () in the package manager. This is because the source packages are not entered in the RPM database. Only installed operating system software is listed in the RPM database. When you install a source package, only the source code is added to the system
](SUSE Documentation)
This is a side question: If “only the source code is added to the system” what is the point of using si?
Mar 10 14:16:56 s1 dbus[1423]: [system] Activating service name='org.opensuse.Snapper' (using servicehelper)
Mar 10 14:16:56 s1 dbus[1423]: [system] Successfully activated service 'org.opensuse.Snapper'
Mar 10 14:17:29 s1 systemd-coredump[4048]: Process 3984 (y2start) of user 0 dumped core.
Nothing to write home about here… snapper is expected.
PS:
zypper si NAME means to install the source package of NAME (NAME.src.rpm), not the packege NAME.rpm. With the src.rpm you can change the sources and build a new package NAME. But you do not need it.
zypper se -si NAME or zypper se -s -i NAME means zypper search (se) for all installed (-i) packages which are named NAME and than show more details (-s).
But this time I have tested as suggested and dropped to runlevel 3 and I still get the same results. As they say, a picture is worth a thousand words. Here is the outcome…