Where does a global startup command go?

mrmazda · 10-11-2018, 12:16 PM

Search here for keywords

Code:

global startup script

produced only an antique hit that long predates the existence of systemd.

I tried putting the "needed" command in:
/etc/rc.local
/etc/bash.bashrc.local

Neither work. What I need is actually a workaround to a problem unique to Ubuntu that I've never found a solution for, which is that in Ubuntu the shell's "blue" color for vttys is a baby blue instead of the standard blue equal to rgb(0,0,255) and ESC[44 ANSI. All I've been able to find to get the same blue as in any other distro I've ever used is

Code:

/etc/console-setup/vtrgb.vga

Can someone provide solution(s) or pointer to appropriate doc?

BW-userx · 10-11-2018, 12:46 PM

Ubuntutututu start ups systemd
https://askubuntu.com/questions/9190...-using-systemd

mrmazda · 10-12-2018, 12:35 AM

That URL generates 404, but based on it I found https://linuxconfig.org/how-to-autom...-systemd-linux and https://www.itechlounge.net/2017/10/...l-in-debian-9/. I tried including in /etc/systemd/system/rc-local.service as the latter directs, eventually including 4 WantedBy lines (instead of just one):

Code:

[Unit]
Description=/etc/rc.local
ConditionPathExists=/etc/rc.local

[Service]
Type=forking
ExecStart=/etc/rc.local start
StandardOutput=tty
RemainAfterExit=yes
TimeoutSec=0
SysVStartPriority=99

[Install]
WantedBy=getty.target
WantedBy=graphical.target
WantedBy=multi-user.target
WantedBy=sysinit.target

but it produces no satisfaction.

Code:

# systemctl status rc-local.service
rc-local.service - /etc/rc.local
  Loaded: loaded (/etc/systemd/system/rc-local.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/rc-local.service.d
           debian.conf
   Active: active (exited) since Fri 2018-10-12 01:20:05 EDT; 25s ago
  Process: 641 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS)

Oct 12 01:20:04 gx780 systemd[1]: Starting /etc/rc.local...
Oct 12 01:20:05 gx780 systemd[1]: Started /etc/rc.local

Following that up with 'systemctl start rc-local.service' does nothing, but following that with 'systemctl restart rc-local.service' works, as does running -rwxr-xr-x /etc/rc.local manually.

Maybe 16.04LTS is broken for this functionality?

ondoho · 10-12-2018, 02:04 AM

Quote:

Originally Posted by mrmazda

Search here for keywords

Code:

global startup script

produced only an antique hit that long predates the existence of systemd.

startup of what?
the system? that's init, and the mechanism your particular init system brings with it.
the shell? i think the best match is /etc/profile.
the GUI? various apporoaches exist. i use ~/.xinitrc before the window manager starts, or the wm/DE's own autostart mechanism.

Quote:

What I need is actually a workaround to a problem unique to Ubuntu that I've never found a solution for, which is that in Ubuntu the shell's "blue" color for vttys is a baby blue instead of the standard blue equal to rgb(0,0,255) and ESC[44 ANSI. All I've been able to find to get the same blue as in any other distro I've ever used is

Code:

/etc/console-setup/vtrgb.vga

i remember having played with that.
have you tried update-alternatives?

Code:

update-alternatives --all
update-alternatives --list newt-palette

mrmazda · 10-12-2018, 03:28 AM

Quote:

Originally Posted by ondoho

startup of what?

I want /etc/console-setup/vtrgb.vga to happen, or anything equivalent to it, such as removing whatever it is that usurps the vanilla kernel's default color palette.

Quote:

the system? that's init, and the mechanism your particular init system brings with it.
the shell? i think the best match is /etc/profile.

/etc/profile.local does such things in openSUSE, Fedora and Mageia, but apparently it does not in Debian and its derivatives.

Quote:

the GUI? various apporoaches exist. i use ~/.xinitrc before the window manager starts, or the wm/DE's own autostart mechanism.

anything in ~/ is user-specific. My interest is global, all users systemwide via a single configuration.

Quote:

i remember having played with that.
have you tried update-alternatives?

Code:

update-alternatives --all
update-alternatives --list newt-palette

Nice thought. /etc/newt contains 2 regular files, palette.original and (0 byte) palette.ubuntu, and a symlink to the latter from palette. Changing the symlink to the former using update-alternatives has no effect.

Stretch has only (0 byte) /etc/newt/palette.original, and same (desired) shade of blue on ttys as all other distros except *buntus.

ondoho · 10-12-2018, 11:32 AM

there are also other tty-related fields in update-alternatives; nothing helps?
i'm guessing a reboot is required each time.

mrmazda · 10-12-2018, 10:39 PM

Fixed via

Code:

update-alternatives --configure vtrgb

but no luck so far figuring out why libnewt exists, what uses it, or why this vtrgb alternative exists on Debians but not non-Debians, not to mention exists at all. There is no vtrgb package installed. On Stretch e.g, /etc/newt/ has only a single file palette.original of 0 bytes, while e.g. Xenial has that plus palette.ubuntu which only includes one color - magenta, which is nothing like baby blue or sky blue, 120° apart on a color wheel. There's also a symlink to palette.ubuntu: palette. The presence of libnewt, vtrgb and /etc/alternatives/vtrgb seems like no more than system bloat.

The problem caused by the *buntu vtgrb configuration is solved, but I'm going to have to do some experimenting before I can say the thread topic has been solved.

ondoho · 10-13-2018, 02:04 AM

good to hear.
keep us posted.

Quote:

Originally Posted by mrmazda

why this vtrgb alternative exists on Debians but not non-Debians

i think i can answer that one.
on my archlinux, there's a file /etc/vconsole.conf. this file is not present on any debian-based install afaics.

mrmazda · 10-13-2018, 02:28 AM

My sole Gentoo has neither. My openSUSE releases have vconsole.conf, but the only content is a KEYMAP=us line. openSUSE Tumbleweeds add FONT_MAP=trivial and FONT=lat9w16.psfu lines. Fedora 28 and Mageia 6 have two lines, keymap & font. Nothing about colors in any.

ondoho · 10-13-2018, 03:35 AM

Quote:

Originally Posted by mrmazda

Nothing about colors in any.

indeed, i might have been wrong there.
i have been using a special program to set the console colors at boot, and it reads colors from vconsole.conf.
have a look.
there doesn't seem to be an easier way.
maybe "vtrgb" is actually based on some software doing that?

you can add color values to the kernel command.

mrmazda · 10-13-2018, 04:16 AM

Around the beginning of my exposure to Linux I discovered

Code:

setterm --background blue --foreground white --blank 59 --bold on --store

in .bashrc did something I wanted, though sometimes .bashrc needed to be linked to .bash_profile and/or .profile. For a long time setterm worked cross-distro. As time went on, various devs and distributions decided to add low contrast colors to cmdline utilities to make them hard to use, and other dumb things that made them hard to use also in xterms, so my .bashrc setterm command morphed into something more convoluted. Mostly what I'm trying to do is recover the state of the vttys as of 20 years ago (limited to foreground, background, bold, blink), not "set" console colors, but unset colors other than those specified by setterm.

ondoho · 10-14-2018, 05:35 AM

the values for white, black etc. are defined either hardcoded in the kernel, or through the above mentioned parameters to the kernel command line.
after that, a program has to either do the same during runtime, or it can only use the abstract color names like red, white, cyan, black etc.

please understand that someone could hardcode "#ff0000" for white, and you would have to refer to it as white from then on, etc.

i'm not quite sure what ubuntu does there, it's perfectly possible this is hardcoded into their own kernels.
i would simply remove all ubuntu customisations from all console related setups (alternatives too) and hope it's not actually hardcoded.

if it is, i pointed out a nice little program i've been using for years.
or look at this:
https://superuser.com/questions/3140...soles-on-linux
https://askubuntu.com/questions/1474...the-tty-colors

looking at my Xubuntu vm, please try

Code:

find /etc -iname '*newt*' -o -iname '*vtrgb*' 2>/dev/null

and see what you see.

the files /etc/vtrgb and /etc/console-setup/vtrgb* look promising.

mrmazda · 07-30-2019, 12:10 AM

Quote:

Originally Posted by mrmazda

Fixed via

Code:

update-alternatives --configure vtrgb

Apparently I started this thread WRT a release older than 18.04.2, where that syntax generates a usage message. Instead is required:

Code:

update-alternatives --config vtrgb

and selecting /etc/console-setup/vtrgb.vga (option 2), or manually changing /etc/alternatives/vtrgb to point to /etc/console-setup/vtrgb.vga instead of /etc/console-setup/vtrgb, if global change is desired. It remains to be determined if and how it might be altered for any particular user.