Долгая загрузка linux

Сдох диск?

Сделай systemd-analyze critical-chain и посмотри, что там отнимает время.

да вроде нет. после загрузки то все работает как и раньше.

смарт никак не изменился.

Как fstab поправил , дай содержимое. Проверь файловые системы на ошибки, и журнал глянь

journalctl -p err..alert```

https://wiki.archlinux.org/title/General_troubleshooting

https://wiki.archlinux.org/title/General_troubleshooting

journalctl -p err..alert

И убери Плимут - бесполезная вещь , хоть будешь видеть процесс загрузки

в fstab было data=writeback вот это удалил. сейчас еще удалил lazyatime фс на ошибки проверил - ошибок нет. журнал

мар 11 08:11:19 xdg12 systemd-udevd[257]: could not read from '/sys/module/pcc_cpufreq/initstate': No such device
мар 11 08:11:37 xdg12 lightdm[2831]: gkr-pam: unable to locate daemon control file
мар 11 08:11:39 xdg12 pulseaudio[2891]: GetManagedObjects() failed: org.freedesktop.systemd1.NoSuchUnit: Unit dbus-org.bluez.service not found.

cat /etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sdb1
UUID=f48f6b37-39d6-49f2-8264-a33ef77e0b29 /         	ext4      	defaults,rw,commit=600,barrier=0,nodiscard	0 1
UUID=0CE0-B59E                                /efi          vfat            defaults                                                0 0

я тут немного поигрался. отключил cpupower libvirtd apparmor auditd вот после отключения последнего стало пошустрее, но все равно как то медленно.

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 @3.993s
└─udisks2.service @3.178s +814ms
  └─basic.target @3.152s
    └─sockets.target @3.152s
      └─dbus.socket @3.152s
        └─sysinit.target @3.150s
          └─systemd-update-done.service @3.141s +8ms
            └─ldconfig.service @2.611s +528ms
              └─local-fs.target @2.608s
                └─efi.mount @2.340s +267ms
                  └─dev-sdb2.device @2.338s

я правильно понимаю что он почему то долго монтирует диск?

dev-sdb2.device @2.338s

две секунды на монтирование диска да?

да уже убрал. и опцию при буте и вообще из системы вынес. только хук в интрд остался. но это как бы вряд ли. т.к раньше грузилось шустро с ним. единственное почему я его снес это оттого что когда система вообще не грузилась, было подозрение на него и я его сервисы отключал удалял т.к даже без опции при буте он все равно дергает его юниты.

UUID=0CE0-B59E                                /efi          vfat            defaults                                                0 0

Я правильно понимаю, этот раздел ты " не по людски" монтируешь? Впрочем, для работы системы это монтирование вообще не нужно. Оно нужно только для установки-обновления загрузчика.

Потом я заметил что какие то ошибки при монтировании корня и поправил fstab, после чего все заработало, но медленно.

Ты прикалываешься? Где дамп ошибок? Где дифф исправлений? Костыль дальше наугад если такой умный.

оно нужно чтобы записать ядро при апдейтах. там дурацкий bootctl который не хочет с другого раздела. а по людски эта как? )

ты сильно удивишся если я таки тебе выкачу дифф исправлений? а нет, я могу выктить дифф только между текущим состоянием и состоянием когда все работало нормально.

правильно понимаю, этот раздел ты " не по людски" монтируешь?

Нет, «не по-людски» это /boot/efi. Нормально — /efi или вообще /boot. Но это, конечно, если дистрибутив уже поддерживает современные варианты.

Не игнорь половину фразы делая вид что так и было. Ошибки какие? Как тебе в голову пришло делать в fstab рандомные правки, даже не вникнув в суть проблем?

barrier=0

Хороший способ ушатать и файловую систему, и данные.

) так нету ошибок. оно просто медленно грузится. из журнала я уже показывал. Когда оно негрузилось, ошибки были, но мелькало слишком быстро зачитать я неуспевал, но что то там про маунт.

ну пока не сломалось ни фс ни данные. На самом деле вообще плевать, есть бакап ) оно уже давно так работает. то что это типа небезопасно я знаю, но судя по всему опасения беспочвены, а ап к производительсти вполне осязаем.

ефи раздел зачем монтируешь? он нужен лишь при обновлении загрузчика что раз в год. dosfsck для проверки но сначала отмонтировать. Или у тебя хук чтоб туда ядро забрасывать?

так нету ошибок. оно просто медленно грузится

Ищи в dmesg подозрительно большие интервалы между сообщениями.

И systemd-analyze + systemd-analyze blame

ну это ты его обновляешь раз в год, а я эксперементирую с откатами к предыдущим версиям. да нет никакого хука, нафиг мне этот хук cp я и руками прописать могу это не сильно сложно.

хехе так в журналах время непопрядку. системд же. а systemd-analyze я уже показывал

к откатам предыдуших версий загрузчика? для этого можно и руками смонтировать. Или ты туда ядро с инитрамс руками переносишь? что у тебя там?

ls /efi

да ядро

хехе так в журналах время непопрядку

Ты вроде помочь просишь, но считаешь, что всё и так знаешь, однако, проблема почему-то не решена :)

В dmesg всё по порядку. Во вторых, я говорю именно про эти команды, а не systemd-analyze critical-chain. Без параметров оно покажет общее время загрузки с разделением на EFI, ядро и юзерспейс. Это вообще первый шаг, чтобы понять, куда дальше смотреть.

экстримал, при обновлении можешь забыть перенести новые

Ну вот объясни, у тебя при загрузке «мелькают какие-то ошибки», но ты не стал выяснять, какие именно, а вместо этого начал вносить рандомные правки в fstab. Как тебе вообще в голову такое пришло? Я реально не понимаю, как можно было до такого додуматься, и меня это удивляет. Исправь fstab назад и разбирайся с ошибками.

ну не все, вот конкретно почему медленно грузится не знаю. ну ладно смотри

systemd-analyze
Startup finished in 4.735s (firmware) + 2.544s (loader) + 5.200s (kernel) + 4.383s (userspace) = 16.864s
graphical.target reached after 3.993s in userspace

ystemd-analyze blame
1.468s dev-sdb1.device
 814ms udisks2.service
 528ms ldconfig.service
 496ms systemd-journal-flush.service
 445ms accounts-daemon.service
 283ms polkit.service
 267ms efi.mount
 205ms systemd-resolved.service
 201ms systemd-sysusers.service
 198ms systemd-networkd.service
 197ms user@1000.service
 197ms iptables.service
 179ms systemd-udevd.service
 173ms systemd-tmpfiles-setup.service
 160ms lvm2-monitor.service
 153ms systemd-logind.service
 132ms systemd-udev-trigger.service
 123ms systemd-timesyncd.service
 120ms laptop-mode.service
 120ms systemd-tmpfiles-clean.service
 107ms systemd-tmpfiles-setup-dev.service
 105ms systemd-fsck-root.service
  94ms systemd-journald.service
  90ms ip6tables.service
  82ms systemd-journal-catalog-update.service
  65ms systemd-modules-load.service
  49ms systemd-binfmt.service
  46ms modprobe@fuse.service
  43ms sys-kernel-tracing.mount
  42ms sys-kernel-debug.mount
  42ms dev-hugepages.mount
  41ms kmod-static-nodes.service
  41ms lightdm.service
  41ms dev-mqueue.mount
  41ms tmp.mount
  40ms modprobe@configfs.service
  40ms modprobe@drm.service
  24ms systemd-sysctl.service
  24ms systemd-random-seed.service
  18ms systemd-update-utmp.service
  10ms user-runtime-dir@1000.service
   9ms rtkit-daemon.service
   9ms systemd-user-sessions.service
   8ms systemd-update-done.service
   8ms systemd-remount-fs.service
   8ms proc-sys-fs-binfmt_misc.mount
   6ms alsa-restore.service
   4ms sys-fs-fuse-connections.mount
   4ms sys-kernel-config.mount

ну могу конечно, только что в этом такого экстримального?

ну вот объясняю, сначало все работало, потом я вносил рандомные правки в fstab, потом я об этом забыл, установил новый пакет и решил ребутнутся, после ребута оно не заработало, и тут я заметил что то там про маунт еррор, ро в корне и тут вспомнил про fstab после чего решил его как то привести к изначальному виду.

а ошибок то нет, с какими ошибками ты предлагаешь разбираться?

вообще идея была в том чтобы кэшировать запись. Ну т.е есть фаерфокс и он очень любит диск, предлагается его запихать в рамдиск, но озу жалко, поэтому, сделать большой кэш на запись и пусть лиса его и любит думая что это диск, но чет пошло не так, ему эта опция почему то не понравилась.

graphical.target reached after 3.993s

неплохой результат вообще то

528ms ldconfig.service обновлял перед перезагрузкой чтото, можно и отключить сервис но тогда ld будет выполняться при загрузке приложения

814ms udisks2.service journalctl -b -u udisks2.service

для браузеров используй psd, жадеть озу нечего на то она и нужна

https://wiki.archlinux.org/title/Profile-sync-daemon

вообще нет, это было отключение юнита - ребут - анализ и так покругу.

- Journal begins at Wed 2024-02-28 11:41:18 MSK, ends at Mon 2024-03-11 10:16:55 MSK. --
мар 11 08:11:20 xdg12 systemd[1]: Starting Disk Manager...
мар 11 08:11:21 xdg12 udisksd[1188]: udisks daemon version 2.9.3 starting
мар 11 08:11:21 xdg12 systemd[1]: Started Disk Manager.
мар 11 08:11:21 xdg12 udisksd[1188]: Acquired the name org.freedesktop.UDisks2 on the system message bus

1.468s dev-sdb1.device а вот это вот почему оно так? на ссаный диск тратиться 2.2сек из 3. )))) как то многовато, пАчИмуууууу? в dmesg тоже секунды начинают «идти» с дисков.

да, я видел это «чудесное решение». но хочу через кэш на запись. а че нет? вот можно было бы сделать этот кэш безлимитным по времени только по объему и на одно приложение. было бы отлично. но я пока что то как бесконечно далек от этого у меня даже просто кэш незавелся. есть еще одна чудно костыльная идея, сделать оверлейфс в рамдиск на профиль лиса, и там какой нибудь скрипт\сервис\чертавступе для переодиского флуха по условию.

Потому что на ssd он бесполезен, и так в озу кешируется

лис еще и сам по себе жрет как тиранозавр озу а тут ему еще и его профиль в озу закинь, а он так то тоже не 3мб, там где то 1.5-2г. и это только сами данные а ему же еще свободное место будет нужно. ну и куда это же феерический писец.

для больших обьемов это нормальное время

journalctl -b|grep sdb1```
возможно fsck отработал

у меня 64г всего диск. )

journalctl -b|grep sdb1
мар 11 08:11:18 xdg12 kernel:  sdb: sdb1 sdb2
мар 11 08:11:18 xdg12 kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
мар 11 08:11:18 xdg12 systemd-fsck[244]: /dev/sdb1: clean, 930700/3883008 files, 13176790/15502336 blocks
мар 11 08:11:18 xdg12 kernel: EXT4-fs (sdb1): re-mounted. Opts: commit=600,barrier=0,nodiscard

чек отрабатывает каждый 10 бут. вот кстати видишь ordered data mode а че на writeback не согласился.

А, ну тогда другое дело, что ж ты сразу не написал что fstab сломал ещё раньше.

я вот че думаю ) а может ли это быть из-за того что в инитрд не запихался драйвер usb3 )))) ? теоритически nvidia-tweaks чета патчил и ребилдил инитрд и помому там чето писалось что он драйвер на усб не нашел. нуда, наверно стоит добавить почему это важно, sdB потому и B что в усб воткнут.

на 8гигах спокойно крутится , после 2 часов работы

               total        used        free      shared  buff/cache   available
Mem:            7877        1958        4988         357        1552        5919
Swap:           4087           0        4087

 du -sh /run/user/1000/psd
1,5G	/run/user/1000/psd

вот видишь какой у тебя лис тощий, недокормленый. а у меня -2г озу просто по факту запуска.

ordered data mode а че на writeback не согласился

нормальное поведение с загрузкой через initramfs, диски сначала монтируются в ro а потом перемонтируются

EXT4-fs (sdb1): re-mounted

Overlayfs его сжимает сильно

ну разумеется, в рамслой он пишет только дифы, посути тот же кэш на запись только прикрученый костылем сбоку )

а так ты уже такую штука сделал, выходит я опоздал и выдамал велосипед )))) ну бывает.

Ну так я о чем, только этот костыль уже готовый в репах с сервисами и работающий на механизмах ядра. Но можешь конечно изобретать свой велосипед, у некоторых выходит изобрести что то новое лучше чем старое