Tutorial How I Got EliveOS Start Time Down From 5 mins+ To 10 Seconds - Wizards Corner

[wizardfromoz]

This tutorial is for Intermediate to Advanced Users. Be warned!

In my quest for finding for users lightweight Distros for low-spec computers, I decided a few days ago to install Elive.

It's based on Debian and runs systemd, and the version I downloaded was at Debian 12.12 'Bookworm'.

It installed successfully, but once I rebooted, I hit a stumbling block.

It would take between 5 mins 6 seconds and 5 mins 11 seconds to get to the Login Screen!


After 2 instances of this behaviour, I decided "Right, what's up?" so on the 3rd boot, at my grub menu, I pressed 'e' to edit the startup parameters and changed "quiet splash" to "noquiet nosplash".

As the output spooled, I saw the culprit to be

eliveinstalledsystem.service

Once into the distro, I took my first three steps, as is my wont, of

1. Enabling my software firewall via sudo ufw enable
2. Installing and setting up Timeshift and
3. Taking a Timeshift snapshot of the freshly installed distro.


I then ran systemd-analyze, systemd-analyze blame and systemd-analyze critical-chain to confirm to confirm that

eliveinstalledsystem.service

was the impediment.

I took steps to stop the service, and to disable the service, and ran sudo systemctl daemon-reload, but on rebooting, same problem.

I located the service, and as a safeguard, copied it to my /home/chris/Documents and then deleted it, reloaded the daemons and rebooted.

Same problem, it found it.

I took a Timeshift snapshot and deleted all traces of the service, and rebooted, and guess what?

I was at the login screen in 10 seconds.

That service I mentioned, eliveinstalledsystem.service, had content as in the Spoiler below (click to open, click to close), and the fly in the ointment was the line near the bottom

TimeoutSec=5min

Spoiler: Service Content

# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/eliveinstalledsystem
Description=LSB: Configure Elive Installer
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
Before=lightdm.service
Before=entrance.service
Before=slim.service
Before=graphical.service
Before=getty.service
Before=getty.target
Before=[email protected]
Before=enlightenment.service
After=remote-fs.target
After=network-manager.service
After=console-setup.service
After=dbus.service
After=urfkill.service
After=vboxweb.service
After=virtualbox.service
After=smartmontools.service
After=cups.service
After=cups-browsed.service
After=inetd.service
After=networking.service
After=network-online.target
After=inetd.service
After=keymap.service
After=udev.service
After=fail2ban.service
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/eliveinstalledsystem start
ExecStop=/etc/init.d/eliveinstalledsystem stop

So irrespective of what might be designed for the service to do, it was going to add 5 minutes to my start time.

Not on my watch.

Although the first line had said

# Automatically generated by systemd-sysv-generator

I found that once I deleted the service, reloaded the daemons and rebooted, it did not recreate itself.

For several days now I have been tweaking Elive, adding software and so on, with no adverse effects.

You may not ever encounter such dramas (and I hope you don't), but if you do, do take a look at the services and determine what is necessary and what is not.

To our keen Helpers, I will say this - although Elive is quite thrifty in its RAM consumption (for me typically 650 Mib to 1.2 Gib), I would in no way recommend it to a Newbie; they will find it very difficult, and it may put them off Linux rather than win them over.

Enjoy your Linux

Wizard

 

[Trml]

Good on you, Wizard! Thanks for sharing your experience with it.

Please allow me to suggest an alternative way to deleting is to use systemctl mask xyz.service. It yields two advantages: First, you can unmask the service again without scrambling through archives or timeshifts. Second, a package update may re-install the service file, but the masking takes precedence.

I figured this alternative as preferred method after a distro (Arch, btw) decided to install a new service that phones home at frequent intervals without explicitly telling me, the user, about its existence. It kept creeping in with new package releases, but conceded being masked.

 

[f33dm3bits]

Nice write up, although I've never heard of EliveOS. I've never seen a boot time of 5 min on a system, usually around a minute or a few seconds more.

 

[wizardfromoz]

Thanks @Trml for the masking option suggestion. I knew of it but did not try it after the stop, disable and reload process did not work.

 

[Condobloke]

I have just completed using the same approach (systemd-analyze blame etc) to find the fly in the ointment for my sometimes ponderous startup......not slow, but certainly longer than this impatient sole wishes to wait.

The fly came in the form of :: fstrim.d.......at 45 seconds .....that is where the wait time was.

After running :

systemctl stop fstrim.timer

and

systemctl disable fstrim.timer

....the overall boot up time has been reduced by approx. 38 seconds



I believe the ssd will continue to run trim commands, without any intervention from me

 

[osprey]

I have just completed using the same approach (systemd-analyze blame etc) to find the fly in the ointment for my sometimes ponderous startup......not slow, but certainly longer than this impatient sole wishes to wait.

The fly came in the form of :: fstrim.d.......at 45 seconds .....that is where the wait time was.

After running :

systemctl stop fstrim.timer

and

systemctl disable fstrim.timer

....the overall boot up time has been reduced by approx. 38 seconds



I believe the ssd will continue to run trim commands, without any intervention from me

Normally fstrim runs around once a week by default in a lot of distros. Here for example, the default is once a week as shown in the unit file:

[~]$ systemctl cat fstrim.timer
# /usr/lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused filesystem blocks once a week
Documentation=man:fstrim
ConditionVirtualization=!container
ConditionPathExists=!/etc/initrd-release

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true
RandomizedDelaySec=100min

[Install]
WantedBy=timers.target

The fstrim.service is a static unit, so it can't be enabled or disabled, rather, it's controlled or activated by the fstrim.timer file above:

[~]$ systemctl status fstrim.service
○ fstrim.service - Discard unused blocks on filesystems from /etc/fstab
     Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static)
     Active: inactive (dead)
TriggeredBy: ● fstrim.timer
       Docs: man:fstrim(8)

One can check if the fstrim.timer is enabled:

[~]$ systemctl status fstrim.timer
● fstrim.timer - Discard unused filesystem blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; preset: enabled)
     Active: active (waiting) since Wed 2025-12-17 07:28:37 AEDT; 15h ago
 Invocation: 05a38a0ca47d454c971cf0775a6407d0
    Trigger: Mon 2025-12-22 01:25:32 AEDT; 4 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim

Dec 17 07:28:37 min systemd[1]: Started fstrim.timer - Discard unused filesystem blocks once a week

It's unwise to not trim, e.g. disable the timer, which would prevent fstrim from doing its work, though one could run fstrim manually if they didn't want to have systemd run it. Fstrim basically lets the solid state drive know which blocks can be used again because files have been deleted so the space is available. If the solid state drive isn't informed, it has to do lots of extra work which is why the time lapse is greater without trimming. That's not a technical description, but captures the spirit of it I think. I can't say why your machine took a long time to boot because of fstrim, but speculatively, I guess if one boots just before fstrim is about to do its work, a longer time lapse might occur. Just a guess.

 

[Condobloke]

Normally fstrim runs around once a week by default in a lot of distros.

I have a memory of manually installing something of this nature, mainly as a "try it and see what happens" approach.

I know....not generally advised..... but such is my nature. I will do these things occasionally, with the comforting thought that Timeshift will haul it me out of trouble if things go south-- plus I have a rescuezilla image as well.....and if things really hit the fan, reinstall. (Thank the heavens the OS is free!)

I use :

sudo fstrim --all

...once a week as part of my routine...regardless of what else has been done/not done