BusterDog + build system (no-systemd)

[ras]

Hi Fred,
what I would like to build is a frugal install that includes wireguard. I would like to have wireguard in a read only module. whether wireguard is in it's own module or part of the base install module does not matter.

wireguard prefers openresolv for use with debian to prevent dns leaks. openresolv conflicts with frisbee and peasywifi, hence my desire to build with network-manager instead.
https://bugs.debian.org/cgi-bin/bugrepo ... bug=860564

the build I have working now was built using these instructions from the wireguard site: https://www.wireguard.com/install/

Debian [module – v0.0.20200318 & tools – v1.0.20200319]

# apt install wireguard

Users with Debian releases older than Bullseye should enable backports.

and backports from here: https://backports.debian.org/Instructions/

so I added deb http://deb.debian.org/debian buster-backports main
to /etc/apt/sources.list
# apt update
# apt-get -t buster-backports install wireguard

when configuring wireguard in busterdog I have found that I also need to have nftables installed. There is also a script from mullvad vpn which generates a configuration and key exchange. it works well, but needs curl and jq

I do not necessarily need to build my install with upgrade-kernel-buster-bpo, I just thought to give it a try and see if it would make a difference doing things the busterdog way. My focus at this point is to create a create a wireguard module or having wireguard inside some other module. Perhaps remastering would be a better way to move forward than using remastercow?

Thanks

[rcrsn51]

openresolv conflicts with frisbee and peasywifi,

Just out of curiosity, is the issue here that you want to control the contents of /etc/resolv.conf instead of the DHCP server?

You can do this in PWF by creating the file /etc/resolv.conf.head

See line 28 of /etc/pwf/udhcpc/default.script.

Or you could give the machine a static IP address and set the DNS server to whatever you want.

[ras]

rcrsn51

if I rename /etc/resolve.conf and run the wireguard command to bring up a tunnel to the vpn server, a new /etc/resolv.conf is created that points to the ip of the vpn company dns server. the vpn setup script installed configs for each of their locations in /etc/wireguard

if in fact, a simple edit of /ect/resolv.conf was all's that was needed, then the wireguard instructions might have mentioned that. the bug report cited above is from the developer of wireguard and he concludes

Therefore, I'd suggest that either:
a) Debian switch to using Openresolv by default instead of its own
"resolvconf". The openresolv package already "Provides: openresolv",
so it should be a drop-in replacement; or
b) Debian's "resolvconf" backport these useful and necessary features
from Openresolv.

it is apt that wants to uninstall peasywifi before it can install openresolv, and it is the mullvad vpn install instructions that recommend the use of openresolv to properly use their service without dnsleaks.

[fredx181]

what I would like to build is a frugal install that includes wireguard. I would like to have wireguard in a read only module. whether wireguard is in it's own module or part of the base install module does not matter.

Here's a squash module that may work for you (but really not sure)
https://github.com/doglinux/busterdog/r ... 4.squashfs
For info, I made it by using apt2sfs, entering this:

Code: Select all

wireguard openresolv nftables jq linux-headers-4.19.0-8-amd64

Made on a minimal system, but curl is installed, so not included in the module)
It includes also linux-headers, required for to build the kernel module wireguard.ko (with wireguard-dkms) which is therefore included (for kernel 4.19.0-8-amd64).
So the squashfs is larger than actually needed because of linux-headers and build tools inside.
If that's a problem I'd be happy to build one again (manually) later with only the required stuff inside (but need to know then from you exactly what)
Btw,It could well be that this module doesn't conflict when frisbee or peasywifi is installed.

Remastercow should work OK (just tested), maybe when you tried the changes were not yet saved ? (should be)

Fred

[fredx181]

Wonderful distribution, complete and easy to use, apt-get works as expected.
Also the dark look is elegant and relaxing to the eyes.

Touchpad tapping is not working on my Hp notebook, and Flsynclient is missing. How to enable tapping?
/etc/X11/xorg.conf isn't there as in other Puppies. Do I have to install flsynclient or is there a workaround?
Thank you!

ps: I'm using the 32bit version.

Hi tommy,

Maybe this script works for you ?

Code: Select all

#!/bin/sh

synclient TapButton1=1
synclient TapButton2=2
synclient TapButton3=3

Found this in old Debiandog thread. I can't test because of my hardware, if above doesn't work hopefully someone else may be able to help.

Fred

[tommy]

@ fredx181
Hi fred,
your script works perfectly, I copied it in Startup folder so tapping will be available at every boot.

Thank you!

[enrique]

I have a few question on temporary files. Lets start with the simple one.
1) /tmp
I do have /tmp

Code: Select all

ls /tmp/
pup-volume-monitor-log  pup_volume_monitor_socket  serverauth.dHiCvpvaHo  ssh-NcpnU6Mp8qCz

Apart of those files, the truth is that I can see this folder been used. Is there are another location where porteous keep the temporary files?

2) dmesg
I can see I have

Code: Select all

ls /var/log
alternatives.log  apt  dmesg  dmesg.0  dmesg.1.gz  dmesg.2.gz  dmesg.3.gz  dmesg.4.gz  dpkg.log  fsck  lastlog  openvpn  porteus-livedbg  wtmp  Xorg.0.log  Xorg.0.log.old

None of those files seems to update.
Where is the physical store location of dmesg contents?

[fredx181]

Hi enrique,

I do have /tmp
Code:
ls /tmp/
pup-volume-monitor-log pup_volume_monitor_socket serverauth.dHiCvpvaHo ssh-NcpnU6Mp8qCz

Apart of those files, the truth is that I can see this folder been used. Is there are another location where porteous keep the temporary files?

Some temp files are created by porteus-boot in /mnt/live/etc and in /mnt/live/tmp

I can see I have
Code:
ls /var/log
alternatives.log apt dmesg dmesg.0 dmesg.1.gz dmesg.2.gz dmesg.3.gz dmesg.4.gz dpkg.log fsck lastlog openvpn porteus-livedbg wtmp Xorg.0.log Xorg.0.log.old

None of those files seems to update.
Where is the physical store location of dmesg contents?

Contents of dmesg should be /var/log/messages
(don't see it in your list, but should be there, not?)

EDIT: For info, at start of boot the script 'linuxrc' (init) from inside initrd1.xz is creating a live system environment, when done that, Debian 'takes over' (the log files do not contain porteus-boot info, except for porteus-livedbg) .

Fred

[enrique]

Code: Select all

ls /mnt/live/etc
cmdline  fstab  homedrv  mtab

ls /mnt/live/tmp
changes-exit  devices  modules

ls /mnt/live/var/
log  tmp

ls /mnt/live/var/log
livedbg

ls /mnt/live/var/tmp

Nothing interesting! Funny is that dmesg do work nice. So data should be store some place. I looking for the file because I do like to do

Code: Select all

 tail -f  /var/log/messages

while I debug. And at the moment I can not. This is with your mklive-buster. I will see how it behave in your, mklive-buster64 or your BusterDog-openbox_jwm-2019-12-29_64-bit.iso. Maybe there is a mising package?

Another situation, many time when I use the pcmanfm to browse /mnt/live area, the AUFS seems to break up. First I can see is that my stuff at the desktop get lost. But in reality all system seems to had unmount. So not only the Icons get lost but the whole system. If I do ls nothing show. I can not even reboot or shutdown as there is no bin folder with commands. That only happens when I play on /mnt/live. Not always.

[fredx181]

Hi enrique, yes, you are right, no /var/log/messages on a minimal build.
Installing "rsyslog" fixes that.

Fred

[ras]

Fred,
Thanks for your build. it still needs something more to work (for me anyway), and thanks for your offer to help further, but I am going to put this on the shelf until kernel 5.6 is available.

[enrique]

I took the day off. Sorry no test from my side.

"Installing "rsyslog" fixes that. "
See People, I had only admiration to this project and its master builders. One more time my thanks.

[fredx181]

*** Addition and updates in custom Busterdog repository ***

-Added package: takeashot, (Take A Shot) advanced screen capture utility (by SFR, see here: http://murga-linux.com/puppy/viewtopic.php?t=84528)
One nice thing about it is that it can create an animated gif, depends on ffmpeg.
See also here: http://murga-linux.com/puppy/viewtopic. ... 03#1054503

-Updated:
- touchpad and p910nd-print-server (by rcrsn51) Touchpad P910nd Print Server
- mm-view (v 0.28, 'a universal file viewer' by Mochimoppel, see here: http://murga-linux.com/puppy/viewtopic.php?t=109573)
- youtube-viewer (v 3.7.4) (if straw-viewer is installed, it will be replaced by youtube-viewer (and vice versa))

Install with synaptic or apt.

Fred

[fredx181]

*** Install Teamviewer on Buster ***

Quite possible, however it's not working "out of the box", so needs a workaround.
(to run teamviewer, having a login-manager installed is required, I found, but maybe there's other way too than below)

1) Go to the teamviewer website and download the deb (ubuntu/debian)
https://www.teamviewer.com/en/download/linux/
After installing (+ dependencies) teamviewer probably won't run (running from terminal says "Launching Teamviewer GUI", but nothing happens), step 2 and 3 should fix that.

2) Install a "display manager" (login manager) e.g. 'slim', 'nodm' or lightdm (with the latter I didn't test)
nodm will do, it's the most small and simple (will login as root automatically).

Code: Select all

apt install nodm

3) Disable autologin in /etc/inittab (nodm should provide it), open with text-editor, find the line:

Code: Select all

1:2345:respawn:/bin/login -f root tty6 </dev/tty1 >/dev/tty1 2>&1

comment it, and uncomment the next line, so then it should become this:

Code: Select all

#1:2345:respawn:/bin/login -f root tty6 </dev/tty1 >/dev/tty1 2>&1
1:2345:respawn:/sbin/getty 38400 tty1

Reboot with saved changes and teamviewer should work.

Fred

[sb-nipper]

Greetings! I finally got signed to participate in the mkklive build system.

I have a Dell Vostro 1015 with
Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz
Min/Max Speed: 1200/2101 MHz
Current Speed of Core 0:1200 MHz, 1:1200 MHz
Core Count: 2
Thread Count: 2

Total RAM: 2969 MB

Specifically what prompted me is that I rebuild a XFCE minimal system (buster 64bit) on perhaps the 4/3rd or 4/4. Approx the 4/7 or 8th I set it up and did the initial apt-get update and upgrade.

I tracked down by clearing and repeating, that it was an upgrade of elogind (241.3-2+antix1 --> 243.7-1.0antix1 which crashed the X-server (I think) saying that elogind had moved (something like that).

Both apt-get and synaptic generated this result.

I repeated the mklive-buster64 -gui script for XFCE -minimal (I also exchanged palemoon for firefox-esr and added git). This picked up the news version of elogind and everything worked fine in this relation.

I subsequently found that at the point of crash, if I tapped the power button the system signaled restart and triggered the save question, and in fact upon restart, elogind was at the new version. So this is not a severe problem at all if someone knows ahead of time.

It seems the elogind package did not signal properly to reboot before changing something. Both those commands are stock items.

Things like this help me understand more what's going on. Can you comment?

I vaguely remember some time before un-commenting some antix repositories, and having the thing crash as well during apt-get upgrade, but I did not explore further, figuring I had just done something stupid.

Thanks

[rcrsn51]

There was a problem with the latest version of elogind in Fred's repo. He has now removed it

[fredx181]

Hi sb-nipper,

Yes, upgrading elogind is problematic, sorry, got a PM yesterday about it and could reproduce the crash myself too when upgrading.

I tracked down by clearing and repeating, that it was an upgrade of elogind (241.3-2+antix1 --> 243.7-1.0antix1 which crashed the X-server (I think) saying that elogind had moved (something like that).

Removed the v243.7-1 now from custom repo, so stays at 241.3-2 when doing apt upgrade (at this point of time).

I've found when exiting X first and then do the the upgrade from console it goes fine

I just tested also downgrading from 243.7-1 to 241.3-2

Code: Select all

apt install libelogind0=241.3-2+antix1 elogind=241.3-2+antix1 libpam-elogind=241.3-2+antix1

Same crash happens, but also, not when done from outside X.
To do that easily (without having to type above code in console), paste it in a text file, name it for example "downgrade-elogind", save in /root, exit X and from console:

Code: Select all

sh downgrade-elogind

From a quick test, I found that when a display-manager is installed, e.g. slim (and autologin is disabled from /etc/inittab) the crash does not happen (so has to do with the way X is started, (the default startx mechanism) but needs further testing.
EDIT: As a sidenote: That could also explain why the crash wouldn't happen on Antix, because it has a display-manager included.

Fred

[fredx181]

I've found that the reason for the X crash at elogind upgrade (which happened only on 64-bit, the 32 bit Busterdog has older xinit installed, see below) is because of restarting elogind service (which is done when upgrading)
A solution is to make X start on another tty, e.g. vt7 (the crash happens because X starts on the same tty as login: vt1 )

One solutiion is to install older xinit v1.3.2-1, it's here:
https://doglinux.github.io/busterdog/NoRepo/
Another way is to edit '/etc/X11/xinit/xserverrc', change to:

Code: Select all

exec /usr/bin/X -nolisten tcp vt7

Exit X > startx will then start X on another tty and elogind can be restarted without crashing, can be tested with:

Code: Select all

service elogind restart

(do NOT run above when X is still started on tty1, then it will crash)
EDIT: Can be checked with: echo $XDG_VTNR, my output is 7 (as I edited /etc/X11/xinit/xserverrc to start X on vt7) :

Code: Select all

root@live:~# echo $XDG_VTNR
7

EDIT2: The variable $WINDOWPATH is probably more reliable.

Not sure yet how to handle things in the future to automate an elogind upgrade without problems.

Fred

[fredx181]

Added the upgradable elogind packages again to the repository (v243), this time it's safe to install (no crash as before).
The fix/workaround I did was modifying the postinst script of elogind package, it checks now if X is on tty1, if so, the elogind daemon will not restart (needs a reboot then), I see no good reason for the restart, btw, everything stays working fine without it.

Also updated touchpad by rcrsn51, see info here:
http://murga-linux.com/puppy/viewtopic. ... 095#974095

Another subject, for anyone interested to try: Simplicity Linux is based on BusterDog (it says on the website, but in fact is not, see below)

I tried the Desktop edition that has Cinnamon DE, nice , but not for anyone preferring "light" (like me).
A bad thing IMO is that it says to be based on Busterdog, but in reality it's based on Devuandog that has been discontinued (it has in sources.list the Devuan repo and the DevuanDog repo, that is not being updated anymore) why?, I don't get it .

Fred

[rcrsn51]

I tested the patched elogind and it looks good. Thanks.

I have posted here updates to PeasyPort. There is now a matching 32bit version. These are for both Stretch and Buster.

I would appreciate some feedback on these, particularly how MAC scanning performs over wifi networks.