Boot lent après reformatage partitions

Support Debian
#1

après un reformatage de partitions, j’ai du refait le fstab avec les nouveaux UID de disques.

Mais je constate un boot plus lent et vois dans dmesg 30s pour monter le disque système:

...
[    5.270041] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 1
[   36.863405] EXT4-fs (nvme0n1p6): mounted filesystem with ordered data mode. Opts: (null)
...

# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=16343156k,nr_inodes=4085789,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3273600k,mode=755)
/dev/nvme0n1p6 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=2599)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p4 on /ubuntu18 type ext4 (rw,relatime)
/dev/nvme0n1p2 on /ubuntu20 type ext4 (rw,relatime)
/dev/nvme0n1p5 on /usr/local/data type ext4 (rw,relatime)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3273596k,nr_inodes=818399,mode=700,uid=1000,gid=1000)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Comment détailler ce qui s’est passé dans ces 30 secondes ?

#2

Si l’UUID du swap utilisé pour l’hibernation a changé, le fichier /etc/initramfs-tools/conf.d/resume a-t-il été mis à jour et l’initramfs a-t-il été reconstruit avec update-initramfs -u ?

#3

Bonjour,

peux-tu montrer ton /etc/fstab?

#4

Jackpot. C’était le pb. Merci Pascal.

Au passage, l’utilisation des UID au lieu des URI /dev/xxx dans le fstab était elle indispensable ?

#5

Tu veux dire l’utilisation des UUID au lieu des noms de périphériques ?
Il est indispensable d’utiliser des identifiants stables et persistants. Or certains noms de périphériques ne le sont pas forcément, notamment /dev/sd* (IDE, SATA, SCSI, USB…) car ils sont nommés dans l’ordre de leur découverte qui peut varier d’un démarrage à l’autre. Les noms de périphériques des volumes logiques LVM /dev/mapper/vg-lv sont stables (mais pas les noms de périphériques device-mapper /dev/dm-* vers lequels ils pointent, à ne pas utiliser directement). Si cette machine n’a qu’un seul SSD NVMe, alors il sera toujours nommé nvme0n1. Toutefois les numéros des partitions peuvent changer aussi lors de manipulations sur la table de partition (notamment ajout ou suppression de partitions logiques, ou mise à jour de Windows en multiboot) donc attention.

Si tu préfères des identifiants persistants plus parlants que les UUID, tu peux définir et utiliser des LABEL ou PARTLABEL suffisamment uniques pour éviter le risque de doublon (donc éviter « root », « home »…).

2 J'aime