[opensuse] Failed login prompts on VTs
The last kernel update seems to have killed of the ability to login at the virtual terminals (that is, all the switches to terminals using Ctl-Alt-Fn no longer produce login prompts). The graphical login still works. Systemd-logind is running but hasn't spawned any login prompts for the tty[1-6] This is Linux Mainbox 4.4.0-2.g368c53d-default #1 SMP PREEMPT Tue Jan 12 13:39:53 UTC 2016 (368c53d) x86_64 x86_64 x86_64 GNU/Linux on a 13.1 machine Systemd is Version: 208-35.1 The contents of /etc/syste/d/logind.conf are all default (that is everything is commented out). This is the one thing that makes me wonder. Normally commented out values in config files mean "use the compiled in default". (As documented in http://www.freedesktop.org/software/systemd/man/logind.conf.html.) Has that changed? I'm aware of 'loginctl' but its use seems obscure. The man page is of no help. I suspect a "loginctl attach seat device" would be useful but I'm far from certain how to specify a new 'seat'. I'm not even sure this is relevant since all I read about it seems to concern a second graphical 'seat'. Yes I have a /etc/systemd/system/getty.target.wants/getty@tty1.service Should there be more? I thought all the getty stuff for the virtual terminals was automatically generated by some process that generates the units, somewhere, somehow. So where have they gone? I find not clues that mean anything to me in the logs. Any suggestions are welcome. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward composed on 2016-01-16 09:47 (UTC-0500):
Any suggestions are welcome.
http://download.opensuse.org/repositories/Base:/System:/Legacy/openSUSE_13.1... has systemd-210. Among other things if fixes broken emergency shell, which is why I have it on all my 13.1 installations. 13.2 and 42.1 use 210 too, so it ought not to be a bad choice, and might even solve your problem. Another option might be to try this script (or a variation therof) I use on most of my Linux with systemd installations: #!/bin/sh cd /etc/systemd/system/getty.target.wants cp -a ../../../../usr/lib/systemd/system/getty@.service ../../../../usr/lib/systemd/system/getty@tty1.service sed -i 's/TTYVTDisallocate=yes/TTYVTDisallocate=no/' ../../../../usr/lib/systemd/system/getty@tty1.service ln -sf ../../../../usr/lib/systemd/system/getty@tty1.service ./getty@tty1.service systemctl start getty@tty1.service ln -sf ../../../../usr/lib/systemd/system/getty@.service ./getty@tty2.service systemctl start getty@tty2.service ln -sf ../../../../usr/lib/systemd/system/getty@.service ./getty@tty3.service systemctl start getty@tty3.service ln -sf ../../../../usr/lib/systemd/system/getty@.service ./getty@tty4.service systemctl start getty@tty4.service ln -sf ../../../../usr/lib/systemd/system/getty@.service ./getty@tty5.service systemctl start getty@tty5.service ln -sf ../../../../usr/lib/systemd/system/getty@.service ./getty@tty6.service systemctl start getty@tty6.service -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/16/2016 10:38 PM, Felix Miata wrote:
Another option might be to try this script (or a variation therof) I use on most of my Linux with systemd installations:
This set of 'units' is supposed to be carried out automatically by a generator. Update; I tried logging in 'blind'. After that I tried the classic 'echo "hello world" but redirected it to /tmp/hello.txt. Then I returned to the graphic login/KDE and found that file in /tmp with the konq file manager. So this is not a problem solved by creating those links, starting login processes. It seems that they are created pretty much on demand. Its a problem with the display. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward composed on 2016-01-16 09:47 (UTC-0500):
The last kernel update seems to have killed of the ability to login at the virtual terminals (that is, all the switches to terminals using Ctl-Alt-Fn no longer produce login prompts). The graphical login still works.
Solution found yet? In previous reply I forgot to include suggestion to disable/remove Plymouth if you haven't already. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 18/01/2016 07:41, Felix Miata a écrit :
Anton Aylward composed on 2016-01-16 09:47 (UTC-0500):
The last kernel update seems to have killed of the ability to login at the virtual terminals (that is, all the switches to terminals using Ctl-Alt-Fn no longer produce login prompts). The graphical login still works.
Solution found yet? In previous reply I forgot to include suggestion to disable/remove Plymouth if you haven't already.
did you reboot in the mean time? after an update some apps are often broken before reboot jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/18/2016 03:03 AM, jdd wrote:
Le 18/01/2016 07:41, Felix Miata a écrit :
Anton Aylward composed on 2016-01-16 09:47 (UTC-0500):
The last kernel update seems to have killed of the ability to login at the virtual terminals (that is, all the switches to terminals using Ctl-Alt-Fn no longer produce login prompts). The graphical login still works.
Solution found yet? In previous reply I forgot to include suggestion to disable/remove Plymouth if you haven't already.
did you reboot in the mean time? after an update some apps are often broken before reboot
I tried rebooting. Actually this persisted not only past a reboot but yet another kernel update and two more reboots. Then, for no apparent reason, it cleared up - ALMOST. Now my fonts on the CLT-ALT-Fn logins are very small and the last few lines that scroll to the bottom don't display. That is the screen buffer is larger than the display .. have i got that right. This is a different front from not only before the whole problem arose but a different font from the logs that were were on all the non-X11 Ctl-Alt-Fn screens when I first reported this problem. Oh, and when I boot now and login to the GUI, the screen display is shifted to the left and I have to reset it with lxrandr. This is plain screwy. Other than new kernel and regular updates I've done nothing that could account for these changes. ----------------- No, wait, I lie! On this boot all the Ctl-Alt-Fns produce a blank screen. Never the less, I have # ps -ef | grep tty root 1843 1 0 Jan17 tty1 00:00:00 /sbin/agetty --noclear tty1 root 1882 1864 0 Jan17 tty7 00:01:55 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -seat seat0 -auth /var/lib/kdm/AuthFiles/A:0-QBzTmb root 4987 1 0 03:52 tty2 00:00:00 /sbin/agetty --noclear tty2 root 4988 1 0 03:52 tty3 00:00:00 /sbin/agetty --noclear tty3 root 4989 1 0 03:52 tty4 00:00:00 /sbin/agetty --noclear tty4 root 4990 1 0 03:52 tty5 00:00:00 /sbin/agetty --noclear tty5 root 4991 1 0 03:52 tty6 00:00:00 /sbin/agetty --noclear tty6 root 5109 5044 0 03:54 pts/6 00:00:00 grep --color=auto tty However, once again the blind login and echo produces something. So its a display problem, but obviously not with the display card and not one that affect the use of the X11/KDE. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Jan 18, 2016 at 11:58 AM, Anton Aylward <opensuse@antonaylward.com> wrote: ...
I tried rebooting. Actually this persisted not only past a reboot but yet another kernel update and two more reboots.
Then, for no apparent reason, it cleared up - ALMOST.
Now my fonts on the CLT-ALT-Fn logins are very small and the last few lines that scroll to the bottom don't display.
What video card you have? It sounds like in the past your video card was not recognized by in-kernel driver(s) and now it is. By default KMS will attempt maximum resolution which matches your description of "tiny fonts". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/18/2016 04:23 AM, Andrei Borzenkov wrote:
On Mon, Jan 18, 2016 at 11:58 AM, Anton Aylward <opensuse@antonaylward.com> wrote: ...
I tried rebooting. Actually this persisted not only past a reboot but yet another kernel update and two more reboots.
Then, for no apparent reason, it cleared up - ALMOST.
Now my fonts on the CLT-ALT-Fn logins are very small and the last few lines that scroll to the bottom don't display.
What video card you have? It sounds like in the past your video card was not recognized by in-kernel driver(s) and now it is. By default KMS will attempt maximum resolution which matches your description of "tiny fonts".
I think you have that the other way round. It worked before. Now it is behaving inconsistently. ==> INCONSISTENTLY <=== Anyway, lspci reports 00:02.1 Display controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Jan 18, 2016 at 12:30 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 01/18/2016 04:23 AM, Andrei Borzenkov wrote:
On Mon, Jan 18, 2016 at 11:58 AM, Anton Aylward <opensuse@antonaylward.com> wrote: ...
I tried rebooting. Actually this persisted not only past a reboot but yet another kernel update and two more reboots.
Then, for no apparent reason, it cleared up - ALMOST.
Now my fonts on the CLT-ALT-Fn logins are very small and the last few lines that scroll to the bottom don't display.
What video card you have? It sounds like in the past your video card was not recognized by in-kernel driver(s) and now it is. By default KMS will attempt maximum resolution which matches your description of "tiny fonts".
I think you have that the other way round. It worked before.
Now it is behaving inconsistently. ==> INCONSISTENTLY <===
Anyway, lspci reports
00:02.1 Display controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)
please show lspci -nnkv -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov composed on 2016-01-18 12:33 (UTC+0300):
Anton Aylward wrote:
00:02.1 Display controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)
please show
lspci -nnkv
vttys working normally here: # fbset mode "1440x900" geometry 1440 900 1440 900 16... # grep PRETTY /etc/os-release /etc/os-release:PRETTY_NAME="openSUSE 13.1 (Bottle) (x86_64)" # uname -a Linux hpg33 4.4.0-2.g368c53d-default #1 SMP PREEMPT Tue Jan 12 13:39:53 UTC 2016 (368c53d) x86_64 x86_64 x86_64 GNU/Linux # cat /proc/cmdline root=LABEL=os131sd32 ipv6.disable=1 noresume splash=0 vga=791 video=1024x768@60 video=1440x900@60 3 # lspci -nnkv #(excerpt) 00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31 Express Integrated Graphics Controller [8086:29c2] (rev 02) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device [103c:2a6f] Flags: bus master, fast devsel, latency 0, IRQ 27 Memory at fea00000 (32-bit, non-prefetchable) [size=512K] I/O ports at c080 [size=8] Memory at d0000000 (32-bit, prefetchable) [size=256M] Memory at fe900000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Kernel driver in use: i915 Kernel modules: i915 # fbset mode "1280x720" geometry 1280 720 1280 720 32... # grep PRETTY /etc/os-release PRETTY_NAME="openSUSE 13.1 (Bottle) (x86_64)" # uname -a Linux vizio 4.4.0-2.g368c53d-default #1 SMP PREEMPT Tue Jan 12 13:39:53 UTC 2016 (368c53d) x86_64 x86_64 x86_64 GNU/Linux # cat /proc/cmdline root=LABEL=08os13164 ipv6.disable=1 net.ifnames=0 noresume splash=0 video=1280x720@60 3 # lspci -nnkv #(excerpt)(aka Intel G43, Dell Optiplex 780) 00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e12] (rev 03) (prog-if 00 [VGA controller]) Subsystem: Dell Device [1028:027f] Flags: bus master, fast devsel, latency 0, IRQ 33 Memory at f7c00000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at ecb0 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Kernel driver in use: i915 Kernel modules: i915 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/18/2016 04:33 AM, Andrei Borzenkov wrote:
lspci -nnkv
All of it? or just the relevant part: 00:02.0 VGA compatible controller [0300]: Intel Corporation 82Q35 Express Integrated Graphics Controller [8086:29b2] (rev 02) (prog-if 00 [VGA controller]) Subsystem: Dell OptiPlex 755 [1028:0211] Flags: bus master, fast devsel, latency 0, IRQ 27 Memory at fea00000 (32-bit, non-prefetchable) [size=512K] I/O ports at ec90 [size=8] Memory at d0000000 (32-bit, prefetchable) [size=256M] Memory at feb00000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Kernel driver in use: i915 Kernel modules: i915 00:02.1 Display controller [0380]: Intel Corporation 82Q35 Express Integrated Graphics Controller [8086:29b3] (rev 02) Subsystem: Dell OptiPlex 755 [1028:0211] Flags: bus master, fast devsel, latency 0 Memory at fea80000 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 As I say, this is intermittent. This mornings boot of the workstation the login appear and the fonts are the normal size. But that's the same kernel and library and config that I used yesterday over three separate boots, non of which were normal and all three were different in what the Ctl-Alt-Del showed. That I have no problem with the X11 login though KDM and into KDE, nothing in the logs about problems there, puts a limit on the idea of flaky hardware. Experience has been that graphics/X11 is the first thing to go, its amazingly picky! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/18/2016 10:09 AM, Anton Aylward wrote:
As I say, this is intermittent. This mornings boot of the workstation the login appear and the fonts are the normal size. But that's the same kernel and library and config that I used yesterday over three separate boots, non of which were normal and all three were different in what the Ctl-Alt-Del showed.
Like I said earlier ... ALMOST I hot-key this Am to Ctl-AltF1 and see the login prompt in a normal font so login as root. I get the "have a lot of fun" messaga agd a # prompt. I hit return. NOTHING HAPPENS. no new line. I hot-key to Ctl-AltF2, 3, 4, 5, 6 and see the same thing. No, nt the same phenomena, the same screen. its as if the framebuffer or whatever, is mapped to them all. I see the exact same screen, pixel for pixel. However, there should be login prompts on each # ps -ef | grep tty root 1872 1854 1 04:32 tty7 00:04:33 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -seat seat0 -auth /var/lib/kdm/AuthFiles/A:0-XXLJMa root 1895 1833 0 04:33 tty1 00:00:00 -bash root 4877 1 0 10:09 tty2 00:00:00 /sbin/agetty --noclear tty2 root 4878 1 0 10:09 tty3 00:00:00 /sbin/agetty --noclear tty3 root 4879 1 0 10:09 tty4 00:00:00 /sbin/agetty --noclear tty4 root 4880 1 0 10:09 tty5 00:00:00 /sbin/agetty --noclear tty5 root 4881 1 0 10:09 tty6 00:00:00 /sbin/agetty --noclear tty6 root 5068 4776 0 10:21 pts/6 00:00:00 grep --color=auto tty There's something inconsistent or perhaps its consistent and I'm just seen different manifestations based on a variable that I'm unaware of. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Anton Aylward <opensuse@antonaylward.com> [01-18-16 10:24]:
On 01/18/2016 10:09 AM, Anton Aylward wrote:
As I say, this is intermittent. This mornings boot of the workstation the login appear and the fonts are the normal size. But that's the same kernel and library and config that I used yesterday over three separate boots, non of which were normal and all three were different in what the Ctl-Alt-Del showed.
Like I said earlier ... ALMOST
I hot-key this Am to Ctl-AltF1 and see the login prompt in a normal font so login as root.
I get the "have a lot of fun" messaga agd a # prompt.
I hit return.
NOTHING HAPPENS.
no new line.
I hot-key to Ctl-AltF2, 3, 4, 5, 6 and see the same thing.
No, nt the same phenomena, the same screen. its as if the framebuffer or whatever, is mapped to them all. I see the exact same screen, pixel for pixel.
However, there should be login prompts on each
# ps -ef | grep tty root 1872 1854 1 04:32 tty7 00:04:33 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -seat seat0 -auth /var/lib/kdm/AuthFiles/A:0-XXLJMa root 1895 1833 0 04:33 tty1 00:00:00 -bash root 4877 1 0 10:09 tty2 00:00:00 /sbin/agetty --noclear tty2 root 4878 1 0 10:09 tty3 00:00:00 /sbin/agetty --noclear tty3 root 4879 1 0 10:09 tty4 00:00:00 /sbin/agetty --noclear tty4 root 4880 1 0 10:09 tty5 00:00:00 /sbin/agetty --noclear tty5 root 4881 1 0 10:09 tty6 00:00:00 /sbin/agetty --noclear tty6 root 5068 4776 0 10:21 pts/6 00:00:00 grep --color=auto tty
There's something inconsistent or perhaps its consistent and I'm just seen different manifestations based on a variable that I'm unaware of.
You have active logins to all those tty's. A "ps -ef|grep tty" on my system only reveals tty's with active logins. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/18/2016 10:44 AM, Patrick Shanahan wrote:
# ps -ef | grep tty root 1872 1854 1 04:32 tty7 00:04:33 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -seat seat0 -auth /var/lib/kdm/AuthFiles/A:0-XXLJMa root 1895 1833 0 04:33 tty1 00:00:00 -bash root 4877 1 0 10:09 tty2 00:00:00 /sbin/agetty --noclear tty2 root 4878 1 0 10:09 tty3 00:00:00 /sbin/agetty --noclear tty3 root 4879 1 0 10:09 tty4 00:00:00 /sbin/agetty --noclear tty4 root 4880 1 0 10:09 tty5 00:00:00 /sbin/agetty --noclear tty5 root 4881 1 0 10:09 tty6 00:00:00 /sbin/agetty --noclear tty6 root 5068 4776 0 10:21 pts/6 00:00:00 grep --color=auto tty
There's something inconsistent or perhaps its consistent and I'm just seen different manifestations based on a variable that I'm unaware of.
You have active logins to all those tty's. A "ps -ef|grep tty" on my system only reveals tty's with active logins.
Please rephrase, Patrick. This is the same list I'd expect if everything was working OK. You can see that i have logged in on tty and there is bash running there The getty running on the other VTs means there should be a login prompt. There isn't. Something is worn with connections, frame buffer, whatever. I don't know enough about these drivers to be sure what. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Anton Aylward <opensuse@antonaylward.com> [01-18-16 11:23]:
On 01/18/2016 10:44 AM, Patrick Shanahan wrote:
# ps -ef | grep tty root 1872 1854 1 04:32 tty7 00:04:33 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -seat seat0 -auth /var/lib/kdm/AuthFiles/A:0-XXLJMa root 1895 1833 0 04:33 tty1 00:00:00 -bash root 4877 1 0 10:09 tty2 00:00:00 /sbin/agetty --noclear tty2 root 4878 1 0 10:09 tty3 00:00:00 /sbin/agetty --noclear tty3 root 4879 1 0 10:09 tty4 00:00:00 /sbin/agetty --noclear tty4 root 4880 1 0 10:09 tty5 00:00:00 /sbin/agetty --noclear tty5 root 4881 1 0 10:09 tty6 00:00:00 /sbin/agetty --noclear tty6 root 5068 4776 0 10:21 pts/6 00:00:00 grep --color=auto tty
There's something inconsistent or perhaps its consistent and I'm just seen different manifestations based on a variable that I'm unaware of.
You have active logins to all those tty's. A "ps -ef|grep tty" on my system only reveals tty's with active logins.
Please rephrase, Patrick.
This is the same list I'd expect if everything was working OK. You can see that i have logged in on tty and there is bash running there The getty running on the other VTs means there should be a login prompt. There isn't. Something is worn with connections, frame buffer, whatever. I don't know enough about these drivers to be sure what.
ps -ef | grep tty htopd 1059 1 0 Jan16 ? 00:00:00 /usr/bin/sh -c /usr/bin/htop d 1 P > /dev/tty12 < /dev/tty12 root 2084 1 0 Jan16 tty1 00:00:00 /sbin/agetty --noclear tty1 linux root 2118 2106 0 Jan16 tty6 00:00:00 -bash root 5685 5667 2 Jan16 tty8 01:04:29 /usr/bin/Xorg -br :0 vt8 -nolisten tcp -seat seat0 -auth /var/lib/kdm/AuthFiles/A:0-iQGPea
I only see vt's which have people logged into them: paka 14834 14833 0 12:50 pts/25 00:00:00 grep --color=auto tty I guess I understand now, tty1 has no-one logged in but has "--noclear" parameter which I *only* have on tty1. That parameter must be making tty2 and 3-6 appear on your ps output and not on mine. I have an active login on tty6 and tty8, which should actually be tty7 but for some lengthy period X chooses tty8 over 7 *most* of the time. sub-note: startx for me usually chooses the tty where it was issued. But that is another topic.... -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/18/2016 05:22 PM, Anton Aylward wrote:
Something is worn with connections, frame buffer, whatever. I don't know enough about these drivers to be sure what.
Have you tried yet disabling plymouth on boot, or uninstall it (needs mkinitrd to apply)? -- Cheers/Saludos Carlos E. R. (openSUSE Leap 42.1, test at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/21/2016 09:41 AM, Carlos E. R. wrote:
On 01/18/2016 05:22 PM, Anton Aylward wrote:
Something is worn with connections, frame buffer, whatever. I don't know enough about these drivers to be sure what.
Have you tried yet disabling plymouth on boot, or uninstall it (needs mkinitrd to apply)?
rpm -qa | grep plymouth
plymouth-scripts-0.8.8_git201309032142-2.5.1.x86_64 plymouth-plugin-label-0.8.8_git201309032142-2.5.1.x86_64 plymouth-branding-openSUSE-13.1-10.4.13.noarch plymouth-plugin-script-0.8.8_git201309032142-2.5.1.x86_64 plymouth-0.8.8_git201309032142-2.5.1.x86_64 Oh, I wasn't aware I was running it! So how do I DISABLE it? I've tried editing the command line at boot, removing the splash=silent quiet Yes I see all the boot time messages scrolling by too fast to read And no the end result isn't stable and consistent. Sometimes the login following is at different parts of the screen, meaning that there were more or fewer messages scrolling, or that some 'clear' occurred or something. Sometimes its the size font I expect, sometimes its been the small font. On one occasion the login prompt was displayed but the vt was unresponsive. I can't claim that the hardware is failing, the CPU failing, the graphics system failing, because I'm encountering no problems with the X11/KDE side or the command line operations even when su'd to root in a kterminal window. My experience has been that as graphics go, X11 is picky! Its the inconsistency that puzzles me. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata composed on 2016-01-18 01:41 (UTC-0500):
In previous reply I forgot to include suggestion to disable/remove Plymouth if you haven't already.
Anton Aylward composed on 2016-01-21 10:17 (UTC-0500):
Carlos E. R. composed on 2016-01-21 15:41 (UTC+0100):
Have you tried yet disabling plymouth on boot, or uninstall it (needs mkinitrd to apply)?
rpm -qa | grep plymouth plymouth-scripts-0.8.8_git201309032142-2.5.1.x86_64 plymouth-plugin-label-0.8.8_git201309032142-2.5.1.x86_64 plymouth-branding-openSUSE-13.1-10.4.13.noarch plymouth-plugin-script-0.8.8_git201309032142-2.5.1.x86_64 plymouth-0.8.8_git201309032142-2.5.1.x86_64
Oh, I wasn't aware I was running it! So how do I DISABLE it?
On Mageia, where attempting Plymouth uninstallation wants to uninstall nearly the whole OS, noplymouth on cmdline works. Maybe try plymouth=0 on cmdline if it that doesn't work for 13.1. On openSUSE, I taboo Plymouth at installation time so don't know how to "disable" it. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/21/2016 07:41 PM, Felix Miata wrote:
rpm -qa | grep plymouth plymouth-scripts-0.8.8_git201309032142-2.5.1.x86_64 plymouth-plugin-label-0.8.8_git201309032142-2.5.1.x86_64 plymouth-branding-openSUSE-13.1-10.4.13.noarch plymouth-plugin-script-0.8.8_git201309032142-2.5.1.x86_64 plymouth-0.8.8_git201309032142-2.5.1.x86_64
In openSUSE not all plymouth related packages can be removed because of dependencies, but the core can.
Oh, I wasn't aware I was running it! So how do I DISABLE it?
On Mageia, where attempting Plymouth uninstallation wants to uninstall nearly the whole OS, noplymouth on cmdline works. Maybe try plymouth=0 on cmdline if it that doesn't work for 13.1. On openSUSE, I taboo Plymouth at installation time so don't know how to "disable" it.
Same here, but from readings, I remember that one of the two works in openSUSE. -- Cheers/Saludos Carlos E. R. (openSUSE Leap 42.1, test at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. composed on 2016-01-22 00:11 (UTC+0100):
Felix Miata wrote:
rpm -qa | grep plymouth plymouth-scripts-0.8.8_git201309032142-2.5.1.x86_64 plymouth-plugin-label-0.8.8_git201309032142-2.5.1.x86_64 plymouth-branding-openSUSE-13.1-10.4.13.noarch plymouth-plugin-script-0.8.8_git201309032142-2.5.1.x86_64 plymouth-0.8.8_git201309032142-2.5.1.x86_64
In openSUSE not all plymouth related packages can be removed because of dependencies, but the core can.
Not my experience. I have at least 50 openSUSE installations all the way back to 10.0, plus 9.3, 9.2 and more, none of which (that I can remember) have any of Plymouth installed. Like I previously wrote, I taboo it at installation time, so none of it gets installed in the first place.
Oh, I wasn't aware I was running it! So how do I DISABLE it?
On Mageia, where attempting Plymouth uninstallation wants to uninstall nearly the whole OS, noplymouth on cmdline works. Maybe try plymouth=0 on cmdline if it that doesn't work for 13.1. On openSUSE, I taboo Plymouth at installation time so don't know how to "disable" it.
Same here, but from readings, I remember that one of the two works in openSUSE. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/22/2016 04:09 AM, Felix Miata wrote:
In openSUSE not all plymouth related packages can be removed because of
dependencies, but the core can. Not my experience. I have at least 50 openSUSE installations all the way back to 10.0, plus 9.3, 9.2 and more, none of which (that I can remember) have any of Plymouth installed. Like I previously wrote, I taboo it at installation time, so none of it gets installed in the first place.
libply-boot-client2 - Plymouth core library libply-splash-core2 - Plymouth core library libply2 - Plymouth core library Minas-Anor:~ # rpm --erase --test libply2 error: Failed dependencies: libply.so.2()(64bit) is needed by (installed) libply-boot-client2-0.9.0-8.1.x86_64 libply.so.2()(64bit) is needed by (installed) libply-splash-core2-0.9.0-8.1.x86_64 libply.so.2()(64bit) is needed by (installed) suspend-1.0-28.1.1.x86_64 Minas-Anor:~ # And obviously I don't want to remove suspend. -- Cheers/Saludos Carlos E. R. (openSUSE Leap 42.1, test at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. composed on 2016-01-22 04:19 (UTC+0100):
Felix Miata wrote:
In openSUSE not all plymouth related packages can be removed because of
dependencies, but the core can.
Not my experience. I have at least 50 openSUSE installations all the way back to 10.0, plus 9.3, 9.2 and more, none of which (that I can remember) have any of Plymouth installed. Like I previously wrote, I taboo it at installation time, so none of it gets installed in the first place.
libply-boot-client2 - Plymouth core library libply-splash-core2 - Plymouth core library libply2 - Plymouth core library
Minas-Anor:~ # rpm --erase --test libply2 error: Failed dependencies: libply.so.2()(64bit) is needed by (installed) libply-boot-client2-0.9.0-8.1.x86_64 libply.so.2()(64bit) is needed by (installed) libply-splash-core2-0.9.0-8.1.x86_64 libply.so.2()(64bit) is needed by (installed) suspend-1.0-28.1.1.x86_64 Minas-Anor:~ #
And obviously I don't want to remove suspend.
I'm pretty sure I have no machines with suspend needed or installed. All are multiboot, with at most one swap partition per storage device. No *ply* installed here. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-01-22 04:42, Felix Miata wrote:
I'm pretty sure I have no machines with suspend needed or installed. All are multiboot, with at most one swap partition per storage device. No *ply* installed here.
Well, that's different: suspend is installed by default, even on Leap. Your systems, being test systems, avoid it. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Is it actually used? Отправлено с iPhone
22 янв. 2016 г., в 7:07, Carlos E. R. <robin.listas@telefonica.net> написал(а):
On 2016-01-22 04:42, Felix Miata wrote: I'm pretty sure I have no machines with suspend needed or installed. All are multiboot, with at most one swap partition per storage device. No *ply* installed here.
Well, that's different: suspend is installed by default, even on Leap. Your systems, being test systems, avoid it.
-- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-01-22 05:49, Andrei Borzenkov wrote:
Is it actually used?
Dunno. I use "systemctl hibernate" on Leap (known bug in xfce prevents hibernating properly) (it was you who told me of the command, thanks), and close the lid of the laptop, which triggers a suspend to ram. I don't know if any of the files in the suspend package are actually used. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. composed on 2016-01-22 05:07 (UTC+0100):
Felix Miata wrote:
I'm pretty sure I have no machines with suspend needed or installed. All are multiboot, with at most one swap partition per storage device. No *ply* installed here.
Well, that's different: suspend is installed by default, even on Leap. Your systems, being test systems, avoid it.
Lots of things are "installed" by default that never get installed here. It's been years since any default openSUSE install has had any of my own systems as its target. Before proceeding to install here, the list of tabooed overflows the YaST installation summary package list in its default sort state. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 22 Jan 2016 05:07, Carlos E. R. <robin.listas@...> wrote:
On 2016-01-22 04:42, Felix Miata wrote:
I'm pretty sure I have no machines with suspend needed or installed. All are multiboot, with at most one swap partition per storage device. No *ply* installed here.
Well, that's different: suspend is installed by default, even on Leap. Your systems, being test systems, avoid it.
Huh? On a fresh install of Leap 42.1 from DVD, there is no package "suspend" at all, and even a search on software.opensuse.org: http://software.opensuse.org/search?q=suspend&baseproject=all returns no match for Leap 42.1 or SLE-12. a call: zypper rm \ libply2-0.9.0-8.1.x86_64 libply-boot-client2-0.9.0-8.1.x86_64 \ libply-splash-graphics2-0.9.0-8.1.x86_64 libply-splash-core2-0.9.0-8.1.x86_64 just removes these packages and nothing more, good. (I had no plymouth installed beforehand) - Yamaban -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-01-22 12:58, Yamaban wrote:
On Fri, 22 Jan 2016 05:07, Carlos E. R. <robin.listas@...> wrote:
Well, that's different: suspend is installed by default, even on Leap. Your systems, being test systems, avoid it.
Huh? On a fresh install of Leap 42.1 from DVD, there is no package "suspend" at all, and even a search on software.opensuse.org:
Something strange happening here. My Leap test install in my laptop certainly has it installed. My test install under vmware player, doesn't. Both were made from the same "DVD" (usb stick). The laptop (Leap) has suspend fromo 13.1. Install Date: 2016-01-14T19:00:56 CET /var/log/zypp/history # 2016-01-14 19:02:55 suspend-1.0-28.1.1.x86_64.rpm installed ok ... 2016-01-14 19:02:55|install|suspend|1.0-28.1.1|x86_64||openSUSE-42.1-0|ce4ad7712564d0ae6b8c7bc737654114b1f92d137c42cd9b7119650a2368a8ad| 2016-01-14 18:54:16 <1> Minas-Anor.Valinor(9298) [zypp:fetcher] Fetcher.cc(provideFromCache):350 start fetcher with 1 cache directories. 2016-01-14 18:54:16 <1> Minas-Anor.Valinor(9298) [zypp:fetcher] Fetcher.cc(provideToDest):547 Not found in cache, downloading 2016-01-14 18:54:16 <1> Minas-Anor.Valinor(9298) [zypp++] MediaSetAccess.cc(provide):203 Going to try to provide file ./suse/x86_64/suspend-1.0-28.1.1.x86_64.rpm from media number 1 2016-01-14 18:54:16 <1> Minas-Anor.Valinor(9298) [zypp++] MediaManager.cc(checkDesired):112 checkDesired(8): desired (cached) 2016-01-14 18:54:16 <1> Minas-Anor.Valinor(9298) [zypp++] MediaManager.cc(checkDesired):112 checkDesired(8): desired (cached) 2016-01-14 18:54:16 <1> Minas-Anor.Valinor(9298) [zypp++] MediaHandler.cc(provideFile):998 provideFile(./suse/x86_64/suspend-1.0-28.1.1.x86_64.rpm) 2016-01-14 18:54:16 <1> Minas-Anor.Valinor(9298) [zypp++] MediaManager.cc(checkDesired):112 checkDesired(8): desired (cached) 2016-01-14 18:54:16 <1> Minas-Anor.Valinor(9298) [zypp++] ExternalProgram.cc(start_program):249 Executing '/bin/cp' '--remove-destination' '--' '/var/adm/mount/AP_0xvaS5KG/suse/x86_64/suspend-1.0-28.1.1.x86_64.rpm' '/var/cache/zypp/packages/openSUSE-42.1-0/suse/x86_64/suspend-1.0-28.1.1.x86_64.rpm' 2016-01-14 18:54:16 <1> Minas-Anor.Valinor(9298) [zypp++] ExternalProgram.cc(start_program):412 pid 9811 launched 2016-01-14 18:54:16 <1> Minas-Anor.Valinor(9298) [zypp++] ExternalProgram.cc(checkStatus):513 Pid 9811 successfully completed 2016-01-14 18:54:16 <1> Minas-Anor.Valinor(9298) [zypp++] MediaSetAccess.cc(releaseFile):85 Going to release file ./suse/x86_64/suspend-1.0-28.1.1.x86_64.rpm from media number 1 2016-01-14 18:54:16 <1> Minas-Anor.Valinor(9298) [zypp:fetcher] Fetcher.cc(validate):392 Checking job [/var/cache/zypp/packages/openSUSE-42.1-0/suse/x86_64/suspend-1.0-28.1.1.x86_64.rpm] (1 checkers ) 2016-01-14 18:54:16 <1> Minas-Anor.Valinor(9298) [Progress++] ProgressData.cc(report):88 {#195|}END 2016-01-14 18:54:16 <1> Minas-Anor.Valinor(9298) [Ruby] modules/PackageCallbacks.rb:199 DoneProvide: 0, , suspend I think I know where it comes from! It is a bug that I was checking before report. The laptop is triple boot: windows, openSUSE 13.1, Leap. When I start yast package manager, it asks for the install media (I don't disable the DVD repo). The probable sequence would be: Use 13.1, do some updates, plug in the 13.1 USB install stick when it asks for it. Reboot to Leap. Do an update with YaST. YaST finds the stick for 13.1 and uses it, not checking that it is the wrong version. I have verified that it does indeed use happily the wrong USB stick during the repository refresh phase. What I had not verified is that it also installed packages from it! I have to verify whether there are other wrong packages. Bugzilla time. Against YaST, I suppose? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2016-01-22 14:31, Carlos E. R. wrote:
I have to verify whether there are other wrong packages.
Several: Minas-Anor:~ # rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" | sort | cut --fields="2-" | tee rpmlist | egrep "openSUSE.13\.1" Thu Jan 14 2016 Sun Oct 20 2013 bundle-lang-common-en 13.1-2.2.7 noarch openSUSE http://bugs.opensuse.org == openSUSE 13.1 (none) Thu Jan 14 2016 Sun Oct 20 2013 bundle-lang-common-es 13.1-2.2.7 noarch openSUSE http://bugs.opensuse.org == openSUSE 13.1 (none) Thu Jan 14 2016 Sun Oct 20 2013 bundle-lang-gnome-en 13.1-2.2.8 noarch openSUSE http://bugs.opensuse.org == openSUSE 13.1 (none) Thu Jan 14 2016 Sun Oct 20 2013 bundle-lang-gnome-es 13.1-2.2.8 noarch openSUSE http://bugs.opensuse.org == openSUSE 13.1 (none) Thu Jan 14 2016 Fri Sep 27 2013 cryptsetup-mkinitrd 0_201307311719-2.1.2 x86_64 openSUSE http://bugs.opensuse.org == openSUSE 13.1 (none) Thu Jan 14 2016 Sat Sep 28 2013 libgcrypt11 1.5.3-2.1.4 x86_64 openSUSE http://bugs.opensuse.org == openSUSE 13.1 (none) Thu Jan 14 2016 Sat Sep 28 2013 libksba8 1.3.0-5.1.2 x86_64 openSUSE http://bugs.opensuse.org == openSUSE 13.1 (none) Thu Jan 14 2016 Sat Sep 28 2013 pm-utils 1.4.1-33.1.2 x86_64 openSUSE http://bugs.opensuse.org == openSUSE 13.1 (none) Thu Jan 14 2016 Sat Sep 21 2013 suspend 1.0-28.1.1 x86_64 openSUSE http://bugs.opensuse.org == openSUSE 13.1 (none) Thu Jan 14 2016 Sat Sep 28 2013 xorg-x11-Xvnc 7.6_1.0.1-15.1.3 x86_64 openSUSE http://bugs.opensuse.org == openSUSE 13.1 (none) Minas-Anor:~ # Correcting those immediately. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2016-01-22 14:31, Carlos E. R. wrote:
Bugzilla time. Against YaST, I suppose?
Bug 963226 - yast2 sw_single and online_update in Leap do not check the version of the install media (DVD, USB stick) during updates. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [01-31-16 12:48]:
On 01/21/2016 07:41 PM, Felix Miata wrote:
rpm -qa | grep plymouth plymouth-scripts-0.8.8_git201309032142-2.5.1.x86_64 plymouth-plugin-label-0.8.8_git201309032142-2.5.1.x86_64 plymouth-branding-openSUSE-13.1-10.4.13.noarch plymouth-plugin-script-0.8.8_git201309032142-2.5.1.x86_64 plymouth-0.8.8_git201309032142-2.5.1.x86_64
In openSUSE not all plymouth related packages can be removed because of dependencies, but the core can.
Oh, I wasn't aware I was running it! So how do I DISABLE it?
On Mageia, where attempting Plymouth uninstallation wants to uninstall nearly the whole OS, noplymouth on cmdline works. Maybe try plymouth=0 on cmdline if it that doesn't work for 13.1. On openSUSE, I taboo Plymouth at installation time so don't know how to "disable" it.
Same here, but from readings, I remember that one of the two works in openSUSE.
"A good Idea" (tm!) to occasionally run: zypper -v se -si |grep zypper se -si |grep \(System\ Packages\) and manually adjust as required. You will see many 3rd party apps such as Corel AfterShotPro/.... -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Patrick Shanahan composed on 2016-01-31 13:16 (UTC-0500):
"A good Idea" (tm!) to occasionally run: zypper -v se -si |grep zypper se -si |grep \(System\ Packages\)
On TW here that generates only a fresh shell prompt.
and manually adjust as required.
What did you intend from that that zypper se -s | grep 'tem Pac' doesn't produce? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Felix Miata <mrmazda@earthlink.net> [01-31-16 16:43]:
Patrick Shanahan composed on 2016-01-31 13:16 (UTC-0500):
"A good Idea" (tm!) to occasionally run: zypper -v se -si |grep zypper se -si |grep \(System\ Packages\)
On TW here that generates only a fresh shell prompt.
and manually adjust as required.
What did you intend from that that
zypper se -s | grep 'tem Pac'
doesn't produce?
fatfingers I guess, s/b: zypper -v se -si |grep \(System\ Packages\) shows only installed items which do not exist within a repo ie: orphaned or no longer provided or changed name or ... I *usually* removed packages I did not manually install, and those who appear to have incremented their .so version and were not automagically removed (happens too frequently). And I check first that they are not needed by some other resident application. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-01-31 23:03, Patrick Shanahan wrote:
ie: orphaned or no longer provided or changed name or ...
I *usually* removed packages I did not manually install, and those who appear to have incremented their .so version and were not automagically removed (happens too frequently). And I check first that they are not needed by some other resident application.
YaST has an "unmantained" display option which I use often. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 01/21/2016 01:41 PM, Felix Miata wrote:
Oh, I wasn't aware I was running it! So how do I DISABLE it? On Mageia, where attempting Plymouth uninstallation wants to uninstall nearly the whole OS, noplymouth on cmdline works. Maybe try plymouth=0 on cmdline if it that doesn't work for 13.1.
Well I tied that and it seems no different from when I remove the "splash=silent quiet " from the command line. Go figure. However when i log in I still have the unaccountable LINES=64 setting in vt1 (and vt2 etc) I also have TERM=linux I've previously posted about not being able to account for that with the infocmp view of the terminfo database entry. Iv just run clear ; for (( i=1 ; i <= 48 ; i++ ) do echo $i done and established that indeed, there are ONLY 48 lines of display on vt1. So why do I have LINES=64 Where is this being set? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/22/2016 11:47 PM, Anton Aylward wrote:
On 01/21/2016 01:41 PM, Felix Miata wrote:
Oh, I wasn't aware I was running it! So how do I DISABLE it? On Mageia, where attempting Plymouth uninstallation wants to uninstall nearly the whole OS, noplymouth on cmdline works. Maybe try plymouth=0 on cmdline if it that doesn't work for 13.1.
Well I tied that and it seems no different from when I remove the "splash=silent quiet " from the command line. Go figure.
If you uninstall plymouth, you have to remember to rebuild the initrd archive? mkinitrd. -- Cheers/Saludos Carlos E. R. (openSUSE Leap 42.1, test at Minas-Anor) -- Cheers/Saludos Carlos E. R. (openSUSE Leap 42.1, test at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/22/2016 06:31 PM, Carlos E. R wrote:
On 01/22/2016 11:47 PM, Anton Aylward wrote:
On 01/21/2016 01:41 PM, Felix Miata wrote:
Oh, I wasn't aware I was running it! So how do I DISABLE it? On Mageia, where attempting Plymouth uninstallation wants to uninstall nearly the whole OS, noplymouth on cmdline works. Maybe try plymouth=0 on cmdline if it that doesn't work for 13.1.
Well I tied that and it seems no different from when I remove the "splash=silent quiet " from the command line. Go figure.
If you uninstall plymouth, you have to remember to rebuild the initrd archive? mkinitrd.
Yes i'm well aware of that; any changes resulting from manipulating with YAST or editing stuff in /etc/boot or /etc/grub.d/* or /etc/grub.cfg and so on. Yes done! As has been commented, trying to *remove* plymouth rather than disable it involves removing large parts of the OS. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/23/2016 12:42 AM, Anton Aylward wrote:
As has been commented, trying to *remove* plymouth rather than disable it involves removing large parts of the OS.
No, just a few packages. Plymouth is known to cause weird effects on some systems. And makes the initrd image to be about double size. -- Cheers/Saludos Carlos E. R. (openSUSE Leap 42.1, test at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/22/2016 06:48 PM, Carlos E. R. wrote:
And makes the initrd image to be about double size.
Indeed it does. I've just rebooted with the new initrd at 6am, and 1) WOW THAT WAS **FAST** Even by what I'm used to with parallel systemd, it was **FAST** 2) It was a lot less noisy in terms of the kernel messages being spewed. It makes me wonder. Plymouth as a boat anchor. There's a price you pay for the 'eye candy'. I have most of it turned off in KDE, but at times I wonder if I shouldn't be running one of the lightweight DMs and then using the KDE libraries to run Kongueror instead of Thunar, Konsole instead of Lxterminal and things like BasKet Notes. But then there's LXDE-Qt isn't there? Is anyone here using that? https://github.com/lxde/lxqt/wiki/LXQt-Roadmap -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-01-23 12:52, Anton Aylward wrote:
On 01/22/2016 06:48 PM, Carlos E. R. wrote:
And makes the initrd image to be about double size.
Indeed it does.
I've just rebooted with the new initrd at 6am, and
1) WOW THAT WAS **FAST** Even by what I'm used to with parallel systemd, it was **FAST**
2) It was a lot less noisy in terms of the kernel messages being spewed.
With plymouth, I think that the boot messages are saved to a file, and later they are displayed, perhaps on request.
It makes me wonder. Plymouth as a boat anchor. There's a price you pay for the 'eye candy'.
Yes. I routinely remove it during initial install, and taboo it. I understand that many users prefer to see a graphical boot display with a progress bar and perhaps animations, and are terribly disgruntled at seeing boot progress in text messages. So plymouth has a place for them. But I really love to see those text messages: they tell what is actually happening, we can see if things go abnormal just by noticing that they are somewhat different than the previous time.
I have most of it turned off in KDE, but at times I wonder if I shouldn't be running one of the lightweight DMs and then using the KDE libraries to run Kongueror instead of Thunar, Konsole instead of Lxterminal and things like BasKet Notes.
But then there's LXDE-Qt isn't there? Is anyone here using that? https://github.com/lxde/lxqt/wiki/LXQt-Roadmap
I haven't tried it yet. But I run XFCE desktop because it is less complex, less features on the desktop, but then I use several KDE applications because they are *good*. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 01/23/2016 07:04 AM, Carlos E. R. wrote:
It makes me wonder. Plymouth as a boat anchor. There's a price you pay for the 'eye candy'. Yes. I routinely remove it during initial install, and taboo it. I understand that many users prefer to see a graphical boot display with a progress bar and perhaps animations, and are terribly disgruntled at seeing boot progress in text messages. So plymouth has a place for them.
But I really love to see those text messages: they tell what is actually happening, we can see if things go abnormal just by noticing that they are somewhat different than the previous time.
Indeed. Are we paranoid or something? If you think about it, this attitude means that we *EXPECT* something to go wrong and are watching out for it. It reminds me, somewhat, of Kipling's "Sons of Martha" They do not preach that their God will rouse them a little before the nuts work loose. They do not preach that His Pity allows them to drop their job when they damn-well choose. As in the thronged and the lighted ways, so in the dark and the desert they stand, Wary and watchful all their days that their brethren's ways may be long in the land. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-01-23 13:27, Anton Aylward wrote:
But I really love to see those text messages: they tell what is actually happening, we can see if things go abnormal just by noticing that they are somewhat different than the previous time.
Indeed. Are we paranoid or something? If you think about it, this attitude means that we *EXPECT* something to go wrong and are watching out for it.
LOL. Not really. I know that things do often go wrong with computers, but 90% of the times is because I changed something, intentionally or unintentionally. Recently, I updated my test Leap install in my laptop, which uses grub 2 and boots directly to level 5. Problem was, I had forgotten that the installation media for 13.1 was still plugged in, and YaST happily used it without thinking (yes, there is a bugzilla about this). So, the result was Leap with some 13.1 packages. Well, I would perhaps have seen some strange messages on boot had I been watching, or had not the X splash screen hidden it from view. I thought there was something strange, but did not pay attention.
It reminds me, somewhat, of Kipling's "Sons of Martha"
They do not preach that their God will rouse them a little before the nuts work loose. They do not preach that His Pity allows them to drop their job when they damn-well choose. As in the thronged and the lighted ways, so in the dark and the desert they stand, Wary and watchful all their days that their brethren's ways may be long in the land.
:-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 01/23/2016 08:45 AM, Carlos E. R. wrote:
Indeed. Are we paranoid or something? If you think about it, this attitude means that we *EXPECT* something to go wrong and are watching out for it. LOL.
Not really.
I know that things do often go wrong with computers, but 90% of the times is because I changed something, intentionally or unintentionally.
Yea, well. I changed the kernel! you'd think the controls around the reliability and operational integrity of the kernel were better than, say, Firefox .. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/23/2016 07:04 AM, Carlos E. R. wrote:
I have most of it turned off in KDE, but at times I wonder if I shouldn't be running one of the lightweight DMs and then using the KDE libraries to run Kongueror instead of Thunar, Konsole instead of Lxterminal and things like BasKet Notes.
But then there's LXDE-Qt isn't there? Is anyone here using that? https://github.com/lxde/lxqt/wiki/LXQt-Roadmap I haven't tried it yet.
But I run XFCE desktop because it is less complex, less features on the desktop, but then I use several KDE applications because they are *good*.
Damn *expletive* right! what we need are Qt versions of Thunderbird and Firefox! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/23/2016 07:04 AM, Carlos E. R. wrote:
But I run XFCE desktop because it is less complex, less features on the desktop, but then I use several KDE applications because they are *good*.
I'm reluctant to switch back and forth between KDE and XFCE. When I've done so in the past ... Well I have a number of Firefox windows in KDE, each with a large number of tabs. Every few months I consolidate them down but they grow back. its like keeping a garden. Firefox is the kudzu. When I login using XFCE or LXDE rather than KDE all of a sudden there is only ONE window when I bring up Firefox. The other one is lost. I don't know why. When I go back to KDE the lost window is still lost. I have to be paranoid and take bookmarks of everything! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-01-23 13:37, Anton Aylward wrote:
On 01/23/2016 07:04 AM, Carlos E. R. wrote:
But I run XFCE desktop because it is less complex, less features on the desktop, but then I use several KDE applications because they are *good*.
I'm reluctant to switch back and forth between KDE and XFCE. When I've done so in the past ... Well I have a number of Firefox windows in KDE, each with a large number of tabs. Every few months I consolidate them down but they grow back. its like keeping a garden. Firefox is the kudzu.
It is a huge, yes.
When I login using XFCE or LXDE rather than KDE all of a sudden there is only ONE window when I bring up Firefox. The other one is lost. I don't know why. When I go back to KDE the lost window is still lost. I have to be paranoid and take bookmarks of everything!
Well, when I login in xfce I get all my FF windows and tabs. A dozen windows, perhaps. Correction. I take care that the XFCE session save does not save FF. First I quit FF, TH, then log out with only the apps I want restarted again, because XFCE doesn't restore apps in the appropriate workspace. So, after login, I go to the appropriate workspace and manually start there the apps that go there. TH in the 2nd, FF in the 3rd... etc. In my test install of Leap, I have a problem with FF. I place it in the 3rd workspace. When I click on a link in TH in the second workspace, it brings FF to the second. I know this is a setting, but I have forgotten which. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Sat, 23 Jan 2016 12:52, Anton Aylward <opensuse@...> wrote:
On 01/22/2016 06:48 PM, Carlos E. R. wrote:
And makes the initrd image to be about double size.
Indeed it does.
I've just rebooted with the new initrd at 6am, and
1) WOW THAT WAS **FAST** Even by what I'm used to with parallel systemd, it was **FAST**
2) It was a lot less noisy in terms of the kernel messages being spewed.
It makes me wonder. Plymouth as a boat anchor. There's a price you pay for the 'eye candy'. I have most of it turned off in KDE, but at times I wonder if I shouldn't be running one of the lightweight DMs and then using the KDE libraries to run Kongueror instead of Thunar, Konsole instead of Lxterminal and things like BasKet Notes.
But then there's LXDE-Qt isn't there? Is anyone here using that? https://github.com/lxde/lxqt/wiki/LXQt-Roadmap
Hear! Hear! Oh, yes. Even on my new Box, running on Leap 42.1 (Cirrus7.com Nimbus with: Haswell i3-4330T, ASUS Q87T, 16GB Ram, Samsung 850EVO 250GB mSATA), it's just more fun to use XFCE as basis than KDE4 / Plasma5. Oh, I'm still using KDE apps (Ksudoku and Okular mostly), but I'm not "fixed" on the hype of KDE in any way. Neither I'm "fixed" on Gnome (which I'm using at work w/ Centos 7) I just like vitual desktops, abhor "Activities", both disqualify actual Plasma5, and KDE4 is a dying beast, at least upstream. No, I do not need eyecandy at boot. Most time at boot is wasted by LVM2 (systemd-analyze blame gives 1 sec for lvm2-pvscan@8:5.service) so, the three and a half (3.5) seconds for a cold boot to desktop with lightdm on autologin is not bad. (1.8 sec I see text scrolling) Most ugly are the hangs of lvm2-pvscan on shutdown for halt or reboot, two (2) to ninethy five (95) seconds, with more of the later. Would LXDE or LXQt (LXDE-Qt) be faster / better? Well, in my case the difference is not measurable for me, but more a matter of taste (LXDE vs. XFCE) Have a nice weekend, - Yamaban -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward composed on 2016-01-23 06:52 (UTC-0500):
Carlos E. R. wrote:
And makes the initrd image to be about double size.
Indeed it does.
I've just rebooted with the new initrd at 6am, and
1) WOW THAT WAS **FAST** Even by what I'm used to with parallel systemd, it was **FAST**
2) It was a lot less noisy in terms of the kernel messages being spewed.
So did Plymouth eradication eradicate the OP, or not? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/23/2016 09:58 PM, Felix Miata wrote:
So did Plymouth eradication eradicate the OP, or not?
No. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward composed on 2016-01-22 17:47 (UTC-0500):
Felix Miata wrote:
On Mageia, where attempting Plymouth uninstallation wants to uninstall nearly the whole OS, noplymouth on cmdline works. Maybe try plymouth=0 on cmdline if it that doesn't work for 13.1.
Well I tied that and it seems no different from when I remove the "splash=silent quiet " from the command line. Go figure.
However when i log in I still have the unaccountable
LINES=64
setting in vt1 (and vt2 etc)
I also have
TERM=linux
I've previously posted about not being able to account for that with the infocmp view of the terminfo database entry.
Iv just run clear ; for (( i=1 ; i <= 48 ; i++ ) do echo $i done
Syntax errors trying that here.
and established that indeed, there are ONLY 48 lines of display on vt1. So why do I have LINES=64 Where is this being set?
Kernel maybe? Does it behave differently if you boot a 13.1-specific kernel? What's your complete kernel cmdline? Is your video driver proprietary? Is your /etc/sysconfig/console file original/unmodified from that in the rpm it belongs to? I tried to replicate your dilemma without success: # 13.1 (with systemd-210-79.1 and its deps from BaseSystemLegacy repo) # lspci | grep VGA # 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04) # on 21" CRT # uname -a Linux gx280 3.12.51-2-desktop #1 SMP PREEMPT Sat Jan 16 00:25:03 UTC 2016 (08f7380) i686 i686 i386 GNU/Linux ## (from repositories/home:/mkubecek:/evergreen-13.1/openSUSE_13.1/) # grep FONT /etc/sysconfig/console CONSOLE_FONT="" # cat /proc/cmdline root=LABEL=os131p19 ipv6.disable=1 noresume splash=0 vga=791 video=1024x768@60 3 # set | grep LINES LINES=48 # fbset | grep ^mode mode "1024x768" # uname -a Linux gx280 3.12.51-2-desktop #1 SMP PREEMPT Sat Jan 16 00:25:03 UTC 2016 (08f7380) i686 i686 i386 GNU/Linux # grep FONT /etc/sysconfig/console CONSOLE_FONT="" # cat /proc/cmdline root=LABEL=os131p19 ipv6.disable=1 noresume splash=0 video=1152x864@60 3 # set | grep LINES LINES=54 # fbset | grep ^mode mode "1152x864" # uname -a Linux gx280 3.12.51-2-desktop #1 SMP PREEMPT Sat Jan 16 00:25:03 UTC 2016 (08f7380) i686 i686 i386 GNU/Linux # grep FONT /etc/sysconfig/console CONSOLE_FONT="" # cat /proc/cmdline root=LABEL=os131p19 ipv6.disable=1 noresume splash=0 3 # set | grep LINES LINES=64 # fbset | grep ^mode mode "1280x1024" # on 22" 1680x1050 LCD # uname -a Linux gx280 3.12.51-2-desktop #1 SMP PREEMPT Sat Jan 16 00:25:03 UTC 2016 (08f7380) i686 i686 i386 GNU/Linux # grep FONT /etc/sysconfig/console CONSOLE_FONT="" # cat /proc/cmdline root=LABEL=os131p19 ipv6.disable=1 noresume splash=0 video=1024x768@60 3 # set | grep LINES LINES=48 # fbset | grep ^mode mode "1024x768" # uname -a Linux gx280 3.12.51-2-desktop #1 SMP PREEMPT Sat Jan 16 00:25:03 UTC 2016 (08f7380) i686 i686 i386 GNU/Linux # grep FONT /etc/sysconfig/console CONSOLE_FONT="" # cat /proc/cmdline root=LABEL=os131p19 ipv6.disable=1 noresume splash=0 video=1440x900@60 3 # set | grep LINES LINES=56 # fbset | grep ^mode mode "1440x900" # uname -a Linux gx280 3.12.51-2-desktop #1 SMP PREEMPT Sat Jan 16 00:25:03 UTC 2016 (08f7380) i686 i686 i386 GNU/Linux # grep FONT /etc/sysconfig/console CONSOLE_FONT="" # cat /proc/cmdline root=LABEL=os131p19 ipv6.disable=1 noresume splash=0 3 # set | grep LINES LINES=65 # fbset | grep ^mode mode "1680x1050" # uname -a Linux gx280 3.12.51-2-desktop #1 SMP PREEMPT Sat Jan 16 00:25:03 UTC 2016 (08f7380) i686 i686 i386 GNU/Linux # grep FONT /etc/sysconfig/console CONSOLE_FONT="sun12x22.psfu" # cat /proc/cmdline root=LABEL=os131p19 ipv6.disable=1 noresume splash=0 3 # set | grep LINES LINES=47 # fbset | grep ^mode mode "1680x1050" # uname -a Linux gx280 4.4.0-5.gb56b151-default #1 SMP Thu Jan 21 07:47:10 UTC 2016 (b56b151) i686 i686 i386 GNU/Linux # grep FONT /etc/sysconfig/console CONSOLE_FONT="sun12x22.psfu" # cat /proc/cmdline root=LABEL=os131p19 ipv6.disable=1 noresume splash=0 3 # set | grep LINES LINES=47 # fbset | grep ^mode mode "1680x1050" # uname -a Linux gx280 4.4.0-5.gb56b151-default #1 SMP Thu Jan 21 07:47:10 UTC 2016 (b56b151) i686 i686 i386 GNU/Linux # grep FONT /etc/sysconfig/console CONSOLE_FONT="lat9w-16.psfu" # cat /proc/cmdline root=LABEL=os131p19 ipv6.disable=1 noresume splash=0 3 # set | grep LINES LINES=65 # fbset | grep ^mode mode "1680x1050" -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/22/2016 09:18 PM, Felix Miata wrote:
and established that indeed, there are ONLY 48 lines of display on vt1. So why do I have LINES=64 Where is this being set?
Kernel maybe?
Does it behave differently if you boot a 13.1-specific kernel?
What's your complete kernel cmdline?
Is your video driver proprietary?
Is your /etc/sysconfig/console file original/unmodified from that in the rpm it belongs to?
I tried to replicate your dilemma without success:
I suspect this is a result of some change to the kernel as it happened even though I had changed nothing to do with any of the above. BOOT_IMAGE=/vmlinuz-4.4.0-5.gb56b151-default root=/dev/mapper/vgmain-vROOT resume=/dev/disk/by-label/SWAP splash=silent quiet showopts elevator=cfq vga=0x31a That last is to force the 1280x1024 for my monitor. I realise that "vga=" has been depreciated, but at the time it was the only way I could get grub and the inital boot to use the full screen. Getting X11 to use the full screen was a seperate issue and solved completely within the X11 config under /etc/X11/xorg.cong.d/ This is 13.1. I've been running with the same command line since I stabilized 13.1 shortly after it came out. The only oddity is that I'm using the repository KERNEL_STABLE http://download.opensuse.org/repositories/Kernel:/stable/standard/ If I recall, this odd behaviour came in somewhere with the 4.3 or 4.4 kernel. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-01-23 13:22, Anton Aylward wrote:
I realise that "vga=" has been depreciated, but at the time it was the only way I could get grub and the inital boot to use the full screen.
I still use vga=791 in one machine, it was the only incantation that worked properly. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 01/23/2016 08:57 AM, Carlos E. R. wrote:
On 2016-01-23 13:22, Anton Aylward wrote:
I realise that "vga=" has been depreciated, but at the time it was the only way I could get grub and the inital boot to use the full screen.
I still use vga=791 in one machine, it was the only incantation that worked properly.
Indeed. Back when I was in 11.x that's what it took to get the grub2 and the initial book to recognise the newly arrived 1280x1024 LG Flatron. Than and an extra set gfxmode=1280x1024 in grub.cfg As you say, it was the only incantation that worked properly. Well, not 'only' But that family and varying the colour depth ... So I've been playing around this weekend with the "command line" and now without any "vga=" at all it seems to .... if not "work properly" than I have a font I can live with and LINES=48 I emphasise that the "vga=" worked fine until kernel 4.3 or 4.4 I've tried looking through change logs but my google-savvy in this area is deficient. So far I've found nothing that shines light on all this. If anyone more familiar with the kernel change process can help, I'd be interested in hearing. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
24.01.2016 14:59, Anton Aylward пишет:
On 01/23/2016 08:57 AM, Carlos E. R. wrote:
On 2016-01-23 13:22, Anton Aylward wrote:
I realise that "vga=" has been depreciated, but at the time it was the only way I could get grub and the inital boot to use the full screen.
I still use vga=791 in one machine, it was the only incantation that worked properly.
Indeed. Back when I was in 11.x that's what it took to get the grub2 and the initial book to recognise the newly arrived 1280x1024 LG Flatron. Than and an extra set gfxmode=1280x1024 in grub.cfg As you say, it was the only incantation that worked properly. Well, not 'only' But that family and varying the colour depth ...
So I've been playing around this weekend with the "command line" and now without any "vga=" at all it seems to .... if not "work properly" than I have a font I can live with and LINES=48
I emphasise that the "vga=" worked fine until kernel 4.3 or 4.4
This is interpreted by vesafb. So it really sounds like different driver is used now. Can you upload dmesg output immediately after boot with "good" and "bad" kernels?
I've tried looking through change logs but my google-savvy in this area is deficient. So far I've found nothing that shines light on all this. If anyone more familiar with the kernel change process can help, I'd be interested in hearing.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata composed on 2016-01-21 13:41 (UTC-0500):
Felix Miata composed on 2016-01-18 01:41 (UTC-0500):
In previous reply I forgot to include suggestion to disable/remove Plymouth if you haven't already.
Anton Aylward composed on 2016-01-21 10:17 (UTC-0500):
Carlos E. R. composed on 2016-01-21 15:41 (UTC+0100):
Have you tried yet disabling plymouth on boot, or uninstall it (needs mkinitrd to apply)?
rpm -qa | grep plymouth plymouth-scripts-0.8.8_git201309032142-2.5.1.x86_64 plymouth-plugin-label-0.8.8_git201309032142-2.5.1.x86_64 plymouth-branding-openSUSE-13.1-10.4.13.noarch plymouth-plugin-script-0.8.8_git201309032142-2.5.1.x86_64 plymouth-0.8.8_git201309032142-2.5.1.x86_64
Oh, I wasn't aware I was running it! So how do I DISABLE it?
On Mageia, where attempting Plymouth uninstallation wants to uninstall nearly the whole OS, noplymouth on cmdline works. Maybe try plymouth=0 on cmdline if it that doesn't work for 13.1. On openSUSE, I taboo Plymouth at installation time so don't know how to "disable" it.
I just saw Andrei Borzenkov write in another thread here: plymouth.enable=0 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/18/2016 01:41 AM, Felix Miata wrote:
Anton Aylward composed on 2016-01-16 09:47 (UTC-0500):
The last kernel update seems to have killed of the ability to login at the virtual terminals (that is, all the switches to terminals using Ctl-Alt-Fn no longer produce login prompts). The graphical login still works.
Solution found yet? In previous reply I forgot to include suggestion to disable/remove Plymouth if you haven't already.
Right now I have normal sized fonts but for some reason the value of the LINES variable is set to 64. Because of a shellopt setting 'checkwinsize' being set, its no use me manually setting that value. This option is set in /etc/bash.bashrc. The terminal name is of tty1 'linux' and tset lines returns "64". Looking at /etc/termcap (OK its not terminfo) I don't see that the entry for 'linux' has a "#li" value of 64. There is a 'terminfo' decompiler utility called 'infocmp' It begins ... # infocmp linux # Reconstructed via infocmp from file: /usr/share/terminfo/l/linux linux|linux console, am, bce, ccc, eo, mir, msgr, xenl, xon, colors#8, it#8, ncv#18, pairs#64, acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260i\316j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376, bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l\E[?1c, clear=\E[H\E[J, cnorm=\E[?25h\E[?0c, cr=^M, the remainder is about positioning, key settings. No further "#" values. Again, I don't see anything saying there are 64 lines "pairs" is the number of colour combination pairs. On a slightly different tack .. The only thing I can find in 'bugs' is old, but seems ... sort of ... related https://bugzilla.kernel.org/show_bug.cgi?id=13249 Perhaps relevant. "dmesg|grep intel" shows [ 2.774044] fb: switching to inteldrmfb from VESA VGA [ 2.808423] fbcon: inteldrmfb (fb0) is primary device [ 2.903561] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R -
Carlos E. R. -
Felix Miata -
jdd -
Patrick Shanahan -
Yamaban