Re: [DNG] vdev

[aitor_czr]

On 08/13/2016 10:45 AM, aitor_czr wrote:

*vdev-example.postinst*_

#!/bin/sh

set -e

PREFIX=/

if [ $# -gt 1 ]; then
   PREFIX=$1
   shift 1
fi

update-rc.d -f udev remove
update-rc.d -f udev-finish remove

ln -s /usr/etc/init.d/vdev /etc/init.d/vdev
ln -s /usr/etc/vdev /etc/vdev
update-rc.d -f vdev defaults
insserv

cd /etc/rcS.d
rm S03udev S10udev-finish
ln -s ../init.d/vdev K02vdev
update-rc.d vdev enable S

mkdir /etc/vdev/acls
echo \
"[vdev-acl]
uid=0" > "/etc/vdev/acls/00-whitelist-root.acl"

update-rc.d -f udev remove
update-rc.d -f udev-finish remove
update-rc.d -f vdev defaults
insserv

#DEBHELPER#


Correction:

ln -s ../init.d/vdev S02vdev


   Aitor.



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

Re: [DNG] vdev

[richard lucassen]

On Thu, 11 Aug 2016 15:01:47 -0400
fsmithred  wrote:

> Anyway, I'm going to start with Jude's directions and see if I can
> catch up. Meanwhile, I did do something useful, and I can answer your
> question about eudev - yeah, I tried it, and it seems to work (with
> minimal testing). I used the debs that David Hare made about a year
> ago.

But are they maintained?

> And let me add that I agree with Steve that we should keep working on
> vdev.

The only thing that works against vdev is that it is (was?) a bit
orphaned. And eudev is not. That's why I asked that question.

> add this line to your sources:
> deb http://exegnulinux.net/nosystemd/ experimental main
> 
> Install this key
> http://exegnulinux.net/nosystemd/pool/main/e/exegnu-archive-keyring/exegnu-archive-keyring_0.0.1_all.deb
> 
> apt-get update
> apt-get install eudev (seems to install the libraries)
> apt-get -t nosystemd install udev  (honest)
> 
> It will rebuild the initrd.

I'll create an extra partition and I will try eudev.

R.

-- 
richard lucassen
http://contact.xaq.nl/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[aitor_czr]

Hi Ralph, Richard:

On 08/12/2016 03:50 AM, Ralph Ronnquist  wrote:

The set up I now have, does the right thing on boot. I think.

Firstly, it loads vdev from initrd during the first stage boot, and then
it exits. A snapshot of /dev taken before the next start shows all
filemod settings to be fine.

Secondly it loads vdev anew at the sysvinit startup, and then this stays
on as a daemon. The filemod settings at this time remain good.

Plugging in a USB disk via virtio redirection gains two new entries
/dev/sdd and /dev/sdd1, with appropriate filemod settings.

This is with vdev installed from the debs, followed by my hands-on,
which resulted in the snapshot files and links. Exactly. I also have
removed all*udev*  links from /etc/rcS.d (as otherwise update-rc.d gets
upset about two different udev provisions)

The diff relative a clean debs install tells of a) two revisions for the
provided files: the changes to /usr/etc/vdev/vdevd.conf, and to
/usr/lib/vdev/udev-compat.sh, b) the additions of
/usr/lib/vdev/daemonlet and /usr/etc/vdev/acls/00-whitelist-root.acl,
and c) the additional /root tree for initrd building.

Now, I would suggest a blanket revision to the debs, to remove the /usr
prefix from all its file paths. Then change /etc/vdev/vdevd.conf and the
initrd building scripts accordingly. Thereafter work out how to
postinstall vdev to also purge systemd-udev without it messing with its
dependencies. (You don't want the kernel uninstalled)


I'm applying changes to the packages. This is my vdev.conf file:

*vdev.conf*_

[vdev-config]
firmware=/usr/lib/firmware
acls=/etc/vdev/acls
actions=/etc/vdev/actions
helpers=/usr/lib/vdev
hwdb=/usr/lib/vdev/hwdb/hwdb.squashfs
ifnames=/etc/vdev/ifnames.conf
pidfile=/run/vdev/vdevd.pid
default_permissions=0600
loglevel=debug
logfile=/var/log/vdev/vdevd.log
preseed=/usr/lib/vdev/dev-setup.sh



I also added the following files:



*vdevd.postinst*_

I also added a *vdevd.postint* file:

#!/bin/sh

set -e

ln -s /usr/sbin/vdevd /sbin/vdevd

#DEBHELPER#



*vdev-example.postinst*_

#!/bin/sh

set -e

PREFIX=/

if [ $# -gt 1 ]; then
   PREFIX=$1
   shift 1
fi

update-rc.d -f udev remove
update-rc.d -f udev-finish remove

ln -s /usr/etc/init.d/vdev /etc/init.d/vdev
ln -s /usr/etc/vdev /etc/vdev
update-rc.d -f vdev defaults
insserv

cd /etc/rcS.d
rm S03udev S10udev-finish
ln -s ../init.d/vdev K02vdev
update-rc.d vdev enable S

mkdir /etc/vdev/acls
echo \
"[vdev-acl]
uid=0" > "/etc/vdev/acls/00-whitelist-root.acl"

update-rc.d -f udev remove
update-rc.d -f udev-finish remove
update-rc.d -f vdev defaults
insserv

#DEBHELPER#



*vdevfs.postinst*_

#!/bin/sh

set -e

ln -s /usr/sbin/vdevfs /sbin/vdevfs

#DEBHELPER#



*vdev-fs.postinst*_

#!/bin/sh

set -e

ln -s /usr/sbin/vdevfs /sbin/vdevfs

#DEBHELPER#



I also have to add the *.postrm files.

Cheers,

  Aitor.



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

Re: [DNG] vdev

[aitor_czr]

On 08/13/2016 10:48 AM, aitor_czr wrote:


On 08/13/2016 10:45 AM, aitor_czr wrote:

*vdev-example.postinst*_

#!/bin/sh

set -e

PREFIX=/

if [ $# -gt 1 ]; then
   PREFIX=$1
   shift 1
fi

update-rc.d -f udev remove
update-rc.d -f udev-finish remove

ln -s /usr/etc/init.d/vdev /etc/init.d/vdev
ln -s /usr/etc/vdev /etc/vdev
update-rc.d -f vdev defaults
insserv

cd /etc/rcS.d
rm S03udev S10udev-finish
ln -s ../init.d/vdev K02vdev
update-rc.d vdev enable S

mkdir /etc/vdev/acls
echo \
"[vdev-acl]
uid=0" > "/etc/vdev/acls/00-whitelist-root.acl"

update-rc.d -f udev remove
update-rc.d -f udev-finish remove
update-rc.d -f vdev defaults
insserv

#DEBHELPER#


Correction:

ln -s ../init.d/vdev S02vdev


   Aitor.


These lines are superfluous:

PREFIX=/

if [ $# -gt 1 ]; then
   PREFIX=$1
   shift 1
fi


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

[DNG] Devuan-ascii: Upgrading runit to 2.1.2-5 can hose your system

[Fred DC]

Hi,

My apololgies for sounding a bit emotional about this issue.

If, up to now, you have "runit" running as pid 1 and managed to
maintain the ability to boot from the kernel commandline using
the sysv-init read on.

The latest update to package 'runit' *wipes* out the 2 binaries
/sbin/runit-init and /sbin/runit, in other words, the carpet has been
pulled from under the init. To add injury to insult the /etc/service
which is a link to /etc/runit/runsvdir/current gets wiped out as well.

During the installation it ask you if the existing 3 runlevel scripts
must be preserved and it does execute your choice (during the
*downgrade* it will however wipe out your existing 3 scripts). At no
time during the *upgrade* process you will see any other warning!!
It appears the the 2 vital binaries have been moved to a new package
'runit-init'. 'runit-init' is *not* marked in the package 'runit' as
a 'recommends' nor as 'suggests'.

Next surprise. Package 'runit-init' *cannot* co-exist with sysv-init.
It will *uninstall* package 'sysvinit-core' and why?...because of 3
so-called runit compatabilty scripts (shutdown, halt/reboot and
runlevel. No diversion of these 3 sysv-executables - no, the whole
sysvinit-core with its /sbin/init had to be removed. So the
alternative boot-option is gone!

Be warned!

BTW, there is a ready solution for making the sysv 'halt/reboot' and
'shutdown' work under 'runit as pid 1'. I use it and it works!
See link: https://wiki.debian.org/runit

Regards

Fred

PS: I was able to recover the OS and everything is back to normal, but
I did put package 'runit' on hold in 'aptitude' and it will stay that
way until the package is not of 'grade experimental' quality anymore.
I know that 'ascii' is 'testing' - but I also know it is not 'unstable'
nor 'experimental' and after all, this is DEVUAN. We are dealing here
with the init-system.

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

Re: [DNG] vdev

[Fred DC]

On 13/08/2016 11:52, aitor_czr wrote:
> [Snip}
> 
> Yes, we need testers :)
> 
> Best,
> 
>   Aitor.

Oh yes, I will test it once it hits 'ascii' or
perhaps even the 'unstable' branch. Sorry can't
do better bacause I am just a user with a fairly
good head on its shoulder.

Regards

Fred

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

Re: [DNG] vdev

[richard lucassen]

On Sat, 13 Aug 2016 11:52:55 +0200
aitor_czr  wrote:

> > We need a vdev package that depends on an empty systemd-udev
> > package. All the other packages that depend on systemd-udev will
> > otherwise be uninstalled.
> 
> vdev will provide udev in teh same way as libudev-compat-dev will 
> provide libudev-dev;
> but first i'll try to build the kernel using libudev-compat-dev
> instead of libudev-dev

I thought the kernel package was dependent on systemd-udev, but
apparently it isn't.

> > I just saw the vdev packages have disappeared on Aitor's site, I
> > think he's busy creating new ones:)
> 
> Yes, i'm rebuilding the packages... But, where are you searching them?
> 
> http://packages.gnuinos.org/pool/main/v/vdev/

No, I looked at http://packages.gnuinos.org/pool/main/libp/libpstat/

:-)

> > I propose not to git anymore, but to use Aitor's packages and test
> > these. I think there is still a lot of testing and debugging to do.
> > And we need more testers!
> 
> Yes, we need testers :)

I have to do some work now, I look forward to the packages. Maybe you
can add a small README.txt for those who are willing to test vdev.

-- 
richard lucassen
http://contact.xaq.nl/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[richard lucassen]

On Fri, 12 Aug 2016 12:54:54 +0200
Adam Borowski  wrote:

> On Fri, Aug 12, 2016 at 11:17:13AM +0200, richard lucassen wrote:
> > We need a vdev package that depends on an empty systemd-udev
> > package. All the other packages that depend on systemd-udev will
> > otherwise be uninstalled.
> 
> Use Provides:.  This can nowadays even give a version.

Ok, thnx. I'm not an apt guru ;-) 


-- 
richard lucassen
http://contact.xaq.nl/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[fsmithred]

On 08/13/2016 04:45 AM, aitor_czr wrote:
> 
> 
> I'm applying changes to the packages. This is my vdev.conf file:
> 
> *vdev.conf*_
> 
> [vdev-config]
> firmware=/usr/lib/firmware
> acls=/etc/vdev/acls
> actions=/etc/vdev/actions
> helpers=/usr/lib/vdev
> hwdb=/usr/lib/vdev/hwdb/hwdb.squashfs
> ifnames=/etc/vdev/ifnames.conf
> pidfile=/run/vdev/vdevd.pid
> default_permissions=0600
> loglevel=debug
> logfile=/var/log/vdev/vdevd.log
> preseed=/usr/lib/vdev/dev-setup.sh
> 

I think firmware should be set to /lib/firmware. That's where my firmware
is. I have no /usr/lib/firmware.

-fsr


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

Re: [DNG] vdev

[Adam Borowski]

On Fri, Aug 12, 2016 at 11:17:13AM +0200, richard lucassen wrote:
> We need a vdev package that depends on an empty systemd-udev package.
> All the other packages that depend on systemd-udev will otherwise be
> uninstalled.

Use Provides:.  This can nowadays even give a version.

-- 
An imaginary friend squared is a real enemy.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[richard lucassen]

On Fri, 12 Aug 2016 06:33:50 -0400
fsmithred  wrote:

> > firmware=/usr/lib/firmware
> 
> I think firmware should be set to /lib/firmware. That's where my
> firmware is. I have no /usr/lib/firmware.

Yep. I agree. Firmware is AFAIK in /lib/firmware

-- 
richard lucassen
http://contact.xaq.nl/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[fsmithred]

On 08/12/2016 12:32 PM, Arnt Karlsen wrote:
> On Fri, 12 Aug 2016 17:41:42 +0200, richard wrote in message 
> <20160812174142.f82635d8a4201d3119759...@lucassen.org>:
> 
>>
>> That's a good point. Devuan means "freedom of choice" and it would be
>> nice if a Devuan user could opt for udev, 
> 
> ..best way would be advice of the looming systemd "support" of udev and
> point them to Debian and the Debian mail list discussions around it and
> its hijacked udev, so they can make an informed decision. ;o)
> 
>> vdev or eudev (or even mdev)
> 
> ..hear, hear.  :o)
> 
>> But for the moment we have to create packages for vdev. I will test
>> eudev as well asap.
> 
> ..eudev etc package link?
> 

These packages were built by David Hare a little over a year ago. They
appear to work on current devuan. I don't know if he plans to update them.

add this line to your sources:
deb http://exegnulinux.net/nosystemd/ experimental main

Install this key
http://exegnulinux.net/nosystemd/pool/main/e/exegnu-archive-keyring/exegnu-archive-keyring_0.0.1_all.deb

apt-get update
apt-get install eudev (seems to install the libraries)
apt-get -t experimental install udev (honest)

It will rebuild the initrd.

Reboot.

David also put together an experimental live iso of refracta with eudev. I
recently made a live-usb for a friend with this iso when her hard drive
died, and she used it for a few weeks without any complaints.

http://exegnulinux.net/refracta/iso/eudev/

-fsr

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

Re: [DNG] Devuan-ascii: Upgrading runit to 2.1.2-5 can hose your system

[Steve Litt]

On Fri, 12 Aug 2016 20:34:07 +0200
Harald Arnesen  wrote:

> Steve Litt [2016-08-12 19:47]:
> 
> > I don't understand. Do you perhaps mean that sysvinit is PID1, and
> > you use runit strictly as a process supervisor? The reason I ask
> > this is, whatever acts as PID1 is what boots the kernel.  
> 
> No. The kernel starts PID1.

LOL, you're right. The bootloader or UEFIwhatever starts the kernel.

Sorry.

SteveT

Steve Litt
August 2016 featured book: Manager's Guide to Technical Troubleshooting
  Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[Robert Storey]

> I have to do some work now, I look forward to the packages. Maybe you
> can add a small README.txt for those who are willing to test vdev.

Yes please. A small README.TXT explaining what we have to do to set up and
install vdev will work wonders at attracting testers. Having to sift
through the archives of the Devuan mailing list for instructions will blow
away 90% of potential testers.

I'm enthused about helping get vdev finished and out the door - it would be
a major coup against the evil forces of Poetterism. Today, I'm setting up a
second install of Devuan on another partition just for testing vdev, since
Devuan is currently my main distro for getting things done and I don't want
to accidentally nuke it.

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

Re: [DNG] vdev

[aitor_czr]

Hi fsr,

On 08/12/2016 02:00 PM, fsmithred  wrote:

On 08/13/2016 04:45 AM, aitor_czr wrote:

>
>
>I'm applying changes to the packages. This is my vdev.conf file:
>
>*vdev.conf* _
>
>[vdev-config]
>firmware=/usr/lib/firmware
>acls=/etc/vdev/acls
>actions=/etc/vdev/actions
>helpers=/usr/lib/vdev
>hwdb=/usr/lib/vdev/hwdb/hwdb.squashfs
>ifnames=/etc/vdev/ifnames.conf
>pidfile=/run/vdev/vdevd.pid
>default_permissions=0600
>loglevel=debug
>logfile=/var/log/vdev/vdevd.log
>preseed=/usr/lib/vdev/dev-setup.sh
>

I think firmware should be set to /lib/firmware. That's where my firmware
is. I have no /usr/lib/firmware.

-fsr


Finally i decided to use the following config file:

[vdev-config]
firmware=/lib/firmware
acls=/etc/vdev/acls
actions=/etc/vdev/actions
helpers=/lib/vdev
hwdb=/lib/vdev/hwdb/hwdb.squashfs
ifnames=/etc/vdev/ifnames.conf
pidfile=/run/vdev/vdevd.pid
default_permissions=0600
loglevel=debug
logfile=/var/log/vdev/vdevd.log
preseed=/lib/vdev/dev-setup.sh

using simbolik links to /usr

Cheers,

  Aitor.




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

Re: [DNG] Off-list - upgrading runit to 2.1.2-5 can hose your system

[Fred DC]

On 12/08/2016 13:43, Tom H wrote:
>> On 12/08/2016 11:49, Tom H wrote:
>>>
>>> Off-list
>>>
>>> Install
>>> runic-init
>>> in order to restore
>>> /sbin/init
>>> and
>>> /sbin/runit
>>
>> Thanks for the suggestion. Unfortunately 'runic-init' it is not in
>> 'ascii' and googling didn't help neither.
> 
> You're welcome.
> 
> runit-init should be in ascii because it's in stretch.
> 

Yes. that is the one which conflicts with sysvinit-core

>
> It's version 2.1.2-5.
> 
>>From the changelog of 2.1.2-4:
> 
> New binary package 'runit-init', that provides /sbin/init replacement
> out-of-box.
> 
> I'd say that it's badly packaged. For sysvinit, there's
> 
> - sysvinit, which provides "/lib/sysvinit/init" so you can boot using
> sysvinit by adding "init=/lib/sysvinit/init" to the kernel cmdline
> 
> - sysvinit-core, which provides "/sbin/init"
>

Thanks for this tip. BTW, sysvinit is a transitional package for people
who are not so sure about systemd-init. So that will go away in not too
distant future.

>
> It would be more work to set things up like sysvinit because it would
> involve others making changes to their packages. For example,
> sysvinit-core and systemd-sysv would have to have conflicts with
> runit-init. Even then, it wouldn't quite right because runit-init
> doesn't provide "/sbin/halt" and friends. So it's simpler to create
> runit-init and hope people using runit as pid 1 install it when
> upgrading.
> 

And in my opinion, it would be even more simpler if 'runit-init' would
just divert the original sysv runlevel, halt/reboot and shutdown befor
it drops it own shims for these modules onto the disk. This means that
the user has choices and he can work with symlinks just as he has to
with runit-init anyway.

Many thanks

Fred

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

Re: [DNG] vdev

[Didier Kryn]

Le 05/08/2016 21:45, Steve Litt a écrit :

Readhttps://wiki.gentoo.org/wiki/Mdev  . mdev means no Gnome allowed,
and neither KDE nor its apps allowed. That don't cross my eyes none, I
banned all KDE software from my computers in 2012, and I haven't used
Gnome since they went to the lame Gnome3. But a lot of Devuaners use
KDE and Kmail, and we all know that somehow, K3b managed to be the best
GUI optical disk burner in the world. These are challenges that must be
overcome.

More troubling is the article says LVM might not work with mdev.
Replacing Gnome and KDE is just a matter of prioritizing "works" over
"pretty" and "drag and drop". But LVM is integral to computer use. I'd
say the "might" in "might not" needs investigation.


Sorry guys, I don't participate in vdev testing yet. I'm trying to 
reach a better understanding of how things are working.


As I understand now, what X.org and other apps need is a library to 
query information on devices - eg keyboard mapping - (and maybe to 
change these properties?). libudev is such a library but libudev and 
udev are mutually dependent. It seems to me that this dependency should 
be broken. This is possible because all information is stored in files 
under /sys, and not in some private udev store.


 In particular, vdev and libudev-compat would better be two 
independent packages. Actually KDE, Gnome K3b etc most probably only 
depend on libudev.


Didier

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

Re: [DNG] vdev

[richard lucassen]

On Fri, 12 Aug 2016 08:08:42 -0500
Jim Murphy  wrote:

> I'm not a dev and haven't done a lot of research on how things
> should work with multiple *dev(s).  It would appear that there
> could be at least 2 or maybe 3 that will be part of devuan's
> offerings(udev, vdev and eudev).  The above example script, and
> yes I know it is not finished or final, assumes there will be only
> 2(udev and vdev) and is part of vdev's post install.  As debian
> appears to have only offered udev this is new ground being
> walking on.
> 
> I was wondering shouldn't there be plans to allow for any number
> of *dev(s)?  Again I'm not a dev.  Looking at funtoo I noticed
> the current offerings are udev and eudev with eudev installing as
> default. Funtoo also has a package virtual/udev defined as
> "Virtual to select between different udev daemon providers".
> Should devuan also take a similar approach? Wouldn't this be
> better approach then having each *dev package do the switching?
> Also there is the issue of which init system has been installed and
> what commands are needed to stop/start daemons.
> 
> FWIW, some random thoughts.

That's a good point. Devuan means "freedom of choice" and it would be
nice if a Devuan user could opt for udev, vdev or eudev (or even mdev)

But for the moment we have to create packages for vdev. I will test
eudev as well asap.

R. 

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan-ascii: Upgrading runit to 2.1.2-5 can hose your system

[Rick Moen]

Quoting Steve Litt (sl...@troubleshooters.com):

> LOL, you're right. The bootloader or UEFIwhatever starts the kernel.

Everyone who's read your excellent troubleshooters.com artlces about
inits figured out that your fingers were merely on autopilot or
something, but you _definitely_ knew that PID1 is the init, PID0 is the
kernel, and whatever hands excecution over to the kernel doesn't have a
PID because nothing is yet running to issue them.

-- 
Cheers, Grossman's Law:  "In time of crisis, people do not rise to
Rick Moen   the occasion.  They fall to the level of their training."
r...@linuxmafia.com  http://linuxmafia.com/~rick/lexicon.html#grossman
McQ! (4x80)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[Peter Olson]

> On August 13, 2016 at 4:45 AM aitor_czr  wrote:

As you know, today is August 12, not August 13.

PLEASE FIX YOUR COMPUTER CLOCK

Here is the trace of your message:

START >

Received: from [192.168.0.10] (114.62-99-112.dynamic.clientes.euskaltel.es
 [62.99.112.114]) (Authenticated sender: aitor_...@gnuinos.org)
 by player761.ha.ovh.net (Postfix) with ESMTPSA id 7C0E748009A;
 Fri, 12 Aug 2016 10:47:58 +0200 (CEST)

From: aitor_czr 
Message-ID: <57aede0d.90...@gnuinos.org>
Date: Sat, 13 Aug 2016 10:45:01 +0200

Hi Ralph, Richard:

On 08/12/2016 03:50 AM, Ralph Ronnquist  wrote:
> The set up I now have, does the right thing on boot. I think.

< END

I'm not going to read anything you say that shows up in my inbox tomorrow.  If 
I did, it would show up in my inbox yesterday, already read.  But in either 
case, it shows up in an incongruous position in the discussion thread, where I 
cannot make sense of the discussion.

Please fix this.

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

Re: [DNG] vdev

[Arnt Karlsen]

On Fri, 12 Aug 2016 17:41:42 +0200, richard wrote in message 
<20160812174142.f82635d8a4201d3119759...@lucassen.org>:

> 
> That's a good point. Devuan means "freedom of choice" and it would be
> nice if a Devuan user could opt for udev, 

..best way would be advice of the looming systemd "support" of udev and
point them to Debian and the Debian mail list discussions around it and
its hijacked udev, so they can make an informed decision. ;o)

> vdev or eudev (or even mdev)

..hear, hear.  :o)

> But for the moment we have to create packages for vdev. I will test
> eudev as well asap.

..eudev etc package link?

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan-ascii: Upgrading runit to 2.1.2-5 can hose your system

[Steve Litt]

On Fri, 12 Aug 2016 11:32:41 +0200
Fred DC  wrote:

> Hi,
> 
> My apololgies for sounding a bit emotional about this issue.

The behavior of the poetterists is enough to make anybody indignant.

> 
> If, up to now, you have "runit" running as pid 1 and managed to
> maintain the ability to boot from the kernel commandline using
> the sysv-init read on.

I don't understand. Do you perhaps mean that sysvinit is PID1, and you
use runit strictly as a process supervisor? The reason I ask this is,
whatever acts as PID1 is what boots the kernel.

> 
> The latest update to package 'runit' *wipes* out the 2 binaries
> /sbin/runit-init and /sbin/runit, in other words, the carpet has been
> pulled from under the init. 

My understanding is that /sbin/runit-init is Runit's PID1 executable,
and /sbin/runit is Runit's early boot manager and process supervisor.
It would seem to me that, together, they comprise the entirety of
runit's capabilities (unless one cobbles something together with runsv
and runsvdir, etc). So if they took away these two executables (rather
than placing them somewhere else), they gave you a capability-free
package.

Could you please check and see that runit and runit-init aren't in
another directory, like /usr/bin or /usr/sbin? Remember, the
poetterists are in love with the "all executables in one dir and then
symlink" philosophy, so that before the call to mount -a, /sbin has
nothing in it.


> To add injury to insult the /etc/service
> which is a link to /etc/runit/runsvdir/current gets wiped out as well.

Maybe it got moved somewhere else. Anyway, that's easy because you can
just make the symlink yourself, and document the fact.

> During the installation it ask you if the existing 3 runlevel scripts
> must be preserved and it does execute your choice (during the
> *downgrade* it will however wipe out your existing 3 scripts). At no
> time during the *upgrade* process you will see any other warning!!
> It appears the the 2 vital binaries have been moved to a new package
> 'runit-init'. 'runit-init' is *not* marked in the package 'runit' as
> a 'recommends' nor as 'suggests'.

Sounds like debian incompetence to me.

> 
> Next surprise. Package 'runit-init' *cannot* co-exist with sysv-init.
> It will *uninstall* package 'sysvinit-core' and why?...because of 3
> so-called runit compatabilty scripts (shutdown, halt/reboot and
> runlevel. No diversion of these 3 sysv-executables - no, the whole
> sysvinit-core with its /sbin/init had to be removed. So the
> alternative boot-option is gone!

I thought all package manager bestowed init systems cancelled out their
alternatives. This is why I'm so partial to compiling your own Runit.
But I digress

The practice of removing an init when installing another one is stupid.
Just like we often keep a "safe" kernel bootable, it's nice to have
different inits so that if we bork one init, we can bust back in with
the other.

With the ascension of the poetterists within the Debian developer
community, I have a feeling that, long term, any Devuan packaging of
Runit (or s6 or Epoch, for that matter) will need to be done by Devuan.
Therefore, people like you and I should begin the process of defining
what directories do what in runit, and perhaps define some best
practices. I'll throw out the first pitch...

We need to define the directory in which symlinks enable daemons. When
Daniel J Bernstein started this whole thing, that directory
was /service. But the existence of a new directory right off the root
caused purists to howl at the moon, so today that's a bad
idea. /etc/service is a possibility, except that's very confusable
with /etc/sv or whatever directory contains the actual daemon subdirs,
not the symlinks. The /etc tree branch has one huge advantage: Except
for the most unusual setups, /etc is always on the root partition.

A lot of people use /var/service. This works beautifully as long
as /etc/runit/1 can get /var mounted, so that the (later) call to
runsvdir has a mounted /var/service to work with.

But, for the sake of Devuan, I might take it a step farther and have it
be /etc/serv_runit. This way, we can also have an /etc/serv_s6 and
an /etc/serv_dtencore, so that Runit, s6 and Daemontool-encore can
coexist on the same box at the same time. This coexistance would also
require the directories containing the actual daemon supervising files
to be distinctive of their init systems:
Perhaps /etc/sv/s6, /etc/sv/runit, and /etc/sv/dtencore.

The preceding six paragraphs are based on 10 minutes thought: They're
designed to start things off, and to be modified as needed.

And yeah, Debian's practice of continually changing alternative inits
is both rude and completely expected.
 
SteveT

Steve Litt
August 2016 featured book: Manager's Guide to Technical Troubleshooting
  Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org

Re: [DNG] Devuan-ascii: Upgrading runit to 2.1.2-5 can hose your system

[Harald Arnesen]

Steve Litt [2016-08-12 19:47]:

> I don't understand. Do you perhaps mean that sysvinit is PID1, and you
> use runit strictly as a process supervisor? The reason I ask this is,
> whatever acts as PID1 is what boots the kernel.

No. The kernel starts PID1.
-- 
Hilsen Harald
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[richard lucassen]

On Sat, 13 Aug 2016 16:12:27 +0200
aitor_czr  wrote:

> Finally i decided to use the following config file:
> 
> [vdev-config]
> firmware=/lib/firmware
> acls=/etc/vdev/acls
> actions=/etc/vdev/actions
> helpers=/lib/vdev
> hwdb=/lib/vdev/hwdb/hwdb.squashfs
> ifnames=/etc/vdev/ifnames.conf
> pidfile=/run/vdev/vdevd.pid
> default_permissions=0600
> loglevel=debug
> logfile=/var/log/vdev/vdevd.log
> preseed=/lib/vdev/dev-setup.sh

Mind that the init.d/vdev should create the /run/vdev/ directory. And
there was this issue that vdev did not start because of a read only
filesystem. I haven't tested it, but update-rc.d puts the /etc/srcS.d
symlink to S03vdev and maybe that is too early. 

> using simbolik links to /usr

Normally it should work without these symlinks. I think it's even better
to leave these symlinks out as these would hide settings still pointing
to the /usr structure.

My 2 cts :)

R.

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan-ascii: Upgrading runit to 2.1.2-5 can hose your system

[Edward Bartolo]

Harald Arnesen wrote:
<<
Steve Litt [2016-08-12 19:47]:

> I don't understand. Do you perhaps mean that sysvinit is PID1, and you
> use runit strictly as a process supervisor? The reason I ask this is,
> whatever acts as PID1 is what boots the kernel.

No. The kernel starts PID1.
>>

Steve Litt knows which executable starts first when a Linux OS starts
to boot. This is a genuine error. I am sure people like Steve Litt
know that the kernel is what starts PID1.

-- 
If you can't explain it simply, you don't understand it well enough.

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

Re: [DNG] Off-list - upgrading runit to 2.1.2-5 can hose your system

[Adam Borowski]

On Fri, Aug 12, 2016 at 03:25:27PM +0200, Fred DC wrote:
> On 12/08/2016 13:43, Tom H wrote:
> >>From the changelog of 2.1.2-4:
> > New binary package 'runit-init', that provides /sbin/init replacement
> > out-of-box.
> > 
> > I'd say that it's badly packaged. For sysvinit, there's
> > 
> > - sysvinit, which provides "/lib/sysvinit/init" so you can boot using
> > sysvinit by adding "init=/lib/sysvinit/init" to the kernel cmdline
> > 
> > - sysvinit-core, which provides "/sbin/init"
> >
> 
> Thanks for this tip. BTW, sysvinit is a transitional package for people
> who are not so sure about systemd-init. So that will go away in not too
> distant future.

For the values of "future" of "Wed, 20 Jul 2016 15:28:28 +0200".

-- 
An imaginary friend squared is a real enemy.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng