BusterDog + build system (no-systemd)

[fredx181]

.....
.....
Is this still applicable?
I tried installing systemd. (Exit X)

Apparently not, I don't know why
Have you ever tried aptitude ? It's more friendly than apt IMO, because often it gives you choices (solve conflicts, not always possible though) in such a situation where apt refuses.
apt install aptitude
aptitude update
aptitude install ... ... ...

edit: for example in your case, apt says:
libpam-systemd : Depends: systemd (= 241-7~deb10u9) but it is not going to be installed
systemd-sysv : PreDepends: systemd but it is not going to be installed
But apt doesn't say why, generally aptitude gives more explanation (at least).

I was curious if it works on Busterdog with aptitude, it does, but it's a hassle Not really recommended ! (to say the least )
I think finally after six or seven times I was happy with question asked "Accept this solution ?" (after some bad propositions IMO removing lots of xserver-xorg-.... packages that I answered with no).
(can't remember exactly, it was finally proposing to downgrade some elogind related packages and removing sysvinit, not sure though)
And it did work installing the systemd packages, and after reboot systemd was active.

[fredx181]

Some time ago since I tested the mklive-buster build script.
Found a major problem that the debootstrap .deb wasn't found.
Fixed, now will download and install debootstrap v1.0.114, download mklive-buster script here: https://debiandog.github.io/MakeLive/Re ... erdog.html

Updated 2023-06-04 mklive-buster

[dcung]

I was curious if it works on Busterdog with aptitude, it does, but it's a hassle Not really recommended ! (to say the least )
I think finally after six or seven times I was happy with question asked "Accept this solution ?" (after some bad propositions IMO removing lots of xserver-xorg-.... packages that I answered with no).
(can't remember exactly, it was finally proposing to downgrade some elogind related packages and removing sysvinit, not sure though)
And it did work installing the systemd packages, and after reboot systemd was active.

I didn't know about aptitude, I just tried it. I'm glad that you've told me. I will play with it more later.
Let me explain why I was looking to install systemd in BusterDog.
viewtopic.php?p=90879#p90879

[fredx181]

I was curious if it works on Busterdog with aptitude, it does, but it's a hassle Not really recommended ! (to say the least )
I think finally after six or seven times I was happy with question asked "Accept this solution ?" (after some bad propositions IMO removing lots of xserver-xorg-.... packages that I answered with no).
(can't remember exactly, it was finally proposing to downgrade some elogind related packages and removing sysvinit, not sure though)
And it did work installing the systemd packages, and after reboot systemd was active.

I didn't know about aptitude, I just tried it. I'm glad that you've told me. I will play with it more later.
Let me explain why I was looking to install systemd in BusterDog.
viewtopic.php?p=90879#p90879

Thanks for explaining.
About aptitude, it may look from my post that it's a hassle, but that was just in the (problematic) case with systemd on Busterdog.
Using aptitude can be very handy, where apt says only "cannot install" , aptitude can search for solutions in case something is partly broken in the package management system or perhaps solution can be to downgrade a package.

[dcung]

About aptitude, it may look from my post that it's a hassle, but that was just in the (problematic) case with systemd on Busterdog.
...

I will definitely try to have BusterDog with systemd ready for 'next adventure' ...
My D630 only has 'proper' nvidia driver (340) up-to BusterDog.
So, don't be surprised with my next 'stupid' questions in the future Fred

And looks like it's time to refresh my BusterDog isos too.
As always - Thanks for all assistance, Fred!

[fredx181]

I will definitely try to have BusterDog with systemd ready for 'next adventure' ...

Here's the log from what I did aptitude install udev systemd-sysv libpam-systemd on Busterdog (after exit X)
After 6 or 7 times not accepting the solution, finally (on line 219 "Downgrade the following packages:") I did accept (from line 226 on).

[dcung]

I refreshed my BusterDog isos set - used the new mkbuild / debootstrap. All good.

I actually used aptitude to install systemd afterward. Not sure how many options were presented before I accepted.
All I remembered was that I was keeping x stuffs, it did removed elogind.
And after reboot, systemd was installed - but no auto login.
So, that's 'good news'.

But sadly, snapd would not install.
I can recall exactly, since I did it days ago.

Code: Select all

apt install snapd
snap install core

One of these commands it didn't like. No real error messages.
I think it was the first one. In the terminal it shuts down porteus (?), back to # prompt.
I didn't take note since I was not thinking to follow it up.
I thought, I have a working Bullseye solution. So BusterDog solution was nice to have/know, but not critical.
I was only looking at BusterDog, solely for nvidia part (curiosity) - due to age of my testing hardwares.

[fredx181]

apt install snapd
snap install core

One of these commands it didn't like. No real error messages.
I think it was the first one. In the terminal it shuts down porteus (?), back to # prompt.

It's the second one, it's because script 'snap' is in /usr/local/bin (it's for porteus-boot save-on-exit) and has priority when you run 'snap'.
It's a bug, later (in Bullseye) I named it 'snap-ex' so it won't conflict with snap.
I understood that you're probably not going to use Buster anymore, but just saying: A workaround is using full path of snap so: /usr/bin/snap install core

[dcung]

...A workaround is using full path of snap so: /usr/bin/snap install core

With this info, it didn't take me long to test.
I redo the setup. Fresh frugal copy only takes minutes.

Code: Select all

/usr/bin/snap install core
/usr/bin/snap install cctv-viewer

snap commands went thru okay - no errors. I thought 'woohoo'...
But not that easy it seems...

Code: Select all

root@live:~# cctv-viewer
2023/06/07 18:55:03.733179 cmd_run.go:783: WARNING: cannot write file at /run/user/0/.portals-unavailable: open /run/user/0/.portals-unavailable: no such file or directory

/snap/core/14946/usr/lib/snapd/snap-confine: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
root@live:~# 

I got rid of the first error by relaxing permission of /run/user/ -> chmod 777.
So, it could then write there.

The second error, I could not.
apt install libudev.so.1 whatever it is -> not found.
I tried apt install libudev1 instead, but I cancelled since it wanted to get rid of all X stuffs.

I can see it created dirs for its configs, but no files there (in Bullseye cctv-viewer wrote configs here).
/root/snap/cctv-viewer/current

In /usr/local/bin, I saw both 'snap' and 'snap-ex'

[fredx181]

...A workaround is using full path of snap so: /usr/bin/snap install core

With this info, it didn't take me long to test.
I redo the setup. Fresh frugal copy only takes minutes.

Code: Select all

/usr/bin/snap install core
/usr/bin/snap install cctv-viewer

snap commands went thru okay - no errors. I thought 'woohoo'...
But not that easy it seems...

Code: Select all

root@live:~# cctv-viewer
2023/06/07 18:55:03.733179 cmd_run.go:783: WARNING: cannot write file at /run/user/0/.portals-unavailable: open /run/user/0/.portals-unavailable: no such file or directory

/snap/core/14946/usr/lib/snapd/snap-confine: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
root@live:~# 

I got rid of the first error by relaxing permission of /run/user/ -> chmod 777.
So, it could then write there.

The second error, I could not.
apt install libudev.so.1 whatever it is -> not found.
I tried apt install libudev1 instead, but I cancelled since it wanted to get rid of all X stuffs.

I can see it created dirs for its configs, but no files there (in Bullseye cctv-viewer wrote configs here).
/root/snap/cctv-viewer/current

In /usr/local/bin, I saw both 'snap' and 'snap-ex'

Haha, Busterdog seems not very "snap friendly" AKA "The ultimate challenge"
Well it's not made to run with systemd (or/and snap).
Tried to reproduce what you got, but cannot really, not getting the error about libudev.so.1, and the libudev1 lib exists for me: '/lib/x86_64-linux-gnu/libudev.so.1'
And cctv-viewer runs for me although with warnings about /run/user/0/ and about pulse.
About libudev1, it's a 'downgraded' package so to keep it as the Debian version (not Devuan) run apt-mark hold libudev1 (and probably also apt-mark hold udev).
(for me udev and libudev1 are installed being the Debian version after the systemd install process that we discussed earlier).
EDIT: Probably best to remove /usr/local/bin/snap so the 'real' snap has priority (is first in PATH) (but will break the porteus-boot 'save-on-exit' function, no problem though if you don't use that)

But perhaps forget about all this for Busterdog ?

[dcung]

And cctv-viewer runs for me although with warnings about /run/user/0/ and about pulse.

Knowing this makes me want to find out why it doesn't work for me...

But perhaps forget about all this for Busterdog ?

I'll keep digging in the background until I'm bored/give up.
Unless I found something significant, I'll write less and won't bore people with this...
Thanks for testing, Fred.

I repeated it again, run apt-mark hold libudev1, apt-mark hold udev, remove /usr/local/bin/snap and still got the same result!
When you run aptitude install udev systemd-sysv libpam-systemd - after your choice, your output was long.
When I run mine - I made same choice - but output was not as long (?). No errors, but was not that long.
I'm looking at apt/aptitude history logs, trying to make sense out of it.

Also libudev.so.1 exists in /lib/x86_64-linux-gnu, but which command does not find it?

Code: Select all

root@live:/lib/x86_64-linux-gnu# ls -las libudev.so.1
0 lrwxrwxrwx 1 root root 17 Mar 31 06:32 libudev.so.1 -> libudev.so.1.6.13
root@live:/lib/x86_64-linux-gnu# which libudev.so.1
root@live:/lib/x86_64-linux-gnu# cctv-viewer
/snap/core/14946/usr/lib/snapd/snap-confine: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
root@live:/lib/x86_64-linux-gnu# 

[fredx181]

I repeated it again, run apt-mark hold libudev1, apt-mark hold udev, remove /usr/local/bin/snap and still got the same result!
When you run aptitude install udev systemd-sysv libpam-systemd - after your choice, your output was long.
When I run mine - I made same choice - but output was not as long (?). No errors, but was not that long.
I'm looking at apt/aptitude history logs, trying to make sense out of it.

I piped the aptitude command to tee <file> , perhaps that made the difference.

Here's my aptitude log from /var/log (probably yours will be similar):

Code: Select all

Aptitude 0.8.11: log report
Wed, Jun  7 2023 17:57:34 +0200

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 7 packages, and remove 6 packages.
12.8 MB of disk space will be used
========================================
[INSTALL, DEPENDENCIES] libsystemd0:amd64 241-7~deb10u9
[INSTALL, DEPENDENCIES] systemd:amd64 241-7~deb10u9
[REMOVE, DEPENDENCIES] elogind:amd64 243.7-1.0antix1
[REMOVE, DEPENDENCIES] eudev:amd64 233:3.2.9-9~beowulf1
[REMOVE, DEPENDENCIES] libeudev1:amd64 233:3.2.9-9~beowulf1
[REMOVE, DEPENDENCIES] libpam-elogind:amd64 243.7-1.0antix1
[REMOVE, DEPENDENCIES] libpam-elogind-compat:amd64 1.3
[REMOVE, DEPENDENCIES] sysvinit-core:amd64 2.93-8
[DOWNGRADE] libelogind0:amd64 243.7-1.0antix1 -> 239.3+20190131-1+debian1
[DOWNGRADE] libudev1:amd64 1:3.2.9+devuan4 -> 241-7~deb10u9
[DOWNGRADE] udev:amd64 1:3.2.9+devuan4 -> 241-7~deb10u9
[HOLD] cpio:amd64 2.12+dfsg-9
[HOLD] libc-bin:amd64 2.28-10+deb10u1
[HOLD] libc6:amd64 2.28-10+deb10u1
[HOLD] libgnutls30:amd64 3.6.7-4+deb10u8
[HOLD] libssl1.1:amd64 1.1.1n-0+deb10u3
[HOLD] libtasn1-6:amd64 4.13-3
[HOLD] ncurses-base:amd64 6.1+20181013-2+deb10u2
[HOLD] ncurses-bin:amd64 6.1+20181013-2+deb10u2
[HOLD] tzdata:amd64 2021a-0+deb10u6
[HOLD] zlib1g:amd64 1:1.2.11.dfsg-1+deb10u1
[INSTALL] libpam-systemd:amd64 241-7~deb10u9
[INSTALL] systemd-sysv:amd64 241-7~deb10u9
========================================

Log complete.

Note that the apt-mark hold ... commands are only to prevent upgrading (where it says [DOWNGRADE] should be put on hold) , not solving the libudev1 issue.
What you could try is to reinstall libudev1 : apt install --reinstall libudev1=241-7~deb10u9
Or/and reinstall snapd . (edit: or perhaps best to purge first: apt purge snapd and then install again).
It's apparently /snap/core/14946/usr/lib/snapd/snap-confine that cannot find libudev.so.1, strange...

[dcung]

I piped the aptitude command to tee <file> , perhaps that made the difference.
Here's my aptitude log from /var/log (probably yours will be similar):

I thought you did that, piping to a file.
Yes, my /var/log is 'identical' to yours.

I'm totally beaten today!
Laptop 1 -> D630 T8300/nvidia-GPU/BusterDog-DDOG iso made 2023-06-05
Laptop 2 -> D630 T8300/Intel-GPU/BusterDog-DDOG iso made in 2021 (my oldest mklive)
Laptop 3 -> Samsung NP740 i5/Intel-GPU/BusterDog-OBDOG iso made 2023-06-05
All gave same results!!! Same error! What dumb mistake could I make now??

One thing at least put a smile to my face before I go to bed shortly.
I just did StretchDog (latest iso made 2023-03-03), just for the heck of it. And guess what? It works! No drama at all!
I did the same things. Install aptitude, install systemd, install snapd, install cctv-viewer (same commands - I already prepared in a file, cut & paste)
However, I did it on another laptop. A Fujitsu with i5.

Anyway, looks like I give up on BusterDog, Fred!

[fredx181]

@dcung I'm suspecting now that snap doesn't work well on a system with running "aufs" (tested now on my old laptop with kernel 4.19 and got the libudev1 error same as you).
Forgot to mention earlier that my testing on Buster was with a newer kernel (running with "overlay").
But if so that aufs is the problem then again I can't explain why it works OK for you with Stretch (with running aufs ? or with overlay ? ).
Will test more in the coming days.

[dcung]

But if so that aufs is the problem then again I can't explain why it works OK for you with Stretch (with running aufs ? or with overlay ? ).

I don't know, Fred.
How to tell the difference aufs ? or with overlay ?
All I know is that, I made the Stretch DDOG iso 2023-03-03 - see attached build-setup.txt.
And it's using kernel k-4.9.0-12-amd64.squashfs.

build_setup.txt

(3.42 KiB) Downloaded 25 times

.
.

Don't know if this is of any significance.
#### PIDOF FROM BUSTER - NOT WORKING

Code: Select all

root@live:~# pidof systemd
1
root@live:~# cctv-viewer
2023/06/09 07:40:59.100484 cmd_run.go:783: WARNING: cannot write file at /run/user/0/.portals-unavailable: open /run/user/0/.portals-unavailable: no such file or directory
/snap/core/14946/usr/lib/snapd/snap-confine: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
root@live:~# 

#### PIDOF FROM STRETCH - WORKING

Code: Select all

root@live:~# pidof systemd
1896 1
root@live:~# cctv-viewer
libEGL warning: DRI2: failed to authenticate
PulseAudioService: pa_context_connect() failed
using null output device, none available

root@live:~# mount | grep aufs
aufs on / type aufs (rw,relatime,si=803039d7d8155df6,nowarn_perm)
root@live:~# mount | grep overlay
root@live:~# 

[fredx181]

Ok, no, with the 4.9 kernel it should be running with aufs (what is used should be visible with mount | grep aufs or mount | grep overlay) (from Bullseye on "overlay" is used instead of "aufs')
I just thought that you possibly swapped kernel with newer on Stretch, but not, so... mystery why it works on Stretch and not on Buster.
edit: as you may notice, I can't stand mysteries

EDIT:

#### PIDOF FROM BUSTER - NOT WORKING

Yes it's only showing 1 but surely systemd is running otherwise no output at all.
No idea why it gives 1896 1 (two pids) on Stretch

[dcung]

edit: as you may notice, I can't stand mysteries

I guess, we're similar..
It's not a necessity, if so, mine have been solved with Bullseye.
It all started since you tickle my curiosity by telling me your BusterDog 'worked'..
I had to know why your Buster 'works' and mine 'didn't'...
Now, we open a can of worms!

[fredx181]

@dcung Second time try this again with the default Buster kernel 4.19, but now on my new laptop, to get cctv-viewer snap working gave me the same libudev1 error.
I gave up, stupid snap!
Did some searching on the web about this error and none of the solutions presented (e.g. related to apparmor) worked for me, it's complicated stuff, the error can possibly be caused by many things I guess.

[dcung]

I gave up, stupid snap!

I understand. Yes, silly snap.
At least we know, with newer kernel it works,
Thanks for spending sometime on it Fred.

Next 'learning adventure', I want to learn compiling app.
While troubleshooting about this, I got impression that cctv-viewer (on github) can be compiled and run w/o snap (?)
The author seems friendly, maybe I'll ask him later if I feel up to it.
But knowing myself (skill wise), it's probably is just wishful thinking.

[dancytron]

I'm still using this on my Thinkcentre M90 all-in-one.

Yt-dlp/Youtube Get won't update because it needs Python 3.8, but Buster only has 3.7.

I didn't find anything in the backports.

I guess it's time to upgrade????

[fredx181]

I'm still using this on my Thinkcentre M90 all-in-one.

Yt-dlp/Youtube Get won't update because it needs Python 3.8, but Buster only has 3.7.

I didn't find anything in the backports.

I guess it's time to upgrade????

If only for yt-dlp , you can use the standalone binary (has newest python3 built in, much bigger though).
See: https://github.com/yt-dlp/yt-dlp/issues ... 1752305216
(rename yt-dlp_linux to yt-dlp , copy to /usr/local/bin/ and make executable)
I tested on Buster and works.

[dancytron]

Works perfect.

Thanks.

--Dan