Sparky Linux

[securitybreach]

Unless its a bug with virtualbox, it has nothing to do with 4.18 and systemd as I have the same kernel version on 5 machines and 4 vms (virt-manager).

[raymac46]

I have not installed Sparky on the rails, only in VirtualBox and this is the LXQt version 5.3 I'm running. So I think you are right Josh - probably a VBox issue.

[Hedon James]

@Ray - that is the exact same issue I experience. Haven't run it down yet because I usually "save current state" when exiting Virtualbox. I think I can rule out the kernel though, as Sparky updated the kernel last night on my VM...i had previously experienced the issue on kernel 4.17, but as of last night, the issue is still there in kernel 4.18. Several posts on the Sparky forum point to systemd-analyze time and then systemd-analyze blame as the first step in troubleshooting. systemd-analyze time seems to suggest the kernel boot time is fine, approx 4 secs, with userspace taking anywhere from 30 secs to 3 mins! A post by pavroo, one of the Sparky devs, seems to suggest a problem with etc/fstab entries not matching UUIDs (going by memory here). Not sure if that applies in Virtualbox and if does, not sure how that happened from the recommended defaults during installation.

 

@SB - I only referenced the 4.18 kernel as there is definitely a problem with that kernel in Siduction. The 4.18 kernel in Siduction will NOT boot in a VirtualBox VM. There's a thread about it on Siduction forums, recommending using the 4.17 kernel as a workaround to boot. However, as I type this, I'm thinking it's probably specific to Siduction, as Siduction rolls its own kernels: UPDATE: while surfing for link to copy/paste, this bug is now resolved in Siduction. Problem was a mis-match between VB guest utilities and upgraded version of VirtualBox. Guest utilities in kernel 4.18 were updated/upgraded and everything is good again apparently. This further confirms (in MY mind, at least, that Ray and my slow-boot issues are not kernel related).

 

https://forum.siduction.org/index.php?topic=7307.0

[sunrat]

Problem was a mis-match between VB guest utilities and upgraded version of VirtualBox.

I don't get why distros ship with Guest Additions as I've experienced several issues with mismatches. It seems to always be better to install Guest Additions of the same version as the VBox they are running in.

 

I continue to run Sparky Linux in Virtual Box. Updates are going well from Debian Testing. One problem I have is that on bootup the display doesn't come up readily - black screen. I have to right click after a bit and then the cursor and desktop appear.

I just downloaded the testing version and loaded it live in VBox in siduction. It took maybe half a minute for the black screen to give way to desktop but it seems to work well, no prompting needed. Didn't try installing or updating.

[Hedon James]

just ran the

systemd-analyze blame

command and looks like exim4.service is the primary culprit for the most recent boot, clocking in at over 27 seconds of the 32 seconds for userspace. A noticeable PITA during boot, but mild compared to some of my other slow boots ranging from 1-3 mins.

 

Not sure what exim4 is....looks like it has something to do with MTA, something with mail delivery. Found a post for Debian to debug whatever is happening with exim...

exim4 -v

on the command line, but results report that exim4 is not installed. So it appears THAT is the problem...systemd is trying to start a service that doesn't exist, until it times out, gives up, and moves on. So I would guess that my potential solutions are to install exim4, or to prevent systemd from wasting time on that non-existent service (mask it?). I'm inclined to just install exim4 to see what happens, but I don't know what exim4 is? Never heard of it before!

 

If it's a standard underlying service/protocol, why wasn't it installed during initial installation? And if it wasn't, why is systemd looking for it to the point of exhaustion? Anyone know what exim4 is? Man exim4 wasn't very enlightening to this layman.

[securitybreach]

Ah ok, thanks Hedon.

 

just ran the

systemd-analyze blame

command and looks like exim4.service is the primary culprit for the most recent boot, clocking in at over 27 seconds of the 32 seconds for userspace. A noticeable PITA during boot, but mild compared to some of my other slow boots ranging from 1-3 mins.

 

Not sure what exim4 is....looks like it has something to do with MTA, something with mail delivery. Found a post for Debian to debug whatever is happening with exim...

exim4 -v

on the command line, but results report that exim4 is not installed. So it appears THAT is the problem...systemd is trying to start a service that doesn't exist, until it times out, gives up, and moves on. So I would guess that my potential solutions are to install exim4, or to prevent systemd from wasting time on that non-existent service (mask it?). I'm inclined to just install exim4 to see what happens, but I don't know what exim4 is? Never heard of it before!

 

If it's a standard underlying service/protocol, why wasn't it installed during initial installation? And if it wasn't, why is systemd looking for it to the point of exhaustion? Anyone know what exim4 is? Man exim4 wasn't very enlightening to this layman.

 

Did you try

systemctl disable exim

[securitybreach]

I did find this;

 

Debian comes by default with exim mail server, you can configure how the mailserver should work with the command

dpkg-reconfigure exim4-config

if you don't want the server to send remote emails you can choose the setting

local delivery only; not on a network

https://serverfault....mail-completely

[raymac46]

Here is my systemd hall of shame:

 

ray@ray-pc:~$ systemd-analyze blame
	  7.260s apt-daily.service
	  1.158s networking.service
	  1.157s udisks2.service
	  1.113s exim4.service
	  1.042s ModemManager.service
	   987ms NetworkManager.service
	   808ms dev-sda1.device
	   781ms avahi-daemon.service
	   757ms wpa_supplicant.service
	   751ms rtkit-daemon.service
	   669ms NetworkManager-wait-online.service
	   649ms acpi-support.service
	   644ms rsyslog.service
	   630ms systemd-logind.service
	   430ms apparmor.service
	   415ms lm-sensors.service
	   409ms pppd-dns.service
	   406ms console-kit-log-system-start.service

 

But this doesn't account for nearly the amount of time before the display shows up.

[Hedon James]

 

Did you try

systemctl disable exim

 

In Sparky it's exim4, and that incantation indicates insufficient permissions. So

sudo systemctl disable exim4

yielded this output:

 

 

exim4.service is not a native service, redirecting to systemd-sysv-install.

Executing: /lib/systemd/systemd-sysv-install disable exim4

insserv: warning: current start runlevel(s) (empty) of script `exim4' overrides LSB defaults (2 3 4 5).

insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `exim4' overrides LSB defaults (0 1 6).

 

WTH is this? I'll try the dpkg reconfigure, but if exim4 isn't installed, I fail to see how that will help. Now I'm REALLY confused!

[Hedon James]

sudo dpkg-reconfigure exim4

allowed reconfiguration of the exim package, where I chose recommended defaults at every step.

 

Rebooted, but still took a LONG time to get the desktop GUI. I'm estimating 1+ minutes. The login manager is almost instantaneous, but 1+ minute for the actual desktop. systemd-analyze time shows MUCH improvement:

 

 

Startup finished in 3.285s (kernel) + 6.057s (userspace) = 9.343s

graphical.target reached after 6.049s in userspace

 

with systemd-analyze blame showing no further red flags, IMO:

 

 

3.803s dev-sda1.device

3.166s udisks2.service

3.115s ModemManager.service

2.353s NetworkManager.service

2.280s console-kit-log-system-start.service

2.201s networking.service

2.137s rtkit-daemon.service

2.120s wpa_supplicant.service

2.114s acpi-support.service

2.097s pppd-dns.service

2.077s avahi-daemon.service

1.992s lm-sensors.service

1.990s virtualbox-guest-utils.service

1.978s systemd-logind.service

1.976s atd.service

1.965s rsyslog.service

928ms apparmor.service

786ms systemd-udevd.service

478ms alsa-restore.service

436ms ntp.service

385ms console-kit-daemon.service

383ms polkit.service

378ms systemd-modules-load.service

354ms run-rpc_pipefs.mount

352ms plymouth-quit-wait.service

352ms lightdm.service

350ms keyboard-setup.service

321ms systemd-tmpfiles-setup.service

306ms rpcbind.service

230ms upower.service

220ms systemd-sysusers.service

210ms dev-hugepages.mount

210ms packagekit.service

210ms dev-mqueue.mount

207ms systemd-remount-fs.service

204ms plymouth-read-write.service

187ms console-setup.service

186ms nfs-config.service

179ms systemd-udev-trigger.service

157ms sys-kernel-debug.mount

127ms systemd-journald.service

114ms ufw.service

98ms user@1000.service

89ms systemd-tmpfiles-setup-dev.service

83ms systemd-user-sessions.service

80ms kmod-static-nodes.service

63ms plymouth-start.service

32ms systemd-random-seed.service

27ms systemd-journal-flush.service

27ms systemd-update-utmp.service

23ms systemd-sysctl.service

11ms rc-local.service

9ms sys-fs-fuse-connections.mount

6ms systemd-update-utmp-runlevel.service

 

Curiously, I note that the systemd-analyze time shows "graphical.target reached after 6.049s in userspace". WHAT is the graphical target? Is it the GUI login manager (lightdm on Sparky), or the GUI desktop?

 

I've never seen this behavior in Virtualbox distros before, with the exceptions of Siduction and Spark; both recent additions in my virtual distro farm, and both based on Debian Unstable/Testing. I'm starting to lean towards a VirtualBox bug, or perhaps a bug in the VirtualBox guest additions, both of which are modules built into the Sid and Sparky kernels.

 

I'm running VirtualBox 5.1.0, downloaded from VB website, with 5.1.0 extension pack. Not the latest & greatest, but it's been supremely stable for me, and I'm reluctant to upgrade stable software for the sake of an upgrade, unless there's a new feature I'm looking for. Perhaps this is a mis-match of newer distro-supplied guest additions in the kernel, installed in an older version of VB.

 

What version of VB you running Ray?

[securitybreach]

sudo dpkg-reconfigure exim4

allowed reconfiguration of the exim package, where I chose recommended defaults at every step.

 

Rebooted, but still took a LONG time to get the desktop GUI. I'm estimating 1+ minutes. The login manager is almost instantaneous, but 1+ minute for the actual desktop. systemd-analyze time shows MUCH improvement:

 

 

Startup finished in 3.285s (kernel) + 6.057s (userspace) = 9.343s

graphical.target reached after 6.049s in userspace

 

with systemd-analyze blame showing no further red flags, IMO:

 

 

3.803s dev-sda1.device

3.166s udisks2.service

3.115s ModemManager.service

2.353s NetworkManager.service

2.280s console-kit-log-system-start.service

2.201s networking.service

2.137s rtkit-daemon.service

2.120s wpa_supplicant.service

2.114s acpi-support.service

2.097s pppd-dns.service

2.077s avahi-daemon.service

1.992s lm-sensors.service

1.990s virtualbox-guest-utils.service

1.978s systemd-logind.service

1.976s atd.service

1.965s rsyslog.service

928ms apparmor.service

786ms systemd-udevd.service

478ms alsa-restore.service

436ms ntp.service

385ms console-kit-daemon.service

383ms polkit.service

378ms systemd-modules-load.service

354ms run-rpc_pipefs.mount

352ms plymouth-quit-wait.service

352ms lightdm.service

350ms keyboard-setup.service

321ms systemd-tmpfiles-setup.service

306ms rpcbind.service

230ms upower.service

220ms systemd-sysusers.service

210ms dev-hugepages.mount

210ms packagekit.service

210ms dev-mqueue.mount

207ms systemd-remount-fs.service

204ms plymouth-read-write.service

187ms console-setup.service

186ms nfs-config.service

179ms systemd-udev-trigger.service

157ms sys-kernel-debug.mount

127ms systemd-journald.service

114ms ufw.service

98ms user@1000.service

89ms systemd-tmpfiles-setup-dev.service

83ms systemd-user-sessions.service

80ms kmod-static-nodes.service

63ms plymouth-start.service

32ms systemd-random-seed.service

27ms systemd-journal-flush.service

27ms systemd-update-utmp.service

23ms systemd-sysctl.service

11ms rc-local.service

9ms sys-fs-fuse-connections.mount

6ms systemd-update-utmp-runlevel.service

 

Curiously, I note that the systemd-analyze time shows "graphical.target reached after 6.049s in userspace". WHAT is the graphical target? Is it the GUI login manager (lightdm on Sparky), or the GUI desktop?

 

I've never seen this behavior in Virtualbox distros before, with the exceptions of Siduction and Spark; both recent additions in my virtual distro farm, and both based on Debian Unstable/Testing. I'm starting to lean towards a VirtualBox bug, or perhaps a bug in the VirtualBox guest additions, both of which are modules built into the Sid and Sparky kernels.

 

I'm running VirtualBox 5.1.0, downloaded from VB website, with 5.1.0 extension pack. Not the latest & greatest, but it's been supremely stable for me, and I'm reluctant to upgrade stable software for the sake of an upgrade, unless there's a new feature I'm looking for. Perhaps this is a mis-match of newer distro-supplied guest additions in the kernel, installed in an older version of VB.

 

What version of VB you running Ray?

 

Graphical target is referring to tty. I get the same thing and I use startx to start my environment. I have a feeling that this has nothing to do with systemd or the boot process and it is instead part of the environment startup. I bet if you switched to another gui, you wouldn't get that delay.

[Hedon James]

switched to another GUI? As in LXDE, or XFCE, etc... Or as in another login manager, such as LXDE, or SDDM?

 

I still question guest addtions in kernen/virtualbox mis-match; but your suggestions are equally plausible. Referencing my Siduction and Sparky VMs as the only distros I see this in, I note that Siduction uses SDDM to login, while Sparky uses LightDM. Based on that, I'm guessing it's an LXQt config, or guest additions mis-match.

 

Depending on Ray's answer to his version of Virtualbox, can I install guest additions from the 5.1.0 extension pack, and overwrite the guest additions baked into the kernel modules? Or will it prevent me, because the baked-in additions are newer than the VB-supplied additions? If I can do that, and problem still remains, or even if Ray is using most recent version of Virtualbox (5.2.?), I'd say that points squarely to LXQt?!

 

And if that is the case, I wonder why LXQt DE loads so slowly in Siduction and Sparky, but not in Lubuntu (I have LXQt installed on an Lubuntu mini iso that I built up). Lubuntu LXQt loads just fine. Puzzling...

Edited September 13, 2018 by Hedon James

[raymac46]

I have VB 5.2.18.

I'm beginning to think this is a problem with the baked-in guest utils in the kernel and VirtualBox. I have similar systemd-analyze results yet this long delay.

[raymac46]

The only other VM I have running is Ubuntu 18.04 and I did not add in the VB guest utils for it either. It loads OK - not real snappy but not bad. It uses kernel 4.15.0.

[Hedon James]

I have VB 5.2.18.

I'm beginning to think this is a problem with the baked-in guest utils in the kernel and VirtualBox. I have similar systemd-analyze results yet this long delay.

 

looks like the installed virtualbox-guest-utils on MY Sparky is 5.2.18-dfsg-2. I'm going to install the VB-supplied additions and see if I can overwrite the newer version in Sparky. Just to be thorough...

 

If this doesn't solve the issue, I can only conclude that SB is likely correct...some kind of config issue with LXQt and Debian. Not in Lubuntu though...head scratcher.

[Hedon James]

okay, I uninstalled virtualbox-guest-utils in Sparky and re-booted. HORRIBLE! Took even LONGER to boot to desktop. Systemd-analyze tools indicated only 9 seconds(?), but it was many minutes. I re-installed Sparky's guest-utils to restore to prior config. I can only conclude this is an LXQt issue with VirtualBox. And I note that Siduction and Sparking are featuring LXQt 0.13 while Lubuntu features LXQt 0.12. Perhaps there's an explanation in that? Perhaps a regression between versions?

 

If this was happening on bare metal, this would be a deal breaker for LXQt at this time. But it's in VirtualBox and it's not that big of a deal there. I'll suffer through it until the bug is fixed. I'm willing to help troubleshoot fixes, but I've done all I can do at this point. Sorry I wasn't more helpful.

[securitybreach]

switched to another GUI? As in LXDE, or XFCE, etc... Or as in another login manager, such as LXDE, or SDDM?

 

I still question guest addtions in kernen/virtualbox mis-match; but your suggestions are equally plausible. Referencing my Siduction and Sparky VMs as the only distros I see this in, I note that Siduction uses SDDM to login, while Sparky uses LightDM. Based on that, I'm guessing it's an LXQt config, or guest additions mis-match.

 

Depending on Ray's answer to his version of Virtualbox, can I install guest additions from the 5.1.0 extension pack, and overwrite the guest additions baked into the kernel modules? Or will it prevent me, because the baked-in additions are newer than the VB-supplied additions? If I can do that, and problem still remains, or even if Ray is using most recent version of Virtualbox (5.2.?), I'd say that points squarely to LXQt?!

 

And if that is the case, I wonder why LXQt DE loads so slowly in Siduction and Sparky, but not in Lubuntu (I have LXQt installed on an Lubuntu mini iso that I built up). Lubuntu LXQt loads just fine. Puzzling...

 

Gui = Environment not login manager. Perhaps the configuration that they use is a bit slow. I am just blindly guessing as we know that it has nothing to do with systemd as pointed out in systemd-analyze.

[Hedon James]

arrgghhhh....perhaps spoke a moment too soon?

 

after re-installing Sparky's virtualbox-guest-utils, the boot time is just fine. however, the side effect is no full screen resolution...only 1020x780. did a little more searching and it looked like maybe I need virtualbox-guest-x11 to restore native resolution. Boom....extreme delay before desktop is loaded. Looks like virtualbox-guest-x11 is the problem...although I still don't have native resolution available for selection. WTH? My brain is jello...I'll make another run at this later...

[raymac46]

I tried Vmware and although I didn't do much aside from install Sparky it seems to load and run much faster. I think it is a VBox issue for sure.

[raymac46]

VmWare Player is really a PITA compared to VirtualBox. Installing the VmWare Tools is a must in any VM with an older kernel at least. These are similar to the Guest Additions in VBox. The Install is more complicated than it is in VBox as far as I can see. Even after you get the Tools installed I don't see any way to resize the VM to get a full screen aside from choosing the Full Screen Option in the Host. I'm doing that now and it seems OK. Right now I'm running the Stable LXDE version of Sparky Linux in VmWare and it is working well.

[Hedon James]

I believe we can safely state that this problem is an issue with Debian-based version 0.13 of LXQt DE in Virtualbox. Those are the only consistencies across all my VM distros. FWIW...

[raymac46]

Makes sense. Trust me to choose the DE and distro that'll go pear-shaped in VBox.

[Hedon James]

haha! it's still a good test-bed though. If it impresses in VirtualBox, even IF it goes pear-shaped, it will probably go beast-mode on bare metal?!

 

I'm still digging Sparky LXQt rolling! Knock on wood...so far so good!

[Hedon James]

Found something interesting Ray. Boot in recovery mode, so you can see the start process without a Plymouth screen. You can see the boot process "hanging" or being "throttled" at several checkpoints in the boot sequence. Not sure what it means, and certainly don't know what to do about it, but instead of wondering what is causing the boot delays, you can SEE the extreme delays. FWIW...

[raymac46]

Recovery mode was rather unenlightening for me. I saw the early part of the boot process but Sparky zipped through it until I either had to put in the root password or hit Ctrl-D. At this point after Ctrl-D the display manager took over and after I put in user ID and password I just got the login screen for a while until the desktop came up.

[raymac46]

Just for giggles I installed the LXQt desktop on my Thinkpad which runs Debian Stretch. It boots and runs like a champion. Posting from it now. So we can safely say it's a VBox issue.

Edited September 14, 2018 by raymac46

[sunrat]

Let me get clear on this. The problem is only on latest VBox when the guest is updated to 4.18 kernel?

Sparky with 4.16 kernel seems fine on latest VBox. Host siduction has 4.18.6.

[raymac46]

The one that has given slow boots (but works eventually) is Sparky LXQt in VBox with kernel 4.18. I am using latest VBox on Windows 10 host.

[Hedon James]

I experienced this issue booting Sparky LXQt on VirtualBox 5.1.0. Both kernel 4.17 and kernel 4.18 are slow. While I initially installed with 4.16 kernel, I don't know if slow boot was an issue with that kernel, as Sparky was brand new to me and the kernel updated so quickly after initial install. And Sparky has already "cleaned up" the 4.16 kernel residuals, so I can't boot with that.

 

Referencing the chain of posts between Ray and me, Ray has the latest & greatest VirtualBox, while I do not (trailing edge, heheh?).

[Hedon James]

Ray, and anyone else following along who's interested, I've got this problem solved!

 

Cruising the Sparky forums looking for ANYTHING that might yield a clue to slow-booting desktop environments, and found this thread:

https://sparkylinux.org/forum/index.php/topic,4554.0.html

 

It was interesting to me, as it indicated the problem wasn't limited to LXQt, but also found in XFCE. I tried the XFCE solution, with no satisfaction, so re-installed the purged package. Cruised around the forum looking for related entries and found threads discussing

systemd-analyze time

and

systemd-analyze blame

(of which this forum thread discussed extensively) and even some resolved threads indicating that 2 desktops installed on the same Sparky, then removed; and similarly, an UUID entry in fstab in a former dual-boot situation were both culprits in a slow-booting Sparky.

 

I even cruised the Siduction forum, knowing that my Siduction LXQt VM experiences a nearly identical issue. (saw a fella named sunrat on that forum! 'Wazzup!) Siduction forum indicates that a Siduction VM (of any flavor) won't even boot in VB with kernel 4.18, recommending boot with kernel 4.17 as a workaround. This is exactly what I do in Siduction.

 

Coupled with Ray & my personal experiences, this all seems to point squarely at Debian Sid/Testing kernels, IMO, and their interaction with VB. Inasmuch as I continue to be enamored with Sparky, and given that I haven't found any deal-killers (yet?!), I decided to register for the forum and pose the question in that thread. Woke up this morning to an overnight response from pavroo, who is a Sparky dev, which I know from experiences lurking on that forum. He said that the Sparky kernel resolves the VB issue? WHAT? Doesn't Sparky install and boot with its own kernel? Nope...

uname -a

indicates the 4.18.0 kernel is a Debian kernel...likely the same problem kernel in Sid, or derived from the same one, I'd venture a guess.

 

So I poked around in Sparky's APTus application (for Sparky repo packages) and sure enough, in the System category, is an option to "Install Sparky Kernel". Long story short, installed the Sparky kernel, rebooted, and the desktop appears rather quickly! Added bonus, I now have sound and my shared folder with my host system is now visible and mounted in PCManFM-QT! Double added bonus, it appears that the Sparky community (or at least the developer) is active, with good ability to troubleshoot the distro. Another criteria checked off the list for new-distro shopping!

 

So there ya go Ray....I think we were right with kernel/VB issues...and the Sparky dev has provided a solution that works in my rig. While I still have the ever-so-smallest nagging doubt that it "could be a coincidence", this is easily tested. If you're so inclined, would you please do the same with your Sparky VB and verify it works in your installation also?