Страница 3 из 4
Re: загрузка: восстановление и оптимизация
Добавлено: 03 сен 2021, 20:02
Olej
Olej писал(а): ↑03 сен 2021, 19:51
Хотелось бы запретить старт сервиса при каждой перезагрузке:
Код: Выделить всё
root@nvidia:/etc/systemd# systemctl is-enabled fstrim.service
static
Но это легко хотеть, но не легко сделать
-
Как использовать Systemctl для управления службами Systemd и юнитами
В этом контексте static означает, что в файле unit не содержится раздел «install», который используется для включения устройства. Таким образом, эти блоки не могут быть включены. Обычно это означает, что устройство выполняет одноразовое действие или используется только как зависимость другого устройства и не должно запускаться само по себе.
Код: Выделить всё
root@nvidia:/etc/systemd# systemctl disable fstrim.service
root@nvidia:/etc/systemd# systemctl is-enabled fstrim.service
static
Мёртвому припарки!
Разве что так:
Код: Выделить всё
root@nvidia:/etc/systemd# systemctl mask fstrim.service
Created symlink /etc/systemd/system/fstrim.service → /dev/null.
root@nvidia:/etc/systemd# systemctl is-enabled fstrim.service
masked
Re: загрузка: восстановление и оптимизация
Добавлено: 03 сен 2021, 20:24
Olej
Olej писал(а): ↑03 сен 2021, 20:02
Разве что так:
Перезагрузка...
Olej писал(а): ↑25 авг 2021, 16:47
Код: Выделить всё
olej@nvidia:~/2021_WORK/ACCOUNTS/Yandex$ systemd-analyze blame | head -n 25
5.813s fstrim.service
3.271s man-db.service
2.413s NetworkManager-wait-online.service
2.276s udisks2.service
1.961s mintupdate-automation-autoremove.service
...
Стало - в этом смысле гораздо лучше:
Код: Выделить всё
olej@nvidia:~$ systemd-analyze blame | head -n 10
2.108s NetworkManager-wait-online.service
1.109s nfs-server.service
874ms dev-zram0.device
854ms dev-zram2.device
818ms tor@default.service
815ms dev-zram1.device
785ms dev-sda1.device
782ms dev-zram3.device
703ms udisks2.service
603ms ubuntu-system-adjustments.service
Но!:
Код: Выделить всё
olej@nvidia:~$ systemd-analyze
Startup finished in 34.373s (kernel) + 4.337s (userspace) = 38.711s
graphical.target reached after 4.324s in userspace
Это не то что хотелось бы ...
И большую часть начальной загрузки, как я вижу но не успеваю зафиксировать - это какая-то проверка-очистка файловой системы (какой?).
Re: загрузка: восстановление и оптимизация
Добавлено: 04 сен 2021, 12:29
Olej
Olej писал(а): ↑03 сен 2021, 20:24
Это не то что хотелось бы ...
И большую часть начальной загрузки, как я вижу но не успеваю зафиксировать - это какая-то проверка-очистка файловой системы (какой?).
- именно
на этом компьютере...
- на котором система не переустанавливалась, а только
обновлялась с 2012 года, раз 6-7-8 обновление релиза системы - начиная ещё с Mint 17...
Код: Выделить всё
olej@nvidia:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Linuxmint
Description: Linux Mint 20.2
Release: 20.2
Codename: uma
- с неоднократными непростыми восстановлениями и откатами...
- с неоднократным апгрейдом железа: из NVIDIA адаптера который был потом снят, с заменой HDD на SSD...
Код: Выделить всё
olej@nvidia:~$ inxi -Gxxx
Graphics: Device-1: Intel Core Processor Integrated Graphics driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:0042
Display: x11 server: X.Org 1.20.11 driver: modesetting unloaded: fbdev,vesa alternate: nvidia
resolution: 1920x1080~60Hz, 1920x1080~60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics (ILK) v: 2.1 Mesa 21.0.3 direct render: Yes
Код: Выделить всё
olej@nvidia:~$ inxi -Dxxx
Drives: Local Storage: total: 387.53 GiB used: 216.69 GiB (55.9%)
ID-1: /dev/sda vendor: Silicon Power model: SPCC Solid State Disk size: 238.47 GiB speed: 3.0 Gb/s
serial: 0E74070A14BC00128320 rev: 61.3 scheme: MBR
ID-2: /dev/sdb vendor: Seagate model: STM3160318AS size: 149.05 GiB speed: 3.0 Gb/s rotation: 7200 rpm
serial: 9VY0E3WK rev: CC35 scheme: MBR
Непонятно почему при
каждой перезагрузке идёт достаточно
долгая (~35 секунд) проверка системного SSD ... не могу поймать ситуацию. Это уже вопрос принципиальный - откуда это может происходить?
На других компьютерах такого (по крайней мере в такой степени) не наблюдается ... на ноутбуке с Fedora вся загрузка до графического экрана идёт 8 секунд.
Re: загрузка: восстановление и оптимизация
Добавлено: 04 сен 2021, 14:07
Olej
Olej писал(а): ↑04 сен 2021, 12:29
Непонятно почему при каждой перезагрузке идёт достаточно долгая (~35 секунд) проверка системного SSD ... не могу поймать ситуацию. Это уже вопрос принципиальный - откуда это может происходить?
Нашёл!
Код: Выделить всё
olej@nvidia:~$ systemd-analyze
Startup finished in 3.609s (kernel) + 4.771s (userspace) = 8.380s
graphical.target reached after 4.755s in userspace
Теперь вместо 35 секунд - 8 секунд
Ну зараза же эта ситуация оказалась!
Re: загрузка: восстановление и оптимизация
Добавлено: 04 сен 2021, 14:08
Olej
Olej писал(а): ↑04 сен 2021, 14:07
Ну зараза же эта ситуация оказалась!
По порядку...
Конспектирую для себя, но может ещё кому пригодится...
Ключевой фразой оказалось сообщение при загрузке (успел подсмотреть):
gave up waiting for suspend/resume device
Как оказалось - я уже
2 или 3 раза попадал в эту ситуацию, и она здесь в теме уже описана, но без детального решения...
(на некоторую ясность натолкнуло обсуждение
gave up waiting for suspend/resume device - но там они нашли решение таки не выяснив причину)...
Причина опять же в параметре RESUME для initramfs-tools:
Код: Выделить всё
olej@nvidia:~$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=692eb628-1869-49e5-af7f-2b9dbd034471
Код: Выделить всё
olej@nvidia:~$ blkid
/dev/sdb1: UUID="64d5075f-c466-44d9-92a3-f8a74276a440" TYPE="ext4" PARTUUID="7c8982da-01"
/dev/sdb2: UUID="70a27ef1-d2c3-4017-975b-645e184be739" TYPE="ext4" PARTUUID="7c8982da-02"
/dev/sda1: UUID="d5247f95-69b6-47b0-baa6-c71dd689a78f" TYPE="ext4" PARTUUID="000bfcf6-01"
/dev/sda2: UUID="3ee8f840-4b98-4984-8ab2-b4aa4cb2db1e" TYPE="ext4" PARTUUID="000bfcf6-02"
Как видно, в RESUME записан UUID которого
нет в системе - это старый UUIS swap-раздела, и произошло это когда я менял HDD на SSD и по ходу swap-раздел на swap-файл.
Код: Выделить всё
root@nvidia:/etc# swapon
NAME TYPE SIZE USED PRIO
/dev/zram0 partition 64M 0B 100
/dev/zram1 partition 64M 0B 100
/dev/zram2 partition 466,6M 0B 5
/dev/zram3 partition 466,6M 0B 100
/swapfile file 3G 0B -2
Но поскольку у swap-файла нет UUID (mkswap создаёт для него UUID, но это фикция для файла), то нужно что-то изобретать что делатьс RESUME=...
Re: загрузка: восстановление и оптимизация
Добавлено: 04 сен 2021, 14:24
Olej
Olej писал(а): ↑04 сен 2021, 14:08
Но поскольку у swap-файла нет UUID (mkswap создаёт для него UUID, но это фикция для файла), то нужно что-то изобретать что делатьс RESUME=...
Выясняю что это за зверь вообще... Это не так просто выяснить оказалось... В конце-концов нахожу:
Код: Выделить всё
olej@nvidia:~$ man initramfs.conf
INITRAMFS.CONF(5) File Formats Manual INITRAMFS.CONF(5)
NAME
initramfs.conf - configuration file for mkinitramfs
DESCRIPTION
The behaviour of mkinitramfs can be modified by its configuration file.
Each line in the file can be a configuration variable, a blank line, or a comment. The value of an variable is assigned
by an statement of the form: name=[value]
Configuration options can be broken out into configuration snippets and placed in individual files in the
/etc/initramfs-tools/conf.d directory. Files in this directory are always read after the main configuration file, so
you can override the settings in the main config file without editing it directly.
...
VARIABLES FOR LOCAL BOOT
RESUME
Specifies the device used for suspend-to-disk (hibernation), which the initramfs code should attempt to resume
from. If this is not defined or is set to auto, mkinitramfs will automatically select the largest available
swap partition. Set it to none to disable resume from disk.
Это
один из параметров, который
только и исключительно относится к
гибернации (для моего стационарного компа это совершеннейшая бессмыслица!) и указывает начальному имиджу initrd.img-* из какого swap-
раздела производить "просыпание" системы при гибернации. Но для этого swap-раздел должен быть как минимум в 2 раза больше памяти RAM ... а у меня:
Код: Выделить всё
olej@nvidia:~$ free
всего занято свободно общая буф./врем. доступно
Память: 3822192 1440572 227052 503080 2154568 1591416
Подкачка: 1498848 0 1498848
Код: Выделить всё
root@nvidia:/etc# swapon
NAME TYPE SIZE USED PRIO
/dev/zram0 partition 64M 0B 100
/dev/zram1 partition 64M 0B 100
/dev/zram2 partition 466,6M 0B 5
/dev/zram3 partition 466,6M 0B 100
/swapfile file 3G 0B -2
Картина в точности "до наоборот".
Какая нахрен тут может быть гибернация?
Re: загрузка: восстановление и оптимизация
Добавлено: 04 сен 2021, 14:29
Olej
Olej писал(а): ↑04 сен 2021, 14:24
Какая нахрен тут может быть гибернация?
Как решить? Радикально...
Правлю (комментарии допускаются как man говорит):
Код: Выделить всё
olej@nvidia:~$ cat /etc/initramfs-tools/conf.d/resume
#RESUME=UUID=692eb628-1869-49e5-af7f-2b9dbd034471
RESUME=none
Перегенерация образов:
Код: Выделить всё
root@nvidia:~# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.4.0-81-generic
Warning: No support for locale: ru_RU.utf8
update-initramfs: Generating /boot/initrd.img-5.4.0-80-generic
Warning: No support for locale: ru_RU.utf8
Свежак! (см. даты):
Код: Выделить всё
olej@nvidia:~$ ls -lt /boot/initrd.img*
-rw-r--r-- 1 root root 67417643 сен 4 13:58 /boot/initrd.img-5.4.0-80-generic
-rw-r--r-- 1 root root 67418716 сен 4 13:58 /boot/initrd.img-5.4.0-81-generic
lrwxrwxrwx 1 root root 27 сен 3 19:58 /boot/initrd.img -> initrd.img-5.4.0-81-generic
lrwxrwxrwx 1 root root 27 сен 3 19:58 /boot/initrd.img.old -> initrd.img-5.4.0-80-generic
Reboot
Всё:
Код: Выделить всё
olej@nvidia:~$ systemd-analyze
Startup finished in 3.609s (kernel) + 4.771s (userspace) = 8.380s
graphical.target reached after 4.755s in userspace
Сколько ж крови он у меня выпил, гад ... со своей гибернацией!
Re: загрузка: восстановление и оптимизация
Добавлено: 04 сен 2021, 14:32
Olej
Olej писал(а): ↑04 сен 2021, 14:29
Сколько ж крови он у меня выпил, гад ... со своей гибернацией!
Теперь можно даже реабилитировать незаслуженно гнобленный fstrim.service - пусть тримингует себе SSD на здоровье:
Код: Выделить всё
root@nvidia:/etc# systemctl unmask fstrim.service
Removed /etc/systemd/system/fstrim.service.
root@nvidia:/etc# systemctl is-enabled fstrim.service
static
После перезагрузки:
Код: Выделить всё
olej@nvidia:~$ systemd-analyze
Startup finished in 3.330s (kernel) + 4.531s (userspace) = 7.862s
graphical.target reached after 4.502s in userspace
Код: Выделить всё
olej@nvidia:~$ systemd-analyze blame | head -n 25
1.945s NetworkManager-wait-online.service
1.121s nfs-server.service
1.044s dev-zram0.device
1.030s dev-sda1.device
988ms dev-zram1.device
928ms dev-zram3.device
909ms dev-zram2.device
703ms tor@default.service
682ms udisks2.service
551ms smartmontools.service
505ms systemd-logind.service
493ms ubuntu-system-adjustments.service
468ms accounts-daemon.service
453ms pure-ftpd.service
438ms alsa-restore.service
399ms loadcpufreq.service
342ms systemd-resolved.service
321ms NetworkManager.service
312ms networking.service
310ms systemd-udevd.service
301ms e2scrub_reap.service
237ms upower.service
224ms zram-config.service
221ms zramswap.service
217ms ModemManager.service
Теперь
субъективно загрузка, от самого начала до самого конца, идёт не более 10 сек. - вот это то что надо!
Re: загрузка: восстановление и оптимизация
Добавлено: 08 фев 2022, 17:31
Olej
Olej писал(а): ↑24 окт 2019, 21:27
Вводная: иногда после "улучшений" системы (установка пакетов или редактирование конфигурация) система начинает: а). не грузиться, б). с большими задержками грузиться, в). не так как хочется грузиться (не те сервисы грузятся ... или наоборот те не грузятся)...
Вот о разборках с такими случаями - эта тема.
Периодически возникает снова и снова эта задача...
На этот раз:
Код: Выделить всё
[olej@xenix ~]$ lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: Fedora
Description: Fedora release 35 (Thirty Five)
Release: 35
Codename: ThirtyFive
После многократных обновлений (системы) и инсталляций (пакетов) ... c 2016 года система неизменно обновляется без переустановки
:
Код: Выделить всё
[olej@xenix ~]$ systemd-analyze critical-chain
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 @53.848s
└─multi-user.target @53.848s
└─plymouth-quit-wait.service @5.459s +48.386s
└─systemd-user-sessions.service @5.372s +76ms
└─remote-fs.target @5.277s
└─remote-fs-pre.target @5.277s
└─nfs-client.target @4.839s
└─gssproxy.service @4.551s +287ms
└─network.target @4.545s
└─systemd-resolved.service @3.955s +589ms
└─systemd-tmpfiles-setup.service @3.912s +34ms
└─local-fs.target @3.906s
└─home-olej-\xd0\x97\xd0\xb0\xd0\xb3\xd1\x80\xd1\x83\xd0\xb7\xd0\xba\xd0\xb8.mount @3.837s +68ms
└─local-fs-pre.target @3.835s
└─lvm2-monitor.service @1.711s +977ms
└─dm-event.socket @1.684s
└─system.slice
└─-.slice
Код: Выделить всё
[olej@xenix ~]$ systemd-analyze blame
48.386s plymouth-quit-wait.service
47.490s akmods.service
1.924s systemd-udev-settle.service
1.923s initrd-switch-root.service
1.855s accounts-daemon.service
1.825s libvirtd.service
1.332s ModemManager.service
977ms lvm2-monitor.service
906ms NetworkManager-wait-online.service
866ms cups.service
627ms nvidia-fallback.service
589ms systemd-resolved.service
497ms nfs-server.service
489ms dracut-initqueue.service
470ms teamviewerd.service
467ms systemd-journal-flush.service
447ms smartd.service
422ms udisks2.service
386ms polkit.service
361ms colord.service
338ms nfs-mountd.service
332ms user@1000.service
323ms initrd-parse-etc.service
317ms NetworkManager.service
312ms dnfdaemon.service
287ms gssproxy.service
261ms lm_sensors.service
257ms proc-fs-nfsd.mount
199ms rsyslog.service
193ms avahi-daemon.service
192ms systemd-vconsole-setup.service
191ms systemd-udevd.service
168ms systemd-udev-trigger.service
160ms rpc-statd.service
152ms systemd-logind.service
148ms chronyd.service
133ms gpm.service
127ms lightdm.service
119ms livesys.service
118ms dracut-cmdline.service
103ms upower.service
98ms rpc-statd-notify.service
96ms rtkit-daemon.service
96ms plymouth-switch-root.service
92ms modprobe@drm.service
83ms setup-cyrfont@tty2.service
82ms setup-cyrfont@tty1.service
82ms setup-cyrfont@tty3.service
77ms setup-cyrfont@tty4.service
76ms systemd-user-sessions.service
75ms dev-zram0.swap
72ms sshd.service
71ms setup-cyrfont@tty5.service
70ms setup-cyrfont@tty6.service
69ms readonly-root.service
68ms home-olej-\xd0\x97\xd0\xb0\xd0\xb3\xd1\x80\xd1\x83\xd0\xb7\xd0\xba\xd0\xb8.mount
63ms dracut-pre-pivot.service
58ms systemd-tmpfiles-setup-dev.service
55ms nfs-convert.service
54ms kmod-static-nodes.service
52ms dbus-broker.service
52ms dev-hugepages.mount
52ms dev-disk-by\x2duuid-e636cb90\x2d5b2c\x2d4383\x2db9d1\x2d290b0f29269a.swap
51ms dev-mqueue.mount
47ms sys-kernel-debug.mount
46ms rpcbind.service
45ms sys-kernel-tracing.mount
43ms systemd-modules-load.service
43ms systemd-journald.service
43ms dracut-pre-udev.service
42ms systemd-remount-fs.service
42ms systemd-fsck@dev-disk-by\x2duuid-6337320c\x2d1562\x2d4db4\x2d8880\x2dff984ce1eea0.service
40ms initrd-cleanup.service
40ms systemd-sysctl.service
40ms systemd-random-seed.service
39ms systemd-zram-setup@zram0.service
35ms systemd-machined.service
34ms systemd-tmpfiles-setup.service
31ms nfs-idmapd.service
29ms nfsdcld.service
29ms systemd-fsck-root.service
27ms sys-fs-fuse-connections.mount
25ms sys-kernel-config.mount
18ms systemd-update-utmp.service
16ms plymouth-read-write.service
16ms plymouth-start.service
15ms livesys-late.service
14ms boot.mount
13ms initrd-udevadm-cleanup-db.service
13ms user-runtime-dir@1000.service
12ms systemd-update-utmp-runlevel.service
11ms var-lib-nfs-rpc_pipefs.mount
6ms dracut-shutdown.service
4ms modprobe@configfs.service
4ms tmp.mount
4ms vboxdrv.service
4ms modprobe@fuse.service
Re: загрузка: восстановление и оптимизация
Добавлено: 08 фев 2022, 19:21
Olej
Olej писал(а): ↑08 фев 2022, 17:31
На этот раз:
Проблема, как я понимаю:
Код: Выделить всё
[olej@xenix ~]$ journalctl -b | grep nouveau
...
фев 08 16:13:53 xenix.localdomain kernel: fbcon: nouveaudrmfb (fb0) is primary device
фев 08 16:13:53 xenix.localdomain kernel: nouveau 0000:01:00.0: [drm] fb0: nouveaudrmfb frame buffer device
фев 08 16:13:53 xenix.localdomain kernel: [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0
фев 08 16:13:53 xenix.localdomain systemd[1]: Finished Fallback to nouveau as nvidia did not load.
фев 08 16:20:34 xenix.localdomain kernel: nouveau 0000:01:00.0: Direct firmware load for nouveau/nvd9_fuc084 failed with error -2
фев 08 16:20:34 xenix.localdomain kernel: nouveau 0000:01:00.0: Direct firmware load for nouveau/nvd9_fuc084d failed with error -2
фев 08 16:20:34 xenix.localdomain kernel: nouveau 0000:01:00.0: msvld: unable to load firmware data
фев 08 16:20:34 xenix.localdomain kernel: nouveau 0000:01:00.0: msvld: init failed, -19
...
Свободному драйверу nouveau (говно, в общем) не хватает ещё какого-то firmware для NVIDIA GeForce GT 520:
Код: Выделить всё
[olej@xenix ~]$ lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 520] (rev a1)
Код: Выделить всё
[olej@xenix ~]$ lspci -s 01:00.0 -k
01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 520] (rev a1)
Subsystem: ASUSTeK Computer Inc. ENGT520 SILENT
Kernel driver in use: nouveau
Kernel modules: nouveau
Код: Выделить всё
[olej@xenix ~]$ inxi -Gxxx
Graphics:
Device-1: NVIDIA GF119 [GeForce GT 520] vendor: ASUSTeK ENGT520 SILENT
driver: nouveau v: kernel bus-ID: 01:00.0 chip-ID: 10de:1040 class-ID: 0300
Display: x11 server: X.Org 1.20.14 driver: loaded: modesetting
unloaded: fbdev,vesa resolution: 1920x1080~60Hz s-dpi: 96
OpenGL: renderer: NVD9 v: 4.3 Mesa 21.3.5 direct render: Yes