Recently Grub has been changing to a high resolution mode. On some systems this is really slow, presumably due to having a crap BIOS. On kvm/qemu systems it doesn't work with -display curses. How do I get grub to stick to 80x25 text? -- Sent from my Huawei Mate 9 with K-9 Mail.
On Fri, Dec 21, 2018 at 04:32:20PM +1100, Russell Coker wrote:
Recently Grub has been changing to a high resolution mode. On some systems this is really slow, presumably due to having a crap BIOS. On kvm/qemu systems it doesn't work with -display curses.
How do I get grub to stick to 80x25 text?
On Debian, Ubuntu etc, edit /etc/default/grub and 1. un-comment the line: GRUB_TERMINAL=console 2. optionally comment out the line starting with: GRUB_GFXMODE= (i can't remember if this is required or not. I think it isn't) 3. save & exit, run "update-grub" On non-debian machines, dunno. probably fuck around with files in /etc/grub.d/ BTW, for kvm you might also want to enable a serial console. I usually enable two serial consoles per VM, one to log the VM's boot up to a text file on the host, the other for console access with 'virsh console' (this is also how console access is provided in a javascript web by openstack and similar virtualisation wrapper systems). Remember to actually configure both grub and a getty (via inittab or systemd) to use the serial console as well as adding the console "hardware" to the VM. craig -- craig sanders <cas@taz.net.au>
On Saturday, 22 December 2018 2:04:46 AM AEDT Craig Sanders via luv-main wrote:
On Fri, Dec 21, 2018 at 04:32:20PM +1100, Russell Coker wrote:
Recently Grub has been changing to a high resolution mode. On some systems this is really slow, presumably due to having a crap BIOS. On kvm/qemu systems it doesn't work with -display curses.
How do I get grub to stick to 80x25 text?
On Debian, Ubuntu etc, edit /etc/default/grub and
1. un-comment the line:
GRUB_TERMINAL=console
Thanks for that, I did that, ran diff on /boot/grub/grub.cfg and found that the following 2 lines were the relevant ones: terminal_input console terminal_output console Knowing that I was able to Google how to do this in Nixos, which is to put the following in /etc/nixos/configuration.nix and run "nixos-rebuild switch". boot.loader.grub.extraConfig = "terminal_input console ; terminal_output console";
BTW, for kvm you might also want to enable a serial console. I usually enable two serial consoles per VM, one to log the VM's boot up to a text file on the host, the other for console access with 'virsh console' (this is also how console access is provided in a javascript web by openstack and similar virtualisation wrapper systems). Remember to actually configure both grub and a getty (via inittab or systemd) to use the serial console as well as adding the console "hardware" to the VM.
Currently I run my kvm VMs under screen and just use screen -r to get the console. Virsh has some benefits, but so far it hasn't seemed worth the pain. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Tue, Jan 08, 2019 at 11:51:33PM +1100, Russell Coker wrote:
Currently I run my kvm VMs under screen
sounds like a PITA doing everything manually...but whatever works for you.
and just use screen -r to get the console.
I strongly recommend switching to tmux. I stuck with screen for many years, been using it since the early 90s, but finally made the switch about a year ago...finally got sick of screen's bugs, quirks, piss-poor unicode support, and effective abandonment as an actively-developed project. it took me about half an hour to configure it so that the transition was non-traumatic. after a few days, i wouldn't even consider switching back, any more than i'd switch back from mutt to elm. As I did with screen, I've mapped tmux's escape key to ^K. I rarely use that for anything else but I use ^A all the time -- ^A is move to start of line in bash/readline, an extremely stupid key for screen to hijack as its default control prefix. tmux's default of ^B is better, but I've got used to ^K over the years. Unlearning that would be too painful.
Virsh has some benefits, but so far it hasn't seemed worth the pain.
for just "virsh console", no not worth it. for everything else - virsh and libvirt are definitely worth it. craig -- craig sanders <cas@taz.net.au>
On Thursday, 10 January 2019 2:57:02 AM AEDT Craig Sanders via luv-main wrote:
On Tue, Jan 08, 2019 at 11:51:33PM +1100, Russell Coker wrote:
Currently I run my kvm VMs under screen
sounds like a PITA doing everything manually...but whatever works for you.
Well it's a small ongoing PITA vs a major PITA to change to something else...
and just use screen -r to get the console.
I strongly recommend switching to tmux. I stuck with screen for many years, been using it since the early 90s, but finally made the switch about a year ago...finally got sick of screen's bugs, quirks, piss-poor unicode support, and effective abandonment as an actively-developed project. it took me about half an hour to configure it so that the transition was non-traumatic. after a few days, i wouldn't even consider switching back, any more than i'd switch back from mutt to elm.
People have been saying that for years. But what I do with screen is fairly basic so it's been working well enough that I haven't had a great incentive to change.
As I did with screen, I've mapped tmux's escape key to ^K. I rarely use that for anything else but I use ^A all the time -- ^A is move to start of line in bash/readline, an extremely stupid key for screen to hijack as its default control prefix. tmux's default of ^B is better, but I've got used to ^K over the years. Unlearning that would be too painful.
Yes, ^A is really annoying. But I don't use screen enough to make it worth changing.
Virsh has some benefits, but so far it hasn't seemed worth the pain.
for just "virsh console", no not worth it. for everything else - virsh and libvirt are definitely worth it.
I probably will do it eventually. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Thu, Jan 10, 2019, at 2:57 AM, Craig Sanders via luv-main wrote:
On Tue, Jan 08, 2019 at 11:51:33PM +1100, Russell Coker wrote:
Currently I run my kvm VMs under screen
sounds like a PITA doing everything manually...but whatever works for you.
and just use screen -r to get the console.
I strongly recommend switching to tmux. I stuck with screen for many years, been using it since the early 90s, but finally made the switch about a year ago...finally got sick of screen's bugs, quirks, piss-poor unicode support, and effective abandonment as an actively-developed project. it took me about half an hour to configure it so that the transition was non-traumatic. after a few days, i wouldn't even consider switching back, any more than i'd switch back from mutt to elm.
The one thing I miss from screen is built in zmodem capture. Okay, so this is a bit esoteric these days, and I guess I should not complain about it and instead send a patch to tmux :)
On Fri, Jan 11, 2019 at 10:48:54PM -0500, Stewart Smith wrote:
The one thing I miss from screen is built in zmodem capture. Okay, so this is a bit esoteric these days, and I guess I should not complain about it and instead send a patch to tmux :)
I'd forgotten that screen could even do that. It's been years since I even used zmodem, possibly decades. Seems you're not the first to miss it: https://github.com/tmux/tmux/issues/906 https://github.com/tmux/tmux/issues/1439 The responses so far have been "No way, this is not what tmux is for" and "tmux has nothing to do with uploading files". The response may be more positive if accompanied by a working patch :) If you're going to send a patch, I'd suggest making two generic features rather than hard-coding support for zmodem. 1. Add an ability to allow tmux to run a program and pipe the output into the terminal. e.g. run "rz" inside the terminal and then have tmux run "sz filename" to upload a file. This would have many other uses, like running "vi" in the terminal and typing "i" or "o" in vi, then having tmux run "cat filename". 2. Add an ability to pipe all input from the terminal into a command until that command terminates. e.g. run "sz filename" in the terminal and then have "tmux" run "rz". For programs like rz that are able to detect the end of their input, this isn't terribly complicated, but it would be much more complicated for programs that just keep on hoovering up stdin until stdin closes - e.g. "cat filename" inside the terminal while tmux runs "xsel -i". Another tmux command to manually close the input to the running external program would be clumsy but workable. 3. An obvious third feature would be programmable triggers to run commands. e.g. if tmux sees a particular sequence of characters, then run a particular program. e.g. "**B00000000000000" could trigger running "rz". I expect that this would probably be quite difficult, and would probably have a noticable impact on tmux's performance. BTW, there's an ssh wrapper called zssh: Package: zssh Depends: lrzsz, openssh-client | telnet | telnet-ssl, libc6 (>= 2.27), libreadline7 (>= 6.0) Description-en: interactive file transfers over ssh zssh (Zmodem SSH) is a program for interactively transferring files to a remote machine while using the secure shell (ssh). It is intended to be a convenient alternative to scp, allowing to transfer files without having to open another session and re-authenticate oneself. . Files are transferred through the zmodem protocol, using the rz and sz commands. Homepage: http://zssh.sourceforge.net/ The main benefit I can see (for either zssh, or zmodem support in tmux) is that due to firewalls, NAT, etc it's often MUCH hard to connect back to the origin host with scp or ftp or whatever, than it was to connect from the origin host to the remote host in the first place. OTOH, that's one of the uses for ssh port-forwarding. There's a Q&A on stackoverflow showing how to do it even from within your current ssh session (i.e. without having to set up port-forwarding when you started ssh) with ssh tilde commands. https://stackoverflow.com/questions/25482099/how-to-scp-back-to-local-when-i... craig -- craig sanders <cas@taz.net.au>
On Saturday, 12 January 2019 5:04:17 PM AEDT Craig Sanders via luv-main wrote:
I'd forgotten that screen could even do that. It's been years since I even used zmodem, possibly decades.
Seems you're not the first to miss it:
If you're going to send a patch, I'd suggest making two generic features rather than hard-coding support for zmodem.
1. Add an ability to allow tmux to run a program and pipe the output into the terminal. e.g. run "rz" inside the terminal and then have tmux run "sz filename" to upload a file. This would have many other uses, like running "vi" in the terminal and typing "i" or "o" in vi, then having tmux run "cat filename".
That is appealing.
2. Add an ability to pipe all input from the terminal into a command until that command terminates. e.g. run "sz filename" in the terminal and then have "tmux" run "rz".
For programs like rz that are able to detect the end of their input, this isn't terribly complicated, but it would be much more complicated for programs that just keep on hoovering up stdin until stdin closes - e.g. "cat filename" inside the terminal while tmux runs "xsel -i". Another tmux command to manually close the input to the running external program would be clumsy but workable.
3. An obvious third feature would be programmable triggers to run commands. e.g. if tmux sees a particular sequence of characters, then run a particular program. e.g. "**B00000000000000" could trigger running "rz". I expect that this would probably be quite difficult, and would probably have a noticable impact on tmux's performance.
I expect that in the common case of running screen/tmux on the same system as an X term the X display would use more CPU time anyway. I just did a quick test of running top while doing a fairly verbose compile with screen and couldn't see screen in top output. I did see konsole (the KDE X-term) taking up to 18% CPU time. I think there's plenty of scope to have a program like screen or tmux do pattern matching on output without comparing to the CPU use of konsole. I anticipate that someone might be about to say "but konsole sucks it uses too much CPU time". However konsole generally works well enough for me and many other people. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
participants (3)
-
Craig Sanders -
Russell Coker -
Stewart Smith