Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemdandtimezone]
* On 2024 06 Jan 22:27 -0600, gene heskett wrote: > On 1/6/24 17:06, Nate Bargmann wrote: > > * On 2024 06 Jan 14:34 -0600, gene heskett wrote: > > > On 1/6/24 14:33, John Hasler wrote: > > > > Try manpages.org . > > > > > > That is downright tasty stuff, bookmarked, thank you John. > > > > For us Debian users a better choice would seem to be: > > > > https://manpages.debian.org/ > > The pages at manpages.org are better colored and a larger, much easier to > read font. Content I believe, was the same on the file I cheked. If so, you were fortunate to find a page that matched that installed on your system. The manpages.org link won't have pages for some third party packages that manpages.debian.org will. For example, the former does not have a page for 'hamlib' and the latter does. In Debian it is a bug if a package does not have a man page so you will find many more at the manpages.debian.org link. Also, the text size of a Web page can be increased with Ctrl-+ (works on Firefox and Chromium, likely others). - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: SOLVED FOR GENE
Nate Bargmann composed on 2024-01-07 05:04 (UTC-0600): > the text size of a Web page can be increased with Ctrl-+ (works on > Firefox and Chromium, likely others). Doing so is called a defensive response, something to be expected in response to (needless) offensive behavior. Browsers have default fonts selectable by users for good reason. Websites shouldn't be assuming user settings are wrong. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: SOLVED FOR GENE
On 7/1/24 19:37, Felix Miata wrote: Doing so is called a defensive response, something to be expected in response to (needless) offensive behavior. Browsers have default fonts selectable by users for good reason. Websites shouldn't be assuming user settings are wrong. Using Debian 12 I recently upgraded my monitor to a high pixel count model. Most websites became unreadable as the font size was then tiny. I won't go through the many steps I took to fix this, none of which was entirely successful, but I now mostly have the ability to read my screens using Firefox and Google Chrome with individual site settings as required
Re: SOLVED FOR GENE
On 1/7/24 13:00, jeremy ardley wrote: On 7/1/24 19:37, Felix Miata wrote: Please stop this unreadable pointless thread. -- John Doe
serial-getty@ttyS0.service does not start
Hello, I tried to start a serial console on ttyS0, but when I try to start the serial-getty service, it does not return: root@master:~# systemctl status serial-getty@ttyS0.service ○ serial-getty@ttyS0.service - Serial Getty on ttyS0 Loaded: loaded (/lib/systemd/system/serial-getty@.service; enabled; preset: enabled) Active: inactive (dead) Docs: man:agetty(8) man:systemd-getty-generator(8) https://0pointer.de/blog/projects/serial-console.html root@master:~# systemctl start serial-getty@ttyS0.service Printing kernel messages on the same console works flawless: rd@master:~$ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-6.1.0-17-amd64 root=/dev/mapper/master--vg-root ro console=tty0 console=ttyS0,115200n8 quiet rd@master:~$ Any hint or idea why the serial console is not working is welcome. Thanks Rainer -- Rainer Dorsch http://bokomoko.de/
Re: xfce screen detachment
Russell L. Harris wrote: > system: amd64 desktop, debian 12, xfce, NEC MultiSync EA192M monitor > > I don't know precisely how to describe the problem, other than > "detachment". About every week or so, when using the rodent, the > entire screen -- borders and all -- moves with respect to the monitor > screen as I move the mouse. > > The only recovery method I have discovered is to reboot. > > My hands and finders no longer are working well, so I likely clicked > on something or pressed a key to cause the problem. That sounds something like having an X11 screen larger than the monitor it is on, and X panning around that. Typically, though, panning requires the mouse to hit the border of the monitor. If that's what is happening, try right clicking-on the desktop to get the application menu, and run Settings => Desktop; then reset the resolution to what your monitor actually supports. You might also check if some key is being held down on your keyboard, or if your mouse buttons are misfiring. -dsr-
systemd-timesyncd
On 07/01/2024 02:17, gene heskett wrote: If debian is going to supply systemd's timesyncd as a client, I expected a bookworm install to just work. It did not and without docs I have to pester the list, which has gotten me a bad rep because the lack of docs for this stuff has me in a screw google frame of mind by the time I get around to asking the list. Lately, everytime I go anywhere near google or a gmail link I get attacked by a virus that calls itself norton antivirus. That is an oxymoron, like military intelligence. I have no idea what malware you have on your machines. systemd-timesyncd is a NTP-client, not a server. It is shipped with man pages and works out of the box (of course, if network is properly configured).
Re: systemd-timesyncd
Gene writes: > Lately, everytime I go anywhere near google or a gmail link I get > attacked by a virus that calls itself norton antivirus. Delete all your Firefox caches and upgrade Firefox. That phishing malware has nothing to do with Google or Norton. You acquired it by visiting an infected or malicious Web site. Quit using Google search. Use DuckDuckGo. -- John Hasler j...@sugarbit.com Elmwood, WI USA
Re: Possibly broken Grub or initrd after updates on Testing
On Thu 04 Jan 2024 at 19:49:43 (+0100), Richard Rosner wrote: > On 04.01.24 19:02, David Wright wrote: > > Could you post the new grub.cfg file, so that people running testing, > > and following along the thread later, can see how boot-repair fixed it? > > Keep in mind, this is based on the assumption that your whole / > partition is LUKS encrypted (in my case now LUKS2). > "root-partition-UUID" is the UUID that's shown in Disks or on the Grub > screen for the decryption password prompt. Now, I can't say for sure > what "root-partition-UUID2" is, but that's what seems to be symlinked > to /dev/dm-0 and with blkid, one of the entries will look like this: > > /dev/mapper/luks-: UUID="" > BLOCK_SIZE="4096" TYPE="ext4" > > So maybe it's just some kind of virtual UUID for the decrypted root > partition. (I would have thought that you'd know encrypted filesystems have UUIDs.) I compared your new grub.cfg with mine (suitably decimated and edited) and the significant differences are very few; extra modules are loaded: cryptodisk, luks2, gcry_rijndael, gcry_rijndael and gcry_sha256. Myset root='hd0,gpt5' is replaced by set root='cryptouuid/' and my --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-bar emetal=ahci0,gpt5 is replaced by hint='cryptouuid/' Unlike the first version of grub.cfg that you pasted earlier: cryptomount -u set root='cryptouuid/ there's no cryptomount in your new one. I'm guessing that means that the LUKS2 partition has been decrypted by Grub before grub.cfg is commanded. Do you now get just the one prompt for the passphrase when you boot? (I'm not very familiar with how far encrypted /boot has progressed.) The other difference in the earlier, pasted grub.cfg is that its linux line was extremely long, and looked as though a large amount of text had been added from GRUB_CMDLINE_LINUX_DEFAULT and/or GRUB_CMDLINE_LINUX, perhaps set in /etc/default/grub? I commented previously on the multiple root= parameters, and have also noticed that the recovery mode lines had "single" duplicated. I presume all that configuration stuff has gone away now. I passed over a couple of other, minor differences that probably don't affect things, like the pasted grub.cfg allowing for decrypting / to get at fonts in /usr/share/grub/, and the similar code (extra relative to mine) in 05_debian_theme for prettyfying the main Grub screen. I somehow doubt whether all this will be any help, as you're working well beyond my experience, and somewhere near the cutting edge of Grub. Cheers, David.
Re: systemd-boot not asking password, not resuming from hibernate
On Sat 06 Jan 2024 at 20:04:57 (+0100), Richard Rosner wrote: > I just tried out systemd-boot. What I noticed, it doesn't ask for my > decryption password to decrypt both my LUKS2 encrypted root and swap > partition. This kinda defeats the purpose of encrypted drives. How do > I have systemd-boot forget and never again remember my credentials? I'm assuming that when you boot, you do get /one/ prompt for your passphrase, and not zero. If it doesn't ask /again/ after that, then I'd guess that it's storing something somewhere. In the little I've read about this, I've come across a scheme where Grub writes an initrd file in memory and appends it to your main initrd(s) so that the kernel can read it later. > For the installation, I just installed systemd-boot. Afterward I had > to uncomment the timeout option in /boot/efi/loader/loader.conf so I > would get the selection screen, but I didn't make any other > modifications. So what exactly is missing? > > Adding to that, resume from hibernate doesn't seem to work. Resume is > included in the options line in the /boot/efi/loader/entries files, > it's also enabled in initramfs-tools, yet after powering on after > hibernating, I'm not greeted with where I left off. I don't use hibernation. I close down desktops because I can remotely boot them, and I leave laptops running as they consume trivial power. > PS: by any chance does anybody know if systemd-boot supports Argon2 > KDF for LUKS2? I only know that Grub2 doesn't (yet), but it's > difficult to find the specific documentation on systemd-boot. You probably need to follow appropriate lists if you want to stay up to date. Cheers, David.
Re: tzdata-legacy [was: Re: systemd and timezone]
On Sat 06 Jan 2024 at 02:57:53 (-0600), Nate Bargmann wrote: > * On 2024 06 Jan 01:00 -0600, Max Nikulin wrote: > > US/Eastern & Co has been moved to tzdata-legacy as well. Currently used > > identifiers are based on cities: America/New_York. > > Ugghhh! > > I guess I'll be going to the legacy package then until > $WHOEVER_IS_IN_CHARGE issues a decree that it too shall be eliminated. > I really don't get the fascination with some city hundreds of miles > distant defining the time zone. Until fairly recently there wasn't a $WHOEVER_IS_IN_CHARGE to issue the decree as Congress now does. A lot of the rules were made locally. > Why Chicago for US/Central? There are > any number of cities in US/Central that could be referenced, but no, > pick the most notorious one--rolls eyes. I don't know what your problem is with Chicago: it's merely the largest city in the area covered by the timezone. > I could even accept America/Central without complaint. Yeah, US is a > directory and Central is a symlink to ../America/Chicago that could be > manually added to a system if need be. States still have the right to decide whether to observe DST, just so long as any clock changes occur at the same time as everybody else. So it's conceivable that Texas could, for example, decide changing clocks is a waste of effort, and stay on one or the other all year. In which case, it's a simple matter to cater for that with the addition of an America/Houston timezone. Impossible to do that with America/Central; I think it's long overdue to recognise these old names as a legacy of earlier attempts to specify time zones. Historically, some of them (like Eastern) don't work anyway. Also it's doubly unfortunate, for non-Americans, that there's a region of the world called Central America. > Ambles off shaking fist at a cloud... Cheers, David.
Re: Possibly broken Grub or initrd after updates on Testing
On 07.01.24 18:07, David Wright wrote: I compared your new grub.cfg with mine (suitably decimated and edited) and the significant differences are very few; extra modules are loaded: cryptodisk, luks2, gcry_rijndael, gcry_rijndael and gcry_sha256. Myset root='hd0,gpt5' is replaced by set root='cryptouuid/' and my --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-bar emetal=ahci0,gpt5 is replaced by hint='cryptouuid/' Unlike the first version of grub.cfg that you pasted earlier: cryptomount -u set root='cryptouuid/ there's no cryptomount in your new one. I'm guessing that means that the LUKS2 partition has been decrypted by Grub before grub.cfg is commanded. Do you now get just the one prompt for the passphrase when you boot? (I'm not very familiar with how far encrypted /boot has progressed.) There was always only one prompt for the passphrase when boot was working on its own. Only if you had to manually decrypt all partitions, you'd need to enter it for every encrypted partition there is — probably because you don't necessarily need to have the same password for everything. There might be an option to have it reuse the key, but I have yet to find that. Also, that the cryptomount lines are missing must be why Grub was still a bit unreliable. I'll write my current grub.cfg in a separate message, as they are back now after some experiments with rEFInd, systemd-boot and trying to get resume from hibernation to work reliably. The other difference in the earlier, pasted grub.cfg is that its linux line was extremely long, and looked as though a large amount of text had been added from GRUB_CMDLINE_LINUX_DEFAULT and/or GRUB_CMDLINE_LINUX, perhaps set in /etc/default/grub? I commented previously on the multiple root= parameters, and have also noticed that the recovery mode lines had "single" duplicated. I presume all that configuration stuff has gone away now. Well, that bunch of text is necessary, since grub has to communicate the location of the root and the swap partitions to the kernel, so of course they are automatically included in the default/grub. The last one there is just a little fix for better handling very old Synaptic touchpads in Wayland. In my current grub.cfg the multiple root= entries in one line seem to be gone, but there are still multiple single in the recovery parts. I somehow doubt whether all this will be any help, as you're working well beyond my experience, and somewhere near the cutting edge of Grub. Just shows how hopelessly outdated Grub is and that it sorely needs a replacement — and a better experience in replacing it. Grub 2.12 was just released in December. On the other hand, LUKS was originally released in 2004, LUKS2 followed in 2018 and became the default with cryptsetup 2.1.0 in early 2019 — though Debian seems to ignore that, since the installer still by default creates LUKS1 volumes. Also, by default, LUKS2 uses Argon2 key derivation function — unsupported even by Grub 2.12. All this in a time when smartphones have been encrypted for years by default, so have MacBooks and even Windows is slowing making it a default. Not to mention the fact that Linux distributions are offering encryption in their installers for many years now, with a few even making it a default, like Pop.
Re: Possibly broken Grub or initrd after updates on Testing
On 04.01.24 19:49, Richard Rosner wrote:
On 04.01.24 19:02, David Wright wrote:
Could you post the new grub.cfg file, so that people running testing,
and following along the thread later, can see how boot-repair fixed it?
Cheers,
David.
Let's hope the mailing list let's this go through.
It did, but since it seems to have been malformed yet again, let's try
again.
Keep in mind, this is based on the assumption that your whole /
partition is LUKS encrypted (in my case now LUKS2). "root partition
UUID1" is the UUID that's shown in Disks or on the Grub screen for the
decryption password prompt. Now, I can't say for sure what
"root-partition-UUID2" is, but that's what seems to be symlinked to
/dev/dm-0 and with blkid, one of the entries will look like this:
/dev/mapper/luks-: UUID=""
BLOCK_SIZE="4096" TYPE="ext4"
So maybe it's just some kind of virtual UUID for the decrypted root
partition.
Adding to that, "root partition UUID1.1" is basically the same as
UUID1.1, just without dashes. So it's the same format as Grub shows for
the ususal bootup password prompt. Let's hope this time this is the
right one.
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
cryptomount -u
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'
else
search --no-floppy --fs-uuid --set=root
fi
font="/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
cryptomount -u
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'
else
search --no-floppy --fs-uuid --set=root
fi
insmod png
if background_image
/usr/share/desktop-base/emerald-theme/grub/grub-4x3.png; then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class
gnu --class os $menuentry_id_option 'gnulinux-simple-UUID2>' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
cryptomount -u
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'
else
search --no-floppy --fs-uuid --set=root
fi
echo 'Loading Linux 6.5.0-5-amd64 ...'
linux /boot/vmlinuz-6.5.0-5-amd64 root=UUID=UUID2> ro quiet root=/dev/mapper/luks- splash
resume=/dev/mapper/luks-
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-6.5.0-5-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-' {
menuentry 'Debian GNU/Linux, with Linux 6.5.0-5-amd64' --class
debi
Re: systemd-boot not asking password, not resuming from hibernate
On 07.01.24 18:07, David Wright wrote: On Sat 06 Jan 2024 at 20:04:57 (+0100), Richard Rosner wrote: I just tried out systemd-boot. What I noticed, it doesn't ask for my decryption password to decrypt both my LUKS2 encrypted root and swap partition. This kinda defeats the purpose of encrypted drives. How do I have systemd-boot forget and never again remember my credentials? I'm assuming that when you boot, you do get /one/ prompt for your passphrase, and not zero. If it doesn't ask /again/ after that, then I'd guess that it's storing something somewhere. Nope, there's absolutely none. It just boots straight into the system, just as I said. Hence, I literally named this topic "systemd-boot *not asking* password". If it wouldn't ask again, that would just be the as expected behavior you'll also get from Grub. It makes no sense to ask for every encrypted partition when the passphrase is the same. In the little I've read about this, I've come across a scheme where Grub writes an initrd file in memory and appends it to your main initrd(s) so that the kernel can read it later. I kinda doubt that, like a lot. Maybe update-initramfs does pull in information from the Grub config, but otherwise there's no indication to that. It does pass parameters you put into the /etc/default/grub to the Kernel though. For the installation, I just installed systemd-boot. Afterward I had to uncomment the timeout option in /boot/efi/loader/loader.conf so I would get the selection screen, but I didn't make any other modifications. So what exactly is missing? Adding to that, resume from hibernate doesn't seem to work. Resume is included in the options line in the /boot/efi/loader/entries files, it's also enabled in initramfs-tools, yet after powering on after hibernating, I'm not greeted with where I left off. I don't use hibernation. I close down desktops because I can remotely boot them, and I leave laptops running as they consume trivial power. Good for you, not my use case. PS: by any chance does anybody know if systemd-boot supports Argon2 KDF for LUKS2? I only know that Grub2 doesn't (yet), but it's difficult to find the specific documentation on systemd-boot. You probably need to follow appropriate lists if you want to stay up to date. That's just how not to do things. Software should be well documented, otherwise it should be replaced by something that is. Systemd replaced SysV Init as a service starter because it was much easier to handle and not just a pile of historical garbage nobody understands anymore. The same should be kept for other systemd services.
OT: coloured text?
Hi folks, just a short question, please allow me to ask: How can I get coloured text output in a shell script? I am using: echo "my text bla" As far as I read and understood, this is not possible in every shell. I found nothing in bash manual for example. Debian is using "dash" and not "bash", if I am correct, and with using the shebang line :!/bin/sh it is using dash, am I correct? If I want coloured text, which shell do I have to use and what is the syntax then within the shell script? I searched the web, but could not find a clear answer to this. Thanks for a short answer. Best regards Hans
Re: OT: coloured text?
On Sun, Jan 07, 2024 at 07:40:28PM +0100, Hans wrote:
> How can I get coloured text output in a shell script?
https://mywiki.wooledge.org/BashFAQ/037
> Debian is using "dash" and not "bash", if I am correct,
Debian installs BOTH of them by default.
Also by default, the /bin/sh symbolic link points to dash, rather
than to bash. But this should not matter to you.
> shebang line :!/bin/sh it is using dash, am I correct?
You mean #!/bin/sh of course. When selecting a shebang, you do so
based on which shell's syntax and features you are using in your
script.
If you're using bash syntax, then your shebang should be #!/bin/bash .
If you are NOT using any bash syntax or features, but strictly POSIX sh,
then you may use #!/bin/sh as your shebang.
The shebang tells the kernel which shell to execute to interpret your
script. So, you match it up to whichever shell you're writing for.
> If I want coloured text, which shell do I have to use and what is the syntax
> then within the shell script?
The wiki page has examples for both Bourne shell (which is a subset of
POSIX sh) and bash.
The approach I would take depends on how you're using colors in your
script. Are you only doing them inside one function which writes an
error message and exits? In this case, you might just use the tput
commands interleaved with printf or echo commands, as shown in the
first example.
If you're going to write *lots* of colored lines, you might choose to
store the escape sequences in global variables, and use them within
the function(s) that write colored messages. Something like:
Program='MyProgram'
Red=$(tput setaf 1)
Normal=$(tput sgr0)
error() {
printf 1>&2 '%s: %s%s%s\n' "$Program" "$Red" "$*" "$Normal"
}
All of this syntax is POSIX sh compatible, by the way.
Re: OT: coloured text?
On Sun, Jan 7, 2024 at 12:41 PM Hans wrote:
> Hi folks,
>
> just a short question, please allow me to ask:
>
> How can I get coloured text output in a shell script?
>
> I am using:
>
> echo "my text bla"
>
> As far as I read and understood, this is not possible in every shell. I
> found
> nothing in bash manual for example.
>
> Debian is using "dash" and not "bash", if I am correct, and with using the
> shebang line :!/bin/sh it is using dash, am I correct?
>
> If I want coloured text, which shell do I have to use and what is the
> syntax
> then within the shell script?
>
> I searched the web, but could not find a clear answer to this.
>
> Thanks for a short answer.
>
> Best regards
>
> Hans
>
>
>
"sh" is probably "/usr/bin/sh" ("$ command -v sh" or the (now-deprecated?)
"which sh" will show you which "sh" is being called), which is probably a
symlink to "dash" ("ls -lah " will show that to you).
But not necessarily.
Perhaps one of the easiest ways to get color in a bash/dash/sh shell is to
use ANSI Terminal Escape Sequences. Not 100% portable, but probably
suitable for what you want.
Something like:
#!/bin/env sh
printf "\033[31m"
printf "Now we're printing in Red\n"
printf "\033[0m"
printf "Now we're printing in the system default color.\n"
--
Kent West<")))><
IT Support / Client Support
Abilene Christian University
Westing Peacefully - http://kentwest.blogspot.com
Re: OT: coloured text?
On 7 Jan 2024 14:03 -0500, from g...@wooledge.org (Greg Wooledge): > The shebang tells the kernel which shell to execute to interpret your > script. So, you match it up to whichever shell you're writing for. Or perhaps rather which interpreter to use to execute the file. Examples of shebang lines which aren't for "shells" in the traditional sense might be: #!/usr/sbin/nft -f #!/usr/bin/env python3 #!/usr/bin/perl or if you are feeling evil... :-) #!/bin/sed -e 1d -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: OT: coloured text?
On Sun, Jan 07, 2024 at 07:12:38PM +, Michael Kjörling wrote: > On 7 Jan 2024 14:03 -0500, from g...@wooledge.org (Greg Wooledge): > > The shebang tells the kernel which shell to execute to interpret your > > script. So, you match it up to whichever shell you're writing for. > > Or perhaps rather which interpreter to use to execute the file. "Interpreter" is the traditional word for the program executed by the kernel, yes. > Examples of shebang lines which aren't for "shells" in the traditional > sense might be: > > #!/usr/sbin/nft -f > > #!/usr/bin/env python3 > > #!/usr/bin/perl Python and perl are both scripting languages. I don't know what nft is. > or if you are feeling evil... :-) > > #!/bin/sed -e 1d This is not a valid shebang. You're only permitted ONE argument after the interpreter name. You're going to execute /bin/sed '-e 1d' 'filename' with this.
Re: OT: coloured text?
On 7 Jan 2024 14:20 -0500, from g...@wooledge.org (Greg Wooledge): >> Examples of shebang lines which aren't for "shells" in the traditional >> sense might be: >> >> #!/usr/sbin/nft -f >> >> #!/usr/bin/env python3 >> >> #!/usr/bin/perl > > Python and perl are both scripting languages. I don't know what nft is. Yes, they are, but they are not typically used as interactive shells. nft is nftables. >> or if you are feeling evil... :-) >> >> #!/bin/sed -e 1d > > This is not a valid shebang. You're only permitted ONE argument after > the interpreter name. You're going to execute /bin/sed '-e 1d' 'filename' > with this. Okay, fair point. In my defense, I tried it and it worked. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
Richard Rosner wrote: > So, since for whatever reason Grub seems to be broken beyond repair, I > today tried to just replace it with rEFInd. Installation succeeded > without any trouble. But when I start my system, rEFInd just asks me if > I want to boot with fwupd or with the still very broken Grub. Am I > missing something? Is rEFInd really just something to select between > different OSs (and not just different distributions like Grub can very > well do) and then gives the rest over to their bootloaders or am I > missing something so rEFInd will take over all of Grubs jobs? ... i don't do encryption or raid so i keep things pretty simple. i've been using refind for years without issues. i also have grub installed so if either of them breaks the other is still likely going to work. i've also set it up so that each can be reached from the other through their menus. i see you've solved your issue, but i just wanted to point out that it works and is ok for people who want to try it out. songbird
Re: OT: coloured text?
On Sun, Jan 07, 2024 at 07:28:12PM +, Michael Kjörling wrote: > On 7 Jan 2024 14:20 -0500, from g...@wooledge.org (Greg Wooledge): > >> #!/bin/sed -e 1d > > > > This is not a valid shebang. You're only permitted ONE argument after > > the interpreter name. You're going to execute /bin/sed '-e 1d' 'filename' > > with this. > > Okay, fair point. In my defense, I tried it and it worked. unicorn:~$ seq 5 | sed '-e 1d' 2 3 4 5 Hmm... my first thought was that GNU sed is being lenient here, but on further reflection I'm not sure about that. This is equivalent to sed -e ' 1d' (with a leading space in front of the script which is the option-argument of -e). And perhaps sed permits leading whitespace in each line of its scripts, for purposes of readability. In any case, trying to put multiple arguments on the shebang won't work in general. It's a well-known behavior, and is why GNU env(1) has -S.
Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
On 07.01.24 20:33, songbird wrote: i see you've solved your issue, but i just wanted to point out that it works and is ok for people who want to try it out. Says who?
Re: systemd-timesyncd
On 1/7/24 10:48, Max Nikulin wrote: On 07/01/2024 02:17, gene heskett wrote: If debian is going to supply systemd's timesyncd as a client, I expected a bookworm install to just work. It did not and without docs I have to pester the list, which has gotten me a bad rep because the lack of docs for this stuff has me in a screw google frame of mind by the time I get around to asking the list. Lately, everytime I go anywhere near google or a gmail link I get attacked by a virus that calls itself norton antivirus. That is an oxymoron, like military intelligence. I have no idea what malware you have on your machines. systemd-timesyncd is a NTP-client, not a server. It is shipped with man pages and works out of the box (of course, if network is properly configured). Is it supposed to be installed by the net-installer? There does not seem to be any man pages other than the bog std stuff. When I found the /etc/systemd/timesyncd I immediately asked the system for man timesyncd, got this: gene@coyote:/etc$ man timesyncd No manual entry for timesyncd So one of the first things I did, after getting an orca-less install ( that took about 26 installs before someone said I had to unplug ALL my usb stuff which other than keyboard/mouse buttons I did leave plugged in because the only other stuff I had here was ps2 based, finally getting an orca-less install, all the other installs were because bookworm with orca removed by removing the exec bits of the executables because apt wouldn't purge it, will not reboot without them forcing a reinstall any time I had to reboot) and getting t-bird setup so I could do email was to install ntpsec, which can be a server. and worked as a client OOTB. Even if timesyncd might have worked, its not a server as you note. But if there are man pages on timesyncd, that is not what they are named. Now I decide to use this ntpsec install as a server to the rest of my systems here, thereby unloading the debian pool a bit, and the lack of docs bytes me again. I'm playing the 10,000 monkeys re-writing Shakespear scene here and catching it for not using google, and got the help I needed from John's post to look at manpages.org. And that seems to have started another endless thread I'll get blamed for. My lack of man pages has been asked, and ignored before, so I'll ask again: What package contains the manpages for a bookworm amd64 install I expect to do anything I might want to do? Take care, stay warm, well, and unvaxed. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: systemd-timesyncd
On 1/7/24 11:24, John Hasler wrote: Gene writes: Lately, everytime I go anywhere near google or a gmail link I get attacked by a virus that calls itself norton antivirus. Delete all your Firefox caches and upgrade Firefox. That phishing malware has nothing to do with Google or Norton. You acquired it by visiting an infected or malicious Web site. Quit using Google search. Use DuckDuckGo. checkrootkit and rkhunter aren't finding anything. FF caches, can they be cleaned w/o loosing bookmarks? And I do use ddg when I can. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: systemd-timesyncd
On Sun, Jan 07, 2024 at 02:51:26PM -0500, gene heskett wrote: > On 1/7/24 10:48, Max Nikulin wrote: > > On 07/01/2024 02:17, gene heskett wrote: > > > Is it supposed to be installed by the net-installer? There does not seem to > be any man pages other than the bog std stuff. When I found the > /etc/systemd/timesyncd I immediately asked the system for man timesyncd, got > this: > gene@coyote:/etc$ man timesyncd > No manual entry for timesyncd > > > What package contains the manpages for a bookworm amd64 install I expect to > do anything I might want to do? > apt install manpages (as noted in a message above earlier in the thread). > Take care, stay warm, well, and unvaxed. > ^^^ Gene - no partisan opinions, please, as per Code of Conduct? All best, as ever, Andy > Cheers, Gene Heskett. > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author, 1940) > If we desire respect for the law, we must first make the law respectable. > - Louis D. Brandeis >
Re: systemd-timesyncd
Hi Gene, Am 07.01.2024 um 20:51 schrieb gene heskett: On 1/7/24 10:48, Max Nikulin wrote: ... systemd-timesyncd is a NTP-client, not a server. It is shipped with man pages and works out of the box (of course, if network is properly configured). Is it supposed to be installed by the net-installer? There does not seem to be any man pages other than the bog std stuff. When I found the /etc/systemd/timesyncd I immediately asked the system for man timesyncd, got this: gene@coyote:/etc$ man timesyncd No manual entry for timesyncd I can not even guess what you did with your installation... here, boring bookworm installation, not caring much about which ntp software I use: $ apropos timesyncd systemd-timesyncd (8) - Synchronisierung der Netzwerkzeit systemd-timesyncd.service (8) - Synchronisierung der Netzwerkzeit timesyncd.conf (5) - Konfigurationsdateien für die Netzwerkzeitsynchronisierung timesyncd.conf.d (5) - Konfigurationsdateien für die Netzwerkzeitsynchronisierung Of course all in German here with my desktop. I'll not comment time zone settings or vaccinations, but I find many things that seem execeptionally difficult for you to just work for me. Cheers, Arno -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück
Trouble with OpenSMTPD
Folks: I'm running Debian Bookworm, and looking to switch from Exim4 to OpenSMTPd. Here is my smtpd.conf file: --- table aliases file:/etc/aliases table secrets file:/etc/secrets listen on lo listen on eno1 # action name method options action "local" mda maildrop virtual action "relay" relay host smtp+tls://pa...@smtp.dreamhost.com auth match from any for domain "yosemite.mars.lan" action "local" match for local action "local" match for any action "relay" --- For reason(s) I don't understand, opensmtpd will not start via "systemctl start opensmtpd". According to "sudo smtpd -n", the configuration file passes, but it just won't start. (For what it's worth, I've used this config back in 2021 running Debian and it worked.) I'm happy to supply whatever data needed in helping to resolve this. Paul -- Paul M. Foster Personal Blog: http://noferblatz.com Company Site: http://quillandmouse.com Software Projects: https://gitlab.com/paulmfoster
Re: systemd-timesyncd
On Sun, 7 Jan 2024 20:36:12 + "Andrew M.A. Cater" wrote: > > Take care, stay warm, well, and unvaxed. > > ^^^ > > Gene - no partisan opinions, please, as per Code of Conduct? Oh, come on! Just because Gene doesn't like certain ancient Digital Equipment products…? -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Trouble with OpenSMTPD
On Sun, 7 Jan 2024 17:36:12 -0500 Paul M Foster wrote: > For reason(s) I don't understand, opensmtpd will not start via > "systemctl start opensmtpd". According to "sudo smtpd -n", the > configuration file passes, but it just won't start. Have you looked to see what systemd has to say? After running "systemctl start opensmtpd", run "systemctl status opensmtpd". You may also find "journalctl -b -u opensmtpd" useful. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
bookworm No printer, No sound
nmap finds printer ,printer ip lan address. with lan address printer's state can be read and test page printed Cups can install printer with a long ipp address, not wifi. Only the lpinfo command works, the others are deprectiated, not working so it is not possible to set an lp destination. xsane finds no devices gnome settings sound finds output device Speakers - Built-in audio pulseaudio volume port shows Speakers (plugged in) Both these show a fluctuating signal when mpv plays an audio file but speakers are silent uname -a shows Debian 6.1.0-amd64 (2023-12--2) This does not change after update and dist-upgrade. Any comments welcomed, Tom George
Re: systemd-timesyncd
On Sun, Jan 7, 2024, 4:51 PM Charles Curley wrote: > On Sun, 7 Jan 2024 20:36:12 + > "Andrew M.A. Cater" wrote: > > > > Take care, stay warm, well, and unvaxed. > > > ^^^ > > > > Gene - no partisan opinions, please, as per Code of Conduct? > > Oh, come on! Just because Gene doesn't like certain ancient Digital > Equipment products…? > Come on There has to be a linux-based VAX simulator somewhere out there for Gene :-D So he can practice getting VAXed... :-D said the man who used to use LSI-11's :-D -- > Does anybody read signatures any more? > > https://charlescurley.com > https://charlescurley.com/blog/ > >
VAX emulation/simulation (was Re: systemd-timesyncd)
On 2024-01-07 at 19:20, Nicholas Geovanis wrote: > On Sun, Jan 7, 2024, 4:51 PM Charles Curley > wrote: > >> On Sun, 7 Jan 2024 20:36:12 + >> >> "Andrew M.A. Cater" wrote: >>> Gene - no partisan opinions, please, as per Code of Conduct? >> >> Oh, come on! Just because Gene doesn't like certain ancient Digital >> Equipment products…? >> > > Come on There has to be a linux-based VAX simulator somewhere out there > for Gene :-D > So he can practice getting VAXed... :-D > said the man who used to use LSI-11's :-D $ apt-cache show simh Package: simh [...] Description-en: Emulators for 33 different computers This is the SIMH set of emulators for 33 different computers: [...] DEC VAX (but cannot include the microcode due to copyright) No idea whether it'd be enough, but if anyone does actually want to pursue the idea, it might be worth looking at. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: systemd-timesyncd
On 08/01/2024 02:51, gene heskett wrote: When I found the /etc/systemd/timesyncd I immediately asked the system for man timesyncd, got this: gene@coyote:/etc$ man timesyncd No manual entry for timesyncd Isn't it /etc/systemd/timesyncd.conf, not /etc/systemd/timesyncd? It might be a reason why systemd-timesyncd did not follow configuration. Did looked into this file? On Debian 12 bookworm it contains (I have no idea concerning modification by Chinese 3d printers manufacturers on the top of Debian-derivatives): # See timesyncd.conf(5) for details. I do not see any problem with the /etc/systemd/timesyncd.conf file documented in "man timesyncd.conf". Besides appropos(1) (or "man -k") and "systemctl help" already mentioned in this thread, there are another ways dpkg -S /etc/systemd/timesyncd.conf systemd-timesyncd: /etc/systemd/timesyncd.conf dpkg -L systemd-timesyncd | grep /man/ /usr/share/man/man5 /usr/share/man/man5/timesyncd.conf.5.gz /usr/share/man/man8 /usr/share/man/man8/systemd-timesyncd.service.8.gz /usr/share/man/man5/timesyncd.conf.d.5.gz /usr/share/man/man8/systemd-timesyncd.8.gz These tools do not rely on remote content and should work even if a twisted pair cable has a degraded hot magenta wire. Certainly arbitrary failures may be expected if Chrome has stolen port 80 and Firefox is under an attack of an antivirus.
Re: Change suspend type from kde menu
On 07/01/2024 12:44, Max Nikulin wrote: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm Instead of tricks with setting proper context for a process executed system-wide, I would consider a process running in user sessions and listening for D-Bus events: $ dbus-monitor --system "type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" dbus-monitor: unable to enable new-style monitoring: org.freedesktop.DBus.Error.AccessDenied: "Rejected send message, 1 matched rules; type="method_call", sender=":1.1080" (uid=1000 pid=48803 comm="dbus-monitor --system type='signal',interface='org") interface="org.freedesktop.DBus.Monitoring" member="BecomeMonitor" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)". Falling back to eavesdropping. signal time=1704679328.754948 sender=org.freedesktop.DBus -> destination=:1.1080 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.1080" signal time=1704679441.870349 sender=:1.6 -> destination=(null destination) serial=3187 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean true signal time=1704679448.065409 sender=:1.6 -> destination=(null destination) serial=3233 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false A tiny python script may be more convenient than dbus-monitor and similar tools.
Re: systemd-timesyncd
On 08/01/2024 03:36, Andrew M.A. Cater wrote: On Sun, Jan 07, 2024 at 02:51:26PM -0500, gene heskett wrote: gene@coyote:/etc$ man timesyncd No manual entry for timesyncd What package contains the manpages for a bookworm amd64 install I expect to do anything I might want to do? apt install manpages (as noted in a message above earlier in the thread). Just to avoid possible confusion. Installing of the manpages package will not make man pages for all debian packages available locally. E.g. systemd-timesyncd(8) is shipped in the systemd-timesyncd package. It is great that https://manpages.debian.org exists and allows to read docs before installing a package.
Re: systemd-timesyncd
On Mon, 8 Jan 2024 10:02:25 +0700 Max Nikulin wrote: > Isn't it /etc/systemd/timesyncd.conf, not /etc/systemd/timesyncd? It > might be a reason why systemd-timesyncd did not follow configuration. It is indeed /etc/systemd/timesyncd.conf. However, there is also /etc/systemd/timesyncd.conf.d/, so one may drop local configurations into place without mucking in timesyncd.conf. Since systemd-timesyncd provides /etc/systemd/timesyncd.conf, changes to it will likely be overwritten on the next upgrade to systemd-timesyncd. I have: root@jhegaala:~# ls /etc/systemd/timesyncd.conf.d/ 50localTimeServers.conf root@jhegaala:~# cat /etc/systemd/timesyncd.conf.d/50localTimeServers.conf [Time] NTP=192.168.100.12 192.168.100.6 # File of local time servers provided via DHCP and 60ntp. root@jhegaala:~# 60ntp is my own script which picks up time servers from DHCP information and which is run by Network Manager. This machine is a laptop. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: systemd-timesyncd
> Quit using Google search. Use DuckDuckGo. Use StartPage instead, aka ixquick.com -- System Information GTK 3.24.39 / GLib 2.78.3 Locale: en_US.UTF-8 (charset: UTF-8) Operating System: Linux 6.6.9-amd64 (x86_64)
Re: xfce screen detachment
Dan Ritter wrote: > Russell L. Harris wrote: > > system: amd64 desktop, debian 12, xfce, NEC MultiSync EA192M monitor [...] > That sounds something like having an X11 screen larger than the > monitor it is on, and X panning around that. Typically, though, > panning requires the mouse to hit the border of the monitor. > > If that's what is happening, try right clicking-on the desktop > to get the application menu, and run Settings => Desktop; then > reset the resolution to what your monitor actually supports. FWIW, I've noticed that Xfce eventually gets confused about the settings for my display. I don't know what triggers it, but I'll suddenly notice that the display has gone from 1920x1200 to 1920x1080. Resetting it works (under Display, not Desktop). I don't see the problem with MATE, KDE, Cinnamon, or i3. This is on Debian 11, amd64 desktop (radeon 3000 video), Acer 23" monitor. regards, mike
Re: xfce screen detachment
On Sun, Jan 07, 2024 at 09:32:55PM -0800, Mike Kupfer wrote: Dan Ritter wrote: Russell L. Harris wrote: > system: amd64 desktop, debian 12, xfce, NEC MultiSync EA192M monitor [...] That sounds something like having an X11 screen larger than the monitor it is on, and X panning around that. Typically, though, panning requires the mouse to hit the border of the monitor. If that's what is happening, try right clicking-on the desktop to get the application menu, and run Settings => Desktop; then reset the resolution to what your monitor actually supports. FWIW, I've noticed that Xfce eventually gets confused about the settings for my display. I don't know what triggers it, but I'll suddenly notice that the display has gone from 1920x1200 to 1920x1080. Resetting it works (under Display, not Desktop). I don't see the problem with MATE, KDE, Cinnamon, or i3. This is on Debian 11, amd64 desktop (radeon 3000 video), Acer 23" monitor. I opened the display settings, but whatever I did did not correct the problem. The next time it happens I try display settings again and pay closer attention. Thanks. RLH
Re: Debian on Asus X205TA [Was: Re: Installing Debian on an old Asus EEE PC]
Am 06.01.2024 um 17:44:41 Uhr schrieb Steve McIntyre: > The amd64 installation media now includes the bits needed to start the > installer on mixed-mode UEFI systems like the Bay Trail platform in > the X205TA. Is that documented anywhere? I haven't found any information on this. The wiki only mentions multi-arch images. https://wiki.debian.org/UEFI#A32-bit_x86_PC_.28i386.29_support_for_UEFI
Re: xfce screen detachment
On 2024-01-07 04:00, Russell L. Harris wrote: system: amd64 desktop, debian 12, xfce, NEC MultiSync EA192M monitor I don't know precisely how to describe the problem, other than "detachment". About every week or so, when using the rodent, the entire screen -- borders and all -- moves with respect to the monitor screen as I move the mouse. The only recovery method I have discovered is to reboot. My hands and finders no longer are working well, so I likely clicked on something or pressed a key to cause the problem. RLH I get this effect if pressing Alt and moving the mouse wheel. mick
Re: Debian on Asus X205TA [Was: Re: Installing Debian on an old Asus EEE PC]
On Mon, Jan 08, 2024 at 08:21:00AM +0100, Marco Moock wrote: > Am 06.01.2024 um 17:44:41 Uhr schrieb Steve McIntyre: > > > The amd64 installation media now includes the bits needed to start the > > installer on mixed-mode UEFI systems like the Bay Trail platform in > > the X205TA. > > Is that documented anywhere? > I haven't found any information on this. > > The wiki only mentions multi-arch images. > https://wiki.debian.org/UEFI#A32-bit_x86_PC_.28i386.29_support_for_UEFI > This was in the release notes for Debian 12 at some point. I have fixed the wiki, noting that as at 2023 there are almost no 32 bit machines that boot UEFI and that the AMD64 media contains the appropriate software for both 32 bit and 64 bit UEFI implementations. All the best, as ever, Andy (amaca...@debian.org)
