Jump to content


Sparky Linux


  • Please log in to reply
73 replies to this topic

#26 OFFLINE   V.T. Eric Layton

V.T. Eric Layton

    Nocturnal Slacker

  • Forum Admins
  • 21,544 posts

Posted 06 September 2018 - 10:28 AM

Heh! I'm old. I remember that group. Here's a good one they did back in the day...

https://youtu.be/Wqw1MGEHKNE

#27 OFFLINE   raymac46

raymac46

    Discussion Deity

  • Forum MVP
  • 3,873 posts

Posted 12 September 2018 - 06:15 PM

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.
Posted Image

Registered Linux User 445659

#28 OFFLINE   Hedon James

Hedon James

    Topic Cop

  • Members
  • PipPipPipPipPipPipPip
  • 876 posts

Posted 12 September 2018 - 07:38 PM

It does boot slow.  I was googling and saw references to possibly being systemd related, or possibly the 4.18 kernel.  I haven't run it down yet, but a summary glance made me think it applies to me.  Perhaps you also?

I noticed that Siduction has problems with booting kernel 4.18 in Virtualbox.  They're recommended workaround is to boot with 4.17 kernel.  I'll probably start there and see if it makes a difference.  If not, I'll move on to systemd.  I think I remember a cli command

systemd-analyze blame

to determine where the bottleneck/roadblock is.  I think I remember that the "daily update" service is starting way too quickly/early in the init process, and by delaying the check for updates to 5 minutes after boot (or something reasonably similar) solved the problem.  Just haven't got to it yet.  But it's not uncommon in Debian-based Sid and/or Testing distros.  FWIW...

Edited by Hedon James, 12 September 2018 - 07:47 PM.


#29 OFFLINE   raymac46

raymac46

    Discussion Deity

  • Forum MVP
  • 3,873 posts

Posted 12 September 2018 - 08:39 PM

ray@ray-pc:~$ systemd-analyze
Startup finished in 3.223s (kernel) + 2.799s (userspace) = 6.022s
graphical.target reached after 2.781s in userspace
ray@ray-pc:~$

It seems to take longer than this. I wonder if there is some issue with the display manager on boot? This is with the 4.18 kernel.

Edited by raymac46, 12 September 2018 - 08:40 PM.

Posted Image

Registered Linux User 445659

#30 OFFLINE   raymac46

raymac46

    Discussion Deity

  • Forum MVP
  • 3,873 posts

Posted 12 September 2018 - 08:56 PM

No it isn't lightdm I don't think. I removed autologin and then I just sat at the login screen for a minute or so after userID and password entry, before the display came up.

https://sparkylinux....pic,4554.0.html

Edited by raymac46, 12 September 2018 - 09:18 PM.

Posted Image

Registered Linux User 445659

#31 OFFLINE   securitybreach

securitybreach

    CLI Phreak

  • Forum Admins
  • 24,026 posts

Posted 13 September 2018 - 08:23 AM

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).
Posted ImagePosted Image Posted Image
CNI Radio/G+ Profile/Configs/PGP Key/comhack π

"Do you begin to see, then, what kind of world we are creating? It is the exact opposite of the stupid hedonistic Utopias that the old reformers imagined. A world of fear and treachery and torment, a world of trampling and being trampled upon, a world which will grow not less but more merciless as it refines itself. Progress in our world will be progress toward more pain." -George Orwell, 1984

#32 OFFLINE   raymac46

raymac46

    Discussion Deity

  • Forum MVP
  • 3,873 posts

Posted 13 September 2018 - 08:59 AM

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.
Posted Image

Registered Linux User 445659

#33 OFFLINE   Hedon James

Hedon James

    Topic Cop

  • Members
  • PipPipPipPipPipPipPip
  • 876 posts

Posted 13 September 2018 - 09:10 AM

@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.siduct...hp?topic=7307.0

#34 OFFLINE   sunrat

sunrat

    Thread Kahuna

  • Forum Moderators
  • 5,712 posts

Posted 13 September 2018 - 09:53 AM

View PostHedon James, on 13 September 2018 - 09:10 AM, said:

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.

View Postraymac46, on 12 September 2018 - 06:15 PM, said:

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.
registered Linux user number 324659  ||    The importance of Reading The *Fine* Manual! :D
Posted ImagePosted ImagePosted ImagePosted Image
For the things we have to learn before we can do them, we learn by doing them.

#35 OFFLINE   Hedon James

Hedon James

    Topic Cop

  • Members
  • PipPipPipPipPipPipPip
  • 876 posts

Posted 13 September 2018 - 10:52 AM

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.

#36 OFFLINE   securitybreach

securitybreach

    CLI Phreak

  • Forum Admins
  • 24,026 posts

Posted 13 September 2018 - 11:35 AM

Ah ok, thanks Hedon.

View PostHedon James, on 13 September 2018 - 10:52 AM, said:

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

Posted ImagePosted Image Posted Image
CNI Radio/G+ Profile/Configs/PGP Key/comhack π

"Do you begin to see, then, what kind of world we are creating? It is the exact opposite of the stupid hedonistic Utopias that the old reformers imagined. A world of fear and treachery and torment, a world of trampling and being trampled upon, a world which will grow not less but more merciless as it refines itself. Progress in our world will be progress toward more pain." -George Orwell, 1984

#37 OFFLINE   securitybreach

securitybreach

    CLI Phreak

  • Forum Admins
  • 24,026 posts

Posted 13 September 2018 - 11:37 AM

I did find this;

Quote

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
Posted ImagePosted Image Posted Image
CNI Radio/G+ Profile/Configs/PGP Key/comhack π

"Do you begin to see, then, what kind of world we are creating? It is the exact opposite of the stupid hedonistic Utopias that the old reformers imagined. A world of fear and treachery and torment, a world of trampling and being trampled upon, a world which will grow not less but more merciless as it refines itself. Progress in our world will be progress toward more pain." -George Orwell, 1984

#38 OFFLINE   raymac46

raymac46

    Discussion Deity

  • Forum MVP
  • 3,873 posts

Posted 13 September 2018 - 12:27 PM

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.
Posted Image

Registered Linux User 445659

#39 OFFLINE   Hedon James

Hedon James

    Topic Cop

  • Members
  • PipPipPipPipPipPipPip
  • 876 posts

Posted 13 September 2018 - 01:15 PM

View Postsecuritybreach, on 13 September 2018 - 11:35 AM, said:


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:


Quote

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!

#40 OFFLINE   Hedon James

Hedon James

    Topic Cop

  • Members
  • PipPipPipPipPipPipPip
  • 876 posts

Posted 13 September 2018 - 01:48 PM

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:


Quote

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:


Quote

          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?

#41 OFFLINE   securitybreach

securitybreach

    CLI Phreak

  • Forum Admins
  • 24,026 posts

Posted 13 September 2018 - 02:52 PM

View PostHedon James, on 13 September 2018 - 01:48 PM, said:

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:


Quote

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:


Quote

  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.
Posted ImagePosted Image Posted Image
CNI Radio/G+ Profile/Configs/PGP Key/comhack π

"Do you begin to see, then, what kind of world we are creating? It is the exact opposite of the stupid hedonistic Utopias that the old reformers imagined. A world of fear and treachery and torment, a world of trampling and being trampled upon, a world which will grow not less but more merciless as it refines itself. Progress in our world will be progress toward more pain." -George Orwell, 1984

#42 OFFLINE   Hedon James

Hedon James

    Topic Cop

  • Members
  • PipPipPipPipPipPipPip
  • 876 posts

Posted 13 September 2018 - 03:03 PM

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 by Hedon James, 13 September 2018 - 03:06 PM.


#43 OFFLINE   raymac46

raymac46

    Discussion Deity

  • Forum MVP
  • 3,873 posts

Posted 13 September 2018 - 03:06 PM

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.
Posted Image

Registered Linux User 445659

#44 OFFLINE   raymac46

raymac46

    Discussion Deity

  • Forum MVP
  • 3,873 posts

Posted 13 September 2018 - 03:12 PM

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.
Posted Image

Registered Linux User 445659

#45 OFFLINE   Hedon James

Hedon James

    Topic Cop

  • Members
  • PipPipPipPipPipPipPip
  • 876 posts

Posted 13 September 2018 - 03:20 PM

View Postraymac46, on 13 September 2018 - 03:06 PM, said:

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.

#46 OFFLINE   Hedon James

Hedon James

    Topic Cop

  • Members
  • PipPipPipPipPipPipPip
  • 876 posts

Posted 13 September 2018 - 03:56 PM

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.  :bangin:

#47 OFFLINE   securitybreach

securitybreach

    CLI Phreak

  • Forum Admins
  • 24,026 posts

Posted 13 September 2018 - 03:58 PM

View PostHedon James, on 13 September 2018 - 03:03 PM, said:

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.
Posted ImagePosted Image Posted Image
CNI Radio/G+ Profile/Configs/PGP Key/comhack π

"Do you begin to see, then, what kind of world we are creating? It is the exact opposite of the stupid hedonistic Utopias that the old reformers imagined. A world of fear and treachery and torment, a world of trampling and being trampled upon, a world which will grow not less but more merciless as it refines itself. Progress in our world will be progress toward more pain." -George Orwell, 1984

#48 OFFLINE   Hedon James

Hedon James

    Topic Cop

  • Members
  • PipPipPipPipPipPipPip
  • 876 posts

Posted 13 September 2018 - 04:14 PM

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

#49 OFFLINE   raymac46

raymac46

    Discussion Deity

  • Forum MVP
  • 3,873 posts

Posted 13 September 2018 - 04:52 PM

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.
Posted Image

Registered Linux User 445659

#50 OFFLINE   raymac46

raymac46

    Discussion Deity

  • Forum MVP
  • 3,873 posts

Posted 14 September 2018 - 10:19 AM

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.
Posted Image

Registered Linux User 445659




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users