Re: [gentoo-user] how to clean up

2021-05-13 Thread n952162

On 5/14/21 12:36 AM, Dale wrote:

Manuel McLure wrote:

On Thu, May 13, 2021 at 2:47 PM n952162 mailto:n952...@web.de>> wrote:

 Hi,

 I'm running out of space and I see I have many versions of all
 pkgs.  Is
 the proper way to get rid of all older tarballs - but retain the
 current
 ones - to simply use the --clean option with emerge?  Any other
 options
 necessary?


You might want to
give https://wiki.gentoo.org/wiki/Knowledge_Base:Remove_obsoleted_distfiles
a read.

--
Manuel A. McLure WW1FA mailto:man...@mclure.org>>

...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.                       -- H.P. Lovecraft


That above is how I clean up mine as well.  When I do a large update, I
give it a few days to make sure everything works and then run the following:


eclean-dist -dq

eclean-pkg -dq


The -d option tells it to leave only what is installed and needed for
recovery.  It leaves a bare minimum of packages.  If you omit that, it
will leave any package versions that is still listed in the tree.
That's my recollection of it anyway.  You may want to start just running
with no options at all.  It's the most conservative method.  If you
still need more space, add -d to get more things deleted.  The -q just
means quiet.  I think it has a -p for pretend so you could run as -p and
then -pd to see the difference.  The options work the same for both
commands.

One of those should work.  I might add, the man page isn't bad.  It
gives quite a bit of details and even examples.

Hope that helps.

Dale

:-)  :-)



Thank you.




Re: [gentoo-user] how to clean up

2021-05-13 Thread n952162

On 5/13/21 11:58 PM, Manuel McLure wrote:

On Thu, May 13, 2021 at 2:47 PM n952162 mailto:n952...@web.de>> wrote:

Hi,

I'm running out of space and I see I have many versions of all
pkgs.  Is
the proper way to get rid of all older tarballs - but retain the
current
ones - to simply use the --clean option with emerge?  Any other
options
necessary?


You might want to give
https://wiki.gentoo.org/wiki/Knowledge_Base:Remove_obsoleted_distfiles

a read.

--
Manuel A. McLure WW1FA mailto:man...@mclure.org>>
>
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.                       -- H.P. Lovecraft



Thank you, that was it.



Re: [gentoo-user] Approx monthly hard lockups

2021-05-13 Thread Jack

On 5/13/21 11:01 PM, Walter Dnes wrote:

On Thu, May 13, 2021 at 06:10:08AM -0700, Mark Knecht wrote

Do double check that you log into a directory that doesn't run out of space
once a month. That could cause problems also.

   After the "separate /usr" brouhaha, I gave up and went to one file
system. We all back up our PC's regularly, don't we?   "fdisk -l"
shows my "1 terabyte" drive as...

Device  StartEndSectors  Size Type
/dev/sda12048 1929381887 1929379840  920G Linux filesystem
/dev/sda2  1929381888 1953525134   24143247 11.5G Linux swap

   I am *NOT* running out of disk space.  mc (Midnight Commander) shows
617 of 905 gigabytes free when logged in as regular user.  663 of 905
free when logged in as root.  Soon to be several gigabytes more free
space when I do some cleaning up of obsolete unused cruft accumulated
over the years.
One thing I've done in a similar situation is to boot to a live image.  
That way, the current system does not mess with anything in /var/log and 
you might find something which would be overwritten by a fresh boot.




Re: [gentoo-user] Approx monthly hard lockups

2021-05-13 Thread Walter Dnes
On Thu, May 13, 2021 at 06:10:08AM -0700, Mark Knecht wrote
> 
> Do double check that you log into a directory that doesn't run out of space
> once a month. That could cause problems also.

  After the "separate /usr" brouhaha, I gave up and went to one file
system. We all back up our PC's regularly, don't we?   "fdisk -l"
shows my "1 terabyte" drive as...

Device  StartEndSectors  Size Type
/dev/sda12048 1929381887 1929379840  920G Linux filesystem
/dev/sda2  1929381888 1953525134   24143247 11.5G Linux swap

  I am *NOT* running out of disk space.  mc (Midnight Commander) shows
617 of 905 gigabytes free when logged in as regular user.  663 of 905
free when logged in as root.  Soon to be several gigabytes more free
space when I do some cleaning up of obsolete unused cruft accumulated
over the years.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications



[gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”

2021-05-13 Thread John Blinka
On Thu, May 13, 2021 at 9:12 PM Jack 
wrote:

> Given  you say the UUID is for the boot partition, then both the linux and
> initrd should just have the name of the kernel and initrd files (without
> leading "/boot",) which sounds like what  you've got.  I'd next wonder if
> something is missing from the kernel/initrd combination, such as a kernel
> module necessary for some early part of the boot process or a file system
> (per Dale's suggestion.)  Assuming that you ran genkernel after booting a
> live image and chrooting into the new system, then we know the hardware can
> boot a good kernel/image combo.  Mainly I'm  just thinking out loud here,
> trying to coax someone's little gray cells into action.
>
In my early linux days, I thought it would be clever to include kernel
support for my root filesystem in a module.  Whose code resided on the root
filesystem...  That didn’t work, of course, but at least the kernel started
to boot and threw out an error message.  Here, I just get complete
silence.  So, I doubt that file system support is an issue.

John


[gentoo-user] Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”

2021-05-13 Thread John Blinka
On Thu, May 13, 2021 at 9:10 PM Dale  wrote:

>
> I hate these init thingys and will admit I know little about the
> things.  I had a thought tho, could it be that the file system needed to
> read the init thingy isn't included somehow or in the kernel maybe?  If
> it is pointing to the right place, sounds like it is to me, then it has
> to be a read problem I'd think.


All the uefi stuff is on a fat filesystem.  I would think that something
that fundamental (and universally supported) is embedded in the bios.  The
grub bootloader itself is on that fat filesystem, and it must have loaded
or else I wouldn’t have access to the grub edit facility.  So I think I’m
ok on file system support.



>
> I haven't ever had to use the edit menu on grub2 that I remember.  It
> might be worth mentioning that it may have tab completion.  That would
> certainly remove a typo if it can complete the kernel or init thingys
> file name on its own.  Just a thought.


Grub documentation says it does have tab completion.  But the file names,
uuids, and other things prone to typos that I referenced are generated by
grub, so typos are unlikely to be an issue.  And I’ve checked them
meticulously.  They look ok.

>
> Going back under my desk now.


Maybe I’d be less frustrated by this new mobo if I did the same! ;)

John


Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”

2021-05-13 Thread Jack

On 5/13/21 6:51 PM, John Blinka wrote:
On Thu, May 13, 2021 at 7:23 PM Jack > wrote:



I'd start by removing any "quiet" or "splash" from the kernel command
line.    You should be able to see them when you hit "e". I'm not
sure
if it will actually help, but it should be a start.


Thanks, but neither one appears.  My command line is

linux  /vmlinuz… root=UUID=… ro loglevel=4 nomodeset

Here I’ve replaced the full name of the kernel and the uuid of the 
boot partition with ellipses because it’s too tedious to type.  I’ve 
scrutinized the actual ones for typos and am convinced there are 
none.  Leaving out the loglevel command doesn’t change the behavior at 
all.


Given  you say the UUID is for the boot partition, then both the linux 
and initrd should just have the name of the kernel and initrd files 
(without leading "/boot",) which sounds like what you've got.  I'd next 
wonder if something is missing from the kernel/initrd combination, such 
as a kernel module necessary for some early part of the boot process or 
a file system (per Dale's suggestion.)  Assuming that you ran genkernel 
after booting a live image and chrooting into the new system, then we 
know the hardware can boot a good kernel/image combo.  Mainly I'm  just 
thinking out loud here, trying to coax someone's little gray cells into 
action.





Re: [gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”

2021-05-13 Thread Dale
John Blinka wrote:
>
>
> On Thu, May 13, 2021 at 7:23 PM Jack  > wrote:
>
>
> I'd start by removing any "quiet" or "splash" from the kernel command
> line.    You should be able to see them when you hit "e". I'm not
> sure
> if it will actually help, but it should be a start.
>
>
> Thanks, but neither one appears.  My command line is
>
> linux  /vmlinuz… root=UUID=… ro loglevel=4 nomodeset
>
> Here I’ve replaced the full name of the kernel and the uuid of the
> boot partition with ellipses because it’s too tedious to type.  I’ve
> scrutinized the actual ones for typos and am convinced there are
> none.  Leaving out the loglevel command doesn’t change the behavior at
> all.
>
> John


I hate these init thingys and will admit I know little about the
things.  I had a thought tho, could it be that the file system needed to
read the init thingy isn't included somehow or in the kernel maybe?  If
it is pointing to the right place, sounds like it is to me, then it has
to be a read problem I'd think. 

I haven't ever had to use the edit menu on grub2 that I remember.  It
might be worth mentioning that it may have tab completion.  That would
certainly remove a typo if it can complete the kernel or init thingys
file name on its own.  Just a thought.

Going back under my desk now. 

Dale

:-)  :-) 



[gentoo-user] Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”

2021-05-13 Thread John Blinka
On Thu, May 13, 2021 at 7:23 PM Jack 
wrote:

>
> I'd start by removing any "quiet" or "splash" from the kernel command
> line.You should be able to see them when you hit "e". I'm not sure
> if it will actually help, but it should be a start.


Thanks, but neither one appears.  My command line is

linux  /vmlinuz… root=UUID=… ro loglevel=4 nomodeset

Here I’ve replaced the full name of the kernel and the uuid of the boot
partition with ellipses because it’s too tedious to type.  I’ve scrutinized
the actual ones for typos and am convinced there are none.  Leaving out the
loglevel command doesn’t change the behavior at all.

John

>


Re: [gentoo-user] boot hangs forever at “Loading initial ramdisk...”

2021-05-13 Thread Jack

On 5/13/21 5:06 PM, John Blinka wrote:

Hi, Gentooers,

New thread, next obstacle in booting new Asus mobo.

As the subject says, the boot hangs indefinitely. Output to the screen is

  Booting a command list

Loading Linux 5.10.27-gentoo-x86_64 ...
Loading initial ramdisk ...

And there it stops forever.

The kernel is the latest stable gentoo-sources.  I normally do a 
custom configuration, but in this instance built it with “genkernel 
all”, using whatever config genkernel produces. I use grub (grub2), 
and installed the kernel and initrd with “grub-mkconfig -o 
/boot/grub/grub.cfg”, as I normally do.


Googling around shows that this problem tends to occur when grub can’t 
find the initrd.


So  I looked at the grub boot script by pressing “e” just before the 
boot starts to make sure that grub is looking in the right place for 
the kernel and for the initrd.  I think it is, since deliberately 
misspelling either file name with the grub editor causes error 
messages saying grub can’t find what I told it to look for.  And those 
error messages do not occur with the boot script that grub generated.


Normally, loading the initrd takes only a few seconds.

How does one debug this situation?

John


I'd start by removing any "quiet" or "splash" from the kernel command 
line.    You should be able to see them when you hit "e". I'm not sure 
if it will actually help, but it should be a start.






[gentoo-user] boot hangs forever at “Loading initial ramdisk...”

2021-05-13 Thread John Blinka
Hi, Gentooers,

New thread, next obstacle in booting new Asus mobo.

As the subject says, the boot hangs indefinitely.  Output to the screen is

  Booting a command list

Loading Linux 5.10.27-gentoo-x86_64 ...
Loading initial ramdisk ...

And there it stops forever.

The kernel is the latest stable gentoo-sources.  I normally do a custom
configuration, but in this instance built it with “genkernel all”, using
whatever config genkernel produces. I use grub (grub2), and installed the
kernel and initrd with “grub-mkconfig -o /boot/grub/grub.cfg”, as I
normally do.

Googling around shows that this problem tends to occur when grub can’t find
the initrd.

So  I looked at the grub boot script by pressing “e” just before the boot
starts to make sure that grub is looking in the right place for the kernel
and for the initrd.  I think it is, since deliberately misspelling either
file name with the grub editor causes error messages saying grub can’t find
what I told it to look for.  And those error messages do not occur with the
boot script that grub generated.

Normally, loading the initrd takes only a few seconds.

How does one debug this situation?

John


Re: [gentoo-user] how to clean up

2021-05-13 Thread Dale
Manuel McLure wrote:
> On Thu, May 13, 2021 at 2:47 PM n952162  > wrote:
>
> Hi,
>
> I'm running out of space and I see I have many versions of all
> pkgs.  Is
> the proper way to get rid of all older tarballs - but retain the
> current
> ones - to simply use the --clean option with emerge?  Any other
> options
> necessary?
>
>
> You might want to
> give https://wiki.gentoo.org/wiki/Knowledge_Base:Remove_obsoleted_distfiles
> a read. 
>
> -- 
> Manuel A. McLure WW1FA mailto:man...@mclure.org>>
> 
> ...for in Ulthar, according to an ancient and significant law,
> no man may kill a cat.                       -- H.P. Lovecraft


That above is how I clean up mine as well.  When I do a large update, I
give it a few days to make sure everything works and then run the following:


eclean-dist -dq

eclean-pkg -dq


The -d option tells it to leave only what is installed and needed for
recovery.  It leaves a bare minimum of packages.  If you omit that, it
will leave any package versions that is still listed in the tree. 
That's my recollection of it anyway.  You may want to start just running
with no options at all.  It's the most conservative method.  If you
still need more space, add -d to get more things deleted.  The -q just
means quiet.  I think it has a -p for pretend so you could run as -p and
then -pd to see the difference.  The options work the same for both
commands. 

One of those should work.  I might add, the man page isn't bad.  It
gives quite a bit of details and even examples. 

Hope that helps.

Dale

:-)  :-) 



Re: [gentoo-user] how to clean up

2021-05-13 Thread Manuel McLure
On Thu, May 13, 2021 at 2:47 PM n952162  wrote:

> Hi,
>
> I'm running out of space and I see I have many versions of all pkgs.  Is
> the proper way to get rid of all older tarballs - but retain the current
> ones - to simply use the --clean option with emerge?  Any other options
> necessary?
>
>
You might want to give
https://wiki.gentoo.org/wiki/Knowledge_Base:Remove_obsoleted_distfiles a
read.

-- 
Manuel A. McLure WW1FA  
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.   -- H.P. Lovecraft


Re: [gentoo-user] Re: sysrescue+new asus mobo+secure boot=0

2021-05-13 Thread John Blinka
On Thu, May 13, 2021 at 1:03 PM antlists  wrote:

> On 13/05/2021 00:51, John Blinka wrote:
> > And it appears your intuition is correct.  I left all the “secure boot”
> > options in the bios at their defaults except one.  I changed “OS Type”
> > from “Windows UEFI mode” to “Other OS”.  That was sufficient to boot
> > from my Sysrescue usb.
>
> One other little point of interest ... so does that mean
> non-windows-uefi, or does it mean bios legacy?
>
> That could be important information at some point, especially if you
> want to dual-boot.


Don’t know for sure.  Suspect it’s non-windows-uefi.  There’s a separate
option in the bios boot submenu called CSM (Compatibility Support Module).
Googling this suggests to me that this is the bios legacy switch.  I’ve
moved on to uefi exclusively, am beginning to get a grip on it, and will
not dual boot on this box.

John

>
>


[gentoo-user] how to clean up

2021-05-13 Thread n952162

Hi,

I'm running out of space and I see I have many versions of all pkgs.  Is
the proper way to get rid of all older tarballs - but retain the current
ones - to simply use the --clean option with emerge?  Any other options
necessary?




Re: [gentoo-user] Rationalizing log files

2021-05-13 Thread Walter Dnes
On Thu, May 13, 2021 at 03:42:44AM -0500, Dale wrote

> Basically, it's two files, that I can find anyway.  One is to run it as
> a cron and the other tells it what to rotate.  If you duplicate that, it
> should help.  Of course, make sure whatever cron you are using is
> running as well.
> 
> Hope that helps.

  Strange.  My files match yours.  Manual rotation did not work.  I
inserted...

maxsize 8M

...into syslog-ng and ran logrotate, which finally worked.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications



Re: [gentoo-user] Re: sysrescue+new asus mobo+secure boot=0

2021-05-13 Thread Mike Kaliman
I boot with UEFI using that setting so i assume it means non-Windows-UEFI,
weird.
I've been booting Windows and Gentoo without issue so Other OS should be
fine for that.

On Thu, May 13, 2021, 1:03 PM antlists  wrote:

> On 13/05/2021 00:51, John Blinka wrote:
> > And it appears your intuition is correct.  I left all the “secure boot”
> > options in the bios at their defaults except one.  I changed “OS Type”
> > from “Windows UEFI mode” to “Other OS”.  That was sufficient to boot
> > from my Sysrescue usb.
>
> One other little point of interest ... so does that mean
> non-windows-uefi, or does it mean bios legacy?
>
> That could be important information at a some point, especially if you
> want to dual-boot.
>
>
> Cheers,
> Wol
>
>


Re: [gentoo-user] Re: sysrescue+new asus mobo+secure boot=0

2021-05-13 Thread antlists

On 13/05/2021 00:51, John Blinka wrote:
And it appears your intuition is correct.  I left all the “secure boot” 
options in the bios at their defaults except one.  I changed “OS Type” 
from “Windows UEFI mode” to “Other OS”.  That was sufficient to boot 
from my Sysrescue usb.


One other little point of interest ... so does that mean 
non-windows-uefi, or does it mean bios legacy?


That could be important information at some point, especially if you 
want to dual-boot.



Cheers,
Wol



Re: [gentoo-user] Approx monthly hard lockups

2021-05-13 Thread Neil Bothwick
On Thu, 13 May 2021 03:19:54 -0400, Walter Dnes wrote:

> > 
> > Most likely in /var/log/messages. The bad thing about dmesg, I think
> > it resets when rebooting which erases previous info.
> > 
> > As Mark pointed out, you need to go back to the time before it starts
> > adding the boot up process.  
> 
>   No help.  /var/log/messages goes straight from iptables messages to
> bootup with no indication of shutdown...


That's not surprising, the messages are cached before writing to disk, so
the most recent messages will be lost. You could try mounting the
filesystem containing /var with sync, which will at least avoid the disk
writes being cached. It's possible that syslog-ng also caches write, in
which case you'll also need to look for an option to prevent that.


-- 
Neil Bothwick

Math and alcohol don't mix. Don't drink and derive.


pgpu772xQqrTL.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] Can't install new ~amd64 system

2021-05-13 Thread Peter Humphrey
On Thursday, 13 May 2021 14:17:43 BST Peter Humphrey wrote:

> I'm trying to install a fresh sytem on my workstation. I've started 
with
> no USE flags set, other than what was requested in emerge -uaDvN
> @world, but the update stops at pango, which fails with a ninja no-
can-
> do error.

Bug 789966 submitted.

-- 
Regards,
Peter.



Re: [gentoo-user] Rationalizing log files

2021-05-13 Thread Mark Knecht
On Thu, May 13, 2021 at 6:20 AM Mark Knecht  wrote:
>
>
>
> On Thu, May 13, 2021 at 12:58 AM Walter Dnes 
wrote:
> >
> 
> > # no packages own wtmp and btmp -- we'll rotate them here.
> > /var/log/wtmp {
> > monthly
> > create 0664 root utmp
> > minsize 1M
> > rotate 1
> > }
> > /var/log/btmp {
> > missingok
> > monthly
> > create 0600 root utmp
> > rotate 1
> > }
> 
>
> As you reported 'roughly monthly' failures my guess would be the above
two sections
>

One additional thought: If the above sections are involved and if it's a
bug then you might find it faster changing the above to daily vs monthly.

If you were to try this then do them one at a time and change the rotate
number to 30 or 40 to keep the data for the month. (I think...)

Good luck,
Mark


Re: [gentoo-user] Rationalizing log files

2021-05-13 Thread Mark Knecht
On Thu, May 13, 2021 at 12:58 AM Walter Dnes  wrote:
>

> # no packages own wtmp and btmp -- we'll rotate them here.
> /var/log/wtmp {
> monthly
> create 0664 root utmp
> minsize 1M
> rotate 1
> }
> /var/log/btmp {
> missingok
> monthly
> create 0600 root utmp
> rotate 1
> }


As you reported 'roughly monthly' failures my guess would be the above two
sections

>   And maybe either stop logging Facebook, or else log iptables messages
> to a separate file (how is that done?).  The Facebook tracker messages
> are generated by iptables rules...

Don't log what you're not interested in. If your disk is getting filled up
with billions of Facebook issues then limit how much of that you track.

HTH,
Mark


[gentoo-user] Can't install new ~amd64 system

2021-05-13 Thread Peter Humphrey
Hello list,

I'm trying to install a fresh sytem on my workstation. I've started with 
no USE flags set, other than what was requested in emerge -uaDvN 
@world, but the update stops at pango, which fails with a ninja no-can-
do error.

I've followed the handbook exactly.

Before I log a bug, has this happened to anyone else?

-- 
Regards,
Peter.



Re: [gentoo-user] Approx monthly hard lockups

2021-05-13 Thread Mark Knecht
On Thu, May 13, 2021 at 12:20 AM Walter Dnes  wrote:
>
> On Wed, May 12, 2021 at 09:50:29PM -0500, Dale wrote
> > Walter Dnes wrote:
> > > On Wed, May 12, 2021 at 11:16:56AM -0700, Mark Knecht wrote
> > >> Is there nothing in the system logs? What's near the end before
whatever
> > >> you get from booting after this issue?
> > >   Where would those logfiles be?  "dmesg" starts off with...
> > >
> >
> >
> > Most likely in /var/log/messages. The bad thing about dmesg, I think it
> > resets when rebooting which erases previous info.
> >
> > As Mark pointed out, you need to go back to the time before it starts
> > adding the boot up process.
>
>   No help.  /var/log/messages goes straight from iptables messages to
> bootup with no indication of shutdown...
>
> May 12 11:26:31 i3 kernel: FECESBOOK:IN= OUT=eth0 SRC=192.168.1.249
DST=31.13.80.12 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=5824 DF PROTO=TCP
SPT=50566 DPT=443 WINDOW=64170 RES=0x00 SYN URGP=0
> May 12 11:26:32 i3 kernel: FECESBOOK:IN= OUT=eth0 SRC=192.168.1.249
DST=31.13.80.12 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=60152 DF PROTO=TCP
SPT=50568 DPT=443 WINDOW=64170 RES=0x00 SYN URGP=0
> May 12 11:34:04 i3 syslog-ng[1384]: syslog-ng starting up;
version='3.30.1'
> May 12 11:34:04 i3 crond[1414]: /usr/sbin/crond 4.5 dillon's cron daemon,
started with loglevel notice
> May 12 11:34:04 i3 /usr/sbin/gpm[1443]: *** info [daemon/startup.c(136)]:
> May 12 11:34:04 i3 /usr/sbin/gpm[1443]: Started gpm successfully. Entered
daemon mode.
>
>   When doing a regular shutdown I get stuff like...
>
> May 12 11:42:31 i3 shutdown[1974]: shutting down for system reboot
> May 12 11:42:31 i3 init[1]: Switching to runlevel: 6
> May 12 11:42:32 i3 init[1]: Trying to re-exec init
> May 12 11:42:32 i3 start-stop-daemon[2053]: Will stop /usr/sbin/sshd
> May 12 11:42:32 i3 start-stop-daemon[2053]: Will stop PID 1764
> May 12 11:42:32 i3 start-stop-daemon[2053]: Sending signal 15 to PID 1764
> May 12 11:42:32 i3 sshd[1764]: Received signal 15; terminating.
>

OK, but those messages are yesterday, May 12th, at 11:42 in the morning.
Being that you started this thread on May 12th at 9:35 (when I received the
first email anyway) the actual lockup presumably occurred earlier.

I believe you're in the correct file, or set of files. Depending on how
your logging works (what logger, what options) generally the logs roll over
into successive files. (*.1, *.2, *.3, etc) Assuming you have some idea
when the lockup occurred you want to look for what was going on just before
that. Do the logs hit a date/time and stop? Or do they go on logging with
lots of similar or repeating messages for hours or days?

Do double check that you log into a directory that doesn't run out of space
once a month. That could cause problems also.

HTH,
MArk


Re: [gentoo-user] Rationalizing log files

2021-05-13 Thread Dale
Walter Dnes wrote:
>   On another thread, I had to dive into into /var/log/messages, and I
> realized that it was not being rotated.  It's 32 megabytes+, most of
> which is iptables reject messages for Facebook trackers.  What do I need
> to do to get log rotation working?
>
> /etc/logrotate.conf
>
> 
>
> #
> # Default logrotate(8) configuration file for Gentoo Linux.
> # See "man logrotate" for details.
>
> # rotate log files weekly.
> weekly
> #daily
>
> # keep 4 weeks worth of backlogs.
> rotate 4
>
> # create new (empty) log files after rotating old ones.
> create
>
> # use date as a suffix of the rotated file.
> dateext
>
> # compress rotated log files.
> compress
>
> notifempty
> nomail
> noolddir
>
> # packages can drop log rotation information into this directory.
> include /etc/logrotate.d
>
> # no packages own wtmp and btmp -- we'll rotate them here.
> /var/log/wtmp {
> monthly
> create 0664 root utmp
> minsize 1M
> rotate 1
> }
> /var/log/btmp {
> missingok
> monthly
> create 0600 root utmp
> rotate 1
> }
>
> # system-specific logs may be also be configured here.
>
> 
>
>   /etc/logrotate.d contains...
> dcron  elog-save-summary  hibernate-script  openrc  rsyncd  syslog-ng
>
> 
>
>   And maybe either stop logging Facebook, or else log iptables messages
> to a separate file (how is that done?).  The Facebook tracker messages
> are generated by iptables rules...
>
> -A INPUT -s 31.13.24.0/21 -j FECESBOOK
> -A INPUT -s 31.13.64.0/18 -j FECESBOOK
> -A INPUT -s 66.220.144.0/20 -j FECESBOOK
> -A INPUT -s 69.63.176.0/20 -j FECESBOOK
> -A INPUT -s 69.171.224.0/19 -j FECESBOOK
> -A INPUT -s 74.119.76.0/22 -j FECESBOOK
> -A INPUT -s 103.4.96.0/22 -j FECESBOOK
> -A INPUT -s 173.252.64.0/18 -j FECESBOOK
> -A INPUT -s 204.15.20.0/22 -j FECESBOOK
>
> -A OUTPUT -d 31.13.24.0/21 -j FECESBOOK
> -A OUTPUT -d 31.13.64.0/18 -j FECESBOOK
> -A OUTPUT -d 66.220.144.0/20 -j FECESBOOK
> -A OUTPUT -d 69.63.176.0/20 -j FECESBOOK
> -A OUTPUT -d 69.171.224.0/19 -j FECESBOOK
> -A OUTPUT -d 74.119.76.0/22 -j FECESBOOK
> -A OUTPUT -d 103.4.96.0/22 -j FECESBOOK
> -A OUTPUT -d 173.252.64.0/18 -j FECESBOOK
> -A OUTPUT -d 204.15.20.0/22 -j FECESBOOK
>
> -A FECESBOOK -j LOG --log-prefix "FECESBOOK:" --log-level 6
> -A FECESBOOK -j REJECT --reject-with icmp-port-unreachable
>


I may be missing something but this is what I could find on my system. 


root@fireball / # cat /etc/cron.daily/logrotate
#!/bin/sh

/usr/bin/logrotate /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
    /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit $EXITVALUE
root@fireball / # cat /etc/logrotate.d/syslog-ng
#
# Syslog-ng logrotate snippet for Gentoo Linux
# contributed by Michael Sterrett
#

/var/log/messages {
    delaycompress
    missingok
    sharedscripts
    postrotate
    /etc/init.d/syslog-ng reload > /dev/null 2>&1 || true
    endscript
}
root@fireball / #


Basically, it's two files, that I can find anyway.  One is to run it as
a cron and the other tells it what to rotate.  If you duplicate that, it
should help.  Of course, make sure whatever cron you are using is
running as well.

Hope that helps.

Dale

:-)  :-)



[gentoo-user] Rationalizing log files

2021-05-13 Thread Walter Dnes
  On another thread, I had to dive into into /var/log/messages, and I
realized that it was not being rotated.  It's 32 megabytes+, most of
which is iptables reject messages for Facebook trackers.  What do I need
to do to get log rotation working?

/etc/logrotate.conf



#
# Default logrotate(8) configuration file for Gentoo Linux.
# See "man logrotate" for details.

# rotate log files weekly.
weekly
#daily

# keep 4 weeks worth of backlogs.
rotate 4

# create new (empty) log files after rotating old ones.
create

# use date as a suffix of the rotated file.
dateext

# compress rotated log files.
compress

notifempty
nomail
noolddir

# packages can drop log rotation information into this directory.
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here.
/var/log/wtmp {
monthly
create 0664 root utmp
minsize 1M
rotate 1
}
/var/log/btmp {
missingok
monthly
create 0600 root utmp
rotate 1
}

# system-specific logs may be also be configured here.



  /etc/logrotate.d contains...
dcron  elog-save-summary  hibernate-script  openrc  rsyncd  syslog-ng



  And maybe either stop logging Facebook, or else log iptables messages
to a separate file (how is that done?).  The Facebook tracker messages
are generated by iptables rules...

-A INPUT -s 31.13.24.0/21 -j FECESBOOK
-A INPUT -s 31.13.64.0/18 -j FECESBOOK
-A INPUT -s 66.220.144.0/20 -j FECESBOOK
-A INPUT -s 69.63.176.0/20 -j FECESBOOK
-A INPUT -s 69.171.224.0/19 -j FECESBOOK
-A INPUT -s 74.119.76.0/22 -j FECESBOOK
-A INPUT -s 103.4.96.0/22 -j FECESBOOK
-A INPUT -s 173.252.64.0/18 -j FECESBOOK
-A INPUT -s 204.15.20.0/22 -j FECESBOOK

-A OUTPUT -d 31.13.24.0/21 -j FECESBOOK
-A OUTPUT -d 31.13.64.0/18 -j FECESBOOK
-A OUTPUT -d 66.220.144.0/20 -j FECESBOOK
-A OUTPUT -d 69.63.176.0/20 -j FECESBOOK
-A OUTPUT -d 69.171.224.0/19 -j FECESBOOK
-A OUTPUT -d 74.119.76.0/22 -j FECESBOOK
-A OUTPUT -d 103.4.96.0/22 -j FECESBOOK
-A OUTPUT -d 173.252.64.0/18 -j FECESBOOK
-A OUTPUT -d 204.15.20.0/22 -j FECESBOOK

-A FECESBOOK -j LOG --log-prefix "FECESBOOK:" --log-level 6
-A FECESBOOK -j REJECT --reject-with icmp-port-unreachable

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications



Re: [gentoo-user] Approx monthly hard lockups

2021-05-13 Thread Walter Dnes
On Wed, May 12, 2021 at 09:50:29PM -0500, Dale wrote
> Walter Dnes wrote:
> > On Wed, May 12, 2021 at 11:16:56AM -0700, Mark Knecht wrote
> >> Is there nothing in the system logs? What's near the end before whatever
> >> you get from booting after this issue?
> >   Where would those logfiles be?  "dmesg" starts off with...
> >
> 
> 
> Most likely in /var/log/messages. The bad thing about dmesg, I think it
> resets when rebooting which erases previous info.
> 
> As Mark pointed out, you need to go back to the time before it starts
> adding the boot up process.

  No help.  /var/log/messages goes straight from iptables messages to
bootup with no indication of shutdown...

May 12 11:26:31 i3 kernel: FECESBOOK:IN= OUT=eth0 SRC=192.168.1.249 
DST=31.13.80.12 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=5824 DF PROTO=TCP SPT=50566 
DPT=443 WINDOW=64170 RES=0x00 SYN URGP=0
May 12 11:26:32 i3 kernel: FECESBOOK:IN= OUT=eth0 SRC=192.168.1.249 
DST=31.13.80.12 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=60152 DF PROTO=TCP 
SPT=50568 DPT=443 WINDOW=64170 RES=0x00 SYN URGP=0
May 12 11:34:04 i3 syslog-ng[1384]: syslog-ng starting up; version='3.30.1'
May 12 11:34:04 i3 crond[1414]: /usr/sbin/crond 4.5 dillon's cron daemon, 
started with loglevel notice
May 12 11:34:04 i3 /usr/sbin/gpm[1443]: *** info [daemon/startup.c(136)]:
May 12 11:34:04 i3 /usr/sbin/gpm[1443]: Started gpm successfully. Entered 
daemon mode.

  When doing a regular shutdown I get stuff like...

May 12 11:42:31 i3 shutdown[1974]: shutting down for system reboot
May 12 11:42:31 i3 init[1]: Switching to runlevel: 6
May 12 11:42:32 i3 init[1]: Trying to re-exec init
May 12 11:42:32 i3 start-stop-daemon[2053]: Will stop /usr/sbin/sshd
May 12 11:42:32 i3 start-stop-daemon[2053]: Will stop PID 1764
May 12 11:42:32 i3 start-stop-daemon[2053]: Sending signal 15 to PID 1764
May 12 11:42:32 i3 sshd[1764]: Received signal 15; terminating.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications