Re: Strange syslog behaviour [Solved]
On Sat 15 Oct 2022 at 13:59:18 (-0400), Wayne Sallee obfuscated the following with HTML: > Jeremy Ardley, did you update your code from " invoke-rc.d rsyslog rotate > > /dev/null" to > "/usr/lib/rsyslog/rsyslog-rotate"? I've added a new post to that part of the thread. I think your problem concerns changing to systemd, whereas his concerns mixing inetdutils-* packages with the more usual equivalent ones. > So I got my servers straitened out, I think. I will know tomorrow. > For anyone else running into this problem, the problem was caused from > modifying > /etc/logrotate.d/rsyslog then upgrading to Buster. > The fix: > diff /etc/logrotate.d/rsyslog.dpkg-dist /etc/logrotate.d/rsyslog > edit /etc/logrotate.d/rsyslog > Change from > invoke-rc.d rsyslog rotate > /dev/null > to > /usr/lib/rsyslog/rsyslog-rotate > Then delete /etc/logrotate.d/rsyslog.dpkg-dist > I then rebooted my servers to get the syslog used. > Then > ls /var/log | grep syslog > To see that it was working. I will know tomorrow if it is still working. I think the point you've missed is that at some stage, you upgraded from SystemV to systemd. Whenever that happened, the upgrade to rsyslog would have supplied a new /etc/logrotate.d/rsyslog file containing "/usr/lib/rsyslog/rsyslog-rotate", which knows how to handle both SystemV and systemd systems. You rejected the new file, which is why it was instead written to /etc/logrotate.d/rsyslog.dpkg-dist (which you could have safely left or removed—it's harmless). Effectively, your edit has merged the contents of both files, whatever changes you made earlier before the Buster upgrade, and the vital change that would have been made for you if you'd accepted the new version. Cheers, David.
Re: Strange syslog behaviour [Solved]
While I was composing my second post in this thread,
On Tue 12 Apr 2022 at 06:38:34 (+0800), Jeremy Ardley wrote:
> On 11/4/22 12:00 pm, Jeremy Ardley wrote:
> > On 11/4/22 11:46 am, David Wright wrote:
> > >
> > > There are tabooext and taboopat directives for ignoring files in
> > > logrotated.d, and I would have thought it reasonable to exclude
> > > these sorts of housekeeping files by default, because they're very
> > > likely to contain some duplication. I would file a bug against
> > > logrotate.
> > >
> > Keywords tabooext and taboopat don't appear in /etc/*
> >
> > I did get a hit in binary file /usr/sbin/rsyslogd
> >
> >
> Further to resolving the problem, on one system I ran
>
> logrotate --debug /etc/logrotate.conf
>
> And discovered that /etc/logrotate.d/inetutils-syslogd was also being
> loaded. It had duplicates of many entries in /etc/logrotate.d/rsyslog
If both those file exist, then I would think that's the cause of your
double rotation problem. As for the .dpkg-{old,dist} files, they just
reflect different responses for the upgrading of /etc/logrotate.d/dpkg
when dpkg was being upgraded on the two systems.
> I have no idea why inetutils did this. I recall inetutils also did
> some other bad stuff I had to disable.
AFAICT there's no package "inetutils", but eleven inetutils-* separate
packages, amongst them inetutils-ping, inetutils-traceroute and
inetutils-syslogd.
> All I wanted was ping but I got a world of hurt as well!
Most people, I suspect, have iputils-ping installed. On my bullseye
systems, it gets installed by the d-i a little after netbase and a
little before logrotate. That's in the early debootstrap stage, and
before the in-target stages.
>From the follow-up to your post, I get the impression that you've
pulled in some inetutils-* stuff. AFAICT inetutils-ping kicks out
iputils-ping, and inetutils-traceroute kicks out traceroute without
any complications, but you appear to have installed inetutils-syslogd,
perhaps on account of inetutils-inetd, but without removing rsyslogd.
In the follow-up, you appear to prevent -syslogd and -inetd from
doing anything, so one might ask why they're installed at all. Have
I missed spotting some dependency?
Cheers,
David.
Re: Some of the parameters used in my genisoimage command don't produce a bootable ISO image
Hello. I have understood that the graphic files I need to change are inside the file called "initrd.gz" that's inside this folder : /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/d-i/gtk/ I should decompress it and I will have the file called "initrd",that's a cpio file. The images that I should edit are inside this archive / folders : initrd/usr/share/graphics and they are called : logo_debian.png and logo_debian_dark.png ; at this point this is what I did to add two new image files inside the archive in the same position of the old ones : chmod +w -R /home/ziomario/Scrivania/PassT-Cubic/Debian-new/custom-disk/d-i/gtk/ echo logo_debian_dark.png | cpio -H newc -o -A -F initrd/usr/share/graphics but unfortunately this is not the proper command to issue : cpio: can't open initrd/usr/share/graphics: Is not a directory how to fix that ? Il giorno sab 15 ott 2022 alle ore 20:48 Mario Marietto < marietto2...@gmail.com> ha scritto: > Hello to everyone. > > I'm trying to customize the debian 11 and I'm creating a derivative distro > for debian 11. I've changed a lot of logos,images and pictures,but not > everything. For example I'm not able to understand which file belongs to > the image and the logo that you see in this picture : > https://ibb.co/SvbvsyR ; thanks. > > Il giorno gio 13 ott 2022 alle ore 22:58 Mario Marietto < > marietto2...@gmail.com> ha scritto: > >> 😂 >> >> Il giorno gio 13 ott 2022 alle ore 22:35 Thomas Schmitt < >> scdbac...@gmx.net> ha scritto: >> >>> Hi, >>> >>> Mario Marietto wrote: >>> > anyway,using another append shouldn't be wrong because the debian >>> developers >>> > used,not me,in this way >>> >>> Oh. In this case we should not bet against their wisdom. >>> >>> If it is by mistake, then it is harmless and heavily tested during the >>> last years. >>> (Regrettably i have not many old Live ISOs and half of them are >>> "standard", >>> i.e. without GUI. I see the line with the unexplained "append" in >>> debian-live-9.2.0-amd64-cinnamon.iso . >>> Maybe one of the subscribed DDs has nostalgic memories from the time >>> when >>> the graphic installer was introduced ?) >>> >>> >>> Have a nice day :) >>> >>> Thomas >>> >>> >> >> -- >> Mario. >> > > > -- > Mario. > -- Mario.
Re: VNC on debian 11 can't get it working on fress install
Hi Mark, I had a similar issue. I changed the ~/.vnc/xstartup file to be: #!/bin/bash # Make sure that the SESSION_MANAGER environment variable is not set. unset SESSION_MANAGER # Launch Xfce in the foreground. startxfce4 and the "exited too early" problem went away. Hope this helps! Michael
Re: [SOLVED] Re: crash with wine and nvidia-driver
Am Samstag, 15. Oktober 2022, 20:37:41 CEST schrieb piorunz: Hi Piotr, tried before as you suggested: deleting all configs of wine without success. I also tried wine7.0 from winehq, but this did not work and wanted to deinstall many of my applications, like digicam or similar. Hope, that debian will update wine soon to version 7, but maybe they will never do on debian/stable. Maybe in the next release Happy gaming and best regards Hans > On 15/10/2022 18:18, Hans wrote: > > Am Samstag, 15. Oktober 2022, 15:08:40 CEST schrieb piorunz: > > Hi Piotr, > > > > sadly this did not work. However, I got a solution: > > > > I purged all wine packages from debian, then reinstalled wine, but only > > minimalistic, say, all necessary packages. > > > > I spared all suggested packages - and it worked now. No crash any more and > > "primusrun glxgears -info" is now running. > > Great! But maybe it was wine configuration files, you seem to be using > only default profile ~/.wine, and maybe files there (Windows > installation so to speak) got corrupted. So not reinstallation necessary. > I suggest to delete/move/manipulate default profile ~/.wine next time, > to save time. And ultimately, you can start using Lutris to manage your > Wine profiles or do it manually by using shortcut for example: > WINEPREFIX=/home/path... wine something.exe > > And lastly if you serious about gaming then latest Wine is good option, > not using Wine 5 from Debian stable but latest and greatest Wine 7. > I am gaming on wine-staging (v7.18 at the moment) and it's great. > https://wiki.winehq.org/Debian > > -- > With kindest regards, Piotr. > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system > ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ > ⠈⠳⣄
Re: Some of the parameters used in my genisoimage command don't produce a bootable ISO image
Hello to everyone. I'm trying to customize the debian 11 and I'm creating a derivative distro for debian 11. I've changed a lot of logos,images and pictures,but not everything. For example I'm not able to understand which file belongs to the image and the logo that you see in this picture : https://ibb.co/SvbvsyR ; thanks. Il giorno gio 13 ott 2022 alle ore 22:58 Mario Marietto < marietto2...@gmail.com> ha scritto: > 😂 > > Il giorno gio 13 ott 2022 alle ore 22:35 Thomas Schmitt > ha scritto: > >> Hi, >> >> Mario Marietto wrote: >> > anyway,using another append shouldn't be wrong because the debian >> developers >> > used,not me,in this way >> >> Oh. In this case we should not bet against their wisdom. >> >> If it is by mistake, then it is harmless and heavily tested during the >> last years. >> (Regrettably i have not many old Live ISOs and half of them are >> "standard", >> i.e. without GUI. I see the line with the unexplained "append" in >> debian-live-9.2.0-amd64-cinnamon.iso . >> Maybe one of the subscribed DDs has nostalgic memories from the time when >> the graphic installer was introduced ?) >> >> >> Have a nice day :) >> >> Thomas >> >> > > -- > Mario. > -- Mario.
Re: [SOLVED] Re: crash with wine and nvidia-driver
On 15/10/2022 18:18, Hans wrote: Am Samstag, 15. Oktober 2022, 15:08:40 CEST schrieb piorunz: Hi Piotr, sadly this did not work. However, I got a solution: I purged all wine packages from debian, then reinstalled wine, but only minimalistic, say, all necessary packages. I spared all suggested packages - and it worked now. No crash any more and "primusrun glxgears -info" is now running. Great! But maybe it was wine configuration files, you seem to be using only default profile ~/.wine, and maybe files there (Windows installation so to speak) got corrupted. So not reinstallation necessary. I suggest to delete/move/manipulate default profile ~/.wine next time, to save time. And ultimately, you can start using Lutris to manage your Wine profiles or do it manually by using shortcut for example: WINEPREFIX=/home/path... wine something.exe And lastly if you serious about gaming then latest Wine is good option, not using Wine 5 from Debian stable but latest and greatest Wine 7. I am gaming on wine-staging (v7.18 at the moment) and it's great. https://wiki.winehq.org/Debian -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: MUD
I don't know if it's still around, but there was a waffle bbs system that could run on unix a while ago. Jude "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) . On Sat, 15 Oct 2022, Roy J. Tellason, Sr. wrote: > On Thursday 13 October 2022 11:13:49 am Maude Summerside wrote: > > I've found out that WWIV got ported to POSIX compatible OS and now runs > > completely under Linux, same goes for Synchronet BBS. > > > > There's Mystic BBS but didn't find source code. > > And there's the closed source BBBS (made in Finland). > > > > I used to run Maximus BBS under dos/desqview. I believe that there is a > linux version of it out there. I did try to run it once, but apparently the > changes I made in the setup broke it pretty good, and I lost interest... > >
Re: Strange syslog behaviour [Solved]
On Sat, Oct 15, 2022 at 01:59:18PM -0400, Wayne Sallee wrote:
>edit /etc/logrotate.d/rsyslog
>Change from
> invoke-rc.d rsyslog rotate > /dev/null
>to
> /usr/lib/rsyslog/rsyslog-rotate
Hmm.
In /etc/init.d/rsyslog (which is what the old command calls upon), the
rotate action calls this function:
do_rotate() {
start-stop-daemon --stop --signal HUP --quiet --pidfile $PIDFILE --exec
$DAEMON
}
where PIDFILE is defined to be /run/rsyslogd.pid .
This file does not exist on my (bullseye) system, where rsyslog is
started by systemd (/lib/systemd/system/rsyslog.service) with the "-iNONE"
argument, which suppresses the creation of *any* PID file. So, that
explains why the start-stop-daemon command doesn't work.
Therefore, what you've done looks like the correct fix. Deleting the
*.dpkg-dist files shouldn't matter, so long as /etc/logrotate.d/rsyslog
gets updated.
However, this looks like a bug in rsyslog to me.
The rsyslog sysv-rc script, if it's going to exist, should duplicate
the /usr/lib/rsyslog/rsyslog-rotate program in the do_rotate function.
It's clearly designed to handle both systemd and sysvinit:
unicorn:~$ less /usr/lib/rsyslog/rsyslog-rotate
#!/bin/sh
if [ -d /run/systemd/system ]; then
systemctl kill -s HUP rsyslog.service
else
invoke-rc.d rsyslog rotate > /dev/null
fi
So, the init.d script should be using something like that. I would do it
like this:
do_rotate() {
if [ -d /run/systemd/system ]; then
systemctl kill -s HUP rsyslog.service
else
start-stop-daemon --stop --signal HUP --quiet \
--pidfile "$PIDFILE" --exec "$DAEMON"
fi
}
Re: MUD
On Thursday 13 October 2022 11:13:49 am Maude Summerside wrote: > I've found out that WWIV got ported to POSIX compatible OS and now runs > completely under Linux, same goes for Synchronet BBS. > > There's Mystic BBS but didn't find source code. > And there's the closed source BBBS (made in Finland). > I used to run Maximus BBS under dos/desqview. I believe that there is a linux version of it out there. I did try to run it once, but apparently the changes I made in the setup broke it pretty good, and I lost interest... -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
Re: Strange syslog behaviour [Solved]
Jeremy Ardley, did you update your code from " invoke-rc.d rsyslog rotate > /dev/null" to "/usr/lib/rsyslog/rsyslog-rotate"? So I got my servers straitened out, I think. I will know tomorrow. For anyone else running into this problem, the problem was caused from modifying /etc/logrotate.d/rsyslog then upgrading to Buster. The fix: diff /etc/logrotate.d/rsyslog.dpkg-dist /etc/logrotate.d/rsyslog edit /etc/logrotate.d/rsyslog Change from invoke-rc.d rsyslog rotate > /dev/null to /usr/lib/rsyslog/rsyslog-rotate Then delete /etc/logrotate.d/rsyslog.dpkg-dist I then rebooted my servers to get the syslog used. Then ls /var/log | grep syslog To see that it was working. I will know tomorrow if it is still working. Wayne Sallee wa...@waynesallee.com http://www.WayneSallee.com
[SOLVED] Re: crash with wine and nvidia-driver
Am Samstag, 15. Oktober 2022, 15:08:40 CEST schrieb piorunz: Hi Piotr, sadly this did not work. However, I got a solution: I purged all wine packages from debian, then reinstalled wine, but only minimalistic, say, all necessary packages. I spared all suggested packages - and it worked now. No crash any more and "primusrun glxgears -info" is now running. Additionally also the games prior not working with nvidia legacy driver are working now, too. It looks for me, some additional package forced the crash, but I can nor say, which one. It is no need, to look at, because wine in debian/stable is rather old (it is version 5, whilst the actual version is now version 7). I suppose, debian will update this package soon, as even for debian/stable version 5 is too old IMHO. Thank you all for any help. Best regards Hans > On 13/10/2022 17:43, Hans wrote: > > As I am not believing, this is related to the game (as ALL games are > > crashing), I believe, it is related to a systematical error in the > > relationship between wine and nvidia-driver. > > To verify this hypothesis, run for example: > primusrun wine notepad.exe > primusrun winecfg > > See if that opens. > > -- > With kindest regards, Piotr. > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system > ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ > ⠈⠳⣄
Re: Strange syslog behaviour [Solved]
On Sat, Oct 15, 2022 at 10:13:05AM -0400, Wayne Sallee wrote: > Original Message > *Subject: * Strange syslog behaviour [Solved] > *From: * Jeremy Ardley > > Anyway long story short, at some stage some package updates must have > > written an extra file into /etc/logrotate.d that had duplicate entries > > to the normal files. > > > > This was interpreted by the logrotate process as well as the intended files > > such as /etc/logrotated.d/rsyslog > > > > On one system this unexpected file was called rsyslog.dpkg-old on another > > system it was rsyslog.dpkg-dist > > > > Removing these files ( but not /etc/logrotate.d/dpkg ) now has a correctly > > configured log rotation Files with extensions *.dpkg-old and *.dpkg-dist are created when a package is updated, and its configuration file has been modified. The current (modified) configuration file is left alone, and the files that *would* have been installed by the package are placed with these extensions. Such files *should not* be operational. Programs are supposed to ignore them. In logrotate(8) there is this paragraph: tabooext [+] list The current taboo extension list is changed (see the include di‐ rective for information on the taboo extensions). If a + pre‐ cedes the list of extensions, the current taboo extension list is augmented, otherwise it is replaced. At startup, the taboo extension list ,v, .cfsaved, .disabled, .dpkg-bak, .dpkg-del, .dpkg-dist, .dpkg-new, .dpkg-old, .rhn-cfg-tmp-*, .rpmnew, .rp‐ morig, .rpmsave, .swp, .ucf-dist, .ucf-new, .ucf-old, ~ So, unless your /etc/logrotate.conf has been changed, or your logrotate is not the one provided by Debian, the *.dpkg-old and *.dpkg-dist files should do nothing. They should be ignored. > > I have systems (armbian) that had anomalous behaviour. If you're *not on Debian* then we can't tell you what to do. Ask your operating system support people.
Re: Strange syslog behaviour [Solved]
Thanks for pointing this out. I just noticed this problem a few days ago. Wayne Sallee wa...@waynesallee.com http://www.WayneSallee.com Original Message *Subject: * Strange syslog behaviour [Solved] *From: * Jeremy Ardley *To: * Debian-user *CC: * *Date: * 2022-4-10 10:07 PM I have systems (armbian) that had anomalous behaviour. This included sometimes writing to /var/log/syslog.1 rather than to /var/log/syslog (which was created, but zero size) Additionally the logrotate was happening daily or twice daily when seemingly configured for weekly rotates Anyway long story short, at some stage some package updates must have written an extra file into /etc/logrotate.d that had duplicate entries to the normal files. This was interpreted by the logrotate process as well as the intended files such as /etc/logrotated.d/rsyslog On one system this unexpected file was called rsyslog.dpkg-old on another system it was rsyslog.dpkg-dist Removing these files ( but not /etc/logrotate.d/dpkg ) now has a correctly configured log rotation
Re: crash with wine and nvidia-driver
On 13/10/2022 17:43, Hans wrote: As I am not believing, this is related to the game (as ALL games are crashing), I believe, it is related to a systematical error in the relationship between wine and nvidia-driver. To verify this hypothesis, run for example: primusrun wine notepad.exe primusrun winecfg See if that opens. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
