You are not logged in.

#1 2024-10-05 15:53:45

novice
Member
Registered: 2020-01-30
Posts: 61

SOLVED. Longer boot time with Boron.

Hi guys
I've been using Lithium for a couple of years and just made the change to Boron. I love it, apart from one thing: it's taking a lot longer to boot up then Lithium. I don't know much about Linux or it's boot process, but when it gets to the point where it says 'Loading initial ramdisk', it's then about 30 seconds before it moves on, whereas with Lithium it was only a couple of seconds. It's not a big problem, just an annoyance, but I just wondered if there was any way to speed it up?
There haven't been any changes hardware wise, it's the same machine. I didn't notice any error messages during the installation, and everything seems to be running just fine.
Cheers

Last edited by novice (2024-10-08 12:03:25)

Offline

#2 2024-10-05 16:42:21

unklar
Back to the roots 1.9
From: #! BL
Registered: 2015-10-31
Posts: 2,695

Re: SOLVED. Longer boot time with Boron.

This can have many causes.
Please show

lsblk -fp

and

cat /etc/fstab

Offline

#3 2024-10-05 20:07:25

novice
Member
Registered: 2020-01-30
Posts: 61

Re: SOLVED. Longer boot time with Boron.

Thanks unklar

First one

NAME FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
/dev/sda
                                                                            
├─/dev/sda1
│    ext4   1.0         683883c9-dd98-4ba4-84ca-57b7315eece9   89.3G     7% /
├─/dev/sda2
│                                                                           
└─/dev/sda5
     swap   1           c8f820fe-1646-4924-ac83-0cc145f7645f                [SWAP]
/dev/sdb
                                                                            
├─/dev/sdb1
│    ntfs         WindowsXP
│                       841090A310909DAC                                    
├─/dev/sdb2
│                                                                           
└─/dev/sdb5
     ntfs               140CFC570CFC3578                        184G    61% /mnt/140CFC570CFC3578
/dev/sdc
                                                                            
├─/dev/sdc1
│    ntfs               2840338B40335EAE                                    
├─/dev/sdc2
│                                                                           
└─/dev/sdc5
     ntfs               2A8C01D98C01A105                                    
/dev/sr0
                                                                            
/dev/sr1

And second

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=683883c9-dd98-4ba4-84ca-57b7315eece9 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=c8f820fe-1646-4924-ac83-0cc145f7645f none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/sr1        /media/cdrom1   udf,iso9660 user,noauto     0       0
/dev/disk/by-uuid/140CFC570CFC3578 /mnt/140CFC570CFC3578 auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Data 0 0

Offline

#4 2024-10-06 12:45:46

unklar
Back to the roots 1.9
From: #! BL
Registered: 2015-10-31
Posts: 2,695

Re: SOLVED. Longer boot time with Boron.

I have not used Windows ntfs for 15 years.

What stands out is this line:

/dev/disk/by-uuid/140CFC570CFC3578 /mnt/140CFC570CFC3578 auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Data 0 0

First, there is a missing comma (auto nosiud) and the 'type' is not specified. Linux can't do a 'dump pass' on Windows either (?).
Unusual for me to mount a data(?) partition ntfs3 to /mnt with its UUID, 'automatically' with system boot.

Why is no mount point created under /media/Data as usual?
And, then in the fstab e.g.

# file_system    mount_point     type         options                   dump pass
UUID=140CFC570CFC3578 /media/Data ntfs3  auto,nofail,nodev,noexec,windows_names

noexec is better (more secure) than nosuid
----------------------
Before you tackle this, also ask systemd for hints as to why the system takes so long to boot (the fstab does not have to be the sole cause):

systemd-analyze critical-chain
systemd-analyze
systemd-analyze blame | head

Last edited by unklar (2024-10-06 12:47:36)

Offline

#5 2024-10-06 15:01:05

novice
Member
Registered: 2020-01-30
Posts: 61

Re: SOLVED. Longer boot time with Boron.

Hi
It's been a few years now since I've used Windows, I might boot it up occasionally for old times sake smile  When I originally set this computer up (it's old) it just had the two drives. I had Windows on both. One was for daily use and the other was just for gaming. When I switched to Linux a got an SSD to put it on and have just never bothered to format the other drives. I don't have any kind of dual boot or anything. If I want to run Windows I just boot into that drive from the BIOS.
That line you ask about was inserted by gnome-disks. I put all my data on that partition so I wanted it mounted at start, and I don't know enough to do that manually. I've just run lsblk again to make sure I hadn't done it copying and it's not putting that comma in.
Anyway, here's the other info you wanted:

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @10.155s
└─multi-user.target @10.154s
  └─cups-browsed.service @10.154s
    └─network-online.target @10.136s
      └─NetworkManager-wait-online.service @3.790s +6.345s
        └─NetworkManager.service @3.674s +112ms
          └─dbus.service @3.565s +68ms
            └─basic.target @3.550s
              └─sockets.target @3.549s
                └─uuidd.socket @3.549s
                  └─sysinit.target @3.546s
                    └─systemd-sysctl.service @3.536s +9ms
                      └─systemd-modules-load.service @357ms +3.155s
                        └─systemd-journald.socket @334ms
                          └─-.mount @292ms
                            └─-.slice @292ms
Startup finished in 6.609s (kernel) + 10.194s (userspace) = 16.804s 
graphical.target reached after 10.155s in userspace.
6.345s NetworkManager-wait-online.service
3.155s systemd-modules-load.service
2.527s dev-sda1.device
2.323s udisks2.service
2.249s lvm2-monitor.service
 820ms mnt-140CFC570CFC3578.mount
 802ms apparmor.service
 727ms systemd-journal-flush.service
 710ms systemd-udevd.service
 661ms nvidia-persistenced.service

Offline

#6 2024-10-06 16:47:12

unklar
Back to the roots 1.9
From: #! BL
Registered: 2015-10-31
Posts: 2,695

Re: SOLVED. Longer boot time with Boron.

Thanks!

systemd looks good
so, is it the fstab

You can first comment out the entry in question (#), save it and then restart to see if the 'wait times' have disappeared.

Offline

#7 2024-10-06 17:05:39

novice
Member
Registered: 2020-01-30
Posts: 61

Re: SOLVED. Longer boot time with Boron.

No difference with that commented out. I should have known it couldn't be that, because it was doing it straight after install before I'd changed anything.

Offline

#8 2024-10-08 12:03:00

novice
Member
Registered: 2020-01-30
Posts: 61

Re: SOLVED. Longer boot time with Boron.

I just want to give an update on this. I have tried all sorts to solve this problem. I tried installing plain Debian to see if it was something to do with Boron, but that had the same issue. I tried Lithium again and that didn't have the issue. So I put Boron back on from an image I had made, and it worked perfectly. Tried installing again and same problem. So it looks like the Debian 12 installer doesn't like my system, or my system doesn't like the Debian 12 installer. Reinstalling an image of my system, which has this problem, from a Clonezilla backup makes it work. I can't understand how that can happen, but it does. I'll mark this as solved now.

Offline

Board footer

Powered by FluxBB