Re: [DNG] New build + extras

[Steve Litt]

o1bigtenor said on Mon, 30 May 2022 21:16:02 -0500

>On Mon, May 30, 2022 at 8:55 PM Steve Litt 
>wrote:
>>
>> o1bigtenor via Dng said on Mon, 30 May 2022 17:07:44 -0500
>>  
>> >On Mon, May 30, 2022 at 5:03 PM o1bigtenor   
>>  
>> >Not trying to start any kind of 'holy war' but was thinking of using
>> >SysV init unless there are some great arguments where another option
>> >is better - - - that is something that needs its own advice.  
>>
>> Before I continue, I was quite happy with sysvinit 1998 to whenever
>> upstart took over. Sysvinit does the job.
>>
>> In my opinion the difference between sysvinit and OpenRC is not
>> enough to walk away from the familiar sysvinit.
>>
>> Now, because runit exists, I would never again start up my daemons
>> using sysvinit. Instead, I would do one of the two following:
>>
>> 1: Use sysvinit for PID1, and:
>> A: Start runit in /etc/inittab as a respawn
>> B: For each daemon:
>> i: Disable the daemon in sysvinit
>> ii: Enable it in runit
>>
>> 2: Use runit as a complete init system
>>
>> If I were using Devuan (my Daily Driver Desktop (DDD) is Void), I
>> would choose alternative 1 because it's simple and sticks with what
>> I know. If I were using a native runit distro like Void I'd use
>> alternative 2.
>>
>> I think #1 is a great way to slowly wade from the shallow end of to
>> the deep end.
>>  
>So on a complicated system - - - - this sounds like things could get
>sorta interesting. I have some 14+ GB of software in my /usr partition
>so I don't think I'm into straightforward stuff (LOL). Dunno what this
>would be like in real life.
>
>I need to make a decision quickly because the new system will
>hopefully be here by the end of the week and then its assemble
>and start the loading!!

Then use sysvinit, and then, at your leasure, slowly move more and more
to runit.

>
>How does runit improve things from SysV?

Thousands of ways. No more PID files to go corrupt or unerased or
prematurely erased. No more 300 line init scripts: The average runit
run script has a line count in the single digits. Runit automatically
respawns everything it starts. If for some reason you want a specific
daemon not to respawn, leave that daemon in sysvinit.

Runit's easier to understand.

But please understand you can use sysvinit as PID1 and do some or all
daemon spawning and respawning from runit. 

>
>Have you tried running devuan on 64 bit SOCs yet?

I've only run Devuan on qemu VMs.

>
>Am thinking of using some such for servers - - - dunno where to
>get info - - - - looking at some interesting logging for a fairly
>large amount of inputs and then afterward looking at the data for
>determining a number of different things. The software - - - looks
>like I'm going to have to roll my own. Just isn't much that I think is
>good stuff at prices I'm willing to pay (ag related stuff).

Runit can log to the individual daemon's logs, or to syslog type stuff
if you run a logging program.

>
>Thanks for the tip!

You're very welcome.

Steve

Steve Litt 
March 2022 featured book: Making Mental Models: Advanced Edition
http://www.troubleshooters.com/mmm
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Fwd: New build + extras

[o1bigtenor via Dng]

On Mon, May 30, 2022 at 8:55 PM Steve Litt  wrote:
>
> o1bigtenor via Dng said on Mon, 30 May 2022 17:07:44 -0500
>
> >On Mon, May 30, 2022 at 5:03 PM o1bigtenor 
>
> >Not trying to start any kind of 'holy war' but was thinking of using
> >SysV init unless there are some great arguments where another option
> >is better - - - that is something that needs its own advice.
>
> Before I continue, I was quite happy with sysvinit 1998 to whenever
> upstart took over. Sysvinit does the job.
>
> In my opinion the difference between sysvinit and OpenRC is not enough
> to walk away from the familiar sysvinit.
>
> Now, because runit exists, I would never again start up my daemons
> using sysvinit. Instead, I would do one of the two following:
>
> 1: Use sysvinit for PID1, and:
> A: Start runit in /etc/inittab as a respawn
> B: For each daemon:
> i: Disable the daemon in sysvinit
> ii: Enable it in runit
>
> 2: Use runit as a complete init system
>
> If I were using Devuan (my Daily Driver Desktop (DDD) is Void), I would
> choose alternative 1 because it's simple and sticks with what I know. If
> I were using a native runit distro like Void I'd use alternative 2.
>
> I think #1 is a great way to slowly wade from the shallow end of to the
> deep end.
>
So on a complicated system - - - - this sounds like things could get
sorta interesting. I have some 14+ GB of software in my /usr partition
so I don't think I'm into straightforward stuff (LOL). Dunno what this
would be like in real life.

I need to make a decision quickly because the new system will
hopefully be here by the end of the week and then its assemble
and start the loading!!

How does runit improve things from SysV?

Have you tried running devuan on 64 bit SOCs yet?

Am thinking of using some such for servers - - - dunno where to
get info - - - - looking at some interesting logging for a fairly large amount
of inputs and then afterward looking at the data for determining a
number of different things. The software - - - looks like I'm going to
have to roll my own. Just isn't much that I think is good stuff at
prices I'm willing to pay (ag related stuff).

Thanks for the tip!

Regards
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New build + extras

[Steve Litt]

o1bigtenor via Dng said on Mon, 30 May 2022 17:07:44 -0500

>On Mon, May 30, 2022 at 5:03 PM o1bigtenor 

>Not trying to start any kind of 'holy war' but was thinking of using
>SysV init unless there are some great arguments where another option
>is better - - - that is something that needs its own advice.

Before I continue, I was quite happy with sysvinit 1998 to whenever
upstart took over. Sysvinit does the job.

In my opinion the difference between sysvinit and OpenRC is not enough
to walk away from the familiar sysvinit.

Now, because runit exists, I would never again start up my daemons
using sysvinit. Instead, I would do one of the two following:

1: Use sysvinit for PID1, and:
A: Start runit in /etc/inittab as a respawn
B: For each daemon:
i: Disable the daemon in sysvinit
ii: Enable it in runit

2: Use runit as a complete init system

If I were using Devuan (my Daily Driver Desktop (DDD) is Void), I would
choose alternative 1 because it's simple and sticks with what I know. If
I were using a native runit distro like Void I'd use alternative 2.

I think #1 is a great way to slowly wade from the shallow end of to the
deep end.

SteveT

Steve Litt 
March 2022 featured book: Making Mental Models: Advanced Edition
http://www.troubleshooters.com/mmm
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New build + extras

[o1bigtenor via Dng]

On Mon, May 30, 2022 at 5:03 PM o1bigtenor  wrote:
>
> Greetings
>
> I am investing in a new system.
> (Ryzen 7 5800X + Ryzen 570 gpu)
>
> The old system has a raid 10 array that I would like to put into the new 
> system.
>
> The new system is going to add 2 M2 drives that I want to set up as raid 1
> and this is for use for /EFI, /boot, /, /var, /usr and swap.
> There are 2 2.5" SDDs that are going to be set up as raid 1 for /home.
> Want to be running Devuan daedalus.
>
> The idea is to transfer the previously used drives from the old system
> into the new system.
>
> The question:
> is it better to load the system and then add the hard drives
>
> or
>
> do I move the drives into the system and then install the system with
> the drives at the same time.
>
> (2 step process or 1 step process.)
>
> Any gotchas I should be aware of - - - have not ever installed AMD
> procs nor gpus (want to run the open source drivers and will be quite
> happy to leave the nvidea world behind).

Not trying to start any kind of 'holy war' but was thinking of using
SysV init unless there are some great arguments where another option
is better - - - that is something that needs its own advice.
>
> (If further information is needed please advise.)
>
> Regards
>
> Aj
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] New build + extras

[o1bigtenor via Dng]

Greetings

I am investing in a new system.
(Ryzen 7 5800X + Ryzen 570 gpu)

The old system has a raid 10 array that I would like to put into the new system.

The new system is going to add 2 M2 drives that I want to set up as raid 1
and this is for use for /EFI, /boot, /, /var, /usr and swap.
There are 2 2.5" SDDs that are going to be set up as raid 1 for /home.
Want to be running Devuan daedalus.

The idea is to transfer the previously used drives from the old system
into the new system.

The question:
is it better to load the system and then add the hard drives

or

do I move the drives into the system and then install the system with
the drives at the same time.

(2 step process or 1 step process.)

Any gotchas I should be aware of - - - have not ever installed AMD
procs nor gpus (want to run the open source drivers and will be quite
happy to leave the nvidea world behind).

(If further information is needed please advise.)

Regards

Aj
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[aitor]

Hi Karl,

On 26/5/22 13:26, k...@aspodata.se wrote:

And, if DEVTMPFS isn't used then udev will not start, don't know
about eudev.
  vdev and mdev will probably run fine without devtmpfs.


Vdev does work without DEVTMPFS. Indeed, i have the following lines in my 
initramfs:

if command -v udevd; then
    mount -t devtmpfs -o nosuid,mode=0755 udev /dev
else
    mount -t tmpfs -o nosuid,mode=0755 none /dev
fi

leading to something like this in my /etc/mtab:

    none /dev tmpfs rw,relatime,size51200k,mode755 0 0

in contrast to

    udev /dev devtmpfs rw,nosuid,relatime,size=.

I did build a kernel without devtmpfs support:

https://www.gnuinos.org/nodevtmpfs/  

but don't expect to get eudev working with it.

On the other hand, and just the same as vdev, you don't need devtmpfs to run 
mdev:

https://sunxiboards.wordpress.com/2013/09/23/using-devtmpfs/  


Calling `|mdev -s`|  will check /sys and will create the correct devices. 
Therefore,
if you don't use devtmpfs, you need to call `mdev -s` in your /bin/init script 
to
populate /dev.

And then, when the kernel detects a new device, it calls the already mentioned

/proc/sys/kernel/hotplug

Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Shutdown/halt versus WiFi and NFS

[Alessandro Vesely via Dng]

On Sat 28/May/2022 10:23:33 +0200 Brad Campbell via Dng wrote:

Before that, I tried renaming K01network-manager to K06network-manager, to 
place it after the NFS unmount, but it ran earlier anyway.



That's the wrong way to do it.  Start/ stop order is defined by the so called 
LSB headers[*].  If the existing LSB header is wrong, you can override it in 
/etc/insserv/overrides/.


The files in /etc/rc?.d should then be "compiled" by insserv.  That program 
runs whenever updating a package requires it, and it is going to undo any 
manual fixes.  To prevent that, I replaced it with a script like so:


676-north:tmp# file `which insserv`
/sbin/insserv: POSIX shell script, ASCII text executable
677-north:tmp# cat !$
cat `which insserv`
#! /bin/sh
echo "***" >&2
echo "insserv: called as $0 $*" >&2
echo "call fix-init instead" >&2
echo "***" >&2
exit 0

Where fix-init[†] is a Perl script I coded trying to take into account existing 
fixes.  Caution: use it if you dare.



Best
Ale
--

[*] https://wiki.debian.org/LSBInitScripts/
[†] http://www.tana.it/sw/fix-init/






___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng