BusterDog + build system (no-systemd)

[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.

[sb-nipper]

Hi, folks -- thanks for the explanations.

I just came across this link to https://apolloinrealtime.org which has preoccupied me at the moment. (I was just past my 14th birthday at the time of Apollo 13).

Looks like I'll rebuild my test set of mklive dog configurations, which is really no problem at all, credit to this build process. FYI I am exploring what makes the various configurations work, which ones I like better and why, and how one configures them from the basic apt or synaptic level. A lot of laying around in the process. Also took some side paths exploring wine and virtual box.

As I knock around, I can effectively be testing things someone else might like tested and of course can report anomalies or questions as I go.

Thanks again for a great platform and all your work

Stephen

[fredx181]

Re: elogind upgrade
For info: I had to make a change in control file of the package libpam-elogind from Antix, otherwise mklive-buster, the build-system, would be broken.
(has to do with removal of libpam-elogind-compat, that is not required anymore)
So, although the newer package libpam-elogind has still the same version, it's seen by apt as "upgradable".

Fred

[Ether]

.

I am running BusterDog64 with kernel 4.19.0-6

I see there is a newer kernel, 4.19.0-8 on github

How important is it to upgrade to the newer kernel?

.

[dancytron]

.

I am running BusterDog64 with kernel 4.19.0-6

I see there is a newer kernel, 4.19.0-8 on github

How important is it to upgrade to the newer kernel?

.

If all of your hardware is working the way you want it to, not important at all (unless you just want to help out by testing).

[fredx181]

.

I am running BusterDog64 with kernel 4.19.0-6

I see there is a newer kernel, 4.19.0-8 on github

How important is it to upgrade to the newer kernel?

.

If all of your hardware is working the way you want it to, not important at all (unless you just want to help out by testing).

I agree with dancytron, however you may want to use 4.19.0-8 because it has included support for the "+EXIT:" boot option (temp changes not in RAM, that you requested for Stretch a while back)

Fred