New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Ubuntu 22.04 LTS slow booting
Hello, hope someone here can help me with this.
I have a Dedicated Server running Ubuntu 22.04.4 LTS OS, It taking a long time rebooting
I did, this two changes in etc/default/grub .. still slow.
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_TIMEOUT=5
Any thing that I can change in grub or other file to speed the booting?
etc/default/grub configuration
GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=lsb_release -i -s 2> /dev/null || echo Debian
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""
Comments
Any chance you got netplan installed? Did result in issues for me and extended the boot time.
Yes, netplan is installed.
dmesg | lesswill show how long each process take.i.e. : my scaleway screw up on init-config network process waiting for ipv4 dhcp response which my vps doesn't have public ipv4 to begin with. modified the dhcp config then it speed things up few seconds than the default config. fortunately I rarely reboot & scaleway uptime were good
root@:~# dmesg | less
[ 0.000000] microcode: microcode updated early to revision 0x28, date = 2019-11-12
[ 0.000000] Linux version 5.15.0-112-generic (buildd@lcy02-amd64-051) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #122-Ubuntu SMP Thu May 23 07:48:21 UTC 2024 (Ubuntu 5.15.0-112.122-generic 5.15.152)
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.15.0-112-generic root=UUID=98f00d96-a7f8-49dd-a742-a0122747be1f ro quiet
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Hygon HygonGenuine
[ 0.000000] Centaur CentaurHauls
[ 0.000000] zhaoxin Shanghai
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000009573efff] usable
[ 0.000000] BIOS-e820: [mem 0x000000009573f000-0x0000000095bbefff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000095bbf000-0x0000000095fbefff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x0000000095fbf000-0x0000000095ffefff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x0000000095fff000-0x0000000095ffffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000096000000-0x000000009fffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000f0000000-0x00000000f7ffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000feb00000-0x00000000feb03fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ffa00000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000085fffffff] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] SMBIOS 2.7 present.
[ 0.000000] DMI: Dell Inc. PowerEdge R220/081N4V, BIOS 1.11.0 09/10/2019
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] tsc: Detected 3392.005 MHz processor
[ 0.000335] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[ 0.000338] e820: remove [mem 0x000a0000-0x000fffff] usable
[ 0.000344] last_pfn = 0x860000 max_arch_pfn = 0x400000000
[ 0.000466] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT
[ 0.001055] last_pfn = 0x96000 max_arch_pfn = 0x400000000
[ 0.007728] found SMP MP-table at [mem 0x000fe1f0-0x000fe1ff]
[ 0.007741] Using GB pages for direct mapping
[ 0.007961] RAMDISK: [mem 0x2ac63000-0x31628fff]
[ 0.007965] ACPI: Early table checksum verification disabled
[ 0.007968] ACPI: RSDP 0x00000000000FE020 000024 (v02 DELL )
[ 0.007972] ACPI: XSDT 0x0000000095FCF188 0000DC (v01 DELL PE_SC3 00000001 01000013)
[ 0.007977] ACPI: FACP 0x0000000095FF7000 00010C (v05 DELL PE_SC3 00000001 DELL 00040000)
[ 0.007982] ACPI: DSDT 0x0000000095FE0000 012362 (v01 DELL PE_SC3 00000000 DELL 00040000)
[ 0.007985] ACPI: FACS 0x0000000095FBD000 000040
[ 0.007987] ACPI: UEFI 0x0000000095FFD000 000236 (v01 DELL PE_SC3 00000001 DELL 00040000)
[ 0.007990] ACPI: UEFI 0x0000000095FFC000 000042 (v01 DELL PE_SC3 00000000 DELL 00040000)
[ 0.007993] ACPI: ASF! 0x0000000095FFB000 0000A5 (v32 DELL PE_SC3 00000001 DELL 00040000)
[ 0.007996] ACPI: ASPT 0x0000000095FFA000 000034 (v07 DELL PE_SC3 00000001 DELL 00040000)
[ 0.007998] ACPI: BOOT 0x0000000095FF9000 000028 (v01 DELL PE_SC3 00000001 DELL 00040000)
[ 0.008001] ACPI: DBGP 0x0000000095FF8000 000034 (v01 DELL PE_SC3 00000001 DELL 00040000)
[ 0.008004] ACPI: HPET 0x0000000095FF6000 000038 (v01 DELL PE_SC3 00000001 DELL 00040000)
[ 0.008006] ACPI: APIC 0x0000000095FF5000 000092 (v03 DELL PE_SC3 00000001 DELL 00040000)
[ 0.008009] ACPI: MCFG 0x0000000095FF4000 00003C (v01 DELL PE_SC3 00000001 DELL 00040000)
[ 0.008012] ACPI: SLIC 0x0000000095FF3000 000176 (v01 DELL PE_SC3 00000001 DELL 00040000)
[ 0.008014] ACPI: SSDT 0x0000000095FDD000 002028 (v01 DELL PE_SC3 00001000 DELL 00040000)
[ 0.008017] ACPI: SPMI 0x0000000095FDB000 000040 (v05 DELL PE_SC3 00000001 DELL 00040000)
[ 0.008020] ACPI: SSDT 0x0000000095FDA000 000533 (v01 DELL PE_SC3 00003000 DELL 00040000)
[ 0.008023] ACPI: SSDT 0x0000000095FD9000 000ACE (v01 DELL PE_SC3 00003000 DELL 00040000)
[ 0.008025] ACPI: SSDT 0x0000000095FD5000 003492 (v01 DELL PE_SC3 00003000 DELL 00040000)
:
try to put them on spoiler or something
or use pastebin-like service then put the link here 
The number on the left between [ ] show the time from boot take to execute the stated info.
i.e : in my scaleway case the time jump from two-digit to 300-ish if I'm not mistaken my memory
OK!
systemd-analyze blame
Use this to see the start up times.
systemd got too greedy imo
but for this, still reasonable
dedicated server always take time to boot, no ?
the bios process itself can take more than 15s before start booting the OS
root@:~# systemd-analyze blame
2min 174ms systemd-networkd-wait-online.service
13.568s snap.lxd.activate.service
13.452s snapd.seeded.service
13.192s snapd.service
10.257s spamassassin.service
8.540s mariadb.service
7.748s systemd-journal-flush.service
7.558s php8.1-fpm.service
5.572s networkd-dispatcher.service
5.413s [email protected]
5.045s udisks2.service
4.349s proftpd.service
4.324s apache2.service
4.113s cloud-init-local.service
2.807s ModemManager.service
2.735s polkit.service
2.704s named.service
2.463s dev-md1p1.device
2.138s dovecot.service
1.731s thermald.service
1.731s systemd-logind.service
1.520s opendkim.service
1.439s quotaon.service
1.377s apparmor.service
1.112s dev-loop5.device
1.109s dev-loop3.device
974ms ssh.service
936ms dev-loop1.device
920ms grub-common.service
894ms dev-loop6.device
884ms dev-loop2.device
864ms apport.service
823ms dev-loop0.device
802ms systemd-fsck@dev-disk-by\x2did-md\x2duuid\x2d0ea9f368:1533e854:94102>
798ms dev-loop4.device
778ms rsyslog.service
770ms amavis.service
594ms clamav-daemon.service
531ms cloud-init.service
466ms e2scrub_reap.service
461ms phpsessionclean.service
428ms plymouth-read-write.service
421ms snapd.apparmor.service
420ms multipathd.service
415ms systemd-udevd.service
401ms systemd-binfmt.service
396ms cloud-final.service
385ms cloud-config.service
366ms keyboard-setup.service
354ms grub-initrd-fallback.service
343ms systemd-fsck@dev-disk-by\x2did-md\x2duuid\x2da6f7ab02:2f0aa46c:06b3a>
304ms ua-timer.service
286ms proc-sys-fs-binfmt_misc.mount
274ms systemd-random-seed.service
253ms systemd-resolved.service
249ms systemd-tmpfiles-setup-dev.service
244ms home.mount
196ms systemd-sysctl.service
196ms systemd-sysusers.service
183ms lvm2-monitor.service
160ms update-notifier-download.service
154ms systemd-modules-load.service
153ms systemd-tmpfiles-setup.service
130ms systemd-remount-fs.service
110ms [email protected]
107ms systemd-journald.service
102ms dev-hugepages.mount
101ms dev-mqueue.mount
101ms sys-kernel-debug.mount
100ms sys-kernel-tracing.mount
98ms systemd-networkd.service
95ms systemd-timesyncd.service
94ms snap-lxd-24061.mount
90ms boot.mount
89ms systemd-update-utmp.service
88ms systemd-user-sessions.service
85ms kmod-static-nodes.service
85ms dev-disk-by\x2duuid-38e73868\x2d1923\x2d4534\x2da074\x2d817fb1e77aec>
84ms [email protected]
84ms [email protected]
83ms [email protected]
83ms snap-core20-1611.mount
82ms systemd-udev-trigger.service
81ms finalrd.service
79ms systemd-tmpfiles-clean.service
71ms snap-lxd-22753.mount
69ms swap.img.swap
52ms snap-core22-1380.mount
50ms ufw.service
47ms setvtrgb.service
47ms snap-snapd-21759.mount
37ms snap-core20-2318.mount
34ms snap-canonical\x2dlivepatch-282.mount
27ms console-setup.service
10ms plymouth-quit.service
8ms snapd.socket
6ms systemd-quotacheck.service
6ms [email protected]
4ms systemd-update-utmp-runlevel.service
1ms modprobe@efi_pstore.service
1ms sys-fs-fuse-connections.mount
1ms sys-kernel-config.mount
1ms plymouth-quit-wait.service
1ms postfix.service
22us blk-availability.service
lines 83-105/105 (END)
network related. maybe the same with me, waiting for dhcp to timeout
Had the same problem with long startup time on a VPS I got. Turned out it was also waiting for network like this as well. The cause was the gateway. I Removed it and startup no longer hanged for 2 minutes. File was in
/etc/netplan. Careful with editing this file.Or remove netplan. Why would anyone need it, nevermind a dedi?
Does it do anything useful for you?
Edited
My new laptop takes 9.4 seconds to boot fully into gnome, using Arch + Gnome, is this acceptable?
NVMe?
Yeah, gen4
We use Netplan.io on every server even Debian.
Netplan keeps the entire network configuration in a single YAML file.
In contrast, systemd needs two units for each network interface: a .link or .netdev unit for lower layer, and a .network unit for upper layer.
You must have very weird configs. For my normal servers (i.e. not complicated routers) I find interfaces file to serve the purpose well. I use it even at home for wireless too, for example.
ifupdown depends on net-tools that is deprecated:
https://wiki.debian.org/NetToolsDeprecation
More often than not, a VPS template that comes with an interface file would not have networking, because the interface name is wrong.
In Netplan YAML, I always use
.match.macaddressto ensure working network.So, what would be faster? apt-install net-tools, figure out what the interface name is and adjust interfaces file or your approach?
I don't say your approach is wrong or that mine will work forever, but I go the classic route until (for example) netplan becomes the classic route or something else takes its place.
I am 49, I prefer my old ways and in this case I don't think I am losing more time or that I introduce more SPoFs by using my approach.
I'm sixteen ageless, we use the modern way.
Is netplan the modern way? Was there a poll or something? Let's use network-manager in cli instead, wicd or god knows what else... We can always throw more layers at the problem, eventually, something will work...
update 24.04?
Updating to 24.04 would fix this problem if it's a fresh install. Or you know, no network settings was transferred.
When I upgraded to 24.04 the problem went away. However transferring the old network settings caused the problem, thus me finding out the gateway for my VPS was bad. This isn't really a Ubuntu problem, more of a bad network config.
netplan is the crap that ubuntu invented like snap.
They end up pushing that unstable crap to users if you want or not as long you using ubuntu.
I know what it is. Instead of reworking the previous system if you know the users had problems with it, you just pull over a new layer to "manage" things and imagine the problem is solved.
I don't say it is good or bad, nobody has to use it or use Ubuntu for that matter, I am glad there are many choices, even as I don't like them, just that the idea looks (to me) rotten from the start.
&
I mean, since I am over-the-hill out of touch with the yunguns, where can I check what is "trending" today on tiktok regarding the network stack "managers"?
The modern way to manage networking on Ubuntu is primarily through Netplan. Netplan is a network configuration utility that simplifies the configuration of networking on Linux systems. It uses YAML configuration files and can work with different network backends like NetworkManager or systemd-networkd.
Here's a quick overview of how to use Netplan:
Configuration Files:
Netplan configuration files are located in the
/etc/netplan/directory. They typically have a.yamlextension.Example Configuration:
Here's an example of a basic Netplan configuration for a system using DHCP on
eth0:For a static IP configuration, the YAML might look like this:
Apply Configuration:
After editing your configuration file, apply the changes with the following command:
Validation:
Before applying, you can validate your configuration to ensure there are no syntax errors:
This will test the configuration and allow you to confirm the changes within a timeout period.
Backends:
Netplan supports two backends:
NetworkManagerandsystemd-networkd. You can specify which one to use in your configuration. For example, to useNetworkManager:Documentation:
You can find more detailed information and options in the official Netplan documentation: Netplan Documentation.
By using Netplan, you can manage your network configurations in a more consistent and modern way, making it easier to automate and script these configurations, especially in cloud environments or with infrastructure as code tools.