Re: [gentoo-user] Nvidia driver plus kernel info questions

2020-05-02 Thread tuxic
On 05/02 03:42, Scott Ellis wrote:
> On Sat, May 2, 2020 at 10:33 AM  wrote:
> >
> > Unfortunatelu "something" is broken, when using the portage version
> > of the driver. So I removed that driver and installed the same
> > version as offered by nvidia directlu and that worked.
> >
> 
> There's a lot missing in the portage version of the driver - it
> doesn't even (at least last I checked) install nvidia-ml.so unless
> you're using X.  I suspect your weren't getting libnvoptix installed
> from portage, which was meaning OptiX won't work.
> 
> I don't really care for the `.run` version of the drivers, and prefer
> to keep everything as an ebuild.  I have my hacked up ebuild at
> https://github.com/ScottESanDiego/scotterepo/tree/master/x11-drivers/nvidia-drivers
> if you wanted to just steal that (it's largely just the original
> ebuild, but installing extra "stuff" so that nvidia-smi works
> headless, nvidia-docker works, etc.
> 
>ScottE
> 

Hi Scott,

oh! :) Thank you very much ... is cloned! :)

Cheers!
Meino





Re: [gentoo-user] 32GB RAM and Swap

2020-05-02 Thread Серега Филатов
I want to say that it really depends on this:

- What do you do on your system (what applications do you use, what DE, how
is your production ram-hungry, maybe it is some large application that
you're contributing on)
- How do you do things on your system (shutting down machine every day or
suspending it with 1-2 months+ uptime, using only apps you need or leaving
plenty of them running in the background, cleaning out tabs in your browser
or leaving them always opened in case you need them)
- You're using hibernation (if so, you definitely need swap large enough to
contain the whole contents of your ram)
- Your expectations of the need in swap in the next couple of years (and
you really SHOULD expect this. Personally I considered recently that 4 GB
is enough for all my needs and now I don't know how to even browse the
modern internet with it). You can have a swap in this case for the future.
Or if your system will live for couple of years without reinstallation
you'll consider that you need swap, so you'll repartition your drive, maybe
it'll get full of data to this time and you need to clean it up first,
maybe you'll need to backup your data before repartitioning, and so on...
It might take a long time in the future.

The first time I heard the "oh, you don't really need swap now, it's plenty
of ram in modern machines" was mid-2000s. Back then I had a 512MB RAM
machine (you'll not get modern fancy browser on it!).
And then every 2-3 years I hear that. But I still end up creating a swap
partition on every new machine I have.


On Fri, May 1, 2020, 23:50 Raphael MD  wrote:

> Hello!
>
> Could I turn my Linux swap off.
> I have 32 GB of RAM memory, I suppose my system don’t need swap, because
> I’vea lot of RAM, is this true?
>
> Thanks
> --
> M.S. Raphael Mejias Dias
> ​Nuclear Engineer | Reactors
>
> Secure e-mail: raphael.mejias.d...@protonmail.com
> PGP Key for raph...@gmail.com:
> https://pgp.mit.edu/pks/lookup?op=get=0x87BC5A746072F951
>


Re: [gentoo-user] Nvidia driver plus kernel info questions

2020-05-02 Thread Scott Ellis
On Sat, May 2, 2020 at 10:33 AM  wrote:
>
> Unfortunatelu "something" is broken, when using the portage version
> of the driver. So I removed that driver and installed the same
> version as offered by nvidia directlu and that worked.
>

There's a lot missing in the portage version of the driver - it
doesn't even (at least last I checked) install nvidia-ml.so unless
you're using X.  I suspect your weren't getting libnvoptix installed
from portage, which was meaning OptiX won't work.

I don't really care for the `.run` version of the drivers, and prefer
to keep everything as an ebuild.  I have my hacked up ebuild at
https://github.com/ScottESanDiego/scotterepo/tree/master/x11-drivers/nvidia-drivers
if you wanted to just steal that (it's largely just the original
ebuild, but installing extra "stuff" so that nvidia-smi works
headless, nvidia-docker works, etc.

   ScottE



Re: [gentoo-user] Trouble with backup harddisks

2020-05-02 Thread tuxic
On 05/02 06:31, Wols Lists wrote:
> On 02/05/20 02:42, tu...@posteo.de wrote:
> > On 05/01 09:27, antlists wrote:
> >> On 01/05/2020 09:03, tu...@posteo.de wrote:
> >>> Hi Wol,
> >>>
> >>> data copied !:)
> >>>
> >>> I did a
> >>>
> >>>  mdadm --examine /dev/sdb
> >>
> >> Except I pointed you at a utility called lsdrv, not mdadm ... :-)
> >>
> >> Cheers,
> >> Wol
> >>
> > 
> > Hi Wol,
> > 
> > Ouuouud...oh damn! Sorry, Wol...
> > 
> > I donwloaded the lsdrv from github and this is, what it prints
> > 
> >   File "./lsdrv", line 323
> > os.mkdir('/dev/block', 0755)
> >   ^
> > SyntaxError: leading zeros in decimal integer literals are not permitted; 
> > use an 0o prefix for octal integers
> > [1]4367 exit 1 ./lsdrv
> > 
> > 
> > Seems a little buggy...
> > 
> did you read the note that says it is a Python 2 script? Unless it's
> been updated (I haven't checked) you need to change the shebang line to
> force python2.
> 
> Cheers,
> Wol
> 
> 

Hi Wol,

the shebang was already changed. It onlu works, when called like

python2.7 lsdrv 

for me.

The output is similiar to what lsblk creates...

Cheers!
Meino





Re: [gentoo-user] Trouble with backup harddisks

2020-05-02 Thread tuxic
On 05/02 06:31, Wols Lists wrote:
> On 02/05/20 02:42, tu...@posteo.de wrote:
> > On 05/01 09:27, antlists wrote:
> >> On 01/05/2020 09:03, tu...@posteo.de wrote:
> >>> Hi Wol,
> >>>
> >>> data copied !:)
> >>>
> >>> I did a
> >>>
> >>>  mdadm --examine /dev/sdb
> >>
> >> Except I pointed you at a utility called lsdrv, not mdadm ... :-)
> >>
> >> Cheers,
> >> Wol
> >>
> > 
> > Hi Wol,
> > 
> > Ouuouud...oh damn! Sorry, Wol...
> > 
> > I donwloaded the lsdrv from github and this is, what it prints
> > 
> >   File "./lsdrv", line 323
> > os.mkdir('/dev/block', 0755)
> >   ^
> > SyntaxError: leading zeros in decimal integer literals are not permitted; 
> > use an 0o prefix for octal integers
> > [1]4367 exit 1 ./lsdrv
> > 
> > 
> > Seems a little buggy...
> > 
> did you read the note that says it is a Python 2 script? Unless it's
> been updated (I haven't checked) you need to change the shebang line to
> force python2.
> 
> Cheers,
> Wol
> 
> 

Hi,

ok...will try that - thanks for the info !!! :)

Cheers!
Meino





Re: [gentoo-user] Nvidia driver plus kernel info questions

2020-05-02 Thread Dale
tu...@posteo.de wrote:
> On 05/02 11:53, Dale wrote:
>> Howdy,
>>
>> I mentioned in another thread that I was going to upgrade to a much
>> newer kernel.  I also have to make sure Nvidia supports that kernel. 
>> So, I went to the Nvidia site and did a search by model number.  This is
>> the output of lspci:
>>
>>
>> 01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX
>> 650] (rev a1)
>>
>>
>> So, I did the manual thing, since this is Linux not windoze, and
>> selected the series and model.  According to the list it provided, I
>> should be using the drivers in the 440 slot.  I'm currently using the
>> 390 slot since when I installed that card, that is what it showed.  I'm
>> almost 100% certain I checked this when installing this card.  My
>> question is, is it normal for nvidia to change the series of drivers for
>> cards like this?  Am I reading this wrong?  Link to Nvidia site.
>>
>> https://www.geforce.com/drivers
>>
>> I couldn't provide a link to the selected part since it doesn't seem to
>> provide one, java stuff I guess.  Next link I went too. 
>>
>> https://www.nvidia.com/en-us/drivers/results/159360/
>>
>> According to that the 440 series supports the 5.6 series of kernel.  It
>> doesn't indicate a specific version tho.  Does that mean I can go to the
>> very latest version or do I need to look elsewhere to see what is
>> supported?  If it matters, I use gentoo-sources.  Currently on 4.19.40
>> and I'm showing gentoo-sources-5.6.7 as the latest available in the
>> tree.  Since I don't upgrade kernels much, may as well take a large
>> leap.  ;-)
>>
>> Thanks much.  A little confused. 
>>
>> Dale
>>
>> :-)  :-)
>>
>> P. S. Got my garden about half disced. Dry side about ready to plant and
>> wet side is lightly disced to help it dry out.  :-D
>>
> Hi Dale, 
>
> I am now running kernel 5.6.9 (vanilla) and nvidia-driver 440.82-r3.
>
> Again, Blender cannot find the Optix related parts of the driver.
> This package still does not work for me. As far as I can see,
> the non-Optix specific things are fine, though.
>
> So I will reboot, remove the portage package of the driver and
> install the original by nvidia and this will fix the issue
> with Optix...
>
> Cheers!
> Meino

Thanks for the info.  Now I think I'm good to go. 

Dale

:-)  :-) 


Re: [gentoo-user] Nvidia driver plus kernel info questions

2020-05-02 Thread Dale
Wynn Wolf Arbor wrote:
> Hi,
>
>> I'm currently using the 390 slot since when I installed that card,
>> that is what it showed.  I'm almost 100% certain I checked this when
>> installing this card. My question is, is it normal for nvidia to
>> change the series of drivers for cards like this?
>
> A driver series is not necessarily bound to a specific card, so it is
> normal to see newer driver series supporting older devices. I'd assume
> that 390 was the current stable series back when you checked it. The
> current series is 440.
>
> For the current series, you also have drivers separated into a
> "long-lived" and a "short-lived" branch - as far as I know that only
> marks how long a driver receives official support, but don't quote me
> on that.
>
> The most recent driver is 440.82 in the long-lived branch. You can
> find a list of all Unix drivers at [1] without having to fill out any
> forms.
>
> Then there's also the legacy driver series specifically for devices
> that the current driver no longer supports. A GTX 480 card, for
> example, would need the 390 series. There's a list at [2] and more
> info about support timeframes at [3].
>
>> According to that the 440 series supports the 5.6 series of kernel.
>> It doesn't indicate a specific version tho. Does that mean I can go
>> to the very latest version or do I need to look elsewhere to see what
>> is supported?
>
> In this case you can go with the very latest release, yes. Any future
> 440.* driver will work for you.
>
> Once a new series is released (I don't know how frequent that is) you
> might want to check whether your card still supports that, however.
>
> Hope this helped clear up the confusion.
>
> [1] https://www.nvidia.com/en-us/drivers/unix/
> [2] https://www.nvidia.com/en-us/drivers/unix/legacy-gpu/
> [3] https://nvidia.custhelp.com/app/answers/detail/a_id/3142
>


That does make sense.  Maybe it was something I recall from a long time
ago but I thought a series of drivers was designed for certain cards and
those drivers were the only ones to be used.  Either I recall that
wrongly or it changed.  Either way.  At least now I can get the latest
kernel and the latest nvidia and give it a go.  I might add, I'm bad to
use older cards.  I buy used or new but on a really good sale.  ;-)  I'm
not to demanding on video cards really.  The biggest thing, it outputs
to my monitor like I look at when typing now and it also outputs to my
TV which is playing Bones at the moment.  Next week it may be Columbo or
Scooby Doo.  ROFL 

Thanks much.  Helped a lot. 

Dale

:-)  :-) 



Re: [gentoo-user] Nvidia driver plus kernel info questions

2020-05-02 Thread tuxic
On 05/02 11:53, Dale wrote:
> Howdy,
> 
> I mentioned in another thread that I was going to upgrade to a much
> newer kernel.  I also have to make sure Nvidia supports that kernel. 
> So, I went to the Nvidia site and did a search by model number.  This is
> the output of lspci:
> 
> 
> 01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX
> 650] (rev a1)
> 
> 
> So, I did the manual thing, since this is Linux not windoze, and
> selected the series and model.  According to the list it provided, I
> should be using the drivers in the 440 slot.  I'm currently using the
> 390 slot since when I installed that card, that is what it showed.  I'm
> almost 100% certain I checked this when installing this card.  My
> question is, is it normal for nvidia to change the series of drivers for
> cards like this?  Am I reading this wrong?  Link to Nvidia site.
> 
> https://www.geforce.com/drivers
> 
> I couldn't provide a link to the selected part since it doesn't seem to
> provide one, java stuff I guess.  Next link I went too. 
> 
> https://www.nvidia.com/en-us/drivers/results/159360/
> 
> According to that the 440 series supports the 5.6 series of kernel.  It
> doesn't indicate a specific version tho.  Does that mean I can go to the
> very latest version or do I need to look elsewhere to see what is
> supported?  If it matters, I use gentoo-sources.  Currently on 4.19.40
> and I'm showing gentoo-sources-5.6.7 as the latest available in the
> tree.  Since I don't upgrade kernels much, may as well take a large
> leap.  ;-)
> 
> Thanks much.  A little confused. 
> 
> Dale
> 
> :-)  :-)
> 
> P. S. Got my garden about half disced. Dry side about ready to plant and
> wet side is lightly disced to help it dry out.  :-D
> 

Hi Dale, 

I am now running kernel 5.6.9 (vanilla) and nvidia-driver 440.82-r3.

Again, Blender cannot find the Optix related parts of the driver.
This package still does not work for me. As far as I can see,
the non-Optix specific things are fine, though.

So I will reboot, remove the portage package of the driver and
install the original by nvidia and this will fix the issue
with Optix...

Cheers!
Meino





Re: [gentoo-user] Nvidia driver plus kernel info questions

2020-05-02 Thread Wynn Wolf Arbor

Hi,

I'm currently using the 390 slot since when I installed that card, 
that is what it showed.  I'm almost 100% certain I checked this when 
installing this card. My question is, is it normal for nvidia to 
change the series of drivers for cards like this?


A driver series is not necessarily bound to a specific card, so it is 
normal to see newer driver series supporting older devices. I'd assume 
that 390 was the current stable series back when you checked it. The 
current series is 440.


For the current series, you also have drivers separated into a 
"long-lived" and a "short-lived" branch - as far as I know that only 
marks how long a driver receives official support, but don't quote me on 
that.


The most recent driver is 440.82 in the long-lived branch. You can find 
a list of all Unix drivers at [1] without having to fill out any forms.


Then there's also the legacy driver series specifically for devices that 
the current driver no longer supports. A GTX 480 card, for example, 
would need the 390 series. There's a list at [2] and more info about 
support timeframes at [3].


According to that the 440 series supports the 5.6 series of kernel. It 
doesn't indicate a specific version tho. Does that mean I can go to 
the very latest version or do I need to look elsewhere to see what is 
supported?


In this case you can go with the very latest release, yes. Any future 
440.* driver will work for you.


Once a new series is released (I don't know how frequent that is) you 
might want to check whether your card still supports that, however.


Hope this helped clear up the confusion.

[1] https://www.nvidia.com/en-us/drivers/unix/
[2] https://www.nvidia.com/en-us/drivers/unix/legacy-gpu/
[3] https://nvidia.custhelp.com/app/answers/detail/a_id/3142

--
Wolf



Re: [gentoo-user] Nvidia driver plus kernel info questions

2020-05-02 Thread tuxic
On 05/02 11:53, Dale wrote:
> Howdy,
> 
> I mentioned in another thread that I was going to upgrade to a much
> newer kernel.  I also have to make sure Nvidia supports that kernel. 
> So, I went to the Nvidia site and did a search by model number.  This is
> the output of lspci:
> 
> 
> 01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX
> 650] (rev a1)
> 
> 
> So, I did the manual thing, since this is Linux not windoze, and
> selected the series and model.  According to the list it provided, I
> should be using the drivers in the 440 slot.  I'm currently using the
> 390 slot since when I installed that card, that is what it showed.  I'm
> almost 100% certain I checked this when installing this card.  My
> question is, is it normal for nvidia to change the series of drivers for
> cards like this?  Am I reading this wrong?  Link to Nvidia site.
> 
> https://www.geforce.com/drivers
> 
> I couldn't provide a link to the selected part since it doesn't seem to
> provide one, java stuff I guess.  Next link I went too. 
> 
> https://www.nvidia.com/en-us/drivers/results/159360/
> 
> According to that the 440 series supports the 5.6 series of kernel.  It
> doesn't indicate a specific version tho.  Does that mean I can go to the
> very latest version or do I need to look elsewhere to see what is
> supported?  If it matters, I use gentoo-sources.  Currently on 4.19.40
> and I'm showing gentoo-sources-5.6.7 as the latest available in the
> tree.  Since I don't upgrade kernels much, may as well take a large
> leap.  ;-)
> 
> Thanks much.  A little confused. 
> 
> Dale
> 
> :-)  :-)
> 
> P. S. Got my garden about half disced. Dry side about ready to plant and
> wet side is lightly disced to help it dry out.  :-D
> 

Hi Dale,

hopefully I understood your question correctlu...

I am running currently the nividia 440.82 (not that one which 
portage...more in a second) with Linux kernel 5.6.8 and a
RTX 2060 SUPER jsut fine.

I few minutes before I had compiled kernel 5.6.9 but hadn't
rebooted my Linux yet.

I am using Blender, which starts to support Optix based rendering,
which is faster than "normal" GPU rendering.

Unfortunatelu "something" is broken, when using the portage version
of the driver. So I removed that driver and installed the same
version as offered by nvidia directlu and that worked.

This problem effects only Blender...as far as I know.

And: I haven't tried nvidia-440.82-r3 which is quite new. Will
try that when booting the new kernel and report later.

HTH!
Cheers!
Meino





Re: [gentoo-user] Trouble with backup harddisks

2020-05-02 Thread Wols Lists
On 02/05/20 02:42, tu...@posteo.de wrote:
> On 05/01 09:27, antlists wrote:
>> On 01/05/2020 09:03, tu...@posteo.de wrote:
>>> Hi Wol,
>>>
>>> data copied !:)
>>>
>>> I did a
>>>
>>>  mdadm --examine /dev/sdb
>>
>> Except I pointed you at a utility called lsdrv, not mdadm ... :-)
>>
>> Cheers,
>> Wol
>>
> 
> Hi Wol,
> 
> Ouuouud...oh damn! Sorry, Wol...
> 
> I donwloaded the lsdrv from github and this is, what it prints
> 
>   File "./lsdrv", line 323
> os.mkdir('/dev/block', 0755)
>   ^
> SyntaxError: leading zeros in decimal integer literals are not permitted; use 
> an 0o prefix for octal integers
> [1]4367 exit 1 ./lsdrv
> 
> 
> Seems a little buggy...
> 
did you read the note that says it is a Python 2 script? Unless it's
been updated (I haven't checked) you need to change the shebang line to
force python2.

Cheers,
Wol




[gentoo-user] Nvidia driver plus kernel info questions

2020-05-02 Thread Dale
Howdy,

I mentioned in another thread that I was going to upgrade to a much
newer kernel.  I also have to make sure Nvidia supports that kernel. 
So, I went to the Nvidia site and did a search by model number.  This is
the output of lspci:


01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX
650] (rev a1)


So, I did the manual thing, since this is Linux not windoze, and
selected the series and model.  According to the list it provided, I
should be using the drivers in the 440 slot.  I'm currently using the
390 slot since when I installed that card, that is what it showed.  I'm
almost 100% certain I checked this when installing this card.  My
question is, is it normal for nvidia to change the series of drivers for
cards like this?  Am I reading this wrong?  Link to Nvidia site.

https://www.geforce.com/drivers

I couldn't provide a link to the selected part since it doesn't seem to
provide one, java stuff I guess.  Next link I went too. 

https://www.nvidia.com/en-us/drivers/results/159360/

According to that the 440 series supports the 5.6 series of kernel.  It
doesn't indicate a specific version tho.  Does that mean I can go to the
very latest version or do I need to look elsewhere to see what is
supported?  If it matters, I use gentoo-sources.  Currently on 4.19.40
and I'm showing gentoo-sources-5.6.7 as the latest available in the
tree.  Since I don't upgrade kernels much, may as well take a large
leap.  ;-)

Thanks much.  A little confused. 

Dale

:-)  :-)

P. S. Got my garden about half disced. Dry side about ready to plant and
wet side is lightly disced to help it dry out.  :-D



Re: [gentoo-user] Listing kernel modules

2020-05-02 Thread Peter Humphrey
On Saturday, 2 May 2020 14:32:22 BST Consus wrote:
> On Sat, May 02, 2020 at 04:29:38PM +0300, Consus wrote:
> > On Sat, May 02, 2020 at 02:19:18PM +0100, Peter Humphrey wrote:
> > > Afternoon all,
> > > 
> > > Is there a straightforward way of listing kernel modules that exist
> > > but haven't been loaded?
> > 
> > This will do I guess:
> > # lsmod | awk '{print $1}' > inserted
> > # find /lib/modules/$(uname -r) -name '*.ko' -printf '%f\n' | sed
> > 's/\.ko$//' > present # cat inserted present | sort -u
> 
> Wait, no, replace the last line with:
> 
>   # cat inserted present | sort | uniq -u

Very good - thanks. Now I have a 183-line list of module names to go through.
:(  And of course, the module names differ from the corresponding config 
options.

Still, it does give me some useful pointers to bunches of modules I specified 
to find out which one I needed.

-- 
Regards,
Peter.






Re: [gentoo-user] 32GB RAM and Swap

2020-05-02 Thread Dale
Michael wrote:
> On Saturday, 2 May 2020 10:54:02 BST Dale wrote:
>> Michael wrote:
>>> I'd be interested to know as a comparison if Nikos' and Dale's I/O
>>> unresponsiveness in swapping sees an improvement with the I/O scheduler
>>> for
>>> spinning drives set to bfq; e.g.:
>>>
>>> echo bfq > /sys/block/sda/queue/scheduler
>> This is its setting at the moment. 
>>
>>
>> root@fireball / # cat /sys/block/sda/queue/scheduler
>> noop deadline [cfq]
>> root@fireball / #
> Ahh, you must be on an older kernel?
>
> I'm on 5.4.28 here and these are the new kernel scheduler options:
>
> #
> # IO Schedulers
> #
> CONFIG_MQ_IOSCHED_DEADLINE=y
> CONFIG_MQ_IOSCHED_KYBER=y
> CONFIG_IOSCHED_BFQ=y
> CONFIG_BFQ_GROUP_IOSCHED=y
> # CONFIG_BFQ_CGROUP_DEBUG is not set
> # end of IO Schedulers
>
> The BFQ scheduler has a number of tunable parameters via sysctl, like weight, 
> latency and what not, but unless you're into running endless benchmark tests 
> to tune your particular devices, I'd leave it to do its thing with default 
> settings.
>


Yea, I got new UPS batteries coming which means a complete power down. 
I may upgrade my kernel before doing that.  It slipped my mind so glad
this came up.  I'm on 4.19.40-gentoo but I need to see what is the
latest version nvidia-drivers supports first.  I guess I'll google that
or something. 


>> I know I can echo it in but where do I set that to that when booting? 
> You can set a local script to switch from other schedulers - the default is 
> mq-deadline - or you can disable the others in the kernel.  I don't know if 
> you can pass an option to the kernel line at boot time.
>
> I understand this is more effective with slow(er) spinning drives and perhaps 
> old SSDs.  NVMe drives won't benefit from it and are better run with the 
> default mq-deadline scheduler.


I googled it, it seems it gets added to the kernel line options via
grub2's conf file.  I have another option there too, IOMMU or something
like that. 

Right now, it's off to the tractor and discing up my garden.  So much
rain lately, I'm just now able to get a tractor in it.  New disc is
awesome tho. 

Oh, for future reference:


# cat /etc/sysconfig/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos/root 
rd.lvm.lv=centos/swap rhgb quiet elevator=cfq"
GRUB_DISABLE_RECOVERY="true"



It's the 2nd line from the bottom.  It may be configurable in menuconfig too. I 
dunno know yet.  I'll try to look.  Must make note to upgrade kernel.  
Batteries will be here Monday.  

Thanks much.  It's on my todo list.

Dale

:-)  :-)  



Re: [gentoo-user] 32GB RAM and Swap

2020-05-02 Thread William Kenworthy
I am afraid this is an ".. it depends" question.

If you work with large images or data sets, swap can be really handy. 
If you are doing a little programming, web browsing, reading email you
will *probably* be ok, but why risk it?

I have a 32gb ram in a master server for an mfs filesystem - it normally
sits at about 5GB of ram - however it can go well over 32Gb into swap at
times - the first machine I tried it with only had 4gb ram and crashed
when it filled the ram, and 8g swap taking the test file system with it
- its now production so I am not going to risk it by underprovisioning
swap.  My 32Gb desktop is not using any swap at the moment ... but it
has used it at times. 

So, yes its quite likely you wont use swap - but if you do something
that needs it, it can help avoid a very messy crash.

Swap is slow, but if you actually need it - its probably critical that
you have it!  Unless you are really short of disk space, treat it as
insurance :)

Look into using swapfiles instead of partitions for flexibility, and the
sysctl values of "vm.swappiness" and "vm.vfs_cache_pressure" to manage
swap usage (you can set to not use swap until it really has to - some
have seen the kernel being too eager to swap out causing slowdowns,
though you can make it go in the other direction and "thrash" when it
actually needs to use swap if you go to far.  The default kernel swap
mechanism isn't really that bad!

So yes, most of my machines don't need swap *right now* and swap looks
like its not being used so it could be removed, but I cant guarantee
that they never will, and having years of experience using swap I
recommend that its better to be cautious and survive :)

BillK


On 2/5/20 3:50 am, Raphael MD wrote:
> Hello!
>
> Could I turn my Linux swap off.
> I have 32 GB of RAM memory, I suppose my system don’t need swap,
> because I’vea lot of RAM, is this true?
>
> Thanks
> -- 
> M.S. Raphael Mejias Dias
> ​Nuclear Engineer | Reactors
>
> Secure e-mail: raphael.mejias.d...@protonmail.com
> 
> PGP Key for raph...@gmail.com :
> https://pgp.mit.edu/pks/lookup?op=get=0x87BC5A746072F951


pEpkey.asc
Description: application/pgp-keys


Re: [gentoo-user] Listing kernel modules

2020-05-02 Thread Jack

On 5/2/20 9:19 AM, Peter Humphrey wrote:

Afternoon all,

Is there a straightforward way of listing kernel modules that exist but
haven't been loaded? I'm sure I have quite a number that I don't need, and I'd
like to remove them from the kernel config.
How about just grepping for them under /lib/modules/version?  In my case 
it would be *.ko.xz.  Note that won't tell you about anything built in 
to the kernal you might want to remove.  Otherwise, it's just a slow 
slog through make xconfig or make menuconfig. I suppose you could also 
grep through the kernel's .config file (or /proc/sys/config.gz) for 
"=m".  In both cases, you probably still need to search to figure out 
where in the configuration that gets set.




Re: [gentoo-user] Listing kernel modules

2020-05-02 Thread Consus
On Sat, May 02, 2020 at 04:29:38PM +0300, Consus wrote:
> On Sat, May 02, 2020 at 02:19:18PM +0100, Peter Humphrey wrote:
> > Afternoon all,
> > 
> > Is there a straightforward way of listing kernel modules that exist
> > but haven't been loaded?
> 
> This will do I guess:
> 
>   # lsmod | awk '{print $1}' > inserted
>   # find /lib/modules/$(uname -r) -name '*.ko' -printf '%f\n' | sed 
> 's/\.ko$//' > present
>   # cat inserted present | sort -u

Wait, no, replace the last line with:

# cat inserted present | sort | uniq -u



Re: [gentoo-user] Listing kernel modules

2020-05-02 Thread Consus
On Sat, May 02, 2020 at 02:19:18PM +0100, Peter Humphrey wrote:
> Afternoon all,
> 
> Is there a straightforward way of listing kernel modules that exist
> but haven't been loaded?

This will do I guess:

# lsmod | awk '{print $1}' > inserted
# find /lib/modules/$(uname -r) -name '*.ko' -printf '%f\n' | sed 
's/\.ko$//' > present
# cat inserted present | sort -u



[gentoo-user] Listing kernel modules

2020-05-02 Thread Peter Humphrey
Afternoon all,

Is there a straightforward way of listing kernel modules that exist but 
haven't been loaded? I'm sure I have quite a number that I don't need, and I'd 
like to remove them from the kernel config.

-- 
Regards,
Peter.






Re: [gentoo-user] 32GB RAM and Swap

2020-05-02 Thread Michael
On Saturday, 2 May 2020 10:54:02 BST Dale wrote:
> Michael wrote:

> > I'd be interested to know as a comparison if Nikos' and Dale's I/O
> > unresponsiveness in swapping sees an improvement with the I/O scheduler
> > for
> > spinning drives set to bfq; e.g.:
> > 
> > echo bfq > /sys/block/sda/queue/scheduler
> 
> This is its setting at the moment. 
> 
> 
> root@fireball / # cat /sys/block/sda/queue/scheduler
> noop deadline [cfq]
> root@fireball / #

Ahh, you must be on an older kernel?

I'm on 5.4.28 here and these are the new kernel scheduler options:

#
# IO Schedulers
#
CONFIG_MQ_IOSCHED_DEADLINE=y
CONFIG_MQ_IOSCHED_KYBER=y
CONFIG_IOSCHED_BFQ=y
CONFIG_BFQ_GROUP_IOSCHED=y
# CONFIG_BFQ_CGROUP_DEBUG is not set
# end of IO Schedulers

The BFQ scheduler has a number of tunable parameters via sysctl, like weight, 
latency and what not, but unless you're into running endless benchmark tests 
to tune your particular devices, I'd leave it to do its thing with default 
settings.


> I know I can echo it in but where do I set that to that when booting? 

You can set a local script to switch from other schedulers - the default is 
mq-deadline - or you can disable the others in the kernel.  I don't know if 
you can pass an option to the kernel line at boot time.

I understand this is more effective with slow(er) spinning drives and perhaps 
old SSDs.  NVMe drives won't benefit from it and are better run with the 
default mq-deadline scheduler.


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] 32GB RAM and Swap

2020-05-02 Thread Dale
Michael wrote:
> On Saturday, 2 May 2020 09:53:06 BST Dale wrote:
>> Wols Lists wrote:
>>> On 01/05/20 21:29, Dale wrote:
 It gets really slow to respond when it uses swap but it beats crashing.
 Just set swapiness to a low number.  I think mine is set to 10.

 Given the cheapness of hard drives, I'm not sure why having several
 gigabytes of swap space is of much concern.  I have the same amount of
 ram as you and I have a 12GB swap space.  I use LVM so I can grow it if
 needed or just add another swap space.  I might add, I've seen times
 where it gets used.
>>> That first paragraph is why too much swap space is bad - if an app goes
>>> rogue it can kill system response and make regaining control of the
>>> system a nightmare.
>>>
>>> Accidentally or on purpose, if a system runs out of ram and starts
>>> thrashing, you're in big trouble if it's an app eating memory like no
>>> tomorrow.
>>>
>>> Cheers,
>>> Wol
>>>
>>> .
>> That's why I set swapiness to a low number.  I don't want it to use swap
>> unless it is to prevent a crash.  If I set it to a higher number, it
>> wants to use swap even when there is memory available.  Once it starts
>> using swap, it gets slow.  The more it uses, the worse it gets. 
>> However, it beats it rebooting without umounting partitions and such. 
>> If nothing else, it may give me time to use the alt-sys sequence. 
>>
>> I'm maxed out on memory at the moment but wish I could get and afford
>> 64GBs, in a way.  Still, I'd have a swap partition. 
>>
>> Dale
>>
>> :-)  :-)
> I'd be interested to know as a comparison if Nikos' and Dale's I/O 
> unresponsiveness in swapping sees an improvement with the I/O scheduler for 
> spinning drives set to bfq; e.g.:
>
> echo bfq > /sys/block/sda/queue/scheduler

This is its setting at the moment. 


root@fireball / # cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
root@fireball / #


I know I can echo it in but where do I set that to that when booting? 
Same as swappiness??  I'm willing to set it and see what it does next
time swap pops into gear.  Given it is me, it may not be to long.  LOL 
I have to say, while sddm-helper is still absorbing to much memory, it
is holding steady at around 1GB or 3.3%.  It's nowhere near enough to
test this theory, yet.  :/

Dale

:-)  :-) 


Re: [gentoo-user] 32GB RAM and Swap

2020-05-02 Thread Michael
On Saturday, 2 May 2020 09:53:06 BST Dale wrote:
> Wols Lists wrote:
> > On 01/05/20 21:29, Dale wrote:
> >> It gets really slow to respond when it uses swap but it beats crashing.
> >> Just set swapiness to a low number.  I think mine is set to 10.
> >> 
> >> Given the cheapness of hard drives, I'm not sure why having several
> >> gigabytes of swap space is of much concern.  I have the same amount of
> >> ram as you and I have a 12GB swap space.  I use LVM so I can grow it if
> >> needed or just add another swap space.  I might add, I've seen times
> >> where it gets used.
> > 
> > That first paragraph is why too much swap space is bad - if an app goes
> > rogue it can kill system response and make regaining control of the
> > system a nightmare.
> > 
> > Accidentally or on purpose, if a system runs out of ram and starts
> > thrashing, you're in big trouble if it's an app eating memory like no
> > tomorrow.
> > 
> > Cheers,
> > Wol
> > 
> > .
> 
> That's why I set swapiness to a low number.  I don't want it to use swap
> unless it is to prevent a crash.  If I set it to a higher number, it
> wants to use swap even when there is memory available.  Once it starts
> using swap, it gets slow.  The more it uses, the worse it gets. 
> However, it beats it rebooting without umounting partitions and such. 
> If nothing else, it may give me time to use the alt-sys sequence. 
> 
> I'm maxed out on memory at the moment but wish I could get and afford
> 64GBs, in a way.  Still, I'd have a swap partition. 
> 
> Dale
> 
> :-)  :-)

I'd be interested to know as a comparison if Nikos' and Dale's I/O 
unresponsiveness in swapping sees an improvement with the I/O scheduler for 
spinning drives set to bfq; e.g.:

echo bfq > /sys/block/sda/queue/scheduler


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Trouble with backup harddisks

2020-05-02 Thread Michael
On Saturday, 2 May 2020 09:39:12 BST tu...@posteo.de wrote:
> On 05/02 09:49, Andrea Conti wrote:
> > > I think, I feel better if I repartitioning/reformat both drives,
> > > though.
> > 
> > It's not necessary, but if it makes you feel better by all means do so.
> > 
> > > *GPT/MBR
> > > From a discussion based on a "GPT or MBR for my system drive" in
> > > conjunction with UEFI it was said, that GPT is more modern and
> > > save.
> > 
> > More modern I concur. For the rest it's mainly about features: >2TB
> > partitions and way more metadata, plus not having to bother with CHS
> > values which make no sense in today's drives. And being able to define >4
> > partitions without littering the disk with extended boot records, which
> > is probably the only thing I'd call "safer".
> > 
> > My point was that none of this is relevant in an external drive which is
> > under 1TB and will only hold a single partition starting at sector 1 and
> > spanning the rest of the disk. A system drive, especially if booting from
> > UEFI is a different case for which GPT absolutely makes sense.
> Ok, the other way around: Does GPT hurt more than MBT on a external HD
> used for backup puporses (no boot), has 1T and 1 partion of that size?

Unless you're planning to boot from Windows XP or some antiquated old LiveCD, 
a GPT partitioning scheme is better in *all* respects and it is more robust 
than MBR because:

- The partitioning tables created by GPT are backed up at the end of the disk.
- GPT uses CRC make sure its data is intact, or will warn of corruption and 
attempt to restore from the back up.


> > > My question was meant not so much as "MBR or GPT?"
> > > but more whether there are some variants of GPT (with
> > > protected MBR for example -- which was completly new to me),
> > > which I should use or avoid.
> > 
> > There are really no "variants" of GPT. The protective MBR is only there to
> > make all space in the disk look allocated to MBR partitioning tools that
> > are not GPT-aware, and is automatically written for you by all GPT
> > partitioning tools.
> > 
> > In addition to the opaque entry of type 0xee, this MBR can also contain
> > entries pointing to at least some of the actual partitions; this is
> > called a 'hybrid' MBR and allows MBR-only access to partitions that are
> > within the limits of MBR addressing (start and end sector <2TB). These
> > are only useful in very specific cases an I would consider them a hack
> > more than a solution; while gpt-fdisk has some support for creating
> > hybrid MBRs (don't know about fdisk), you won't get one unless you
> > specifically ask for it.
> Thanks of the information! :)
> 
> > > But: Are rescue systems for USB-stick more UEFI/GPT aware nowadays
> > > or "traditionally" based on MBR/BIOS-boot?
> > 
> > I think that anything that's not ancient will have tools and kernel
> > support for both MBR and GPT, and will boot fine in both BIOS and UEFI
> > modes.> 
> > > One thing I found is really handy: An USB-stick with an rEfind
> > > installation. As long as your PC supports UEFI (or can switched to it)
> > > rEfind is able to boot "everything" without prior configuration.
> > 
> > You can probably do the same with GRUB2, albeit in a way less
> > user-friendly fashion :) But why do you consider the ability to boot
> > anything but the rescue system itself important in a rescue system?
> Recently a BIOS update deleted all UEFI entries and the system no
> longer boots. With rEfind from a USBstick I was able to boot
> the sustem nonetheless and the reinstallation of grub solves
> the problem.
> Task accomplished! :)
> 
> > > Some rescue-system which really shines and with which you have made good
> > > experiences?
> > 
> > My usual go-to is SystemRescueCD (the old 5.x gentoo-based one).
> > 
> > andrea
> 
> Thanks for the info, Andrea!
> 
> Cheers!
> Meino

Any up to date Linux LiveCD/USB should be able to boot your PC and 
automatically recognise its GPT partitioning.

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Getting rid of unwanted languages (Was: Re: gimp help not available, even with USE doc)

2020-05-02 Thread Dale
Frank Steinmetzger wrote:
> On Thu, Apr 30, 2020 at 10:15:54AM -0500, Dale wrote:
>
>> These settings are from AGES ago.  I think they are still in use tho. 
>>
>> root@fireball / # cat /etc/make.conf | grep lang
>> LANG="en_US"
>> root@fireball / # cat /etc/make.conf | grep L10N
>> L10N="en en-US"
> Just to scratch an itch:
> https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat
>
> ;-)
>


But it works just fine.  ;-)  lol

Dale

:-)  :-)


Re: [gentoo-user] 32GB RAM and Swap

2020-05-02 Thread Dale
Wols Lists wrote:
> On 01/05/20 21:29, Dale wrote:
>> It gets really slow to respond when it uses swap but it beats crashing. 
>> Just set swapiness to a low number.  I think mine is set to 10.
>>
>> Given the cheapness of hard drives, I'm not sure why having several
>> gigabytes of swap space is of much concern.  I have the same amount of
>> ram as you and I have a 12GB swap space.  I use LVM so I can grow it if
>> needed or just add another swap space.  I might add, I've seen times
>> where it gets used.
> That first paragraph is why too much swap space is bad - if an app goes
> rogue it can kill system response and make regaining control of the
> system a nightmare.
>
> Accidentally or on purpose, if a system runs out of ram and starts
> thrashing, you're in big trouble if it's an app eating memory like no
> tomorrow.
>
> Cheers,
> Wol
>
> .
>


That's why I set swapiness to a low number.  I don't want it to use swap
unless it is to prevent a crash.  If I set it to a higher number, it
wants to use swap even when there is memory available.  Once it starts
using swap, it gets slow.  The more it uses, the worse it gets. 
However, it beats it rebooting without umounting partitions and such. 
If nothing else, it may give me time to use the alt-sys sequence. 

I'm maxed out on memory at the moment but wish I could get and afford
64GBs, in a way.  Still, I'd have a swap partition. 

Dale

:-)  :-)


Re: [gentoo-user] Trouble with backup harddisks

2020-05-02 Thread tuxic
On 05/02 09:49, Andrea Conti wrote:
> > I think, I feel better if I repartitioning/reformat both drives,
> > though.
> 
> It's not necessary, but if it makes you feel better by all means do so.
> 
> > *GPT/MBR
> > From a discussion based on a "GPT or MBR for my system drive" in
> > conjunction with UEFI it was said, that GPT is more modern and
> > save.
> 
> 
> More modern I concur. For the rest it's mainly about features: >2TB 
> partitions and way more metadata, plus not having to bother with CHS values 
> which make no sense in today's drives.
> And being able to define >4 partitions without littering the disk with 
> extended boot records, which is probably the only thing I'd call "safer".
> 
> My point was that none of this is relevant in an external drive which is 
> under 1TB and will only hold a single partition starting at sector 1 and 
> spanning the rest of the disk.
> A system drive, especially if booting from UEFI is a different case for which 
> GPT absolutely makes sense.
> 

Ok, the other way around: Does GPT hurt more than MBT on a external HD
used for backup puporses (no boot), has 1T and 1 partion of that size?


> > My question was meant not so much as "MBR or GPT?" 
> > but more whether there are some variants of GPT (with 
> > protected MBR for example -- which was completly new to me),
> > which I should use or avoid.
> 
> There are really no "variants" of GPT. The protective MBR is only there to 
> make all space in the disk look allocated to MBR partitioning tools that are 
> not GPT-aware, and is automatically written for you by all GPT partitioning 
> tools.
> 
> In addition to the opaque entry of type 0xee, this MBR can also contain 
> entries pointing to at least some of the actual partitions; this is called a 
> 'hybrid' MBR and allows MBR-only access to partitions that are within the 
> limits of MBR addressing (start and end sector <2TB). These are only useful 
> in very specific cases an I would consider them a hack more than a solution; 
> while gpt-fdisk has some support for creating hybrid MBRs (don't know about 
> fdisk), you won't get one unless you specifically ask for it.
>: 

Thanks of the information! :)

> > But: Are rescue systems for USB-stick more UEFI/GPT aware nowadays
> > or "traditionally" based on MBR/BIOS-boot?
> 
> I think that anything that's not ancient will have tools and kernel support 
> for both MBR and GPT, and will boot fine in both BIOS and UEFI modes.
> 
> > One thing I found is really handy: An USB-stick with an rEfind
> > installation. As long as your PC supports UEFI (or can switched to it)
> > rEfind is able to boot "everything" without prior configuration.
> 
> You can probably do the same with GRUB2, albeit in a way less user-friendly 
> fashion :)
> But why do you consider the ability to boot anything but the rescue system 
> itself important in a rescue system?

Recently a BIOS update deleted all UEFI entries and the system no
longer boots. With rEfind from a USBstick I was able to boot
the sustem nonetheless and the reinstallation of grub solves
the problem.
Task accomplished! :)

> > 
> > Some rescue-system which really shines and with which you have made good
> > experiences?
> 
> My usual go-to is SystemRescueCD (the old 5.x gentoo-based one). 
> 
> andrea

Thanks for the info, Andrea!

Cheers!
Meino


 




[gentoo-user] how to partition a dm-crypt disk?

2020-05-02 Thread Caveman Al Toraboran
hi - why can't i use fdisk to partition a dm-crypt
disk?

tried to `sudo fdisk /dev/mapper/ea`, which is created by:

> `sudo cryptsetup open --type plain /dev/sda ea`

fdisk shows my partitions:

> Device  StartEndSectors   Size Type
> /dev/mapper/ea-part1 2048   10487807   10485760 5G Linux filesystem
> /dev/mapper/ea-part2 10487808 1953525134 1943037327 926.5G Linux filesystem

but, as i save that partition table, i get this
error:

> Command (m for help): w
> The partition table has been altered.
> Failed to add partition 1 to system: Invalid argument
> Failed to add partition 2 to system: Invalid argument

if i repeat the execution of fdisk, i see that
partition table, and if i hit `w`, it saves
without showing that error.

then, as i go to run `mkfs.ext4` on them, i can't
see them under `/dev/mapper/`.

rgrds,
cm.




Re: [gentoo-user] Trouble with backup harddisks

2020-05-02 Thread Andrea Conti
> I think, I feel better if I repartitioning/reformat both drives,
> though.

It's not necessary, but if it makes you feel better by all means do so.

> *GPT/MBR
> From a discussion based on a "GPT or MBR for my system drive" in
> conjunction with UEFI it was said, that GPT is more modern and
> save.


More modern I concur. For the rest it's mainly about features: >2TB partitions 
and way more metadata, plus not having to bother with CHS values which make no 
sense in today's drives.
And being able to define >4 partitions without littering the disk with extended 
boot records, which is probably the only thing I'd call "safer".

My point was that none of this is relevant in an external drive which is under 
1TB and will only hold a single partition starting at sector 1 and spanning the 
rest of the disk.
A system drive, especially if booting from UEFI is a different case for which 
GPT absolutely makes sense.

> My question was meant not so much as "MBR or GPT?" 
> but more whether there are some variants of GPT (with 
> protected MBR for example -- which was completly new to me),
> which I should use or avoid.

There are really no "variants" of GPT. The protective MBR is only there to make 
all space in the disk look allocated to MBR partitioning tools that are not 
GPT-aware, and is automatically written for you by all GPT partitioning tools.

In addition to the opaque entry of type 0xee, this MBR can also contain entries 
pointing to at least some of the actual partitions; this is called a 'hybrid' 
MBR and allows MBR-only access to partitions that are within the limits of MBR 
addressing (start and end sector <2TB). These are only useful in very specific 
cases an I would consider them a hack more than a solution; while gpt-fdisk has 
some support for creating hybrid MBRs (don't know about fdisk), you won't get 
one unless you specifically ask for it.

> But: Are rescue systems for USB-stick more UEFI/GPT aware nowadays
> or "traditionally" based on MBR/BIOS-boot?

I think that anything that's not ancient will have tools and kernel support for 
both MBR and GPT, and will boot fine in both BIOS and UEFI modes.

> One thing I found is really handy: An USB-stick with an rEfind
> installation. As long as your PC supports UEFI (or can switched to it)
> rEfind is able to boot "everything" without prior configuration.

You can probably do the same with GRUB2, albeit in a way less user-friendly 
fashion :)
But why do you consider the ability to boot anything but the rescue system 
itself important in a rescue system?

> 
> Some rescue-system which really shines and with which you have made good
> experiences?

My usual go-to is SystemRescueCD (the old 5.x gentoo-based one). 

andrea