Re: [DNG] installation images

[Ralph Ronnquist]

On Thu, Sep 08, 2022 at 11:46:50AM +0100, Peter Duffy wrote:
> I assume that at some point, the installation iso images are going to
> be rebuilt to include the new devuan-keyring package? Until this is
> done, a devuan install can only be completed by using the
> wget/chroot/dpkg kludge. 
> 
> Given LP's move to M$, there's probably more interest than usual in
> devuan and other non-systemd distros at the moment - so maybe this
> needs doing quite urgently.
> 
> I did manage to rebuild the chimaera netinstall image with the new
> devuan-keyring package yesterday (I needed to install several chimaera
> VMs, and it was an interesting challenge). The new image appears to
> work (install on a virtualbox VM completed without a problem, and the
> VM booted fine). If it would be helpful, I'm happy to give details of
> how I did it - but I'm conscious that although it seems to work, my new
> image is probably slightly different from the original, and I don't
> want to muddy any waters. The best by far would be to have new images
> available, built using the standard process. On the other hand, it
> might be good for the process of generating debian/devuan installation
> images to be more widely known (there doesn't seem to be a lot of
> information on the web about it, and what there is seems mostly to be
> out-of-date and/or broken).   

To build a chimaera netinstall, the following command sequence might
work:

$ git clone https://git.devuan.org/devuan/installer-iso.git
$ cd installer-iso
$ TRIAL=yes ./build-sudo chimaera netinstall 4.2.meown

You obviusly need sudo, or you may run it as root.

That scripting will firstly debootstrap a chimaera installer building
hosting filesystem, then chroot into that for the actual iso building.
The resulting ISO ends up at chimaera.$ARCH.fs/installer-iso/ with the
name of netinstall-$ARCH.iso.

I'm doing like that so it must work the same for everyone ;)

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

Re: [DNG] chimaera install problem

[Ralph Ronnquist]

On Tue, Sep 06, 2022 at 03:53:08PM +0200, Adrian Zaugg wrote:
> In der Nachricht vom Tuesday, 6 September 2022 15:02:47 CEST steht:
> > At that point you use wget to grab the devuan-keyring package
> > http://deb.devuan.org/merged/pool/DEVUAN/main/d/devuan-keyring/devuan-keyrin
> > g_2022.09.04_all.deb and store that at /target, so you can follow up with
> > manual
> > installation into /target, by:
> > # chroot /target /usr/bin/dpkg -i devuan-keyring_2022.09.04_all.deb
> There is neither curl, wget nor dpkg available in the netinst iso, at least 
> not in daedalus and presumably not in chimaera either.

I must say that you are mistaken about that.
"/usr/bin/wget" is available in the installer itself, and
"/usr/bin/dpkg" is available in the installed base system
(i.e. chroot /target)

Ralph.

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

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

Re: [DNG] chimaera install problem

[Ralph Ronnquist]

On Tue, Sep 06, 2022 at 01:14:06PM +0100, Peter Duffy wrote:
> Adrian and Olaf - thanks for the comments.
> 
> This is definitely the expired key problem - so at the moment, chimaera
> can't be installed via the netinstall image. Probably the same for
> other devuan versions.
> 
> Adrian - I tried changing the date as you suggested. That doesn't work
> - I now get a message in the log saying:
> 
> "http://deb.devuan.org/merged/dists/chimaera/InRelease is not valid
> yet"
> 
> I found that I could get the install to complete if I told it to ignore
> the error, and the resulting system would boot. However, it's obviously
> just the bare-bones base system from the netinstall image. 
> 
> Are the netinstall images going to be re-generated fairly soon? If not,
> is it worth while thinking of a way of importing the new key into the
> install process?

The required hands-on to make use of the current installer ISOs
includes the use of wget and dpkg at the point where the installation
first breaks, though probably only via a C-A-F2 escape to a root shell
while the installation (at C-A-F1) is blocked and waiting on the error
report dialog.

At that point you use wget to grab the devuan-keyring package
http://deb.devuan.org/merged/pool/DEVUAN/main/d/devuan-keyring/devuan-keyring_2022.09.04_all.deb
and store that at /target, so you can follow up with manual
installation into /target, by:
# chroot /target /usr/bin/dpkg -i devuan-keyring_2022.09.04_all.deb

Following that, you re-enter the installation at C-A-F1 and select
"continue" so that it re-tries with the failing step using the the
updated keyring.

On the side of all that I should add that I also taken have the
opportunity to polish the installer-iso project so that it easily
builds ISOs for the old releases. Some trial builds of that are
currently available for testing at https://ido.rrq.id.au/download

Ralph.

> 
> On Mon, 2022-09-05 at 16:49 +0100, Peter Duffy wrote:
> > Sorry if this has been addressed before - I did look through the
> > posts,
> > but couldn't see anything relevant. Also sorry if I'm missing
> > something
> > obvious.
> > 
> > I'm trying to install chimaera on a virtualbox VM, using the
> > netinstall
> > image (devuan_chimaera_4.0.0_amd64_netinstall.iso, dated Nov 18 2021)
> > -
> > I've done this many times before, without a problem. This time, when
> > I
> > get to "configure the packet manager", it comes back with "The
> > installer failed to access the mirror". I used wireshark to check
> > that
> > it's talking to the network and the server - it appears to be doing
> > so
> > (accessing server at 95.216.15.86). 
> > 
> > I'm wondering if it could be another effect of the recent key expiry
> > problem.
> > 
> >  
> > 
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Installing build-essential on Chimaera PPC

[Ralph Ronnquist]

On Mon, Aug 22, 2022 at 08:37:52PM +0200, Luciano Mannucci wrote:
> 
> I installed a Chimaera guest on my KVM/quemu PPC (well, not exactly;
> I had to install a Debian bullseye and then migrate using rrq script).
> Now I'm trying to install some usefull software via apt-get and it says
> I have broken packages. This is what I typed (with anwers :):
> 
> root@bob:~# apt-get install build-essential
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  libtirpc-dev : Depends: libtirpc3 (= 1.3.1-1) but 1.3.1-1+deb11u1 is to be 
> installed
> E: Unable to correct problems, you have held broken packages.
> 
> Do I have any chance to correct that issue?

I think your sources.list lines have soe impurity, because the
expected installation version for libtirpc-dev is 1.3.1-1+deb11u1 and
that package depends on "libtirpc3 (= 1.3.1-1+deb11u1)".

If/when your sources.list lines are correct, then the first step would
be
# apt-get update
so as to ensure that your local Packages files are up to date, and
then this particular problems should no longer come up.

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

Re: [DNG] Question re: screen blanking and shutoff

[Ralph Ronnquist]

On Wed, Jul 27, 2022 at 09:24:42PM -0500, o1bigtenor via Dng wrote:
> On Wed, Jul 27, 2022 at 6:26 PM onefang  wrote:
> >
> > On 2022-07-27 18:04:26, o1bigtenor via Dng wrote:
> > > Greetings
> > >
> > > Running a AMD 3800X with a Radeon RX570X graphics card using
> > > opensource amdgpu drivers (version compiled for 1.21.1.3, module
> > > version = 22.0.0, Module class: X.Org Video Driver, ABI class: X.Org
> > > Video Driver, version 25.2) running xorg-server 2:21.1.3-2+b1.
> > >
> > > I think my system is reasonably upto date running Daedalus. (Last apt
> > > update check done this morning.)
> > >
> > > The issue - - -
> > >
> > > After a system reboot the screens will enter screensaver pretty
> > > picture mode and then blank to off at the chosen times. I've got 5
> > > monitors set up to display most of a 7680x3000 virtual desktop.
> > > Also run a lot of desktops and tend to accumulate a lot of tabs in my
> > > browsers. Run at least 3 browsers at once (Opera, Brave and Firefox)
> > > with Firefox as the default and have in the past also run Vivaldi.
> > > Firefox is the default browser.
> > > Firefox is the only browser that will place its windows where I had
> > > them on the various desktops. Finding this I have reduced every other
> > > browser to windows on at most one 'desktop'. That is the only way that
> > > I can get any time at all where the screensaver just does its job.
> > > The problem is that after about 80 hours (or so - - - - haven't
> > > defined that time with any precision) the screensaver will move to the
> > > pretty pics screens but does NOT move to screen off.
> > >
> > > I have been trying to find what in either the browsers is hindering
> > > the screen 'blanking' (if I'm using the correct term) or is breaking
> > > on my system - - - dunno. Have been looking at xset as well but really
> > > don't know what the bleeping blazes I'm doing and don't want to create
> > > an even bigger mess!
> > > I am using lxqt still on version 0.16.0 trying to wait patiently for
> > > version 1.01 which is supposedly going to move from experimental to
> > > unstable and testing hopefully very soon but that timing is NOT up to
> > > me.
> > >
> > > Is there someone out there in Devuan land who has any idea of how to
> > > change this annoying behavior?
> > > Can I change something in Xset to make this happen?
> > > Something else?
> > >
> > > (I can reboot and set up things the way I want (takes about 1/2 hour
> > > in total to do everything) so I find that this time every 4 days is a
> > > nuisance. )
> >
> > That sort of thing was driving me crazy for ages, screensaver would blank
> > the screen, but not turn the monitors off.  I finally tracked it down.
> > In my case it was running SDL based programs, the fix is -
> >
> > export SDL_VIDEO_ALLOW_SCREENSAVER=1
> >
> > That may or may not be your problem though.
> >
> >
> Hmmm - - - - will dig into that but I don't run any steam connected
> items - - - at least AFAIK but - - - thanks!
> 
> Reassuring to know that I'm not the only one with a similar problem!!!

I had that similar problem; a laptop + second monitor, and for me it
was caused by "xfsettingsd" which discovered the monitor turning off
(due to screen blanking) and then forced it back on. The program
seemed to react to the acpi video events and really didn't want the
second monitor turned off while connected.

I resolved this by not running xfsettingsd. That also means the
keyboard shortcuts don't work (other than those of the window
manager), and of course no compositor (but who cares about that?).

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

Re: [DNG] window manager question

[Ralph Ronnquist]

On Thu, May 19, 2022 at 11:33:16AM +1000, Ralph Ronnquist wrote:
> On Wed, May 18, 2022 at 06:17:44PM -0700, Fred wrote:
> > On 5/18/22 17:46, Ralph Ronnquist wrote:
> > > On Wed, May 18, 2022 at 02:47:25PM -0700, Fred wrote:
> > > > Hello,
> > > > 
> > > > I normally use openbox for window manager but I would like to try fvwm. 
> > > > Can
> > > > this be done without disrupting openbox and how to do it?
> > > 
> > > Run X on a free virtual terminal, then you'll start fvwm and, say,
> > > xterm on that:
> > > 
> > > E.g.:
> > > $ sudo /usr/lib/xorg/Xorg -nolisten tcp -auth $HOME/fvwm-trial.auth :2 
> > > vt09
> > > $ DISPLAY=:2
> > > $ fvwm&
> > > $ xterm&
> > > 
> > > That will start an X server on vt9 with display identity :2, with fvwm
> > > and an xterm. Shift to it with C-A-F9 and shift back with C-A-F7.
> > > 
> > > Ralph.
> > > ___
> > > Dng mailing list
> > > Dng@lists.dyne.org
> > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> > Hi Ralph,
> > 
> > I assume that when I install fvwm first it won't automagically replace
> > openbox?
> 
> I donät think so. I installed fvwm on my xfce without hiccup. Though I
> havenät tried rebooting yet.
> 
> > Your sudo command line and following commands are executed in an openbox
> > xterm which starts fvwm in the "void" and the C-A-F9 switches out of openbox
> > and into fvwm?
> 
> Yes, all fine.
> 
> > 
> > When I am done evaluating fvwm I can stop it by kill -9 whatever-its-PID is?
> > Or is there a proper way?
> 
> Yes. Will need sudo of course, since Xorg is owned by root.

See e.g.

https://www.x.org/archive/X11R6.8.1/doc/Xserver.1.html#sect11

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

Re: [DNG] window manager question

[Ralph Ronnquist]

On Wed, May 18, 2022 at 06:17:44PM -0700, Fred wrote:
> On 5/18/22 17:46, Ralph Ronnquist wrote:
> > On Wed, May 18, 2022 at 02:47:25PM -0700, Fred wrote:
> > > Hello,
> > > 
> > > I normally use openbox for window manager but I would like to try fvwm. 
> > > Can
> > > this be done without disrupting openbox and how to do it?
> > 
> > Run X on a free virtual terminal, then you'll start fvwm and, say,
> > xterm on that:
> > 
> > E.g.:
> > $ sudo /usr/lib/xorg/Xorg -nolisten tcp -auth $HOME/fvwm-trial.auth :2 vt09
> > $ DISPLAY=:2
> > $ fvwm&
> > $ xterm&
> > 
> > That will start an X server on vt9 with display identity :2, with fvwm
> > and an xterm. Shift to it with C-A-F9 and shift back with C-A-F7.
> > 
> > Ralph.
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> Hi Ralph,
> 
> I assume that when I install fvwm first it won't automagically replace
> openbox?

I donät think so. I installed fvwm on my xfce without hiccup. Though I
havenät tried rebooting yet.

> Your sudo command line and following commands are executed in an openbox
> xterm which starts fvwm in the "void" and the C-A-F9 switches out of openbox
> and into fvwm?

Yes, all fine.

> 
> When I am done evaluating fvwm I can stop it by kill -9 whatever-its-PID is?
> Or is there a proper way?

Yes. Will need sudo of course, since Xorg is owned by root.

regards,

Ralph.

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

Re: [DNG] window manager question

[Ralph Ronnquist]

On Thu, May 19, 2022 at 10:46:31AM +1000, Ralph Ronnquist wrote:
> On Wed, May 18, 2022 at 02:47:25PM -0700, Fred wrote:
> > Hello,
> > 
> > I normally use openbox for window manager but I would like to try fvwm. Can
> > this be done without disrupting openbox and how to do it?
> 
> Run X on a free virtual terminal, then you'll start fvwm and, say,
> xterm on that:
> 
> E.g.:
>  
> $ sudo /usr/lib/xorg/Xorg -nolisten tcp -auth $HOME/fvwm-trial.auth :2 vt09
> $ DISPLAY=:2
> $ fvwm&
> $ xterm&
> 
> That will start an X server on vt9 with display identity :2, with fvwm
> and an xterm. Shift to it with C-A-F9 and shift back with C-A-F7.
> 

I lost the ">& $HOME/fvwm.log &" bit at the end of the first line.

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

Re: [DNG] window manager question

[Ralph Ronnquist]

On Wed, May 18, 2022 at 02:47:25PM -0700, Fred wrote:
> Hello,
> 
> I normally use openbox for window manager but I would like to try fvwm. Can
> this be done without disrupting openbox and how to do it?

Run X on a free virtual terminal, then you'll start fvwm and, say,
xterm on that:

E.g.:
 
$ sudo /usr/lib/xorg/Xorg -nolisten tcp -auth $HOME/fvwm-trial.auth :2 vt09
$ DISPLAY=:2
$ fvwm&
$ xterm&

That will start an X server on vt9 with display identity :2, with fvwm
and an xterm. Shift to it with C-A-F9 and shift back with C-A-F7.

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

Re: [DNG] no access to router administation page

[Ralph Ronnquist]

On Sat, Apr 23, 2022 at 06:09:31PM -0400, Haines Brown wrote:
> I find that I now cannot access my router administration page. The 
> router provides access to internet, but when I run 192.168.1.254 (this 
> IS the correct address), the connection times out. This happens both 
> with Chromium and Firefox. Rebooting the router and resarting the 
> network did not help

HTTP://192.168.1.254

Ralph.

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

Re: [DNG] mouse driver question

[Ralph Ronnquist]

On Sat, Apr 23, 2022 at 09:07:57AM -0700, Fred wrote:
> On 4/23/22 02:34, k...@aspodata.se wrote:
> > Fred:
> > > On 4/22/22 15:31, k...@aspodata.se wrote:
> > ...
> > > >gpm -b 1200 -m /dev/ttyS1 -t msc
> > ...
> > > It shows up at /dev/ttyUSB0.  I have tried that command line several
> > > times.  Nothing happens.  ps -e shows gpm is running.  The pointer will
> > > not move and the mouse buttons have no effect.
> > ...
> > 
> > You have to be aware that gpm is for virtual consoles:
> > 
> > $ man gpm | grep 'gpm - '
> > gpm - a cut and paste utility and mouse server for virtual consoles
> > 
> > So in X11, openbox etc. graphical environment, it has no effect unless
> > you take special action. With graphical environment I mean bitmapped as
> > opposed to character (i.e. letters) based graphics.
> > 
> > Testing with gpm is best done without X11, so stop your window manager
> > (obenbox) and exit from X11. If you then is presented with a greeter
> > (also called display manager, see
> >   https://en.wikipedia.org/wiki/X_display_manager_(program_type)
> > ), see if you can stop the greeter.
> > 
> > Also testing has to be done as root.
> > 
> > So, make sure you are running in a virtual console and logged in as
> > root, then run the gpm -b etc. thing and move the mouse around.
> > 
> > To make the mouse to work in X11, please test the mouse with gpm in
> > a console first to assert basic functionality, and then come back.
> > 
> > Regards,
> > /Karl Hammar
> > 
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> Hi,
> I understand now.  I was stuck on gpm because it worked some time ago on
> Debian Jessie.  I was not ready to continue with it then because I still had
> use of my Sun workstation.  The Sun is gone now, I was able to move the
> application program to Linux and now I need a three button mouse without the
> scroll wheel that works with X11.  Maybe the Sun mouse.
> 
> A previous post mentioned xorg.conf which doesn't appear to exist in Devuan
> Beowulf (AMD64).
> 
> So, where do I go from here?

I think all mice are supposed to be handled by the kernel and will
then get presented at /dev/input/mice

You should be able to check that with a simple
$ cat -v /dev/input/mice
which should then show "noise" when you move the mouse.

Then, I think the X11 system relies on udev for setting up its inputs
and load the appropriate modules. You may take over that and do things
"by hand" by a) making the following file /etc/X11/xorg.conf.d/a.conf

Section "ServerFlags"
Option "AutoAddDevices" "false"
EndSection


and b) installing xserver-xorg-input-kbd and xserver-xorg-input-mouse

With that you avoid the automagic processes around X11 inputs and
might have a slightly more stable system for tracking down the issue,
if it remains. (Needs an X11 restart of course)

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

Re: [DNG] daedalus with chromiium

[Ralph Ronnquist]

presuamably it now says daedalus with u rather than daedalas ?

Ralph.

On Mon, Apr 18, 2022 at 04:22:54PM -0400, Haines Brown wrote:
> I apologize for allowing Bob's message to get burried.
> 
> On Sat, Apr 16, 2022 at 09:02:08PM -0600, Bob Proulx via Dng wrote:
> > Haines Brown wrote:
> > > I still get "Unable to locate package chromium". It seems that when I
> > > did update/dist-upgrade after modifying sources.list to accommodate
> > > daedulus I did not get the no InRelease file error. The chimaera
> > > previously installed on this disk did not have chromium installed.
> > 
> > What does this say for you?
> > 
> > apt-cache policy chromium
> > 
> > It should say something similar to this.
> > 
> > root@clash:~# apt-cache policy chromium
> > chromium:
> >   Installed: (none)
> >   Candidate: 100.0.4896.127-1
> >   Version table:
> >  100.0.4896.88-1 500
> > 500 http://deb.debian.org/debian daedalus/main amd64 Packages
> 
> Yes it did
> 
> I stumbled on the reason for my not getting a release file. The 
> line in my sources.list was 
> 
>   deb http://deb.devuan.org/merged daedalas main non-free contrib
> 
> I changed it to 
> 
>   deb http://deb.devuan.org/merged daedalas main
> 
> and the update/upgrade worked. I was then able restore the non-free 
> and contrib and install chromium.
> 
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beowulf to Chimaera update breaks suspend on laptop

[Ralph Ronnquist]

Fair enough; I remembered that I've also disabled "xfsettings" because
it kept waking up my second monitor after I shut the lid. I'm using
acpid to capture the lid button event, then invoking pm-suspend in the
handler script (after resetting the keyboard and screen locking).

Ralph.

On Fri, Apr 08, 2022 at 08:24:43AM +0800, Brad Campbell via Dng wrote:
> On 8/4/22 08:15, Ralph Ronnquist wrote:
> > afaik on chimaera xfce4 relies on elogind for handling "suspend on lid
> > close", and this is something you may disable by a slight edit of
> > /etc/elogind/logind.conf, to have the three assignments:
> > HandleLidSwitch=ignore
> > HandleLidSwitchExternalPower=ignore
> > HandleLidSwitchDocked=ignore
> > 
> > Hopefully that will let your previous suspend solution work.
> > 
> 
> G'day Ralph,
> 
> No, that didn't work. xfce4-power-manager had already taken over the 
> monitoring and management and I couldn't
> figure out how to stop it using elogind as the back-end even with all the 
> suspend/hibernate tasks disabled
> in elogind.
> 
> As pm-utils hasn't been updated in years, and xfce4 recently dropped support 
> for it entirely (removed the interface code)
> I figure I'm going to have to make elogind work at some point, so it might as 
> well be now.
> 
> Regards,
> Brad
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beowulf to Chimaera update breaks suspend on laptop

[Ralph Ronnquist]

afaik on chimaera xfce4 relies on elogind for handling "suspend on lid
close", and this is something you may disable by a slight edit of
/etc/elogind/logind.conf, to have the three assignments:
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore

Hopefully that will let your previous suspend solution work.

Ralph.

On Thu, Apr 07, 2022 at 08:58:36PM +0800, Brad Campbell via Dng wrote:
> G'day,
> 
> I could use a bit of advice if anyone has the relevant experience.
> 
> My laptop is running Devuan Beowulf currently, but this suspend config goes 
> back at least 10 years.
> It suspends / hibernates using pm-utils with the uswsusp back-end onto a 
> dmycrypted swap partition. The kernel is vanilla with a cut-down config and 
> locally compiled.
> 
> This works flawlessly and has done since I set it up. The GUI is xfce4 and 
> when I hit the power button xfce4-power-manager does all the right things 
> (which is hit up pm-utils and get out of its way).
> 
> Last night I upgraded to Chimaera. This installed elogind and tries to use 
> that to pull the relevant kernel levers to suspend. Unfortunately on my 
> system, while it suspends most times, it comes back about 1 in 10 and then 
> usually the nvme is broken and it dies in a ball of flames. I spent the best 
> part of a day experimenting with the in-kernel suspend mechanisms and I can't 
> seem to make it work, while the trusty old uswsusp userspace suspend/resume 
> works first time every time.
> 
> So, I'm asking for either :
> - Experience in making the in-kernel mechanisms work; or preferably
> - How to remove elogind from an xfce4 Chimaera install and make 
> xfce4-power-manager use pm-utils like it used to.
> 
> Does anyone have any ideas?
> 
> Thankfully I always backup the root partition before an upgrade, so a 
> rollback to a working system was only a quick rsync away. I'd like to upgrade 
> (and I've upgraded all my desktops) but working suspend is a not-negotiable 
> on a laptop.
> 
> Regards,
> Brad
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Web md RAID monitoring [was: Re: Fake RAID]

[Ralph Ronnquist via Dng]

On Sat, 12 Mar 2022 09:33:01 +1100
Ralph Ronnquist  wrote:

> On Fri, 11 Mar 2022 16:04:45 +0100
> Didier Kryn  wrote:
> > 
> >      Its almost done. I have added a few features devised from
> > Tito's suggestions, and added git version control, but I can't
> > remember how to create the initial version in Devuan's git store.
> 
> You need an acount set up first; let's say it's "kryn" and for the
> sake of example I use the name "webraid" for this project.
> 
> Then, at home, you use the 2 commands:
> 
> $ git remote add origin g...@git.devuan.org:kryn/webraid.git
> 
> $ git push --set-upstream origin master
> 
> Thereafter you need to jump onto the store's web interface and change
> the project settings into not being a private project.

Actually, the above would be only if you have your ssh key registered
at the git store. If not you would rather use the following first
command:

$ git remote add origin https://git.devuan.org/kryn/webraid.git

and then follow on with the login credentials it asks for.

regards,

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

Re: [DNG] Web md RAID monitoring [was: Re: Fake RAID]

[Ralph Ronnquist via Dng]

On Fri, 11 Mar 2022 16:04:45 +0100
Didier Kryn  wrote:
> 
>      Its almost done. I have added a few features devised from Tito's 
> suggestions, and added git version control, but I can't remember how
> to create the initial version in Devuan's git store.

You need an acount set up first; let's say it's "kryn" and for the sake
of example I use the name "webraid" for this project.

Then, at home, you use the 2 commands:

$ git remote add origin g...@git.devuan.org:kryn/webraid.git

$ git push --set-upstream origin master

Thereafter you need to jump onto the store's web interface and change
the project settings into not being a private project.

regards,

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

Re: [DNG] No-Internet Devuan Installer?

[Ralph Ronnquist via Dng]

On Thu, 24 Feb 2022 22:14:19 +0100
aitor  wrote:

> Hi,
> 
> On 24/2/22 21:39, Dr. Nikolaus Klepp via Dng wrote:
> 
> >> Isn't that exactly what
> >> https://files.devuan.org/devuan_chimaera/desktop-live/
> >>
> >> and
> >> https://files.devuan.org/devuan_chimaera/installer-iso/
> >> devuan_chimaera_4.0.0_amd64_desktop.iso and
> >> devuan_chimaera_4.0.0_i386_desktop.iso
> >>
> >> do?  
> > And you'd need to burn the packages of all extra software you want
> > (e.g. *-dev) + dependecies - in  case that you want to install them
> > later. Might turn out that you need a copy
> > ofhttp://pkgmaster.devuan.org/merged/dists/chimaera-*  of whatever
> > architecture you want to use. Don't know how big a copy of one
> > architecture might be, but I guess you should use BD instead of
> > DVD.  
> 
> Only the netinst image requires network connection. This image
> contains just the minimal amount of packages to install the base
> system; from thereon the remaining packages are installed over the
> internet.
> 
> For your purpose, Steve, the desktop installer-iso mentioned by
> golinux might be the best choice. As a complement, cd2, cd3 and cd4
> contain more packages sorted by popularity. So labeled images are
> entirely optional and play the role of a local repository that can be
> added with "apt-cdrom add". Hence, they aren't meant to boot.

.. and nowadays there is the "pool1" ISO that includes the 5000 "most
popular" packages. That's double of desktop ISO which merely includes
the 2500 most "popular packages".

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

Re: [DNG] Install Daedalus

[Ralph Ronnquist via Dng]

On Tue, 8 Feb 2022 11:39:51 -0500
"Ismael L. Donis Garcia"  wrote:

> When installing the
> devuan_daedalus_5.0.preview-20220207_amd64_server.iso file do I get a
> graphical linux installation or only console?

All modern Devuan installer ISOs use the same "text mode" installer. It
lets you install a graphical desktop, though only the "desktop" ISO and
the complementary pool-only ISOs hold those packages for off-line
installation. Otherwise it requires network for that.

> 
> I recently installed an older version and got a non-graphical
> installation as a result, also it didn't allow me to mount an NTFS
> partition during the installation, only using the installation disk
> since I don't have Internet access on the PC where I am going to
> mount it 

Did you try the mount.ntfs command? There does seem to be an issue with
using "mount -t ntfs" but the direct command should be fine.

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

Re: [DNG] Accepting changed priority for chimaera-backports- what action?

[Ralph Ronnquist via Dng]

On Sun, 23 Jan 2022 12:44:55 +0100
"d...@d404.nl"  wrote:

> On 23-01-2022 10:17, terryc wrote:
> > So exactly what does this message mean and exactly what do I need
> > to do. Previously I've just repeated the command and the nag
> > message went away but this time it stays.
> >
> > user@system: sudo apt-get update
> > Get:1 http://deb.devuan.org/merged chimaera InRelease [33.9 kB]
> > Get:2 http://deb.devuan.org/merged chimaera-security InRelease
> > [21.5kB] Get:3 http://deb.devuan.org/merged chimaera-updates
> > InRelease [26.5 kB] Get:4 http://deb.devuan.org/merged
> > chimaera-backports InRelease [19.4 kB] Get:5
> > http://deb.devuan.org/merged chimaera/main amd64 Packages [8,311
> > kB] Get:6 http://deb.devuan.org/merged chimaera/main i386 Packages
> > [8,248 kB] Get:7 http://deb.devuan.org/merged chimaera/main
> > Translation-en [6,482 kB] Get:8 http://deb.devuan.org/merged
> > chimaera-security/main amd64 Packages [111 kB] Get:9
> > http://deb.devuan.org/merged chimaera-security/main i386 Packages
> > [111 kB] Get:10 http://deb.devuan.org/merged chimaera-updates/main
> > amd64 Packages [2,608 B] Get:11 http://deb.devuan.org/merged
> > chimaera-updates/main i386 Packages [2,612 B]
> >
> > Reading package lists... Done
> > E: Repository 'http://deb.devuan.org/merged chimaera-backports
> > InRelease' changed its default priority for apt_preferences(5) from
> > 500 to 100. N: This must be accepted explicitly before updates for
> > this repository can be applied. See apt-secure(8) manpage for
> > details
> >
> > Except man apt-secure doesn't give me anything I understand.
> >
> > TIA.
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng  
> 
> IIRC you should use apt instead of apt-get.
> apt will ask for conformation.

That's what I do. But according to the man page one may also use a
command line option:

$ sudo apt-get update --allow-releaseinfo-change-defaultpin

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

Re: [DNG] HDA AD1882 no card

[Ralph Ronnquist via Dng]

On Mon, 10 Jan 2022 11:55:22 +0100 (CET)
k...@aspodata.se wrote:

> Nick:
> > On 09-01-2022 19:32, k...@aspodata.se wrote:  
> > > I have a lenovo desktop computer which I cannot make sound work
> > > on, what am I missing ?
> > >
> > > It's a HDA AD1882 "sound card", but alsamixer says "no card".  
> ...
> > Maybe obvious but is your sound card enabled in the BIOS? (I did
> > have that once so I always ask now)  
> 
> Yes, very obvious...
> The only configuration in BIOS I found is ENABLED/DISABLED,
> and yes, I have set it to ENABLED.
> 
> Setting it to DISABLE did not help.
> Nor did disabling pci parity, power management etc.

There's good stuff in kernel Documentation/sound/hd-audio/notes.rst
that may help, especially about probing.

Ralph.

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

Re: [DNG] Pipewire and PulseAudio: apulse & firefox

[Ralph Ronnquist via Dng]

On Wed, 5 Jan 2022 18:30:25 +0100
Antoine via Dng  wrote:

> On Tuesday,  4 January at 14:24, Bob Proulx via Dng wrote:
> > (...)
> >Portable shell use would be "whatever() {" which I wish to encourage
> >by saying that here.  Please use only that form for /bin/sh scripts.
> >:-)
> >
> >The "function" keyword was introduced by ksh.  This syntax is also
> >supported by bash and zsh but not by other shells.  When "function"
> >is used then the #! line must be /bin/ksh, /bin/bash, or /bin/zsh.  
> 
> Well, learn something new every day...
> Thank you for that little nugget.

Agree.

You need to add a second line "alias function=''" in the scripts to
enjoy the "function foo()" syntax also with /bin/sh and /bin/dash 

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

Re: [DNG] Question about the text editor named medit.

[Ralph Ronnquist via Dng]

On Tue, 4 Jan 2022 13:18:07 +0100
Edward Bartolo via Dng  wrote:

> Dear All,
> 
> Upgrading to chimeara removed medit, a text editor I used for writing
> code and any other plain text document. I could not install it and it
> seems it has been removed from the repository. Searching online for a
> recently updated source tarball, I did not find any. It seems it has
> been abandoned by its developer/s.
> 
> Thanks for your replies.

.. gratuitous result:

https://askubuntu.com/questions/1372529/is-it-possible-to-get-latest-version-of-medit-aka-mooedit-for-ubuntu-20-04-lts

The tarball was available; the rest is for ubuntu of course

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

Re: [DNG] merged /usr breakage

[Ralph Ronnquist via Dng]

On Mon,  3 Jan 2022 18:25:12 +0100 (CET)
k...@aspodata.se wrote:

>  The first one gives me an unbootable system
> $ ldd /sbin/init | grep /usr
> libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
> (0x7f737ba28000)
> 
>  fortunately /bin/bash didn't depend on /usr so I could boot with
>  init=/bin/bash, but there is more breakage:
> 
> $ ldd /bin/mount | grep /usr
> libmount.so.1 => /usr/lib/x86_64-linux-gnu/libmount.so.1
> (0x7f5bc9b06000) libblkid.so.1 =>
> /usr/lib/x86_64-linux-gnu/libblkid.so.1 (0x7f5bc98f)
> libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
> (0x7f5bc982c000)
> 
> $ dpkg -l | grep sysvinit-core
> ii  sysvinit-core2.96-7+devuan1
>   amd64System-V-like init $ dpkg -l | grep mount
> ii  libmount1:amd64  2.36.1-8+devuan1
>   amd64device mounting library ii  mount
>   2.36.1-8+devuan1   amd64
> tools for mounting and manipulating filesystems
> 

No solution, but it looks like "the culprit" for this is that the
libselinux1 package changed in between beowulf (buster) and chimaera
(bullseye) from depending on libpcre3 to depending on libcre2-8-0.

The former, libpcre3, installs its libraries in both /lib and /usr/lib
(different), in both its beowulf and chimaera versions,  whereas
libcre2-8-0 installs only in /usr/lib.

I haven't reviewed the source for comment around that dependency
change.

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

Re: [DNG] Priter trouble again.

[Ralph Ronnquist via Dng]

On Sat, 1 Jan 2022 15:07:44 -0500
Hendrik Boom  wrote:

> I installed CUPS a part of the standard istall long ago.
> I had no trouble configuring it back the to talk sweet to me printer.
> Worked fine.  Bu tnow it doesn't.
> 
> The printer seems to hae changed its IP number.
> Now I can tell it explicitly what IP numder to use by entering stuff
> in its physical control panel.  So all I should have to do is to set
> its IP number to whatever CUPS (now unsuccessfuly) uses to talk to
> it. 
> 
> What I don't know is how to get CUPS to tell me what IP number it
> currently thinks belongs to the printer.
> 
> There should be some simple way of asking CUPS to tell me this.

Perhaps it works with either
   # grep Location /etc/cups/printers.conf
or
   # grep DeviceURI /etc/cups/printers.conf
plus some intelligent parsing.

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

Re: [DNG] EFI boot not found, partially solved in gnuinos (Was: 1st boot failed but repaired OK)

[Ralph Ronnquist via Dng]

On Tue, 21 Dec 2021 01:44:39 +0100
aitor  wrote:
> ...
> The outcome is that i've been compelled to turn back the distributor
> to its default ID=devuan, and i'm rebuilding the images of gnuinos
> chimaera right now so that they will work properly in UEFI mode
> without workarounds during the first boot on the part of users.
> 
> I wonder, to this regard, what is the trick in Devuan to put in place
> the distributor ID without the need of hijacking the boot loader...

... doesn't "scripts/magic-touch" tell the story?

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

Re: [DNG] chimaera and xfce look consistency

[Ralph Ronnquist via Dng]

On Sat, 20 Nov 2021 22:39:06 +0100
Riccardo Mottola via Dng  wrote:

> Hello,
> 
> 
> Riccardo Mottola via Dng wrote:
> > Hi,
> >  
> 
> sorry, message was sent without content.. I wonder, something went
> wrong with Thunderbird which sent out an email when I put the laptop
> to sleep.
> 
> What I wanted to write is this.
> 
> I use xfce since ascii and chimaera: I think it has a consistent
> look: timeless enough, something between CDE and Windows XP but not
> so ugly. I refer especially to the windowmanager, smooth design, well
> usable, not inrusive. Colors, shades changed but it remained.
> 
> Now, in chimaera, I notice something inconsistent. When opening 
> applications like xterm or firefox, the look of windows decoration is 
> similar, but updated to previous versions.
> Other windows, however "internal" apps, like system preferences,
> panels, etc of XFCE look ugly without decorations, similar to windows
> 10. Is that an intention? or is there some setting inconsistency I
> did not detect?
> 
> Thanks for hints. Of course you may understand what I want to restore 
> proper decoration to all windows, not the other way around.

What you see there is one of the effects of "Client Side Rendering"
which is this new fad that wants to return to the cowboy times of
mid-80's where every GUI program implements its own looks and style.
It's generally called "progress".
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lpr command not working

[Ralph Ronnquist via Dng]

On Wed, 17 Nov 2021 06:51:39 +1100
Ralph Ronnquist  wrote:

> On Tue, 16 Nov 2021 08:03:21 -0500
> Haines Brown  wrote:
> 
> > On Tue, Nov 16, 2021 at 12:28:57PM +1100, Ralph Ronnquist via Dng
> > wrote:
> > > On Mon, 15 Nov 2021 19:21:15 -0500
> > > Haines Brown  wrote:  
> > > > These problems I'll pursue, but my pont is that none of the ways
> > > > to get access to the lpr command are workig.  
> > > 
> > > 
> > > use: $ lpstat -d -v -p
> > > to list which the default printer is and which printers there are
> > >  
> > 
> >   $ lpstat -d -v  -p
> >   no system default destination
> >   lpstat: Bad file descriptor
> >   lpstat: Bad file descriptor
> > 
> > > use: # lpadmin -d "$queue"
> > > to set $queue as the default for cups and lpr  
> > 
> > I'm unsure whether you are telling me now to set the queue for CUPS 
> > or if I need to set it to "queue". 
> > 
> > I do # /etc/cups/diff -y cupsd.conf cupsd.conf.O | less .
> > I discover that is it cups.conf. not cups.conf.
> > So "O" means Original?
> > 
> > My current cupsd.conf has line Port 631 vs. Listen localhost:631
> > 
> > My current location is 
> > 
> > 
> > # Allow shared printing... 
> > Order allow,deny   
> > Allow @LOCAL   
> > 
> > 
> > the file cupsd.conf.O has 
> > 
> >   
> >   # Restrict access to the server...
> > Order allow,deny
> >   
> > 
> > One thing I could is to backup /etc/cups/cupsd.conf and replace
> > it with cupsd.conf.O and reinstall the printer. Would you suggest
> > doing this? 
> >  
> > > (using cups-lpr)  
> > 
> > what does this mean?
> 
> Sorry, I was a bit short...
> 
> That command, "lpadmin -d $queue", is documented as the one to be used
> for telling CUPS and lpr (from cups-lpr) which printer to use as
> default printer; the $queue bit is "the printer queue name" or "the
> user's printer name" and e.g. not it's connection detail (unless they
> happen to coincide).
> 
> The resulting "conf" change seems to be the inclusion of the line
> with "" (where again $queue is the printer
> queue name, which also is the file name for the ppd of the printer),
> together with a subsequent "". That same XML
> "object" appears in both /etc/cups/printers.conf and
> /etc/cups/printers.conf.O, and that's about the limit of what I know
> about those files.
> 
> In my simpleton approach to printing, I usually use the GUI of
> "system-config-printer" to administrate via its required combinations
> of mousing and keyboarding, and in fact I print so seldom that I
> hadn't even installed an lpr program before. So my short note merely
> reflected what I just had learnt from the man pages while attempting
> to print a small text file with lpr, and discovering that my
> defaulted default printer "PDF" was not what I wanted as default.

... actually the "DefaultPrinter" object has a lot of more stuff in it,
and is apparently just a rebadging of one of the pre-existing "" objects.

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

Re: [DNG] lpr command not working

[Ralph Ronnquist via Dng]

On Tue, 16 Nov 2021 08:03:21 -0500
Haines Brown  wrote:

> On Tue, Nov 16, 2021 at 12:28:57PM +1100, Ralph Ronnquist via Dng
> wrote:
> > On Mon, 15 Nov 2021 19:21:15 -0500
> > Haines Brown  wrote:  
> > > These problems I'll pursue, but my pont is that none of the ways
> > > to get access to the lpr command are workig.  
> > 
> > 
> > use: $ lpstat -d -v -p
> > to list which the default printer is and which printers there are  
> 
>   $ lpstat -d -v  -p
>   no system default destination
>   lpstat: Bad file descriptor
>   lpstat: Bad file descriptor
> 
> > use: # lpadmin -d "$queue"
> > to set $queue as the default for cups and lpr  
> 
> I'm unsure whether you are telling me now to set the queue for CUPS 
> or if I need to set it to "queue". 
> 
> I do # /etc/cups/diff -y cupsd.conf cupsd.conf.O | less .
> I discover that is it cups.conf. not cups.conf.
> So "O" means Original?
> 
> My current cupsd.conf has line Port 631 vs. Listen localhost:631
> 
> My current location is 
> 
> 
> # Allow shared printing... 
> Order allow,deny   
> Allow @LOCAL   
> 
> 
> the file cupsd.conf.O has 
> 
>   
>   # Restrict access to the server...
> Order allow,deny
>   
> 
> One thing I could is to backup /etc/cups/cupsd.conf and replace
> it with cupsd.conf.O and reinstall the printer. Would you suggest
> doing this? 
>  
> > (using cups-lpr)  
> 
> what does this mean?

Sorry, I was a bit short...

That command, "lpadmin -d $queue", is documented as the one to be used
for telling CUPS and lpr (from cups-lpr) which printer to use as default
printer; the $queue bit is "the printer queue name" or "the user's
printer name" and e.g. not it's connection detail (unless they happen
to coincide).

The resulting "conf" change seems to be the inclusion of the line
with "" (where again $queue is the printer queue
name, which also is the file name for the ppd of the printer), together
with a subsequent "". That same XML "object" appears
in both /etc/cups/printers.conf and /etc/cups/printers.conf.O, and
that's about the limit of what I know about those files.

In my simpleton approach to printing, I usually use the GUI of
"system-config-printer" to administrate via its required combinations
of mousing and keyboarding, and in fact I print so seldom that I hadn't
even installed an lpr program before. So my short note merely reflected
what I just had learnt from the man pages while attempting to print a
small text file with lpr, and discovering that my defaulted default
printer "PDF" was not what I wanted as default.

regards,

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

Re: [DNG] lpr command not working

[Ralph Ronnquist via Dng]

On Mon, 15 Nov 2021 19:21:15 -0500
Haines Brown  wrote:
> These problems I'll pursue, but my pont is that none of the ways to
> get access to the lpr command are workig.


use: $ lpstat -d -v -p
to list which the default printer is and which pringters there are

use: # lpadmin -d "$queue"
to set $queue as the default for cups and lpr

(using cups-lpr)

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

Re: [DNG] lpr command not working

[Ralph Ronnquist via Dng]

On Mon, 15 Nov 2021 15:11:22 -0500
Haines Brown  wrote:

> On Mon, Nov 15, 2021 at 06:18:06PM +0100, Dr. Nikolaus Klepp via Dng
> wrote:
> > Anno domini 2021 Mon, 15 Nov 10:52:06 -0500
> >  Haines Brown scripsit:  
> > > On Sun, Nov 14, 2021 at 12:55:59PM -0500, Haines Brown wrote:  
> > > > I reinstalled a printer on a Chimaera box. The CUPS test file
> > > > prints just fine. The lpr  > > > send data to the printer. Status: Processing - "Sending data to
> > > > printer." Some 15 min (?) later the job does print.
> > > > ...

According to
https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=file=bin%2Flpr=submit
there are three packages providing "bin/lpr":
cups-bsd
lpr
lprng

Which one do you have? Are they all the same?
I think they are somewhat different and from memory I think the cups-bsd
variant is best integrated with cups.

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

Re: [DNG] Chimaera and ntpd/openntpd/chrony???

[Ralph Ronnquist via Dng]

Hmm not sure where you take information from:

https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=file=bin%2Fntpd=submit

https://pkginfo.devuan.org/cgi-bin/package-query.html?c=package=ntp=1:4.2.8p15+dfsg-1

perhaps a missing crucial "apt-get update" ?

regards,

Ralph.

On Wed, 20 Oct 2021 14:56:42 +0900
Simon Walter  wrote:

> Hi all, ntpd doesn't seem to be in the default repos. What is the
> recommended NTP daemon? I've never used openntpd nor chrony.
> 
> Thanks,
> 
> Simon
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

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

Re: [DNG] Fw: Testers for Chimaera alpha netinstall iso

[Ralph Ronnquist via Dng]

Which ISO does this concern? Does it happen with the latest?
Which hands-on is involved?
Bugs would still be reported as per the original instruction.

regards,

Ralph.

On Tue, 12 Oct 2021 18:29:43 +0900
Simon Walter  wrote:

> I'm trying to install Chimaera from the netinstall, and I get the
> debootstrap error:
> "Failed to determine the codename for the release"
> 
> Is this known? Where should I report problems with the installer?
> 
> Thanks,
> 
> Simon
> 
> On 2021-06-18 07:24, Ralph Ronnquist via Dng wrote:
> > 
> > 
> > Begin forwarded message:
> > 
> > Date: Fri, 18 Jun 2021 08:22:06 +1000
> > From: Ralph Ronnquist 
> > To: Devuan Maintainers 
> > Subject: Testers for Chimaera alpha netinstall iso
> > 
> > 
> > The Chimaera alpha netinstall ISOs version dated 14-Jun-2021 or
> > later now include "the final" versions of the forked udebs, and
> > they need testing to confirm that it is ready for RC1 in the coming
> > month.
> > 
> > The URL path at files.devuan.org is devuan_chimaera/installer-iso/
> > but that's rather slow to download from, and you're better off using
> > some of mirrors listed at https://www.devuan.org/get-devuan
> > 
> > E.g
> > https://sledjhamr.org/devuan-cd/devuan_chimaera/installer-iso/devuan_chimaera_4.0.alpha-20210614_amd64_netinstall.iso
> > 
> > Please report bugs via email sent to "submit" at bugs.devuan.org
> > with the first 2 lines being the following:
> > Package: devuan-installer
> > Version: 4.0
> > 
> > But, please report against the source package concerned where you
> > can isolate that. And, note that most packages come directly from
> > Debian without forking, and that upstreamed reporting directly to
> > Debian's bug tracking is then best
> > (https://www.debian.org/Bugs/Reporting).
> > 
> > 
> > regards,
> > 
> > Ralph.
> > 
> > 
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >   
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

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

Re: [DNG] devuan gitea broken?

[Ralph Ronnquist via Dng]

On Fri, 24 Sep 2021 21:39:01 +0200
tito  wrote:

> On Fri, 24 Sep 2021 09:57:59 +1000
> Ralph Ronnquist via Dng  wrote:
> 
> > This one turned out to be that someone (aka me) had mistakenly
> > raised a blanket traffic blockage as a misdirected response to an
> > apparent DoS effect via gitea accesses. Things should be better
> > now, at least until I have another go at dealing with the same
> > problem.
> > 
> > Ralph.  
> 
> Hi,
> whatever you did it fixed the web interface.
> It is speedy now, just loading files in the
> editor is still a little slow but acceptable.
> 
> Thanks for your time and effort.

Yeah; if I don't have things to do I create some :)

Btw the favoured way to work with git, both generally and also
for Devuan's git store, is to clone the project into a workspace on your
own machine to edit and commit locally, and then push changes back.
Apart from being slow, editing via the repository browser is error prone
in many ways, especially because it causes a very refined commit history
which reduces its usefulness.

In fact, if you deep dive into the ontological structure that underpins
the notion of version control for collaborative authoring you're likely
to arrive at and take a position to the very question whether editing
while browsing is or is not a contrary idea. I'd say "is".

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

Re: [DNG] devuan gitea broken?

[Ralph Ronnquist via Dng]

This one turned out to be that someone (aka me) had mistakenly raised a
blanket traffic blockage as a misdirected response to an apparent DoS
effect via gitea accesses. Things should be better now, at least until I
have another go at dealing with the same problem.

Ralph.

On Thu, 23 Sep 2021 21:42:41 +0200
tito via Dng  wrote:

> On Wed, 22 Sep 2021 14:54:54 +0200
> tito via Dng  wrote:
> 
> > Hi,
> > is there any problem with devuan's gitea web interface?
> > It loads so slowly that it is impossible to work with it.
> > My connectivity seems ok as all other sites work as expected.
> > 
> > Ciao,
> > Tito
> >
> 
> Hi,
> just wanted to tell that the gitea problem has not improved yet.
> Opening files is slow but editing them is impossible.
> I'm still waiting after 6 min that the file loads in the web editing
> interface.
> It used to work flawlessly  last time I used it so please whatever
> was changed revert it.
> Still after 8.21 mins no file loaded.
> 
> Ciao,
> Tito
>  
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

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

Re: [DNG] /run/user/#

[Ralph Ronnquist via Dng]

On Tue, 31 Aug 2021 12:44:07 +
g4sra via Dng  wrote:

> On Tuesday, August 31st, 2021 at 1:11 PM, Pontus Goffe via Dng
>  wrote:
> > Among running systems I can quickly search I can only find one box
> > without /run/user and it has a custom monolithic kernel so perhaps
> > this is kernel specific rather than packages.  
> 
> Its not kernel specific.
> 

Try "man pam_elogind" .. about line 20 for me...

Ralph.


pgpC8ZPIzAn6r.pgp
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] manpages

[Ralph Ronnquist via Dng]

On Mon, 30 Aug 2021 09:42:25 +
g4sra via Dng  wrote:

> Looking for the gcc..g++ suite manpages, expected to find them in
> 'gcc-doc' but it's missing. Anybody point me in the right direction ?

You find 5:8.3.0-1~bpo10+1 in beowulf-backports, not beowulf,
then 5:10.1.0-1 in chimaera and ceres


pgpjDM1VbRHjL.pgp
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Cannot install on W10 laptop (was: Re: Reinstalling unbootable laptop...)

[Ralph Ronnquist via Dng]

On Sun, 22 Aug 2021 09:21:33 +0200
al3xu5  wrote:

> Sun, 15 Aug 2021 12:05:19 +0200 - al3xu5 :
> ...
> So now I'm trying to reinstall it with Devuan, but I can't.
> 
> Using beowulf netinstaller (3.1.1), it starts with a blocking error:
> 
> ~~~
>   Loading Devuan beowulf installer in standard mode...
> 
>   error: invalid sector size 0
>   error: you need to load the kernel first.
> ~~~

That error suggests that the partition holding the installer's kernel
(off the ISO) is on a partition type that the efi boot program (also off
the ISO) can't handle. E.g. extfat.

Is the install ISO on actual DVD or on USB? If on a USB, how did you
write it? I.e., is that USB a true copy of the ISO?


pgpnbrImt2CI2.pgp
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Download a package, maybe a few, for a different architecture and a different release.

[Ralph Ronnquist via Dng]

On Wed, 18 Aug 2021 19:01:09 -0400
Hendrik Boom  wrote:

> I need to download a package to install on a machine that is
> currently air-gapped.
> 
> I have to download an i386 package for chimaera on an AMD64 beowulf
> machine.
> 
> I'll be transferring that package by sneakernet, and then installing
> it using dpkg..
> If it turns out to have dependencies, I'l have to repeat the process
> for those dependencies.
> 
> How do I go about doing the download?

One "easy access" approach is to use https://pkginfo.devuan.org to
locate the package (deb) concerned, and then download it/them via the
link(s) provided on the package content page(s). That also provides
links for dependencies.

If you want to script it, you might use the XML access variation, e.g.
like these for a bash:i386 index of packages, and the content page for
the version 5.0-4
https://pkginfo.devuan.org/cgi-bin/policy-query.xml?c=package=bash%3Ai386
https://pkginfo.devuan.org/cgi-bin/package-query.xml?c=package=bash:i386=5.0-4

The XML response is friendlier for scripting. The access URLs are
pretty much the same as for HTML but different.

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

Re: [DNG] grub-install device node not found

[Ralph Ronnquist via Dng]

On Wed, 4 Aug 2021 00:59:30 +0200
aitor  wrote:

> Hi,
> 
> On 4/8/21 0:18, aitor wrote:
> >
> > Hi Arnt,
> >
> > On 3/8/21 22:31, Arnt Karlsen wrote:  
> >> ..is there one?  'fdisk -l ' or somesuch should work, even if
> >> there are some new fancy /dev names missing symlinks to /dev/sdc,
> >> e.g. killed by that mlterm crash.  
> >
> > The command for the interactive shell of debian-installer is 
> > "list-devices". Examples:
> >
> > ~ # list-devices usb-partition
> > /dev/sda1
> > /dev/sda2
> >
> > ~# list-devices disk
> > /dev/sda
> > /dev/sdb
> >
> > HTH,
> >
> > Aitor.
> >  
> Forget this, it was a cross-install...
> 
> Aitor.

Yes, it's a matter of ensuring that the device node /dev/sdc is
installed in the "chroot" filesystem; basically doing
   # mknod $target/dev/sdc b 8 32

(see eg linux/Documentation/admin-guide/devices.txt)

If installing on a loopback filesystem you'd need to use the
major:minor of the loopback device while naming it /dev/sdc during this
installation.

.. and don't forget to remove that dev/sdc afterwards

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

Re: [DNG] Fw: Testers for Chimaera alpha netinstall iso

[Ralph Ronnquist via Dng]

Aitor,

eventually it dawned on me that probably you meant the mini.iso which
LeePen builds with debian-installer; he just now merged the forked s/w
(https://git.devuan.org/devuan/debian-installer.git) with debian's and
built new mini.iso(s). Perhaps that is a help?

regards,

Ralph.

On Tue, 3 Aug 2021 18:36:22 +1000
Ralph Ronnquist  wrote:

> Hmm the installer iso's are built with the "installer-iso" project
> https://git.devuan.org/devuan/installer-iso.git
> using the branch amd64-chimaera-sudo (or i386-..)
> 
> This enumerates the udebs (in udeb-sets.mk.tmpl) and it doesn't seem
> to be upset .. it only pulls in libffi7 so evidently not any of those
> udebs. In fact, I tried grep libffi6 through its package files with
> empty result. These are all chimaera and not ceres of course.
> 
> One thing that springs to mind is "newlisp" which depended on libffi6
> on beowulf and libffi7 on chimaera; I'm not sure if that is relevant
> for you, but I think I added it to vdev some winters ago, and I
> believe you might be using vdev...
> 
> Ralph.
> 
> On Tue, 3 Aug 2021 09:54:14 +0200
> aitor  wrote:
> 
> > Hi Ralph,
> > 
> > On 18/6/21 0:24, Ralph Ronnquist via Dng wrote:
> > > The Chimaera alpha netinstall ISOs version dated 14-Jun-2021 or
> > > later now include "the final" versions of the forked udebs, and
> > > they need testing to confirm that it is ready for RC1 in the
> > > coming month.  
> > How are you building debian-installer in chimaera? I did it several 
> > times in ceres,
> > but i'm still getting some .udeb dependency issues in testing. For 
> > instance, libff6 has
> > been replaced by libff7, but there's still something depending on
> > it.
> > 
> > Are you passing flags like "--ignore-errors --keep-going" to the
> > make command, maybe?
> > 
> > Cheers,
> > 
> > Aitor.
> > 
> > 
> 

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

Re: [DNG] Fw: Testers for Chimaera alpha netinstall iso

[Ralph Ronnquist via Dng]

Hmm the installer iso's are built with the "installer-iso" project
https://git.devuan.org/devuan/installer-iso.git
using the branch amd64-chimaera-sudo (or i386-..)

This enumerates the udebs (in udeb-sets.mk.tmpl) and it doesn't seem to
be upset .. it only pulls in libffi7 so evidently not any of those
udebs. In fact, I tried grep libffi6 through its package files with
empty result. These are all chimaera and not ceres of course.

One thing that springs to mind is "newlisp" which depended on libffi6
on beowulf and libffi7 on chimaera; I'm not sure if that is relevant
for you, but I think I added it to vdev some winters ago, and I believe
you might be using vdev...

Ralph.

On Tue, 3 Aug 2021 09:54:14 +0200
aitor  wrote:

> Hi Ralph,
> 
> On 18/6/21 0:24, Ralph Ronnquist via Dng wrote:
> > The Chimaera alpha netinstall ISOs version dated 14-Jun-2021 or
> > later now include "the final" versions of the forked udebs, and
> > they need testing to confirm that it is ready for RC1 in the coming
> > month.  
> How are you building debian-installer in chimaera? I did it several 
> times in ceres,
> but i'm still getting some .udeb dependency issues in testing. For 
> instance, libff6 has
> been replaced by libff7, but there's still something depending on it.
> 
> Are you passing flags like "--ignore-errors --keep-going" to the make 
> command, maybe?
> 
> Cheers,
> 
> Aitor.
> 
> 

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

Re: [DNG] Rant: was fresh install of chimaera on an Ultrabook - no touchpad

[Ralph Ronnquist via Dng]

On Fri, 30 Jul 2021 14:31:17 +0200
tito via Dng  wrote:

> ... If I understood it correctly the
> problem is about adding the drivers and firmware blobs which are in
> the non-free repos to the isos and install images ...

Let me repeat it once: the installer isos do contain all packages named
*firmware* in their respective pool, and in addition, they have a
toplevel directory named /firmware that contains symbolic links to all
of them.

It has been like that since the ASCII installer isos.

... go on ranting.

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

Re: [DNG] Rant: was fresh install of chimaera on an Ultrabook - no touchpad

[Ralph Ronnquist via Dng]

On Wed, 28 Jul 2021 17:29:55 -0400
Steve Litt  wrote:

> Riccardo Mottola via Dng said on Wed, 28 Jul 2021 22:06:15 +0200
> >Hi all,
> >
> >I "converted" a laptop from Windows 7 to Devuan and as a test, I
> >installed chimaera. The intel display should have no issues.
> >Install wasn't too easy due to the system having only WiFi and no
> >Optical drive - the WiFi needs firmware not included in the install
> >media. I used an USB stick with the full DVD, installed offline then
> >found the firmware on debian, copied over with an USB stick and
> >things do work.  
> 
> I hate the preceding hassle. Every Linux distro's install media should
> have all drivers available during installation. After installation, if
> the user wishes to remove all non-free from his computer, he can do
> so. Or, the installation process can come with an "include nonfree
> drivers and blobs" switch that defaults to "yes".
> ...

I thought it worth to accompany this with the factual observation, that
Devuan's chimaera install isos, even before the alpha builds, have all
included all identifiable firmware. There is of course some story about
"using Joliet rather than Rick Ridge", which possibly may apply to
Windows-targeted hardware and cause grief for the unfortunate. And also,
maybe Riccardo's media was not a "Devuan's chimaera installer iso".

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

Re: [DNG] Refracta have a static IP

[Ralph Ronnquist via Dng]

On Tue, 13 Jul 2021 16:41:06 -0400
Steve Litt  wrote:

> Hi all,
> 
> I'm trying to make my new Chimera based Refracta have a static IP
> address at 192.168.0.199/24, in order that every other computer on the
> 192.168.0.0/24 subnet can easily access it, and so I can put it on my
> LAN DNS.
> 
> So I made my /etc/network/interfaces look like the following, which
> follows the guidelines of "man interfaces":
> 
> ===
> auto lo
> iface lo inet loopback
> 
> allow-hotplug eth0
> iface eth0 inet static
>   address 192.168.0.199
>   gateway 192.168.0.1
> ===
> 
> Unfortunately, instead of the IP address being 192.168.0.199, it's a
> DHCP supplied 192.168.0.204 . What additional steps must I take to get
> my desired 192.168.0.199?
> 
> Additional note: When I used 192.168.0.40, which I KNOW is not in my
> leased DHCP range, the result was the same. What must I do to get a
> static IP at 192.168.0.199/24 ?

Maybe you didn't uninstall connman? It has a default setup to use DHCP
for the Ethernet cable, and that's presumably what is helpful here.

According to the connmanctl man page you may reconfigure connman
either to ignore eth0 (which it calls Ethernet_46ea672351_cable, or
something like that), or to use static IP for it.

As far as I can gather, connman calls it a "service", and you would
inspect current operational state with "connmanctl services", followed
by "connmanct services Ethernet_46ea672351_cable" to hone in on its
setup for eth0 (note the name).

Then there is the alternative of purging connman and stay with
ifupdown; if I were to try to advice you, then that would be it.

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

Re: [DNG] problem with apt after restore after crashed disk...

[Ralph Ronnquist via Dng]

I would advice you to use
https://pkginfo.devuan.org/cgi-bin/policy-query.html
for manual recovery of packages. This provides links for downloading
the deb files, and it also presents all the meta information for
following up all dependencies.

Ralph.

On Thu, 1 Jul 2021 12:18:31 +0100 (BST)
Jim Jackson  wrote:

> Hi all,
> 
> Thanks for the various comments on my problem ...
> 
> On Mon, 28 Jun 2021, Jim Jackson wrote:
> 
> > Hi all,
> > 
> > My Beowulf amd64 system hard drive crashed, and after I'd restored
> > my backup I've had problems with apt-get etc.
> > 
> > apt-cache: relocation error: 
> > /usr/lib/x86_64-linux-gnu/libapt-private.so.0.0: symbol 
> > _ZN3URIcvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEB5cxx11Ev 
> > version APTPKG_5.0 not defined in file libapt-pkg.so.5.0 with link
> > time reference
> > 
> > I use rsync for backups, but without the -X -A options, so extended 
> > attributes and ACLs are lost, don't know if that's the reason. If I
> > need to reinstall libapt-pkg5.0 package, does anybody know if it's
> > ok to just to use the debian package file?
> > 
> > If not, can anyone tell where I can get the devuan libapt-pkg5.0
> > package file?  
> 
> I was a bit scared that the devuan packages might not be the debian
> buster ones. Anyway I bit the bullet and downloaded the debian 
> apt_1.8.2.3_amd64.deb package and installed with dpkg -i and cross my 
> fingers :-)
> 
> Anyway apt and apt-get are back. 
> 
> Jim
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

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

[DNG] Fw: Testers for Chimaera alpha netinstall iso

[Ralph Ronnquist via Dng]

Begin forwarded message:

Date: Fri, 18 Jun 2021 08:22:06 +1000
From: Ralph Ronnquist 
To: Devuan Maintainers 
Subject: Testers for Chimaera alpha netinstall iso


The Chimaera alpha netinstall ISOs version dated 14-Jun-2021 or later
now include "the final" versions of the forked udebs, and they need
testing to confirm that it is ready for RC1 in the coming month.

The URL path at files.devuan.org is devuan_chimaera/installer-iso/
but that's rather slow to download from, and you're better off using
some of mirrors listed at https://www.devuan.org/get-devuan

E.g
https://sledjhamr.org/devuan-cd/devuan_chimaera/installer-iso/devuan_chimaera_4.0.alpha-20210614_amd64_netinstall.iso

Please report bugs via email sent to "submit" at bugs.devuan.org with
the first 2 lines being the following:
Package: devuan-installer
Version: 4.0

But, please report against the source package concerned where you can
isolate that. And, note that most packages come directly from Debian
without forking, and that upstreamed reporting directly to Debian's bug
tracking is then best (https://www.debian.org/Bugs/Reporting).


regards,

Ralph.


pgpfh5hO3RLUB.pgp
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] network measurement

[Ralph Ronnquist via Dng]

On Fri, 7 May 2021 20:02:13 -0400
Hendrik Boom  wrote:

> I've been having trouble using zoom recently.
> If there's a large meeting, no questions I ask can heard clearly,
> even if the meeting uses the protocol of muting everyone else.
> 
> I also have problems with short browser delays that may last a few 
> seconds to a minute or so.
> 
> However, the pppoe connection stays up when this happens.
> 
> I've been complaining to the ISP, who does what it can and raises 
> tickets with the phone company.
> 
> There has been improvement since two weeks ago, when the ppp
> connectino would drop even more frequenty than the delays I'm
> encountering now.
> 
> The problem usually occurs in the daytime, but occasionally in the 
> evening.
> 
> The phone company now opines that the data rate on the connection is 
> barely sufficient for a multiparty zoom connection, and this is
> because of the distance to the exchange.
> 
> 
> 
> Now I'd like to measure what's going on in my system.
> 
> 
> 
> My home network accesses the rest of the world using a Linux box,
> whch also hosts a website, does SMTP, does firewalling/masquerading,
> and has a file server for the LAN.  That Linux box is the only thing
> connected directly to the DSL modem, which operates in bridge mode. 
> 
> What tools does Linux have to measure this, so I can find out 
> what's going on in my network and why.  And maybe even correlate 
> measurable activity with the perceived hiatuses.
> 
> I'd be surprisd if there were none, Linux being born on the net.
> (I'd even be more surprised if they were easy to use.)
> 
> Maybe I do ned to replace my DSL with a higher-capacity connection of 
> some kind.  But I'd like to see the numbers.

Often enough that kind of problem is due to DNS being slow rather than
actual networking; is it the same with a local, caching DNS ?

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

Re: [DNG] connection manager as dns resolver?

[Ralph Ronnquist via Dng]

On Fri, 16 Apr 2021 23:22:30 -0400
Hendrik Boom  wrote:

> On Sat, Apr 17, 2021 at 08:36:23AM +1000, Ralph Ronnquist via Dng
> wrote:
> > On Fri, 16 Apr 2021 18:24:23 -0400
> > Hendrik Boom  wrote:
> >   
> > > Hers's the /etc/resolv.conf on my davuan buster laptop:
> > > 
> > > # Generated by Connection Manager
> > > nameserver ::1
> > > nameserver 127.0.0.1
> > > 
> > > Now I have no problem resolving domain names, whither in
> > > chromium, firefox-esr, or even just ping.
> > > 
> > > But a far as I know, I have never put a dns esolver on the laptop.
> > > 
> > > Does devuan do this for me?
> > > Have I done it and forgotten?
> > > 
> > > How should I find just how dns lookup is done on my machine,
> > > and how should it be done?  
> > 
> > In order to determine which process if any is listening on port 53
> > (the registered DNS port) do, as root, "netstat -lnp | grep -w 53",
> > or if you prefer less typing "ss -lnp | grep -w 53".  
> 
> root@midwinter:~# netstat -lnp | grep -w 53
> tcp0  0 127.0.0.1:530.0.0.0:*
> LISTEN  1686/connmand tcp6   0
> 0 ::1:53  :::*LISTEN
> 1686/connmand udp0  0 127.0.0.1:53
> 0.0.0.0:*   1686/connmand udp6   0
> 0 ::1:53  :::*
> 1686/connmand root@midwinter:~#
> 
> Looks as if the connection manager is taking over dns.
> 
> Who knew?  And whom does it talk to?  Does it contain its own
> recursive DNS resolver?  Or does it just pick up on the DHCP signals
> it gets from elsewhere and take over?
> 
> Interesting.

I don't use connman myself but according to 
https://wiki.archlinux.org/index.php/ConnMan#Avoiding_conflicts_with_local_DNS_server
the DNS feature can be disabled with a startup argument; possibly there
is an /etc/default/connman configuration script for that, or else a
magic hand to init script itself might work.

It doesn't directly say how the connman resolver connect "upstream" but
(following the git docs it points to) there seems to be one or more
configuration files somewhere with some "INI format" configuration
settings to declare "Nameservers" and "FallbackNameservers" for connman.

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

Re: [DNG] dns resolver

[Ralph Ronnquist via Dng]

On Fri, 16 Apr 2021 18:24:23 -0400
Hendrik Boom  wrote:

> Hers's the /etc/resolv.conf on my davuan buster laptop:
> 
> # Generated by Connection Manager
> nameserver ::1
> nameserver 127.0.0.1
> 
> Now I have no problem resolving domain names, whither in chromium, 
> firefox-esr, or even just ping.
> 
> But a far as I know, I have never put a dns esolver on the laptop.
> 
> Does devuan do this for me?
> Have I done it and forgotten?
> 
> How should I find just how dns lookup is done on my machine,
> and how should it be done?

In order to determine which process if any is listening on port 53
(the registered DNS port) do, as root, "netstat -lnp | grep -w 53",
or if you prefer less typing "ss -lnp | grep -w 53".

Ralph.

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

Re: [DNG] rm not freeing space

[Ralph Ronnquist via Dng]

On Tue, 16 Mar 2021 07:41:42 -0700
Marc Shapiro via Dng  wrote:
> ...
> tmpfs 2466616 24 2466592 1% /run/user/1001
> tmpfs 2466616 24 2466592 1% /run/user/1002
> tmpfs 2466616 32 2466584 1% /run/user/1000

Is it possible that one of the users runs some program that holds
on to cached directory entries for the file(s) if not the files
themselves?

I believe there's currently significant effort going into trying to
isolate users, including root, from each other so that even sharing of
common resources is "hidden" (with virtual file systems and various
forms of "unsharing" and whatnot).

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

Re: [DNG] Jitsi advice please

[Ralph Ronnquist via Dng]

On 05/03 10:23, g4sra via Dng wrote:
> ...
> 
> Can anyone recommend a browser (other than Chrome) that they know works with 
> Jitsi-meet ?
> Any other suggestions to fix the audio ?

If you use headphones you can open two tabs to the same meeting and
talk to yourself.

Ralph.

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

Re: [DNG] Does Devuan normally feature eth0 as the NIC?

[Ralph Ronnquist via Dng]

On 04/03 19:34, Steve Litt wrote:
> Hi all,
> 
> My Devuan VM guest has the one and only "Ethernet card", which of
> course is virtual, as eth0. Is eth0 standard operating procedure for
> Devuan installations with only one wired NIC?

Yes. That name originates in the adapter module of the Linux kernel,
and the default Devuan software layers don't change adapter name.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] My Qemu LAN-peer documentation is now in its first draft

[Ralph Ronnquist via Dng]

Of course the code was wrong; I've corrected it below...

On 03/03 19:24, Ralph Ronnquist wrote:
> On 03/03 01:06, Steve Litt wrote:
> > 
> > Am I hearing correctly when I think you two are saying I can make
> > multiple network devices have determinate names (even if I don't select
> > those names) by doing something with their MAC addresses? If so, how do
> > I do it?
> 
> Since you do networking setup via a script you can do this at the top
> of that script before the interfaces are configured. Something like
> the following:
> 
> for IF in $(ls /sys/class/net) ; do
> case "$(ip link show $IF | awk '$1=="link/ether" {print $2;}')" in
> 4a:4a:8d:dc:d4:bf)
ip link set $IF name somewhatspecial
>   ;;
>   06:22:66:ff:5a:e2)
ip link set $IF name veryspecial
>   ;;
> esac
> done
> 
> where you choose your own MAC addresses as case patterns and your own
> names instead of the ${blah}special .. anything unused less than 16
> 7-bit ascii is fine.
> 
> That loop only works for unconfigured, "down" interfaces. In
> particular, when interfaces are configured during boot, then the
> renaming should occur before that configuration.
> 
> If configuration is via hotplug handling than the hotplug handling
> would provide the enumeration, and one only need have to define the
> recognition-to-action "rules" and make sure they are used before
> confguration.
> 
> Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] My Qemu LAN-peer documentation is now in its first draft

[Ralph Ronnquist via Dng]

On 03/03 01:06, Steve Litt wrote:
> 
> Am I hearing correctly when I think you two are saying I can make
> multiple network devices have determinate names (even if I don't select
> those names) by doing something with their MAC addresses? If so, how do
> I do it?

Since you do networking setup via a script you can do this at the top
of that script before the interfaces are configured. Something like
the following:

for IF in $(ls /sys/class/net) ; do
case "$(ip link show $IF | awk '$1=="link/ether" {print $2;}')" in
4a:4a:8d:dc:d4:bf)
ip link set name somewhatspecial
;;
06:22:66:ff:5a:e2)
ip link set name veryspecial
;;
esac
done

where you choose your own MAC addresses as case patterns and your own
names instead of the ${blah}special .. anything unused less than 16
7-bit ascii is fine.

That loop only works for unconfigured, "down" interfaces. In
particular, when interfaces are configured during boot, then the
renaming should occur before that configuration.

If configuration is via hotplug handling than the hotplug handling
would provide the enumeration, and one only need have to define the
recognition-to-action "rules" and make sure they are used before
confguration.

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

Re: [DNG] My Qemu LAN-peer documentation is now in its first draft

[Ralph Ronnquist via Dng]

On 03/03 00:19, g4sra via Dng wrote:
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, March 3, 2021 12:15 AM, spiralofhope 
>  wrote:
> 
> > On Wed, 3 Mar 2021 01:34:40 +1100
> > Ralph Ronnquist via Dng dng@lists.dyne.org wrote:
> > > For bare-metal hardware I believe there is a first possible "race"
> > > between different modules (that handle different card types), and a
> > > second possible "race" for multiple same-type cards, which are handled
> > > by the one and same module.
> 
> > I've always found this strange..
> 
> > Is there nothing like hard drives' UUID?
> 
> Yes, MAC Addresses.
> Sysadmins are just generally too lazy to use them.

Well, this is really a fundamental problem, the "das ding an sich"
that Kant brought up some few years ago to the merriment and pleasure
of his contemporary philosphical minded peers.

But yes, MAC address for network interfaces are alike UUID for
partitions in that they are used for identifing the *functions* of
devices so that further configurations can be made with respect to
those identifications regardless of which actual, physical device
implements them (the functions). The same function (e.g. partition)
can then be transferred to a different physical device without needing
to change those configurations.

Between a physical device and the function you find the adapter, which
implements actual device control and makes the device be of a class,
so that software can access it by virtue of a class API. The names
"eth0" and such then corresponds to the disk adapter naming like "sda"
and such; they are identification labels for the adapters rather than
for the actual devices that the adapters operate on.

I think Lewis Carroll had a stab at this issue as well in "Through The
Looking Glass" where the name of the Black Knight was called
something... or how it was.

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

Re: [DNG] My Qemu LAN-peer documentation is now in its first draft

[Ralph Ronnquist via Dng]

On 02/03 14:29, tito wrote:
> On Wed, 3 Mar 2021 00:06:27 +1100
> Ralph Ronnquist via Dng  wrote:
> 
> > On 02/03 06:48, Steve Litt wrote:
> > > Hi all,
> > > 
> > > As you know, I was asking many Qemu LAN-peer questions on this list
> > > a week ago. My documentation on the subject has finally achieved
> > > first-draft status. If you'd like to see it, go to:
> > > 
> > > http://troubleshooters.com/linux/qemu/nobs.htm
> > 
> > Thank you for the dedication :)
> > 
> > The following are three specific comments to your write-up:
> > 
> > 1) Re the name "eth0" of the VM guest network interface; this name is
> > invented by the kernel module that gets loaded by the kernel upon
> > discovery of the hardware unit. It's not a Qemu naming; it's the Linux
> > kernel (module).
> > 
> > Afaik, all Ethernet kernel modules will name the adapters they
> > discover in the "ethN" series of names, and there is no way to tell
> > them to do something else.
> > 
> > But the hotplug handling subsystem comes in later, i.e. after that the
> > adapter has been registered with the kernel name, and possibly renames
> > the adapter as per the one or the other funnily named naming scheme.
> > That is for instance how your Void Linux ends up with the name
> > "enp42s0".
> > 
> > The intended default in Devuan is to *not* rename the adapater in the
> > hotplug subsystem (aka udev or eudev) but rather retain the name that
> > the module assigned. Of course, it's still possible to have hotplug
> > code (aka rules) to rename the adapters, but that's not the intended
> > default in Devuan.
> > 
> > Note: I say "intended default" because any particular installation
> > typically has further layers of software that also might bring in
> > hotplug handling deviations that implements a different "local
> > default".
> 
> Hi,
> nonetheless even in devuan you have no guarantee that your
> network interface will come up always with the same name
> (unless you have only one) as bios quirks and pnp enumeration
> can change the order of network interface discovery and thus
> their naming.
> 
> Ciao,
> Tito
> > ...

Yes that is true for bare-metal hardware. But I think that in a Qemu
emulation the device order is fully determinstic and therefore that
randomness doesn't come up.

For bare-metal hardware I believe there is a first possible "race"
between different modules (that handle different card types), and a
second possible "race" for multiple same-type cards, which are handled
by the one and same module.

In theory each and every actual network device should have a globally
unique MAC address, and for that reason one might want the adapter
names to be functionally dependent on that, so as to have any one
actual device always have the same adapter name (when it comes to
networking configuration time).

The crux for that is that renaming happens in hotplug handling or
later. I.e. each card will be renamed after having got an initial
module-assigned name, and also at that time any other card may have at
random either their initial module-assigned name or their name after
renaming. And of course, an interface may only be renamed if
unconfigured.

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

Re: [DNG] My Qemu LAN-peer documentation is now in its first draft

[Ralph Ronnquist via Dng]

On 02/03 06:48, Steve Litt wrote:
> Hi all,
> 
> As you know, I was asking many Qemu LAN-peer questions on this list a
> week ago. My documentation on the subject has finally achieved
> first-draft status. If you'd like to see it, go to:
> 
> http://troubleshooters.com/linux/qemu/nobs.htm

Thank you for the dedication :)

The following are three specific comments to your write-up:

1) Re the name "eth0" of the VM guest network interface; this name is
invented by the kernel module that gets loaded by the kernel upon
discovery of the hardware unit. It's not a Qemu naming; it's the Linux
kernel (module).

Afaik, all Ethernet kernel modules will name the adapters they
discover in the "ethN" series of names, and there is no way to tell
them to do something else.

But the hotplug handling subsystem comes in later, i.e. after that the
adapter has been registered with the kernel name, and possibly renames
the adapter as per the one or the other funnily named naming scheme.
That is for instance how your Void Linux ends up with the name
"enp42s0".

The intended default in Devuan is to *not* rename the adapater in the
hotplug subsystem (aka udev or eudev) but rather retain the name that
the module assigned. Of course, it's still possible to have hotplug
code (aka rules) to rename the adapters, but that's not the intended
default in Devuan.

Note: I say "intended default" because any particular installation
typically has further layers of software that also might bring in
hotplug handling deviations that implements a different "local
default".

2) Re VM client gateway with DHCP configuration. This belongs to the
(default) configuration of the DHCP client daemon on the VM client.
That configuration, in /etc/dhcp/dhclient.conf, includes the setting
to ask for the "router" from the DHCP service, which in itself has a
configuration of this, i.e. which router to tell the client(s) to use.

The normal setup for that is that the router also provides the DHCP
service and thus is configured to nominate itself as networking
gateway.

3) Re specifying the physical device on the host to connect to the
bridge; when using the "bridge" type netdev setup it will create a tap
device with an invented name, and afaik there is no easy way to play
with that one. It is automatic and hidden, but if a tap of the
invented name happens to exist already then it will be used.

If you instead use the "tap" type netdev setup you may specify the
names of both the tap (to create unless pre-existing) and bridge
(pre-existing) in the parameters.

regards,

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

Re: [DNG] EFI Installation of Beowulf? [solved]

[Ralph Ronnquist via Dng]

On 24/02 22:39, Jonathan Moebius wrote:
> Dear all, 
> 
> the issue is solved. 
> 
> During research for Ralphs questions I realized my UEFI/BIOS was severly out 
> of date (I had thought this would have been done during refurbishing of the 
> device). After updating from a 2016 UEFI to one from 2020 (many thanks to HP 
> for still supporting such a rather old device) Grub works from Devuan.
> 
> Still it would be interesting, why Debian worked even with the old bios, but 
> I 
> guess I have neither EFI knowledge nor enough motivation to find out.
> 
> Thanks a lot, all of you and a happy system-d free time!

Great.

The EFI setup for Devuan includes the ugly patch to copy
EFI/devuan/grub.cfg into EFI/debian/cfg in order to make the latter
available for debian's grub boot loader EFI/devuan/grubx64.efi which
is signed and requires that config file pathname. This makes the UEFI
menu say Devuan (from being found in EFI/devuan) which we thought
desirable, and to do differently would require a forked grub package.

This however makes it impossible to have both devuan and debian boot
setups on the one EFI partition, but one will need two separate EFI
partitions for the two different EFI/devuan/grub.cfg files, and an
UEFI bios that is happy with that.

I suppose this may and might not be the answer to why it didn't work
before, but it's in any case an explanation to a failure attemping to
have both debian and devuan on a UEFI host.

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

Re: [DNG] SystemD OS home directories

[Ralph Ronnquist via Dng]

On 24/02 17:04, Hendrik Boom wrote:
> On Wed, Feb 24, 2021 at 09:13:07PM +, g4sra via Dng wrote:
> > 
> > Just pulled this kernel commit...
> > 
> > commit 7d6beb71da3cc033649d641e1e608713b8220290
> > Merge: aa8e3291729f f69e8091c4a2
> > Author: Linus Torvalds 
> > Date:   Tue Feb 23 13:39:45 2021 -0800
> > 
> > 
> > 
> >- Idmapped mounts make it possible to easily share files between
> >  multiple users or multiple machines especially in complex
> >  scenarios. For example, idmapped mounts will be used in the
> >  implementation of portable home directories in
> >  systemd-homed.service(8) where they allow users to move their  
> >   home
> >  directory to an external storage device and use it on multiple
> >  computers where they are assigned different uids and gids. This
> >  effectively makes it possible to assign random uids and gids at
> >  login time.
> > 
> > 
> > 
> > 
> > I remember the question regarding implementation of migratory home 
> > directories raising it's head in the past. We now have the answer.
> 
> Let me hopw NFS will use that technique.
> 
> It squashes root.  I'd like it to reassign UIDs too.

Wasn't "idmapping" invented with and for NFS, a couple of decades ago?

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

Re: [DNG] EFI Installation of Beowulf?

[Ralph Ronnquist via Dng]

Please give some more details, specifically:

1. which iso (with sha256sum)?
2. was it a cleared disk, or existing paritions?
3. which installation mode (default or expert)?
4. which partitioning?
5. which network mirror (or none?)?
6. which software selection(s)?
7. which init system?
8. # md5sum $(find /boot/efi -type f)
9. please do 8 for the "working debian" as well

10. which EFI brand and version?

regards,

Ralph.

On 22/02 23:25, Jonathan Moebius wrote:
> Dear all,
> 
> I have switched to a new computer and tried to install Beowulf 3.1.0 in a 
> pure-EFI setting. 
> I have tried installing on a SATA SSD as well as a a m.2 PCIe SSD. 
> Originally, 
> the plan was a dual boot install with Win10 being installed first, however 
> after several failed attempts, I scraped Win10 and went for a Linux-only 
> install.
> Installation seems to run smoothly but after reboot grub presents itself 
> without the "graphical" selection menu but instead delivers the line
> "Minimal BASH-like line editing is supported..."
> 
> After 5 hours of installing and re-installing I tried installing Debian 
> Buster 
> 10.8 (I understand, Beowulf 3.1.0 is based on 10.8). With debian the 
> installation works out of the box.
> 
> I have found following hints regarding this:
> 
> EFI Partition may be missing or too small
> I tried both with guided partitioning and manual partitioning, I created EFI 
> partitions up to 1 gb without success.
> 
> Grub may have to be re-installed. 
> I tried to chroot into the installation and did a grub-install (after 
> mounting 
> the efi-partition). This did not solve the issue
> 
> Grub.cfg may be missing
> I compared the grub.cfg from Debian and Devuan. Superficially they look very 
> similar.
> 
> 
> Do you have any hints what else to try? Can you spare me going back to debian?
> 
> Kind regards,
> Jonathan
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest

[Ralph Ronnquist via Dng]

Networking for qemu is not that hard though better documentation is a
praiseworthy aim. But there are an awful lot of variations both in
what to achieve and in the ways in achieving it. These are some
thoughts from me:

Like for all qemu device emulations, the network setup arguments for
qemu come in pairs:
+ one argument that declares the internal emulation device, and
+ another argument that declares to host side attachment.

The connection between the two arguments is done by means of an
identification label, where (for net emulation) the host attachment is
"named" by the label using an "id=LABEL" option and the internal
emulation device argument mentions it using a "netdev=LABEL" option,
where thus the LABEL bit is your choosen name.

If you leave out identifications then qemu makes guesses about how
arguments go together; it invents labels "cleverly" and uses them
"intelligently". Unfortunately most documentation relies on that
hidden labelling and as a result things appear to work by magic.

Further just for the sake of increased confusion, there is also an
alternative combination or shortcut argument ("-nic") that lets you
configure both the emulation and attachment in a single option
collection.

In your case you have declared a single internal device, the e1000,
and linked that to one of the two host attachments by the label
"mynet0". The other host attachment, "mybridge0", is dangling, i.e.
not linked with any internal interface emulation device, which qemu
advices about with the "no peer for mybridge0" warning.

HOST SIDE ATTACHMENT

The hands-on for the host side setup depends firstly on which type of
host attachment it is. "user" and "bridge" are two host attachment
types. The (currently) full list is
"(tap|bridge|user|l2tpv3|vde|netmap|vhost-user|socket)".

They are all configured in their own ways although typically they use
the same or overlapping names of options with typically concordant
uses of them. The qemu-system-x86 "man" page is rather good at
describing the attachment types and their options.

In my words:

  The "user" type attachment is a "pretend" attachment as it
  facilitates IP level networking for the guest without having
  networking presence as an actual host interface. There is little
  good to say about this attachment type except that it's the one to
  use if you don't want to know anything about anything. Well, not my
  preference at least. The "user" type attachment is especially
  peculiar as it includes a DHCP service for the guest with a client
  visible IP address for the host, even though the attachment is not
  associated with an interface.

  The "bridge" type attachment results in a host side tap interface
  that get added to (and remove from) a nominated bridge or bridge
  "br0" by default.

  The "tap" type attachment results in a host side tap interface
  seemingly without any bridge juggling. However, its default script
  option nominates the /etc/qemu-ifup script which adds the tap to the
  bridge, if any, nominated by a br option, or by default the bridge,
  if any,that facilitates the default route for the host at the time
  guest is started.

  The "vde" type attachment is also a "pretend" attachment but it
  facilitates full Ethernet level networking via VDE virtual
  networking, which typically is present as a tap interface on the
  host. In this case you set up a "VDE switch" with a tap, and then
  make qemu connect up to that via the sock option which is
  "/tmp/vde.ctl" by default (coincidentally the same as the default
  setting for a VDE switch).

and so forth.

CLIENT SIDE

The hands-on for the client side is just normal network configuration.
which parimarily depends on whether to use DHCP (in part or full) or
static configuration.

With the "user" type attachment, the client is not a full networking
entity from the host (or outside) point of view as it only handles IP
level transport. Other attachment types makes the client a full
networking entity.

To use DHCP the overall setup must of course include a DHCP server on
the network of the host side attachment (or the built-in one of the
"user" type attachment).

etc.

Ralph.

On 21/02 03:08, Steve Litt wrote:
> 
> On Thu, 18 Feb 2021 07:18:44 -0700
> Gabe Stanton via Dng  wrote:
> 
> > I'm sorry for the confusion. That was not the guide I used. I did find
> > the guide I used. It seems pretty straight forward, and I believe it
> > clears up all the confusion and questions caused by my previous email.
> > 
> > https://www.debian.org/doc/manuals/debian-handbook/sect.virtualization.en.html#sect.lxc.network
> 
> Thanks Gabe. The preceding link helped, but was not sufficient.
> Although better than most, it shares the same ambiguities as the
> others, including not telling whether they're referring to the metal
> host or the VM guest when discussing TAPs, bridges, devices and the
> like. Also, like most of the others, they don't specifically identify
> what should go in the "id=" slots.
> 
> Based 

Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest

[Ralph Ronnquist via Dng]

On 16/02 07:55, Steve Litt wrote:
> 
> On Tue, 16 Feb 2021 20:29:46 +1100
> Ralph Ronnquist via Dng  wrote:
> 
> > On 16/02 03:24, Steve Litt wrote:
> > > Hi all,
> > > 
> > > My ultimate goal is to have a Devuan VM guest on my Void Linux Daily
> > > Driver Desktop (DDD) that acts like just another metal computer on
> > > my LAN at 192.168.0.0/24. I want it to have address 192.168.0.66.
> > > I've tried to do this sporadically over the past 2 years, never
> > > with success. ...
> > > 
> > > I tried setting the VM guest's /etc/network/interfaces to static
> > > with address 192.168.0.66, with the gateway, netmask etc set
> > > accordingly, but after doing that, ip addr on the VM showed no IP
> > > address at all.  
> > 
> > It all looks fine, and static setup should work. Possibly you left out
> > the "auto eth0" or "allow-hotplug eth0" line?
> 
> Thanks Ralph,
> 
> I had left them both out, but putting them in didn't change the
> symptom. I tried with only auto eth0, and that didn't change the
> symptom either.

Peculiar :)

Yes, "auto eth0" would be right for telling ifupdown that the
interface should be brought up during (post-pivot) boot, and all in
all /etc/network/interfaces would have the following as the only
configruations for eth0:

auto eth0
iface eth0 inet static
address 192.168.0.66/24
gateway 192.168.0.1

The previous setting that gives VM 10.0.2.15 would have been caused by
a DHCP configuration, like:

auto eth0
iface eth0 inet dhcp

or by having some other networking tool such as wicd running. One way
or the other it would have started a dhcp client that requests an
address assignment via UDP broadcast, and something (either a dhcp
service on DDD or on the network outside DDD) responded to offer
10.0.2.15 for the VM.

If that client was a networking tool such as wicd then possibly that
is still running and it now competes about the confgiuration of eth0
with ifupdown. Usually though it (wicd) would be more insistant and
eventually take over, so you should then end up with a 10.0.2.0/24
address eventually, with some period of an unconfigured network.

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

Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest

[Ralph Ronnquist via Dng]

On 16/02 03:24, Steve Litt wrote:
> Hi all,
> 
> My ultimate goal is to have a Devuan VM guest on my Void Linux Daily
> Driver Desktop (DDD) that acts like just another metal computer on my
> LAN at 192.168.0.0/24. I want it to have address 192.168.0.66. I've
> tried to do this sporadically over the past 2 years, never with success.
> ...
> 
> I tried setting the VM guest's /etc/network/interfaces to static with
> address 192.168.0.66, with the gateway, netmask etc set accordingly,
> but after doing that, ip addr on the VM showed no IP address at all.

It all looks fine, and static setup should work. Possibly you left out
the "auto eth0" or "allow-hotplug eth0" line?

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

Re: [DNG] NFS+Kerberos on Beowulf

[Ralph Ronnquist via Dng]

On 14/02 00:23, Jackman via Dng wrote:
> Has anyone successfully gotten NFS and Kerberos working together on
> Beowulf? I was able to get a working setup going in a fresh Debian Buster
> VM in about 10 minutes. On the other hand, I've been working on trying to
> get it working on Beowulf for two days without success.
> 
> ➜  ~ cat /etc/exports
> /srv/nfs-test   *(rw,no_subtree_check,sec=krb5)

afaiu, possibly, without a 'no_root_squash' option, the server side
will perform its actions as user 'nobody' who might not have write
access to the source and thus will gain a:

> mount.nfs4: mount(2): Permission denied
> mount.nfs4: access denied by server while mounting storage0:/srv/nfs-test

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

Re: [DNG] Request for assistance

[Ralph Ronnquist via Dng]

On 25/01 10:59, o1bigtenor via Dng wrote:
> On Mon, Jan 25, 2021 at 2:27 AM al3xu5 / dotcommon
>  wrote:
> >
> > Sun, 24 Jan 2021 19:59:19 -0600 - o1bigtenor :
> >
> > > Greetings
> > >
> > > (Asking this here as so far I've seen some seriously skilled folks
> > > connecting in!)
> > >
> > > I've been working on getting a HiSense 50" TV (3840x2160_30) working
> > > on a Nvidia GTX1050 Ti graphics card. I have a second graphics card
> > > (Nvidia GT (IIRC) 570) with a present stable of 4 -1920x1080 monitors.
> > > I am running Nouveau rather than proprietary Nvidia software and get
> > > to use xrandr to set up my graphics system after every boot but
> > > although it took me a while to learn how to do this setup its pretty
> > > quick now.
> > > ...
> 
> I am presently stuck trying to get 'videogen' working.
> 
> Can see everything in the directory but using either root or user I get the
> same error message:
> $ videogen
> could not open configuration file "~/.videogen" (errno=2)
> 
>+--+
>|  |
>| videogen 0.33 simple XFree86 Modeline calculator |
>|  |
>|  by Szabolcs Rumi, (c) 1997 - 2003   |
>|THIS PROGRAM COMES WITH ABSOLUTELY NO WARRANTY|
>|for details see the GNU General Public License (GPLv2)|
>|  |
>+--+
> 
> error: no modes (resolutions) have been specified
> 
> Suggestion(s) on how to get over this hurdle?

Unfortunately "videogen" has compiled-in limits for width, height and
refresh rate so can't be used directly here. But, I grabbed the source
and patched for that, and then got the modeline:

% ./videogen -v -m=3840x2160  -mdc=290.000 -mhf=67.5 -hfp=176 -hbp=296 -vfp=8 
-vbp=72 -mvf=30

Modeline "3840x2160" 290.00 3840 3960 4104 4800 2160 2168 2171 2274  # 290 MHz, 
60.4 kHz, 26.6 Hz

.. if that's any use for you

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

Re: [DNG] Request for assistance

[Ralph Ronnquist via Dng]

On 24/01 19:59, o1bigtenor via Dng wrote:
> Greetings
> 
> (Asking this here as so far I've seen some seriously skilled folks
> connecting in!)
> 
> I've been working on getting a HiSense 50" TV (3840x2160_30) working
> on a Nvidia GTX1050 Ti graphics card. I have a second graphics card
> (Nvidia GT (IIRC) 570) with a present stable of 4 -1920x1080 monitors.
> I am running Nouveau rather than proprietary Nvidia software and get
> to use xrandr to set up my graphics system after every boot but
> although it took me a while to learn how to do this setup its pretty
> quick now.
> 
> Part of the 'fun' in wanting to add the 3840x2160_30 monitor is that
> EDID has become a more than somewhat 'challenging' system. Enough so
> that I was able to find this:
> https://www.kernel.org/doc/html/v5.6/driver-api/edid.html
> 
> Creating this 'custom' EDID is a long ways from my wheelhouse - - - I
> have spend some time today trying to find some of the stuff indicated
> on that page - - - - can't find anything (maybe also a good thing!). I
> am going to attach (hopefully the list accepts attachments) 2 files
> which give enough information so that someone with the requisite
> skills could create this 'custom' EDID that I need so that I could
> then use xrandr to get this monitor working. Is there someone who
> might be able to do this? (I think doing it might be a lot less time
> consuming that guiding me through the doing of it - - - especially as
> I have essentially zero programming skills)

I think that

1) the program "cvt" is useful for getting the details right

$ cvt 3840 2160 30
# 3840x2160 29.98 Hz (CVT) hsync: 65.96 kHz; pclk: 338.75 MHz
Modeline "3840x2160_30.00"  338.75  3840 4080 4488 5136  2160 2163 2168 2200 
-hsync +vsync


2) you can use that almost verbatim to assign this with xrandr, rather
than rebuilding the module:

$ xrandr --newmode "3840x2160_30.00"  338.75  3840 4080 4488 5136  2160 2163 
2168 2200 -hsync +vsync

and then add that mode for the output (say VGA-2):

$ xrandr --output VGA-2 --addmode 3840x2160_30.00

and then set that as the current mode for the output:

$ xrandr --output VGA-2 --mode 3840x2160_30.00

regards,

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

Re: [DNG] double negative

[Ralph Ronnquist via Dng]

On 26/12 10:19, Simon Walter wrote:
> On 12/26/20 2:31 AM, Hendrik Boom wrote:
> > On Fri, Dec 25, 2020 at 10:07:57AM -0500, Steve Litt wrote:
> > > On Fri, 25 Dec 2020 00:18:55 -0800
> > > Rick Moen  wrote:
> > > > Quoting Didier Kryn (k...@in2p3.fr):
> > > > 
> > > > >      Just to remind, if you forgot it.
> > > > > 
> > > > >      There's one known case where double positive means negative:
> > > > > C++
> > > > 
> > > > "Yeah, yeah."
> > > > 
> > > > (The gag may not travel well, so:  At least in some USA regions,
> > > > the phrase "Yeah, yeah" is something of a dismissive phrase with
> > > > meaning at least bordering on denial.)
> > > 
> > > Here's what I want to know...
> > > 
> > > Why is the first word of any answer to any question asked of self
> > > defined intellectuals "so"?
> > 
> > To give them time to think.
> > 
> 
> 
> Merry Christmas and a Happy New Year?

One might suggest, use instead instead of but but but instead of not
but not instead of clarity, or not.

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

Re: [DNG] What I learned at Distrowatch

[Ralph Ronnquist via Dng]

On 14/12 23:31, Hendrik Boom wrote:
> On Sun, Dec 13, 2020 at 09:31:02PM +0100, Didier Kryn wrote:
> > Le 13/12/2020 à 03:15, Steve Litt a écrit :
> > > On Fri, 11 Dec 2020 15:53:35 +0100
> > > Didier Kryn  wrote:
> > >
> > >
> > >>     I don't make it an argument against xdm. Just cheating about your
> > >> own arguments (~:
> > > Didier, why didn't you make that suggestion to me 15 years ago? It's a
> > > brilliant way to guarantee that if somebody logs out of X, they have no
> > > logged in shell to make mischief with.
> > >
> > > I should have thought of that myself. 15 years ago :-).
> > >
> >     Yes you should have. But this is something everybody forgets all the
> > time. We all imagine a program invocation like a function call, in which
> > the caller is suspended until the callee returns; but actually when the
> > shell is suspended waiting the application to return, it intentionnally
> > waits, but can easily stop waiting. The artefact is that we must add an
> > '&' to tell it not to wait in the first place. This is a semantic sugar
> > to make it behave by default "as if" it was a function call.
> > 
> >     exec does not create a new process; instead it substitutes the new
> > application to the current one (the shell). I had fun some years ago
> > writing an application which opened an http connection to a server on
> > standard input, read the http header, and then execed another
> > application given in argument.
> 
> We Scheme programmers are very aware of this -- it's called tail-calling, and 
> the Scheme 
> implementation does this anytime it can.

indeed.  And in Forth it's called "next" :)

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

Re: [DNG] Ethernet names revisited

[Ralph Ronnquist via Dng]

On 13/12 22:22, Antony Stone wrote:
> On Sunday 13 December 2020 at 21:42:50, Simon Hobson wrote:
> 
> > Hendrik Boom  wrote:
> > > I had to solve it by assigning new names to the interfaces (thus not eth0
> > > or eth1) and modifying all the config files mentioning those interface
> > > names (I found them with grep) to use the new names instead.
> > 
> > Not for the OPs reason, but a long time ago I started to use "meaningful
> > names" like ethext, ethint, and so on. Making it clearer in config files
> > what each interface is.
> 
> Ironically enough, that is precisely what I have done on my own routers, 
> which 
> have interfaces named "Internet", "Clients", "Phones", "PubServers" and 
> "PriServers".
> 
> I did that because by default they create VLAN interfaces called eth0.0, 
> eth0.1, eth0.2 etc, and so I used the rename facility in 
> /etc/network/interfaces to give them names which meant something to me.
> 
> > I think removing the need to remember something is better than being good
> > at remembering it (which I'm not anyway !)
> 
> I completely agree with that, however in this case (wanting eth0 to be on the 
> motherboard and eth1/2 to be the PCI card), is close enough to "familiar" for 
> me not to get confused about it (once I get the machine to agree on the 
> names).

One option could be to ensure tg3 is loaded before r8196 by mentioning
them in that order in /etc/modules (or maybe it needs to be in
/etc/initramfs-tools/modules). The tg3 would claim eth0 and r8196
would claim eth1 and eth2 (which probably would name its ports
consistently in the desired order).

Then yo don't even need that 70-.. udev file, which you did need for
jessie so as to counteract its "predictable names" mangling.

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

Re: [DNG] Ethernet names revisited

[Ralph Ronnquist via Dng]

On 13/12 02:47, Antony Stone wrote:
> On Sunday 13 December 2020 at 01:09:18, Ralph Ronnquist via Dng wrote:
> 
> > Well, the kernel modules makes the first naming, and assigns them as
> > eth0, eth1, eth2. That happens before udev starts.
> > 
> > The kernel refuses any attempt to name an interface to, say, eth0 if
> > that name is taken.
> > 
> > Those "facts" have been in effect since last millenium, so whatever
> > happened for you before would have happened within the eclipse of
> > those "facts".
> 
> So... what's the correct way, in a current Devuan release, to ensure
> that each ethernet interface gets the name you want it to have,
> based on its MAC address (which, as far as I know, is the only
> uniquely identifiable thing about an interface, wherever it happens
> to be found, and in whatever order it gets identified)?

I wish I could tell you exactly: there are many different ways that
turn out to work well for some range of situations, but then not for
others.

Generally the first step is to use a different, unused name series,
say en0, en1, en2, with udev rules for mapping particular macaddress
to particular name.

If one could live with that, it would be a solution.

To map back into ethN requires another udev rule, but this rule must
not be in use until all the interfaces have been duly mapped (by the
above rules). If you use initrd the root pivot make a "stage barrier";
you can arrange the rules such that this mapping-back rule is checked
before the mapping forward rule for each interface, and thereby
achieve that the back mapping only happens at the post-pivot /sys
enumeration.

I'm sure there may be other ways to achieve the "stage barrier"; udev
is a programming language even if obscure.

>
> Antony.
> 
> -- 
> Don't procrastinate - put it off until tomorrow.
> 
>Please reply to the list;
>  please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Ethernet names revisited

[Ralph Ronnquist via Dng]

On 13/12 00:40, Antony Stone wrote:
> > If it worked for you previously then, a) there would have been rules
> > for double renaming,
> 
> Please point me at where I should find these.
> 
> I only know that /etc/udev/rules.d/70-persistent-net.rules was the
> *only* file I needed to edit if I wanted to rearrange the naming of
> the interfaces under Jessie or earlier.

Well, the kernel modules makes the first naming, and assigns them as
eth0, eth1, eth2. That happens before udev starts.

The kernel refuses any attempt to name an interface to, say, eth0 if
that name is taken.

Those "facts" have been in effect since last millenium, so whatever
happened for you before would have happened within the eclipse of
those "facts".

> > and b) any network management would have kicked
> > in late enough to let name fiddling happen before bringing up the
> > interfaces. As you know, one of the joys with parallel boot is the
> > random effects of things happening in parallel.
> 
> I thought "parallel boot" was one of the evils that systemd was designed to 
> bring in.  In what way does Devuan do "parallel boot"?

afact 1) udev processes events (somewhat) in parallel, and 2) the
post-pivot boot runs init scripts in as much parallelism as is allowed
with respect to their declared dependencies. That latter thing is
something newish (10 years?) but current default.

> > The default installation (unfortunately?) have wicd as player to
> > provide networking randomness, but network-manager is good at it too.
> 
> I have neither of those installed on the machines in question.

That's good. Then also avoid "allow-hotplug" declarations as otherwise
udev will bring up interfaces in the pre-pivot boot. I think that
should be enough for using ifrename. (It does come with the
disadvantage of needing manual touch after plugging in cables)

> Antony.
> 
> -- 
> Perfection in design is achieved not when there is nothing left to add, but 
> rather when there is nothing left to take away.
> 
>  - Antoine de Saint-Exupery
> 
>Please reply to the list;
>  please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Ethernet names revisited

[Ralph Ronnquist via Dng]

On 12/12 23:22, Antony Stone wrote:
> On Saturday 12 December 2020 at 23:11:25, Ralph Ronnquist via Dng wrote:
> ...
> 
> 1. Why is this so totally different from what I could previously do using 
> /etc/udev/rules.d/70-persistent-net.rules under jessie and earlier releases?
> 
> 2. https://wiki.debian.org/NetworkInterfaceNames clearly says that if you 
> upgraded a machine from jessie to stretch and to buster (which for these 
> purposes I regard as the same as jessie to ascii to beowulf), then it will 
> continue to work as before, so - what is the difference between doing those 
> upgrades, and doing a fresh buster / beowulf installation?  What needs to be 
> changed on a beowulf machine to make it work the same as a jessie machine 
> upgraded to ascii, upgraded to beowulf?

If it worked for you previously then, a) there would have been rules
for double renaming, and b) any network management would have kicked
in late enough to let name fiddling happen before bringing up the
interfaces. As you know, one of the joys with parallel boot is the
random effects of things happening in parallel.

> 
> And, of course, finally:
> 
> 3. Once /etc/udev/rules.d/70-persistent-net.rules no longer works at
> all under Chimaera, what is the correct / official way of getting
> interfaces named as you want them, according to their MAC addresses?

Without being held awake by this issue myself, I can only suggest a
two phase solution where you have 1) udev rules kicking in during
pre-pivot boot to rename anything ethN onto say the xethN series, and
then 2) an ifrename service for the post-pivot boot, to name the
interfaces by macaddress.

Howver, in order for that to work you must also make sure that your
network management software stays inactive until after the ifrename
activity. The easiest for that is to only rely the ifupdown networking
which in the normal setting is a post-pivot activity subsequent to
ifrename.

The default installation (unfortunately?) have wicd as player to
provide networking randomness, but network-manager is good at it too.

Ralph

> 
> Thanks,
> 
> 
> Antony.
> 
> -- 
> I bought a book about anti-gravity.  The reviews say you can't put it down.
> 
>Please reply to the list;
>  please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Ethernet names revisited

[Ralph Ronnquist via Dng]

It really isn't that hard:

when the kernel starts it will give its default names to the
interfaces as ethN numbering them in order it initializes them. In
your case it will use the names eth0, eth1 and eth2 that get assigned
in whatever time order the kernel discovers them in.

Eventually(!) the hotplug handler (udev) kicks in to process your
rules, and at that time there are three interfaces named eth0, eth1
and eth2, so it will be impossible to make, say, the eth2 interface
get the name eth0 without first making the eth0 interface be named
something else. It would here be nice with a name *swapping* program,
but there is none.

So, if you are not happy with those names being used the way they are
by the kernel, then you will have to arrange it to name them all
twice: first to some other name series (eg en0, en1, en2) and
thereafter back onto the original name series (eth0, eth1, eth2) on
the basis of some other adapter property (eg macadress).

Ralph.

On 12/12 15:27, d...@d404.nl wrote:
> On 12-12-2020 14:15, Antony Stone wrote:
> > Hi.
> >
> > I've just installed a couple of Beowulf systems, each of which has three 
> > ethernet interfaces; one on the motherboard, and two on a PCI card.
> >
> > I'm trying to work out how to give those interfaces the names I want; the 
> > motherboard as eth0, and the PCI card as eth1 / eth2.
> >
> > Historically, I've been used to udev and /etc/udev/rules.d/70-persistent-
> > net.rules doing this, where I can specify the name I want for each 
> > interface 
> > according to its MAC address.
> >
> > The file didn't exist (although the directory did) on my Beowulf system, so 
> > I 
> > created one with the appropriate contents, and I now get messages while the 
> > kernel is booting:
> >
> > udevd[441]: Error changing net interface name eth2 to eth0: File exists
> > udevd[441]: could not rename interface '4' from 'eth2' to 'eth0': File 
> > exists
> > udevd[438]: Error changing net interface name eth1 to eth2: File exists
> > udevd[438]: could not rename interface '3' from 'eth1' to 'eth2': File 
> > exists
> > udevd[445]: Error changing net interface name eth0 to eth1: File exists
> > udevd[445]: could not rename interface '2' from 'eth0' to 'eth1': File 
> > exists
> >
> > I've followed the entire thread on this list from July 2018 about this, 
> > which 
> > I've found _some_ of in the archives at 
> > https://lists.dyne.org/lurker/message/20180715.200323.7a2473a2.en.html 
> > however 
> > that link shows only a very small proportion of the emails in the 
> > discussion 
> > for some reason (I have my own local copy in my mail client).
> >
> > According to https://wiki.debian.org/NetworkInterfaceNames the old 70-
> > persistent-net.rules system _should_ still work in Buster / Beowulf, but I 
> > can't work out how to get it to do so.
> >
> > I _have_ tried adding "net.ifnames=0" to the kernel boot line; this makes 
> > no 
> > difference.
> >
> > So:
> >
> > 1. how can I get 70-persistent-net.rules to carry on working under Beowulf?
> >
> > 2. what's the "correct" way to get my interfaces named the way I want, 
> > according to their MAC addresses, under Beowulf?
> >
> > (The above Debian wiki document indicates that Buster is the last release 
> > which will continue to support this, so I'm assuming I'll need to do 
> > something 
> > else for Chimaera; what is it?)
> >
> >
> > Thanks,
> >
> >
> > Antony.
> >
> From what I understand after some research you need a additional
> /etc/udev/rules.d/10-network.rules as follow:
> 
> |SUBSYSTEM=="net", ATTR{address}=="90:e6:ba:01:00:01", NAME="eth0"
> SUBSYSTEM=="net", ATTR{address}=="90:e6:ba:01:00:02", NAME="eth1"|
> ||SUBSYSTEM=="net", ATTR{address}=="90:e6:ba:01:20:01", NAME="eth2" Hope
> this helps. Grtz Nick | |
> 




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

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

Re: [DNG] US mirror is broken? Failed to fetch http://us.deb.devuan.org Not Found [IP: 130.89.148.13 80]

[Ralph Ronnquist via Dng]

On 02/12 09:25, crich...@blackfoot.net wrote:
> Hi, I was trying to update something a bit ago, and it failed.
> 
> I ran apt update, then: apt install libsasl2-2 libsasl2-modules, and got
> this output:
> .
> Do you want to continue? [Y/n] y
> Err:1 http://us.deb.devuan.org/merged ascii/main amd64 libsasl2-modules-db
> amd64 2.1.27~101-g0780600+dfsg-3+deb9u1
>   404  Not Found [IP: 130.89.148.13 80]
> ...
> I didn't try -fix-missing, since this seems more a server issue.

This typically happens when the version known to your host is no
longer, or not yet, available at the repository. The usual remedy is
to re-run "apt-get update" and then try again.

> Trying to
> pull up http://us.deb.devuan.org/ in a browser
> gets a NET::ERR_CERT_COMMON_NAME_INVALID error.

It wouldn't be a "cert error" unless you used https.

> router1:/var/log# host us.deb.devuan.org
> us.deb.devuan.org is an alias for pkgmaster.devuan.org.
> pkgmaster.devuan.org has address 54.36.142.183
> pkgmaster.devuan.org has address 5.135.82.179
> 
> router1:/var/log# host 130.89.148.13
> 13.148.89.130.in-addr.arpa domain name pointer klecker-archive.debian.org.
> 
> Navigating to klecker-archive.debian.org directly seems to work fine.

Yes, most country-code domains "*.deb.devuan.org" incluing
"us.deb.devuan.org" are aliased to pkgmaster.devuan.org, and its
service for those domains renders a 301 redirect to "deb.devuan.org",
which then resolves to the mirror collection of IP that obviously
included 130.89.148.13 as one of the mirrors.

As golinux noted: it's best to use deb.devuan.org directly in your
source list.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Which package holds CPU frequency governor "on_demand"?

[Ralph Ronnquist via Dng]

On 28/11 14:01, А. Сорокин via Dng wrote:
> Hello.
> 
> 
> On my system with 5.9.0-3-amd64 kernel, CPU frequency governor
> "on_demand" was expired somehow. And now CPU works at full speed all
> the time.
> 
> Currently, only following governors are available:
> performance
> schedutil
> 
> I have installed following packages:
> libcpufreq0
> cpufrequtils
> libcpupower1
> 
> So, which package i do miss, that holds the "OnDemand" governor?
> Thank you.

maybe the "governor_simpleondemand" module is the new name?
it's in the linux-image-5.9.0-3-amd64 so should be installed

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

Re: [DNG] Ancient releases

[Ralph Ronnquist via Dng]

On 14/11 20:17, Hendrik Boom wrote:
> On Sat, Nov 14, 2020 at 06:40:45PM -0600, goli...@devuan.org wrote:
> > On 2020-11-14 18:06, d...@d404.nl wrote:
> > > On 14-11-2020 22:36, Fred wrote:
> > > > Hello,
> > > > 
> > > > I want to upgrade from Debian Jessie to Devuan.  Apparently all I need
> > > > to do is change the sources list and do a dist-upgrade.
> > > > 
> > > > Is this likely to go smoothly?  If there are any problems I would
> > > > probably not have Internet to ask for help.
> > > > 
> > > > How does the upgrade get rid of systemd and everything associated with
> > > > it?  Or how does one do that?
> > > > 
> > > > Best regards,
> > > > Fred
> > > > ___
> > > > Dng mailing list
> > > > Dng@lists.dyne.org
> > > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> > > 
> > > Coming from Debian you maybe should change your sources list first to
> > > 
> > > deb http://deb.devuan.org/merged jessie main
> > > 
> > > and install the devuan-keyring and sysvinit-core before you move over to
> > > devuan ascii.
> 
> Is there a line for sources that will access an archived Debian release?  I'm 
> interested in running some software that was dropped from Debian about a 
> decade ago.  I still have a bootable partition with that ancient release 
> lying round somewhere.

The archived Devuan jessie is available at archive.devuan.org/merged,
with its Packages files referring to the likewise archived Debian
packages at archive.debian.org/debian.

E.g, you may have the following sources.list line:

deb http://archive.devuan.org/merged jessie main

for accessing the Devuan jessie packages, including the directly
incorporated debian packages.

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

Re: [DNG] devuan ?

[Ralph Ronnquist via Dng]

Also, to manually inspect out a particular IP, e.g. 130.225.254.116, as a
resolution for deb.devuan.org, you would add temporarily a line to /etc/hosts:

130.225.254.116 deb.devuan.org

and then point your sane browser at http://deb.devuan.org/devuan/
Remove that line later,

Ralph.

radisso...@gmx.de wrote on 30/10/20 7:24 am:
>> Gesendet: Donnerstag, 29. Oktober 2020 um 20:31 Uhr
>> Von: "Antony Stone" 
>> An: dng@lists.dyne.org
>> Betreff: Re: [DNG] devuan ?
>>
>> On Thursday 29 October 2020 at 19:31:10, radisso...@gmx.de wrote:
>>
>>> Do you want to continue? [Y/n]
>>> Err:1 http://deb.devuan.org/merged beowulf/main amd64 linux-libc-dev amd64
>>> 4.19.118-2 404  Not Found [IP: 130.225.254.116 80]
>>> Unable to correct missing packages.
>>> E: Failed to fetch
>>> http://mirrors.dotsrc.org/debian/pool/main/l/linux/linux-libc-dev_4.19.118
>>> -2_amd64.deb  404  Not Found [IP: 130.225.254.116 80] E: Aborting install.
>>
>> I too experience this from time to time with mirrors.dotsrc.org
>>
>> I jut repeat the command, and provided I get a different IP destination, the
>> package installs.
>>
>> It seems to me that there's some problem with one of the servers
>> mirrors.dotsrc.org points at - the IP address presumably reveals which one.
>>
> 
> So far i understand it is a RR. When i tried to find it (with browser) i had 
> no success.
> Is there any way to really check it ?
> 
> 
> 
>>
>> Antony.
>>
>> --
>> In Heaven, the beer is Belgian, the chefs are Italian, the supermarkets are
>> British, the mechanics are German, the lovers are French, the entertainment 
>> is
>> American, and everything is organised by the Swiss.
>>
>> In Hell, the beer is American, the chefs are British, the supermarkets are
>> German, the mechanics are French, the lovers are Swiss, the entertainment is
>> Belgian, and everything is organised by the Italians.
>>
>>Please reply to the list;
>>  please *don't* CC 
>> me.
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] No route to packages.roundr.devuan.org.

[Ralph Ronnquist via Dng]

Андрей via Dng wrote on 29/8/20 3:29 am:
> Hello.
> 
> 
> Thank you for your answers. On Sat, 22 Aug 2020 01:01:39 +0200, you
> wrote:
> 
>> Several things:
>>
>> 1. You should use deb.devuan.org
> 
> Whould you explain why, please?

There are three collaborating reasons:

1) the domain "packages.roundr.devuan.org" used to be a round-robin service
entry for Devuan-servicing repository hosts. It (the domain) is no longer
maintained as such. For a while it has resolved gratuitously to nexlab's old
repository server, but since a couple of years Devuan's package service has
been moved to new hosting.

2) the domain "packages.roudr.devuan.org" used to be the round-robin service
implementation domain, to actually be accessed by a front-line domain name such
as "auto.mirror.devuan.org" or "packages.devuan.org". Therefore
"packages.roundr.devuan.org" should never have been used directly anyhow.

3) nowadays (since a couple of years) the front-line domain name for Devuan's
repository service is "deb.devuan.org". This domain also resolves to a
round-robin implementation domain, "deb.roundr.devuan.org", which like the one
in 1) above is administered by nexlab. The current intention is to retain the
front-line domain, "deb.devuan.org", but change its implementation domain at
our leisure to a QoS based automated mirror management.

Thus: You should use "deb.devuan.org"

> ...

Ralph.

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

Re: [DNG] dev1galaxy.org down?

[Ralph Ronnquist via Dng]

yes, "dev1galaxy.org" is currently unavailable. A technical mishap and nothing
is lost. It'll come back shortly; probably in the EU morning.

Ralph

Ozi Traveller via Dng wrote on 18/8/20 9:49 am:
> me either
> 
> This site can’t be reached
> 
> *dev1galaxy.org * unexpectedly closed the connection.
> 
> 
> On Mon, Aug 17, 2020 at 11:28 PM pekman  wrote:
> 
>> yes. I don't access
>> --
>> att, pekman
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Deleted qemu image

[Ralph Ronnquist via Dng]

fraser kendall wrote on 16/7/20 8:35 pm:
> I have just done the stupidest thing.  I was freeing up (rm -rf) space
> on what I thought was a storage directory (/srv), but I have now just
> discovered that it contained a critical qemu image.  The image is a W7
> VM and is still running; it appears unaffected. The /srv partition
> is the largest on this machine and the testdisk recovery image of this
> partition (~170G) is too large to fit anywhere on the hard drive.
> 
> This machine is mission critical.  I cannot take it offline for another
> 6 hours, and I'll need to have it back up asap, (within an hour) so I
> need to plan my attack.
> 
> So some very naive questions.
> 
> Best option:  1) can I retrieve the deleted qcow image from a running
> instance of that image?

If that qemu is still running, then a) find out it's process id (pgrep -a
qemu), b) use that to find the open files of the process (ls /proc/$P/fd), c)
identify the deleted image, and then d) copy that into a new pathname.

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

Re: [DNG] Can't get graphic output from qemu

[Ralph Ronnquist via Dng]

Mark Hindley wrote on 13/7/20 10:00 pm:
> On Sun, Jul 12, 2020 at 05:42:12PM -1000, Joel Roth via Dng wrote:
>> Hi list,
>>
>> Since upgrading to ascii, I don't get a graphic window by default
>> as before.  Instead, qemu tries (and fails) to make a VNC connection.
>>
>> I can run qemu-system-x86_64 -display curses for text only.
>> The sdl and gtk options to -display which I think should
>> invoke graphic output, instead generate an error message of
>> being unsupported.
>>
>> What do I need to do to get the regular graphic output?
> 
> I think the gui has moved to a separate package. Try installing 
> qemu-system-gui.

That's very good. That works. Thanks. I've been living in the dark :)

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

Re: [DNG] Can't get graphic output from qemu

[Ralph Ronnquist via Dng]

Joel Roth via Dng wrote on 13/7/20 1:42 pm:
> Hi list,
> 
> Since upgrading to ascii, I don't get a graphic window by default
> as before.  Instead, qemu tries (and fails) to make a VNC connection.
> 
> I can run qemu-system-x86_64 -display curses for text only.
> The sdl and gtk options to -display which I think should
> invoke graphic output, instead generate an error message of
> being unsupported.
> 
> What do I need to do to get the regular graphic output?

Afaict even for ascii, qemu has progressed away from offering a built-in
display. I don't know what the necessary improvements where that accidentally
rendered the built-in display non-functional, but now a separate display seems
be the only option; vnc or spice. Plus that the serial console option is still
available.

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

Re: [DNG] About amprolla-3

[Ralph Ronnquist via Dng]

aitor_czr wrote on 2/7/20 9:13 pm:
> Hi again,
> 
> On 02/07/20 10:42, aitor_czr wrote:
>> for other values of *dist* we would find also other categories like 
>> 'contrib' or 'non-free' and also other different architectures ( 
>> 'source' 'all' 'i386 and 'amd64' aside)
> 
> Strictly speaking: the source for each category and, on the other hand, 
> the binaries and the contents for each category and architecture 
> (binary-all, etc...). You understand...

All clear. Except your note about '/binary-armhf/Packages.gz' which you said it
should be '/Packages.gz' but didn't use it so ...

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

Re: [DNG] annoying pulse symlinks

[Ralph Ronnquist via Dng]

Ian Zimmerman wrote on 21/6/20 2:25 am:
> This is a Debian question, but I don't expect any difference between
> Debian and Devuan in these matters, and I feel I have a better chance
> getting a useful answer here.
> 
> Roughly once in a blue moon, "something somewhere" creates a symlink of
> the form
> 
> ~/.config/pulse/08708c6cd6764173b7a41bdbc6995778-runtime ->
> /tmp/pulse-zZVyptPvnw4G
> 

Perhaps it's firejail?

For me it's the only binary that names ".config/pulse", and by a glance at
its sources it looks like it might well do a thing like that.

Ralph.

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

Re: [DNG] Picking VM MAC addresses (was Re: A way of holding telephone-conferences with DEVUAN?)

[Ralph Ronnquist via Dng]

Olaf Meeuwissen wrote on 9/4/20 9:48 pm:
> Hi,
> 
> Ralph Ronnquist via Dng writes:
> 
>> [...]
>> btw, the MAC address choice has some rules apart from needing to be different
>> from any other MAC address your networking will get to know of. My rule of
>> thumb is to start with 04, end with 2, and fill the middle "randomly", but 
>> keep
>> the same MAC address allocated for its individual guest system, which I also
>> keep documented in /home/share/dhcphosts.
> 
> If you pick MAC addresses for your VMs, just make sure they are locally
> administered ones.  See
> 
>   https://en.wikipedia.org/wiki/MAC_address#Universal_vs._local
> 
> These have the second least significant bit of the first byte set to
> one, so starting with 04 is NG.  First byte values matching 0x#2, 0x#3,
> 0x#6, 0x#7, 0x#a, 0x#b, 0x#e and 0x#f, where # stands for an arbitrary
> hexdigit, are fine.

.. any day without learning something is a lost day. :) Obviously I need to
polish my thumb.

thanks,

Ralph.




signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Current state of VPN software ?

[Ralph Ronnquist via Dng]

Simon Hobson wrote on 9/4/20 6:14 am:
> It's been a while since I last did anything with VPNs on Linux, and I recall 
> there being 3 options, some of which were "less well supported" than others. 
> I'm looking to setup a site-site tunnel so I can remotely access stuff at 
> mum's (she's in isolation because of this Covid 19 stuff) and using remote 
> desktop control, connect her Mac to a video call.
> 
> So what's the state of play in the VPN on Linux world - both ends would be 
> running Devuan (one end an AMD64 VM, the other end rPi) ? Last thing I used 
> was OpenVPN which AIUI is completely non-interoperable with anything else, 
> while FreeSwan and OpenSwan were having a bun fight.

For the Devuan infrastructure we do "virtual cabling" bmo "udptap" which is
available in experimental. It's similar to all else with, in my eyes, a couple
of advantages. The source project includes an openbsd branch which looks good
even if it's more or less untested.

However, for a one-off virtual cabling I would use "ssh -w"; as I remember that
works fine also on a mac (though I do remember there were some hurdles with
tun/tap).

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

Re: [DNG] A way of holding telephone-conferences with DEVUAN?

[Ralph Ronnquist via Dng]

Steve Litt wrote on 8/4/20 3:06 am:
> On Wed, 8 Apr 2020 00:40:50 +1000
> Ralph Ronnquist via Dng  wrote:
> 
> 
>> I've done two separate jitsi installations on tiny qemu hosts
>> (beowulf), single-cpu with 1G RAM (and 4G swap). An ad hoc test
>> indicated a load increase of about 0.2 per connections, and it worked
>> on the test with 8 connections (5 from myself, and 3 from someone
>> else).
> 
> Hi Ralph,
> 
> Could you please post the shellscript with which you spin up these qemu
> hosts? I've never been successful building a qemu host with full
> featured networking.

Ah, those hosts I rent from Vultr.com at $5.5/m, and admittedly I'm only
guessing they are qemu hosts from some droppings in dmesg. However, I think
I've learnt enough of qemu networking to call it easy, so let me digress this
thread momentarily about this.

The options are many and it depends on your taste. Basically, you'll need to
add two command line "-net" arguments": one for selecting network device in the
guest, and one for identifying the connection facility on the host. Perhaps
like so:
-net nic,macaddr=04:07:a6:c8:34:e2 -net vde,sock=/tmp/vde.ctl

The first says to use the default net device in the guest with the specified
MAC address. The second says to use "vde" networking via the /tmp/vde.ctl
socket directory. vde is installed as "vde2", and I do it this way because it
lets me set up the host side once for any number of concurrent qemu guests.

So for completeness: I would have set up the host with something like the
following:
# ip tuntap add tap0 mode tap user ralph
# ifconfig tap0 10.10.10.1/24 up
# sysctl net.ipv4.ip_forward=1
# iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -j MASQUERADE
# dnsmasq -i tap0 -a 10.10.10.1 -I wlan0 -I eth0 -K -D -N -b \
  --dhcp-sequential-ip --dhcp-hostsfile=/home/share/dhcphosts \
  -F 10.10.10.2,10.10.10.254,255.255.255.0,10.10.10.255
$ vde_switch -t tap0 -d

That one is a little bit of a mouthful but it's easily scriptable:
1. create a tap owned by "ralph",
2. configure it with IP 10.10.10.1,
3. enable kernel forwarding,
4. add NAT masquerading for packets from the tap0 network and
5. set up a DHCP responder and DNS forwarder for that interface taking
static ques from the file /home/share/dhcphosts (with lines like
"04:44:25:2f:17:12,beowulf-i386,10.10.10.2", though fully optional)
6. finally, run the vde networking switch as user ralph

Skip point 5 and use static IP set up in the guest if the host's port 53 is
already taken by some other program; dnsmasq gets unrecoverably sulky if it
can't grab that, but there are also other ways to service DHCP. And if you want
to go ipv6, you'll need different steps 2 and 5, but the rest stays the same.

I set up the host side with tap0 "owned" by "ralph" so I can run vde_switch and
the qemu guests as "ralph" (rather than "root"). The set up survives any number
of qemu up/down, separately or concurrently, and I think of it as the easiest
way. It also seems to perform better even than having a separate tap for each
qemu; at least it did that one time when I tested it.

btw, the MAC address choice has some rules apart from needing to be different
from any other MAC address your networking will get to know of. My rule of
thumb is to start with 04, end with 2, and fill the middle "randomly", but keep
the same MAC address allocated for its individual guest system, which I also
keep documented in /home/share/dhcphosts.

hth

Ralph.



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] A way of holding telephone-conferences with DEVUAN?

[Ralph Ronnquist via Dng]

Rod Rodolico wrote on 7/4/20 4:05 pm:
> I just installed a Jitsi instance on one of my old servers last week. My
> 15 year old granddaughter did most of the work. We built it as a Xen
> virtual with 10G disk, 4G RAM and 4 dedicated cores. We used ASCII as
> the Distro.
> ...

I've done two separate jitsi installations on tiny qemu hosts (beowulf),
single-cpu with 1G RAM (and 4G swap). An ad hoc test indicated a load increase
of about 0.2 per connections, and it worked on the test with 8 connections (5
from myself, and 3 from someone else).

Of course my chrome client couldn't service more than 5 concurrent connections,
and that took that client machine (8 CPU with 16 G RAM) up to a load of 15, but
the server was happy.

I give a special tick for jitsi that it is without any login, ie "anonymous",
and the server, if you want one, is quite easily installed. I wanted my own
server nearby in Sydney, and in LA for a friend; meet.jit.si is somewhere in EU
I think.

Ralph.



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Help needed:[Fwd: eudev: Methods to detect if running in a container.]

[Ralph Ronnquist via Dng]

Note that the inode number is per file system. If you make a file as an ext4
image, then its root will have inode=2 as well. You can verify that by mounting
the file somewhere and then stat that somewhere; or even chroot into that file
system (if set up), and use "stat /".

Ralph.

aitor_czr wrote on 2020-03-31 02:18:
> Hi Svante,
> 
> On 19/2/20 15:17, Svante Signell via Dng wrote:
>> Hello,
>>
>> No replies so far from the devuan-dev list. Maybe with a larger audience I 
>> can
>> get some help!
>>
>> Thanks!
> Checking  whether the *inode* number of the primary directory in the 
> standard filesystem hierarchy
> used in the most unix-like sytems(that is, the root "/" directory) is 
> *equal* to 2 will help to differentiate
> if you are within a container or not. eg you can do:
> 
> $ ls --inode --directory "/"
> 
> 2 /
> 
> While in a container the output of this command will return a high inode 
> number. I tested it in three
> different scenarios:
> 
> a) Using docker bash shell of ubuntu:
> 
> # docker run -it ubuntu bash
> 
> root@b87da5b70a84:/# ls --inode --directory "/"
> 
> 2492863 /
> 
> b) Using a qemu qcow2 image of devuan:
> 
> $ ls --inode --directory "/"
> 
> 9531 /
> 
> c) Inside the chroot jail of the live-sdk:
> 
> root@devuan:/# ls --inode --directory "/"
> 
> 22839335 /
> 
> I reckon this approach won't work neither in the case of operating 
> systems using random inode numbers
> (but this is not our case),nor in the case of chroot jails rooted on a 
> mount point, in which case we have
> the following workaround(at least in debian-based systems):
> 
> https://manpages.debian.org/jessie/debianutils/ischroot.1.en.html
> 
> Hope this helps,
> 
> Aitor.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Anyone installed a jitsi server on Devuan?

[Ralph Ronnquist via Dng]

Yes I installed it on my 1G/26G VPS (https://meet.rrq.id.au), running jitsi
with its web interface proxied through nginx. Very straight-forward to install
(apt-get install), though I needed to reduce its -Xmx from 3G to 1G.

Basically: you set up the domain; set up nginx SSL; install jitsi and follow
the prompts. I suppose, if you want to use jitsi's jetty web server directly,
then the SSL step is slightly different.

Ralph.

Steve Litt wrote on 2020-03-23 08:55:
> Hi all,
> 
> Has anyone installed a jitsi server on Devuan? I need to maintain a
> jitsi server in these days of virtual life.
> 
> SteveT
> 
> Steve Litt
> March 2020 featured book: Troubleshooting: Why Bother?
> http://www.troubleshooters.com/twb
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Clean install of ascii: / is huge ~ 40gb

[Ralph Ronnquist via Dng]

Traversing / directly like that is not a good idea. Rather do:

# mount -obind / /mnt
# du -sh /mnt/*

so that you traverse the root file system without traversing all special mounts
(/proc, /sys etc)

Thenn you'll do
# umount /mnt
to release the bind mount

Ralph.

Pontus Goffe via Dng wrote on 2020-02-13 18:38:
> You fail to mention what was included in 'additional programs' but to 
> give you a hint I have a pretty much vanilla but up-to-date Ascii here 
> with just LXDE and root partition uses 7.1G.
> May I suggest you traverse into / and look for usage?
> cd /; du -sh *;
> //PG
> 
> 
> On 2020-02-13 03:26, Owen wrote:
>> Hi,
>>
>> looking to get away from systemd, I'm moving from Ubuntu to Devuan (ascii).
>>
>> The system was installed 10 days ago, all went well and updates and 
>> additional pgograms installed well unyil today . . .
>>
>> The / partition was set as 40gb to be safe but today an "apt-get upgrade" 
>> failed due to lack of space:
>>
>> I've increased / to 60gb but I was never expecting it to ever get past 10gb.
>>
>> root@nucdevuan:/# df -m
>> Filesystem   1M-blocksUsed Available Use% Mounted on
>> udev  7947   0  7947   0% /dev
>> tmpfs 1594   1  1593   1% /run
>> /dev/nvme0n1p4   60786   39295 18375  69% /
>> tmpfs5   1 5   1% /run/lock
>> tmpfs 6464  93  6372   2% /run/shm
>> /dev/nvme0n1p5   26617 554 24682   3% /home
>> /dev/nvme0n1p22960 103  2688   4% /boot
>> /dev/nvme0n1p1 200   1   200   1% /boot/efi
>> tmpfs 7967   0  7967   0% /sys/fs/cgroup
>> tmpfs 1594   1  1594   1% /run/user/1000
>>
>> "du -s" shows no huge files.
>>
>> "apt-get clean" and "apt-get autoclean" don't highlight anything to remove.
>>
>> Any ideas how I can reclaim 30gb of my disk space please?
>>
>>
>> Thanks in anticipation.
>>
>> --
>> Owen
>> o...@gonwanda.net
>>
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 
> 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] interfaces.d question

[Ralph Ronnquist via Dng]

The "word" following "iface" in is the name of the configuration blocks. The 
full format for using them has the syntax:


# ifup =

Thus, you should define two blocks:
---
iface staticlan ...

iface dynamiclan ...
---

and use that on the command line, like:

# ifup eth0=staticlan

or

# ifup eth0=dynamiclan

You might want to refer to the man pages for more extensive details.

Ralph.

Gregory Nowak wrote on 24/12/19 9:57 am:

Hi All,
assume the following:

--- start /etc/network/interfaces.d/staticlan ---
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
# no gateway

--- end /etc/network/interfaces.d/staticlan ---

--- start /etc/network/interfaces/dynamiclan ---
iface eth0 inet dhcp

--- end /etc/network/interfaces.d/dynamiclan ---

If I do:

ifup staticlan
or:
ifup dynamiclan

I get:

"staticlan: unknown interface"

Same for dynamiclan

That makes sense, since there are no such physical interfaces in the
system. However, for ppp links the following works:

iface dsllink inet ppp
provider dsl-provider
...

This works, even though there is no such physical interface as
dsllink. This leads me to believe that what I want to do is
possible. However, I've read interfaces(5), and don't see there
anything that suggests how to do what I want to do.

So, Is it possible for me to define interfaces based on
/etc/network/interfaces.d/* instead of physical interfaces,
even though those interfaces don't
actually exist? If yes, then can someone either point me to an
explanation of how to do that, or can someone please explain how to do
that? Thanks.

Greg



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

Re: [DNG] Formail for managing digests

[Ralph Ronnquist via Dng]

Hmm, I understood

http://www.trek.eu.org/devel/sysd2v/sysd2v-0.2.sh

to be the code, and that it's about to be included in the sysvinit package.

If it works well enough, it'll be a handy tool for init script writers, even 
though it implicitly validates the existence of something the world could have 
been without to start with.


Ralph.

Steve Litt wrote on 28/11/19 11:53 am:

On Wed, 27 Nov 2019 12:18:55 -0600
goli...@devuan.org wrote:


More fiddling while Rome burns . . . sigh . . .

I'm in a bit of a mood because I thought that a script to convert
systemd units to init style shell scripts would be worthy of at least
some discussion.

golinux


Well holy cow, give us a chance!

That conversion is pretty technical, and I haven't yet seen the source
code: Its location isn't obvious. I can't discuss something I have
little knowledge of. After all, we're not systemd fanboiz. The URL you
supplied raises more questions than answers.

For instance, how the script decides whether to execute something in a
function or straightaway is a bit of a mystery to me. Another mystery
is which init system the output is intended to control. It doesn't look
like any sysvinit scripts I've seen, and it's for sure not runit, s6 or
Epoch.

If anyone finds the URL of the *actual code* of the converter, please
post it.

You're right about one thing: This is great news. Whether we end up
using the script and adapting to other inits by parsing the output, or
whether we end up using part of the script to work with each init, this
should make life easier.

SteveT

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


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

Re: [DNG] test_rewrite.sh http://pkgmaster.devuan.org fail

[Ralph Ronnquist via Dng]

Possibly things go better if you create the build/pool directory by hand.

It's unclear to me how you got the situation of an x86.cfg using util/get-dist 
without also having a build/pool directory, but I may well have messed it up 
(although I tried staying on "my" branch(es) -- note that the beowulf/* 
branches are not ready).


Ralph.

m_ma...@web.de wrote on 27/11/19 8:43 pm:

nothing important really, it's just that the script is looking for older
packages, that don't exist in repo anymore.. just needs updating...

d.


sorry Dimitris, i think it is imortant, i can not build a netinstall package 
for my cluster installation any more.
The make can not find the needed udeb packages.

util/get-dist: 19: cd: can't cd to pool
E: Unable to locate package base-installer
util/get-dist: 19: cd: can't cd to pool
E: Unable to locate package bootstrap-base
util/get-dist: 19: cd: can't cd to pool
E: Unable to locate package finish-install
util/get-dist: 19: cd: can't cd to pool
E: Unable to locate package acpi-modules-4.19.0-6-amd64-di
E: Couldn't find any package by glob 'acpi-modules-4.19.0-6-amd64-di'
E: Couldn't find any package by regex 'acpi-modules-4.19.0-6-amd64-di'
util/get-dist: 19: cd: can't cd to pool
E: Unable to locate package alsa-utils-udeb
util/get-dist: 19: cd: can't cd to pool
and lot more udeb..
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


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

Re: [DNG] mlterm to display path in window frame

[Ralph Ronnquist via Dng]

my shell function "title()" has

 echo -n "\033]0;$1\007"

which seems to do its thing for mlterm as well as xfce4-terminal and xterm, and 
probably other.


Ralph.

marc wrote on 11/11/19 8:44 am:

Hello

I am under the impression that some xterminal emulators
understand a certain escape sequence (maybe tsl ?) which
update the title bar.

What does

   tput hsl

and

   tput tsl ; echo -n hello ; tput fsl

do ? Maybe that escape sequence has been removed
from your terminfo entry ? Use infocmp to check
on a working system...

regards

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


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

Re: [DNG] Can't grub ignore /dev/hdb?

[Ralph Ronnquist via Dng]

Hendrik Boom wrote on 14/9/19 1:03 pm:
> On Fri, Sep 13, 2019 at 06:50:05PM -0400, fsmithred via Dng wrote:
>> On 9/13/19 5:43 PM, goli...@devuan.org wrote:
>>> On 2019-09-13 16:24, Hendrik Boom wrote:
 Haven't replaced /dev/hdb yet.
 Is there some way of getting it ignored in the following scenario?

 I started aptitude.
 It told me it hadn't been cleanly shut down last time, and recommended
 I do
     dpkg --configure -a
 before I do anything else.

 I do that, and the system apparently does some cleanup, generating
 initrd images, and then starts to update grub.

 Update-grub stalls on block 51 of device /dev/hdb, trying to do
 something with it over and over (as presented on the main system
 console, which is *not* the one I'm trying to run aptitude on)

 Now evidently /dev/hdb is not working and will need to be replaced.

 But isn't there some way to tell grub to ignore /dev/hdb?
 What is it that controls which drives grub tries to work with.
 It must get this from somewhere.  I did not specify or mention /dev/hdb
 anywhere in my dpkg --configure -a.  And there are several other drives
 I could use to install grub and a boot record.  I can even use the
 grub-install command to do so.  So why, oh why, does it pick on
 /dev/sdb?

 -- hendrik


>>>
>>> Open the case and unplug it?
>>>
>>> (golinux ducks and runs)
>>
>>
>> Golinux beat me to it.
>>
>> update-grub (grub-mkconfig) uses black magic to find all the bootable
>> systems within reach. 
> 
> That's useful information.  It does suggest that I have to unplug to 
> get update-grub to work.
> 
> Does that mean if I temporarily have a disk drive plugged in for any 
> temporary readon, it'll be found and get grub boot records installed on 
> it?
> 
> Sonds ike it.
> 

That same question apparently came up a while ago at
https://unix.stackexchange.com/questions/56004/how-to-stop-update-grub-from-scanning-all-drives

In short: do something to /etc/grub.d/30_os-prober
(which is a shell script)

Ralph.

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

Re: [DNG] VLAN interfaces over Bond interfaces

[Ralph Ronnquist via Dng]

I don't think "vconfig" brings up the interfaces, so you might need to
tell udev to do that when they are added:

allow-hotplug bond1.1
allow-hotplug bond1.10
allow-hotplug bond1.99

or if you prefer, by adding explicit "post-up ifup bond1.1" phrases instead.

Ralph.

Mike Tubby wrote on 3/9/19 9:34 am:
> I have an application that needs both VLANs and bonding at the same time
> and I'm having trouble getting it to work.
> 
> System is Dell R610 and Devuan 2.0 ("ASCII").  The machine is operating
> as a firewall and has duplicated Ethernet on the outside and inside.
> Duplication is for resilience, not performance.
> 
> The bonding driver works fine on the outside and works fine on the
> inside for a single, non-VLAN, network - however my problem is that I
> need to implement the legacy inside network on VLAN 1, a new internal
> network on VLAN 10 and a guest network on VLAN 99, hence I need "VLAN
> over bonding".
> 
> I have a similar setup at home where I just have straight Ethernet
> interfaces (no bonding) and the VLANs work fine on eth1.1, eth1.145,
> eth1.99 etc.
> 
> I have module '8021q' loaded and package 'vlan' installed (to get
> 'vconfig' executable).
> 
> Interface bond0 is the 'outside' and doesn't use VLAN and is fine.
> 
> Interface bond1 is the 'inside' and needs to be brought up without any
> untagged IP and three VLAN interfaces are needed:
> 
>     bond1.1    for legacy 192.168.1.0/24 traffic
>     bond1.10    for new 10.10.0.0/16 traffic
>     bond1.99    for secure guest traffic on 192.168.99.0/24
> 
> I have tried various incantations of configs in /etc/network/interfaces
> and don't seem to be able to get the VLAN over Bond to work.  I have
> tried with and without hints like "vlan-raw-device bond1" and
> with/without explicit 'vconfig' entries to try to force configuration of
> the VLANs and just about every combination seen on StackExchange etc.
> 
> With /etc/network/interfaces as shown (below) the system boots, doesn't
> output any errors, bond1 comes up with no IPv4 address, and only an
> FE80:: link-local IPv6 address.
> 
> Doing:
> 
>     cat /proc/net/vlan/status
> 
> shows that no VLANs are configured.
> 
> 
> Am I missing something or are the network startup scripts not able to
> configure VLAN over Bond?  They work just fine for VLAN over plain Eth?
> 
> 
> Mike
> 
> PS. IP addresses redacted/changed to protect the innocent.
> 
> 
> 
> #
> # Loopback
> #
> auto lo
> iface lo inet loopback
> 
> #
> # Outside (Internet)
> #
> auto bond0
> iface bond0 inet static
>     address 195.xx.yy.2
>     netmask 255.255.255.192
>     gateway 195.xx.yy.1
>     bond-mode 1
>     bond-miimon 100
>     bond-slaves eth0 eth1
>     bond-primary eth0
> 
> iface bond0 inet6 static
>     pre-up modprobe ipv6
>     address 2999::1999::2
>     netmask 64
>     gateway 2999::1999::1
> 
> #
> # Inside bonding interface
> #
> auto bond1
> iface bond1 inet manual
>     pre-up modprobe 8021q
>     post-up vconfig add bond1 1
>     post-up vconfig add bond1 10
>     post-up vconfig add bond1 99
>     bond-mode 1
>     bond-miimon 100
>     bond-slaves eth2 eth3
>     bond-primary eth2
> 
> #
> # Inside VLAN1 - Legacy 192.168.1.0/24
> #
> iface bond1.1 inet static
>     address 192.168.1.1
>     netmask 255.255.255.0
>     vlan-raw-device bond1
> 
> iface bond1.1 inet6 static
>     pre-up modprobe ipv6
>     address 2999::1999:8000::1
>     netmask 64
>     vlan-raw-device bond1
> 
> #
> # Inside new VLAN10 - 10.10.0.0/16
> #
> iface bond1.10 inet static
>     address 10.10.0.1
>     netmask 255.255.0.0
>     vlan-raw-device bond1
> 
> iface bond1.10 inet6 static
>     pre-up modprobe ipv6
>     address 2999::1999:8010::1
>     netmask 64
>     vlan-raw-device bond1
> 
> #
> # VLAN99 - Insecure/Guest use
> #
> iface bond1.99 inet static
>     address 192.168.99.1
>     netmask 255.255.255.0
>     vlan-raw-device bond1
> 
> iface bond1.99 inet6 static
>     pre-up modprobe ipv6
>     address 2999::1999:9900::1
>     netmask 64
>     vlan-raw-device bond1
> 
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Help to install LiLo to a GPT HDD.

[Ralph Ronnquist via Dng]

Arnt Karlsen wrote on 25/8/19 12:15 am:
> On Fri, 23 Aug 2019 00:48:10 -0400, Steve wrote in message 
> <20190823004810.18664...@mydesk.domain.cxm>:
> 
>> If I remember from my LILO days, LILO couldn't reach out 2.7 GB to
>> find a kernel.
> 
> ..can this be fixed with a simple patch to make lilo "reach out 
> beyond 2.7GB", or is there some nasty fundamental limitation 
> going on here?
> 

I don't know enough about LILO (anymore), but thought that it could
possibly be an option for you to change and use extlinux unstead.

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

Re: [DNG] Qemu with Beowulf host / Ascii guest dies without much of an error message

[Ralph Ronnquist via Dng]

Lars Noodén via Dng wrote on 12/8/19 9:14 pm:
> On 8/12/19 1:42 PM, Ralph Ronnquist via Dng wrote:
>> Lars Noodén via Dng wrote on 12/8/19 8:07 pm:
>>> [snip]
>>> -net user,hostfwd=tcp::-:22 \
>>> -net user,hostfwd=tcp::8880-:80 \
>>> -net user,hostfwd=tcp::4443-:443 \
>>> -net nic,model=virtio \
>>> [snip]
>>
>> Won't those declaration set up multiple concurrent backends for the
>> single guest NIC ? Shouldn't you rather join up all redirections into a
>> single backend parameter? I can imagine that multple backends could well
>> compete rather than collaborate (though to end up crashing is a bit
>> insensitive). This is of course pure guess work...
>>
>> Ralph.
> 
> Thanks.  That was it.  I am rather sure that invoking it the way shown
> above /used/ to work even if it now causes qemu to crash: Multiple old
> shell scripts I have from 2017 have that style of options, and worked,
> but I'm not sure for which version of qemu they last ran on.
> 
> Definitely, putting forwarding all under one option keeps it from
> crashing.  The qemu manual page does not warn against using multiple
> "-net user," options though it explicitly says that hostfwd can be used
> multiple times.  I guess the right way is now like this:
> 
>   -net user,hostfwd=tcp::-:22,hostfwd=tcp::8880-:80,...
> 
> The behavior has changed.  I wonder if this is a bug in qemu?

Well, a slightly irrelevant, and perhaps well known observation: I have
come to think that the most flexible networking for my local VM's is the
"vde mode". It does need a small amount of initial plumbing, with a
(single) supporting tap, and then either a bridge or routing plus local
dhcp. This ends up with a networking "portal" through a (shared) socket
that the qemu processes happily connect to.

With that, I can bring up my VM's willy-nilly, together or in isolation,
all running as non-root user, and presented to the host (and on the
network) as full featured machines without additional sysadmin; just
like "user mode", but without its limitations. And faster, I believe.

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

Re: [DNG] Qemu with Beowulf host / Ascii guest dies without much of an error message

[Ralph Ronnquist via Dng]

Lars Noodén via Dng wrote on 12/8/19 8:07 pm:
> [snip]
> -net user,hostfwd=tcp::-:22 \
> -net user,hostfwd=tcp::8880-:80 \
> -net user,hostfwd=tcp::4443-:443 \
> -net nic,model=virtio \
> [snip]

Won't those declaration set up multiple concurrent backends for the
single guest NIC ? Shouldn't you rather join up all redirections into a
single backend parameter? I can imagine that multple backends could well
compete rather than collaborate (though to end up crashing is a bit
insensitive). This is of course pure guess work...

Ralph.

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