Mmh, maybe you found something from:
cd /etc ; grep -Rne ping
But this will probably give you a lot of matches 
Too many indeed, but "ifconfig" is not too bad and shows the solution:
avahi/avahi-autoipd.action:60:elif [ -x /bin/ifconfig -o -x /sbin/ifconfig ] ; then
avahi/avahi-autoipd.action:62: # We have the old ifconfig tool
avahi/avahi-autoipd.action:66: ifconfig "$2:avahi" inet "$3" netmask 255.255.0.0 broadcast 169.254.255.255 up
avahi/avahi-autoipd.action:72: ifconfig "$2:avahi" down
seems like this makes it working back:
sudo dpkg-reconfigure iputils-ping
Improving the installer to automatically fix the ping thing (when you'll install, it will be updated and then your installed system should have it working)
1 Like
Any idea why that works?
Or better said: Why the initial configuration didn't?
read the install script (called when reconfigure):
/var/lib/dpkg/info/iputils-ping.postinst
Seems like it adds the missing configuration (setcap), but I don't know why its not done by default, maybe because something in the system changed (when installed) and then the setcap validation was removed (no idea how setcap works atm), which required to set it again. For example, the ssh keys of the host machine are newly generated on install, it would be insecure to use the same keys as the live mode (but even these, are regenerated on boot time), so who knows...
Note: after to grep for other "setcap" calls, I have added a few other packages in the installer to be reconfigured just in case they needs the new setcap setting
Systemd and pulseaudio can due to wrong design consume alot of cpu and memory resurses.
Best way to solve this, specially for embedded systems is to remove then or shorten then out.
I have used many other Linux and -BSD system and there specially for Linux (latest CentOS7 or RedHat) systemd and pulseaudio has misbehaved in normal, suspend or hibernate or from resume, even from power up. It's not normal action to loop forever and consume too much cpu resources as the do today if wrong configuration. This can kill any embedded with battery support. Best solution is to do as MX linux (wrapper around) or better AntiX Linux (removed) do today. Then this wrong behavior is also removed. Previous versions of Elive did not used systemd or pulseaudio. There are also problems with pulseaudio usage with increased latency dependent of audio source, my audio mixing software also misbehave and results will be trash.
Firefox has also made wrong decisions about using pulseaudio due to its DRM requirement.
As I wrote, MX linux and AntiX linux had made a solution around this.
Debian and many other distribution make a wrong decision when the integrate pulseaudio and systemd, most due to other ie Gnome took wrong way due to they are not engineer for embedded targets.
Now many distributions leaves embedded market behind, consider that smartphones are embedded targets with limited battery usages.
3 Likes
Exactly
Thanks, I will need to do some research and tests in MX linux and AntiX to see how / what they did
Actually Elive has been fully integrated to not use / depend on pulseaudio in the 3.0 stable version, but entirely Alsa (without the need of pulseaudio), this means that in the theory, you can remove pulseaudio and everything should still work (except e16 sound themes which uses pulseaudio, and skype if you use it)
Systemd is more complicated to remove, debian buster depends more on it, in fact it will remove thunar and network-manager, so will be needed to use alternatives then
You (or anybody) can experiment with these things and do some tests, like resources usage, by removing them
I have did a small experiment in a virtual machine and removed systemd, the OS can run with "wicd" (instead of network-manager) and with "slim" instead of lightdm (login-manager)
In a 32-bit based system, the memory usage is reduced to only consume between 100 and 150 MB (depends of if you use the dock, etc...), similar optimizations can be obtained by removing eventually pulseaudio
By other side you cannot shutdown / reboot from desktop anymore, the login manager doesn't has these options too, and probably you could encounter more issues...
It's just an experiment for now, but maybe in the future we could have the option to remove it entirely from our systems 
2 Likes
Devuan sounded good, but wouldn't it be the same as installing init in vanilla debian (so it wouldn't be able to install those packages)?
Maybe someone could write a module for the desktop that for shutdown just runs shutdown -h now etc? The login-manager is more complicated tho, and there probably are more issues...So I'm definitely thinking trying devuan.
EDIT: Updated list from running api sysvinit-core:
The following additional packages will be installed:
brasero-common cairo-dock-core dbus dbus-x11 gnome-settings-daemon-common
gnome-software-common gsettings-desktop-schemas gvfs-bin gvfs-common
gvfs-libs libbrasero-media3-1 libdbus-1-3 libdbus-1-3:i386 libdbus-1-dev
libip4tc2 libnewt0.52 libnm0 libsystemd0 libsystemd0:i386 systemd
systemd-timesyncd
Suggested packages:
xcompmgr empathy f-spot gnome-calculator gvfs systemd-container policykit-1
bootlogd
Recommended packages:
cairo-dock-plugins gvfs
The following packages will be REMOVED:
brasero cairo-dock dbus-user-session eltrans gdebi gksu gnome-disk-utility
gnome-settings-daemon gnome-software gnome-software-plugin-flatpak gvfs
gvfs-backends gvfs-daemons gvfs-fuse libpam-systemd lightdm network-manager
network-manager-fortisslvpn network-manager-fortisslvpn-gnome
network-manager-gnome network-manager-l2tp network-manager-l2tp-gnome
network-manager-openconnect network-manager-openconnect-gnome
network-manager-openvpn network-manager-openvpn-gnome network-manager-pptp
network-manager-pptp-gnome network-manager-strongswan network-manager-vpnc
network-manager-vpnc-gnome packagekit packagekit-tools policykit-1
policykit-1-gnome systemd-sysv udisks2 udisks2-btrfs urfkill
usb-bootable-elive
The following NEW packages will be installed:
libip4tc2 systemd-timesyncd sysvinit-core
The following packages will be upgraded:
brasero-common cairo-dock-core dbus dbus-x11 gnome-settings-daemon-common
gnome-software-common gsettings-desktop-schemas gvfs-bin gvfs-common
gvfs-libs libbrasero-media3-1 libdbus-1-3 libdbus-1-3:i386 libdbus-1-dev
libnewt0.52 libnm0 libsystemd0 libsystemd0:i386 systemd
19 upgraded, 3 newly installed, 40 to remove and 1536 not upgraded.
Need to get 19.4 MB of archives.
After this operation, 43.9 MB disk space will be freed.
Kind of funny how cairo-dock-plugins is a recommended package but cairo-dock would be removed. It's also irritating how it would remove eltrans.
Gnome desktop requires systemd thus everything related or stating dependencies gets removed.
That includes cairo-dock ....... you could give "tint2" a try as a drop in replacement for the dock though. 
haha this doesn't affect me, i'm using e23 
Ugh...Well I guess we'd need to make completely new software (like eltrans) for elive without zenity. 
I mean, I'm decent with Python 3.x and Tkinter, but...
Actually I even started an eltrans in tkinter when I thought that it was just the program that didn't work and not the server. But I have no idea how I'd login to the server...I was kind of assuming (hoping?) that we'd use GitHub and we'd all just be direct contributors lol, plus it didn't really get that far, but I can pick back up on it if it sounds good?
Zenity shouldn't be touched in any way .... it isn't gnome-shell dependent.
then why were a bunch of elive tools removed? Like usb-bootable-elive and eltrans?
because of other dependencies
basically you need to add the devuan repositories and follow their howtos about how to switch to non-systemd, after the few "main" packages that depends on systemd are replaced by the ones in devuan you could be able to finish the switch without the things removed
about elive-tools or zenity, its because depends on another that depends on another that depends on systemd
I think we should need a howto about it 
1 Like
Ok so now we have an amazing and extent howto:
Those who wants to switch to removing systemd can do it following it, it should be pretty stable and not breaking anything (amazing!)
Maybe it can be included in the installer of Elive in the future, if enough people betatest it
as you can see, it includes a good SEO title so maybe it catches some good amount of searches in google for people wanting to switch, and, it should be fully compatible with debian systems
2 Likes
