#26 Le 17/09/2020, à 21:15
- Coeur Noir
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Démarrage normal revenu après :
django@ASGARD:~$ sudo update-initramfs -u -k $(uname -r)
update-initramfs: Generating /boot/initrd.img-5.4.0-47-generic
cryptsetup: ERROR: Couldn't resolve device
/dev/disk/by-uuid/22faac8b-34aa-4425-98a7-184d0613ccff
I: The initramfs will attempt to resume from /dev/sda7
I: (UUID=3a205e8d-920c-44f8-b614-7c268fb25f12)
I: Set the RESUME variable to override this.
django@ASGARD:~$
Est-ce que j'ajoute
# lecteur cartes
blacklist ums_realtek
à
/etc/modprobe.d/blacklist.conf
???
J'ai déjà viré le ums-realtek.conf de /etc/modprobe.d/ histoire de revenir à une situation « vanille » ( voir #18 ).
Et puis tiens là aucun souci pour changer l'étiquette de sda1 :
django@ASGARD:~$ sudo e2label /dev/sda1 Budgie
[sudo] Mot de passe de django :
django@ASGARD:~$ lsblk -fe7 -o +SIZE
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT SIZE
sda 111,8G
├─sda1 ext4 Budgie 25c341fb-320d-4a4a-9d64-b08c5fe55540 3,9G 78% / 23,9G
├─sda2 ext4 Ubuntu16.04 90a0f248-65ad-4247-b7ba-fb4e9f632905 27G
├─sda3 1K
├─sda5 ext4 Ubuntu20.04 f85e730c-6ea2-4dfe-9f16-10b47958f049 28G
├─sda6 ext4 autre_syst 7ea83f3d-196f-4821-8be1-7c91fcc0cf34 28G
└─sda7 swap swap 3a205e8d-920c-44f8-b614-7c268fb25f12 [SWAP] 5G
sdb 931,5G
└─sdb1 ext4 DATA b19322e6-8a6d-4e24-b87f-4b0155b41963 370,8G 54% /media/DATA 930,8G
sr0 1024M
django@ASGARD:~$
Dernière modification par Coeur Noir (Le 17/09/2020, à 21:15)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#27 Le 17/09/2020, à 21:34
- moko138
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
cryptsetup: ERROR: Couldn't resolve device
/dev/disk/by-uuid/22faac8b-34aa-4425-98a7-184d0613ccff
Apparemment, le #25 reste à appliquer (plusieurs points, dans l'ordre).
Dernière modification par moko138 (Le 17/09/2020, à 21:34)
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#28 Le 17/09/2020, à 22:37
- Coeur Noir
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Ok je vais refaire le tour car bizarreries.
Sous 20.04 il n'y a pas de fichier resume dans
django@ASGARD:~$ ls /etc/initramfs-tools/conf.d/
django@ASGARD:~$
pourtant la commande sudo update-initramfs -u -k $(uname -r)
avait bien évalué
update-initramfs: Generating /boot/initrd.img-5.4.0-47-generic
cryptsetup: ERROR: Couldn't resolve device
/dev/disk/by-uuid/22faac8b-34aa-4425-98a7-184d0613ccff
I: The initramfs will attempt to resume from /dev/sda7
I: (UUID=3a205e8d-920c-44f8-b614-7c268fb25f12)
I: Set the RESUME variable to override this.
Où est donc cette variable RESUME ?
Sous 16.04, la même commande ne m'a rien retourné, j'ai donc cru que tout allait bien pourtant là il y a bien un ficher resume qui contient
RESUME=UUID=22faac8b-34aa-4425-98a7-184d0613ccff
soit une référence à l'ancienne partition swap.
Cependant ce système démarre sans broncher.
Dernière modification par Coeur Noir (Le 17/09/2020, à 22:39)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#29 Le 17/09/2020, à 22:53
- xubu1957
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Vu > ./viewtopic.php?pid=22017509#p22017509
Ne faudrait-il pas commenter la ligne UUID de la swap ?
Conseils pour les nouveaux demandeurs et pas qu'eux
Important : Pensez à passer vos sujets en [Résolu] lorsque ceux-ci le sont, au début du titre en cliquant sur Modifier sous le premier message, et un bref récapitulatif de la solution à la fin de celui-ci. Merci. Membre de Linux-Azur
Hors ligne
#30 Le 17/09/2020, à 23:07
- Coeur Noir
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Sous 16.04 sudo update-initramfs -u -k all a fait son office sans retour particulier, sur 3 noyaux.
L'update grub a bien vu mes systèmes existants ( il n'y en a que 2 en ce moment, 2 partitions /4 sont vides )
Et j'ai corrigé l'uuid dans le fichier resume.
Sous 20.04 - alors que j'ai déjà passé cette commande pour le noyau en cours, j'ai comme retour :
django@ASGARD:~$ sudo update-initramfs -u -k all
[sudo] Mot de passe de django :
update-initramfs: Generating /boot/initrd.img-5.4.0-47-generic
cryptsetup: ERROR: Couldn't resolve device
/dev/disk/by-uuid/22faac8b-34aa-4425-98a7-184d0613ccff
I: The initramfs will attempt to resume from /dev/sda7
I: (UUID=3a205e8d-920c-44f8-b614-7c268fb25f12)
I: Set the RESUME variable to override this.
update-initramfs: Generating /boot/initrd.img-5.4.0-45-generic
cryptsetup: ERROR: Couldn't resolve device
/dev/disk/by-uuid/22faac8b-34aa-4425-98a7-184d0613ccff
I: The initramfs will attempt to resume from /dev/sda7
I: (UUID=3a205e8d-920c-44f8-b614-7c268fb25f12)
I: Set the RESUME variable to override this.
django@ASGARD:~$
Or quand on liste /dev/disk…
django@ASGARD:~$ ls /dev/disk/by-uuid/
25c341fb-320d-4a4a-9d64-b08c5fe55540 90a0f248-65ad-4247-b7ba-fb4e9f632905
3a205e8d-920c-44f8-b614-7c268fb25f12 b19322e6-8a6d-4e24-b87f-4b0155b41963
7ea83f3d-196f-4821-8be1-7c91fcc0cf34 f85e730c-6ea2-4dfe-9f16-10b47958f049
django@ASGARD:~$
…point de 22faac8b-34aa-4425-98a7-184d0613ccff !
Puis l'update grub a bien vu mes 2 systèmes existants.
_________________________
J'ai toujours toutes les ± 53 secondes un
[ 163.140354] usb 3-6: reset high-speed USB device number 3 using xhci_hcd
mais pas de
usb 3-6: device not accepting address 5, error -62
ou
usb 3-6: device descriptor read/64, error -110
Ok la prochaine étape sera sans doute de virer ( ou au moins déconnecter physiquement ) ce lecteur multicartes. J'aimerais quand même m'assurer à quel port correspond usb 3-6 : je soupçonne la fente lecteur SD, la seule dont j'ai absolument besoin finalement.
Dernière modification par Coeur Noir (Le 17/09/2020, à 23:30)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#31 Le 17/09/2020, à 23:21
- Coeur Noir
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Vu > ./viewtopic.php?pid=22017509#p22017509
Ne faudrait-il pas commenter la ligne UUID de la swap ?
Cette Budgie 20.04 est en fait la résultante de plusieurs mises à niveau ( 17.10 → 18.04 → 19.10 → 20.04 ).
Au moment de l'installation ( 17.10 ) la partition de swap était encore la situation par défaut, ça n'est plus le cas aujourd'hui sur une 20.04 qui utilise un fichier d'échange par défaut dès l'installation.
Sauf si une partition d'échange swap est repérée par l'installateur, dans ce cas c'est elle qui sera utilisée en priorité.
Bref. Ça explique pourquoi j'ai toujours une partition swap.
Ce qui n'explique pas de où 20.04 tire cette référence ( uuid=22faac8b-34aa-4425-98a7-184d0613ccff ) à une partition qui n'existe plus ( anciennement sdb5 ) ?
Pas de /etc/initramfs-tools/conf.d/resume puisqu'un tel fichier n'existe pas - le crée-je ?
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#32 Le 17/09/2020, à 23:45
- inbox
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Si tu utilises la même partition sur deux système en formatant, c'est le 2ème qui système installé qui renomme l'UUID en dernier et qui a raison. C'est peut-être ça ton problème ?
Un problème résolu ? Indiquez le en modifiant le titre du sujet.
Hors ligne
#33 Le 18/09/2020, à 00:38
- Coeur Noir
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Pourquoi pas, pourtant on a bien le même uuid pour la même partition sous chaque système, 16.04 :
coeurnoir@Asgard:~$ lsblk -fe7 -o +SIZE
NAME FSTYPE LABEL UUID MOUNTPOINT SIZE
sdb 931,5G
└─sdb1 ext4 DATA b19322e6-8a6d-4e24-b87f-4b0155b41963 /media/DATA 930,8G
sr0 1024M
sda 111,8G
├─sda2 ext4 Ubuntu16.04 90a0f248-65ad-4247-b7ba-fb4e9f632905 / 27G
├─sda7 swap swap 3a205e8d-920c-44f8-b614-7c268fb25f12 [SWAP] 5G
├─sda5 ext4 Ubuntu20.04 f85e730c-6ea2-4dfe-9f16-10b47958f049 28G
├─sda1 ext4 Budgie19.10 25c341fb-320d-4a4a-9d64-b08c5fe55540 /media/coeurnoir/Budgie19.10 23,9G
└─sda6 ext4 autre_syst 7ea83f3d-196f-4821-8be1-7c91fcc0cf34 28G
coeurnoir@Asgard:~$
et 18.04 :
django@ASGARD:~$ lsblk -fe7 -o +SIZE
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT SIZE
sda 111,8G
├─sda1 ext4 Budgie 25c341fb-320d-4a4a-9d64-b08c5fe55540 3,9G 78% / 23,9G
├─sda2 ext4 Ubuntu16.04 90a0f248-65ad-4247-b7ba-fb4e9f632905 27G
├─sda3 1K
├─sda5 ext4 Ubuntu20.04 f85e730c-6ea2-4dfe-9f16-10b47958f049 28G
├─sda6 ext4 autre_syst 7ea83f3d-196f-4821-8be1-7c91fcc0cf34 28G
└─sda7 swap swap 3a205e8d-920c-44f8-b614-7c268fb25f12 [SWAP] 5G
sdb 931,5G
└─sdb1 ext4 DATA b19322e6-8a6d-4e24-b87f-4b0155b41963 370,8G 54% /media/DATA 930,8G
sr0 1024M
django@ASGARD:~$
Ce souci là est réglé apparemment ( les 2 systèmes démarrent sans encombre rapidement, plus de messages concernant l'ancienne swap ) - même si je ne comprends pas bien d'où il est venu.
Maintenant faut-il que je cherche à « éliminer » la source des répétitions de usb 3-6: reset high-speed USB device number 3 using xhci_hcd ?
J'attends un prochain démarrage qui traînera en longueur, pour voir ?
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#34 Le 18/09/2020, à 01:38
- Coeur Noir
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Ce souci là est réglé apparemment … non pas complètement.
J'ai blacklisté ums_realtek via ajout de
# lecteur cartes
blacklist ums_realtek
à
/etc/modprobe.d/blacklist.conf
suivi d'un
sudo update-initramfs -u -k all
qui pour chaque noyau m'a répondu
update-initramfs: Generating /boot/initrd.img-5.4.0-47-generic
cryptsetup: ERROR: Couldn't resolve device
/dev/disk/by-uuid/22faac8b-34aa-4425-98a7-184d0613ccff
update-initramfs: Generating /boot/initrd.img-5.4.0-45-generic
cryptsetup: ERROR: Couldn't resolve device
/dev/disk/by-uuid/22faac8b-34aa-4425-98a7-184d0613ccff
Rrrraaa… ça sort d'où cet uuid ?
En attendant, plus de ums_realtek sur ce système :
django@ASGARD:~$ lsmod
Module Size Used by
snd_hda_codec_realtek 126976 1
snd_hda_codec_generic 81920 1 snd_hda_codec_realtek
intel_rapl_msr 20480 0
ledtrig_audio 16384 2 snd_hda_codec_generic,snd_hda_codec_realtek
snd_hda_codec_hdmi 61440 1
intel_rapl_common 24576 1 intel_rapl_msr
x86_pkg_temp_thermal 20480 0
snd_hda_intel 53248 5
intel_powerclamp 20480 0
snd_intel_dspcfg 24576 1 snd_hda_intel
mei_hdcp 24576 0
snd_hda_codec 131072 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
coretemp 20480 0
snd_hda_core 90112 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
snd_hwdep 20480 1 snd_hda_codec
snd_pcm 106496 5 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
snd_seq_midi 20480 0
snd_seq_midi_event 16384 1 snd_seq_midi
snd_rawmidi 36864 1 snd_seq_midi
kvm 663552 0
rapl 20480 0
intel_cstate 20480 0
snd_seq 69632 2 snd_seq_midi,snd_seq_midi_event
eeepc_wmi 16384 0
asus_wmi 32768 1 eeepc_wmi
snd_seq_device 16384 3 snd_seq,snd_seq_midi,snd_rawmidi
snd_timer 36864 2 snd_seq,snd_pcm
sparse_keymap 16384 1 asus_wmi
wmi_bmof 16384 0
mei_me 40960 1
joydev 24576 0
input_leds 16384 0
mei 106496 3 mei_hdcp,mei_me
snd 90112 20 snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm,snd_rawmidi
soundcore 16384 1 snd
mac_hid 16384 0
sch_fq_codel 20480 2
parport_pc 40960 0
ppdev 24576 0
lp 20480 0
parport 53248 3 parport_pc,lp,ppdev
ip_tables 32768 0
x_tables 40960 1 ip_tables
autofs4 45056 2
hid_generic 16384 0
uas 28672 0
usbhid 57344 0
usb_storage 77824 1 uas
hid 131072 2 usbhid,hid_generic
i915 1986560 4
crct10dif_pclmul 16384 1
crc32_pclmul 16384 0
ghash_clmulni_intel 16384 0
i2c_algo_bit 16384 1 i915
mxm_wmi 16384 0
drm_kms_helper 184320 1 i915
aesni_intel 372736 0
syscopyarea 16384 1 drm_kms_helper
sysfillrect 16384 1 drm_kms_helper
sysimgblt 16384 1 drm_kms_helper
fb_sys_fops 16384 1 drm_kms_helper
crypto_simd 16384 1 aesni_intel
cryptd 24576 2 crypto_simd,ghash_clmulni_intel
drm 491520 6 drm_kms_helper,i915
glue_helper 16384 1 aesni_intel
r8169 90112 0
realtek 24576 1
ahci 40960 3
libahci 32768 1 ahci
i2c_i801 32768 0
lpc_ich 24576 0
video 49152 2 asus_wmi,i915
wmi 32768 3 asus_wmi,wmi_bmof,mxm_wmi
django@ASGARD:~$
et plus de répétitions de usb 3-6: reset high-speed USB device number 3 using xhci_hcd
(…)
[ 12.680577] rfkill: input handler disabled
[ 171.868375] kauditd_printk_skb: 41 callbacks suppressed
[ 171.868377] audit: type=1400 audit(1600385182.352:52): apparmor="DENIED" operation="capable" profile="/snap/core/9993/usr/lib/snapd/snap-confine" pid=3647 comm="snap-confine" capability=4 capname="fsetid"
[ 175.203676] audit: type=1107 audit(1600385185.688:53): pid=795 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.bluez" pid=3647 label="snap.chromium.chromium"
exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?'
[ 176.411111] audit: type=1326 audit(1600385186.896:54): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=3916 comm="chrome" exe="/snap/chromium/1298/usr/lib/chromium-browser/chrome" sig=0 arch=c000003e syscall=203 compat=0 ip=0x7f8cdfc16b9f code=0x50000
[ 176.411131] audit: type=1326 audit(1600385186.896:55): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=3916 comm="chrome" exe="/snap/chromium/1298/usr/lib/chromium-browser/chrome" sig=0 arch=c000003e syscall=203 compat=0 ip=0x7f8cdfc16b9f code=0x50000
[ 176.411138] audit: type=1326 audit(1600385186.896:56): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=3916 comm="chrome" exe="/snap/chromium/1298/usr/lib/chromium-browser/chrome" sig=0 arch=c000003e syscall=203 compat=0 ip=0x7f8cdfc16b9f code=0x50000
[ 176.411168] audit: type=1326 audit(1600385186.896:57): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=3916 comm="chrome" exe="/snap/chromium/1298/usr/lib/chromium-browser/chrome" sig=0 arch=c000003e syscall=203 compat=0 ip=0x7f8cdfc16b9f code=0x50000
[ 398.579269] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
django@ASGARD:~$
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#35 Le 18/09/2020, à 07:06
- moko138
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
1) Avant tout, vérifier /etc/initramfs-tools/conf.d/resume dans chaque S.E. et y supprimer toute référence à l'uuid périmé 22faac8b-(...)ccff
2) Mais ensuite, bordelum ! tu oublies comment fonctionnent les grubs !
Rappelle-toi qu'un sudo update-grub consulte les fichiers /boot/grub/grub.cfg de TOUS tes S.E., y compris sur les partitions non montées.
Tu en as au moins un qui contient de l'info périmée.
Et peut-être as-tu oublié avoir bidouillé un des scripts /etc/grub.d/* ?
Alors tu peux faire tous les sudo update-initramfs -u -k $(uname -r) que tu veux, ça ne suffira pas.
Je le répète :
2.1) Fais dans chaque S.E. un
sudo update-initramfs -u -k all
je dis bien "-k all" et pas ce "-k $(uname -r)" qui est trop restrictif, puisque tu as des systèmes à plusieurs noyaux..
2.2) Fais dans chaque S.E. un
sudo update-grub
en finissant par le S.E. contenant le grub maître !
3) "cryptsetup"
À cause de ce fichu
update-initramfs: Generating /boot/initrd.img-5.4.0-47-generic
cryptsetup: ERROR: Couldn't resolve device
/dev/disk/by-uuid/22faac8b-34aa-4425-98a7-184d0613ccff
je ne suis pas du tout certain que ce qui précède suffise.
N'aurais-tu pas (eu) une appli de chiffrement, qui aurait laissé des traces dans /etc/initramfs-tools/* ou dans je ne sais quel /etc/crypt*/* ou keepass.conf ?
Et, si ce n'est pas indiscret, qu'y a-t-il en
└─sda6 ext4 autre_syst 7ea83f3d-196f-4821-8be1-7c91fcc0cf34
?
= =
4) Quand tes démarrages de tous tes S.E. auront cessé de mentionner un uuid périmé et de patienter 90 secondes(*),
alors tu pourras utilement remplacer dans le fstab de chaque S.E.
none swap sw 0 0
par
none swap sw,nofail 0 0
.
Mais tu peux dès maintenant mettre le ",nofail" sans avoir corrigé le "Couldn't resolve device".
___
(*) En #23, tu mentionnes un trou de cinq minutes dans fstab. En réalité, c'est 330 secondes. Qui n'est pas un multiple de 90 secondes.
C'est l'indice d'un ou plusieurs autres problèmes, qui te bouffent 240 secondes (= 330 - les 90 de l'uuid périmé de swap).
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#36 Le 18/09/2020, à 10:19
- inbox
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
L'erreur suivante :
update-initramfs: Generating /boot/initrd.img-5.4.0-47-generic
cryptsetup: ERROR: Couldn't resolve device
/dev/disk/by-uuid/22faac8b-34aa-4425-98a7-184d0613ccff
update-initramfs: Generating /boot/initrd.img-5.4.0-45-generic
cryptsetup: ERROR: Couldn't resolve device
/dev/disk/by-uuid/22faac8b-34aa-4425-98a7-184d0613ccff
provient probablement du contenu du fichier /etc/crypttab.
Un problème résolu ? Indiquez le en modifiant le titre du sujet.
Hors ligne
#37 Le 18/09/2020, à 11:57
- moko138
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
provient probablement du contenu du fichier /etc/crypttab.
Merci inbox !!!
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#38 Le 18/09/2020, à 16:45
- Coeur Noir
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Moko, je t'assure que :
les points ont été vus et revus. Un doute sur le 2.1.
1⋅ il n'y avait pas de fichier resume sous 20.04 - il y en a un maintenant, qui contient l'uuid de ma swap en sda7. Le fichier resume de la 16.04 a été corrigé aussi. Lui existait bien.
2⋅ je n'avais pas oublié - juste qu'à priori je ne voyais pas le rapport entre la swap et les grub.
2.1⋅ fut fait, plusieurs fois. Pas de script persos dans /etc/grub.d/* par contre j'enlève les droits d'exécution à 30_os-prober sur tous les systèmes ( 1 seul en ce moment donc ) sauf le dernier installé.
→ Donc c'est là potentiellement qu'il y a des traces plus anciennes ¡¿?!
2.2⋅ fait d'abord en 16.04 puis en 20.04, SE dont le grub est affiché au démarrage.
Déjà précisé : je n'ai "que" 2 systèmes ici, les partitions autre_syst et ubuntu20.04 sont vides ( depuis des mois - elles n'ont jamais vu l'ombre de l'ombre d'un système ).
N'aurais-tu pas (eu) une appli de chiffrement, qui aurait laissé des traces dans /etc/initramfs-tools/* ou dans je ne sais quel /etc/crypt*/* ou keepass.conf ?
J'allais dire non.
Mais j'ai utilisé - et n'utilise plus depuis des mois - deja-dup/duplicity pour des sauvegardes, qui me semble-t-il, sont chiffrées ?
Sinon aucune partition chiffrée ici.
cat /etc/crypttab
# <target name> <source device> <key file> <options>
…vide donc ? Retour au 2.1 et tests, je reviens…
Dernière modification par Coeur Noir (Le 18/09/2020, à 17:20)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#39 Le 18/09/2020, à 16:58
- xubu1957
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Je lis :
swap
Le périphérique de bloc chiffré sera utilisé comme une partition de swap et sera formaté comme une partition de swap après la configuration du périphérique de bloc chiffré. Le périphérique de bloc sous-jacent sera de nouveau formaté comme une partition de swap non chiffrée après destruction du périphérique de bloc chiffré. (Cela permet le partage d'une seule partition de swap entre plusieurs installations de système d'exploitation, certains chiffrant la partition de swap, d'autres non.)
ATTENTION : l'utilisation de l'option swap détruira le contenu de la partition nommée à chaque démarrage. Aussi, assurez-vous que le périphérique de bloc sous-jacent soit correctement spécifié.
Conseils pour les nouveaux demandeurs et pas qu'eux
Important : Pensez à passer vos sujets en [Résolu] lorsque ceux-ci le sont, au début du titre en cliquant sur Modifier sous le premier message, et un bref récapitulatif de la solution à la fin de celui-ci. Merci. Membre de Linux-Azur
Hors ligne
#40 Le 18/09/2020, à 17:08
- inbox
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Si tu as deux système, tu as bien vérifié le contenu de "/etc/crypttab" sur chacun ?
Un problème résolu ? Indiquez le en modifiant le titre du sujet.
Hors ligne
#41 Le 18/09/2020, à 17:13
- Coeur Noir
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Si tu as deux système, tu as bien vérifié le contenu de "/etc/crypttab" sur chacun ?
yep, les 2 idem, vides.
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#42 Le 18/09/2020, à 17:33
- Coeur Noir
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
j'enlève les droits d'exécution à 30_os-prober sur tous les systèmes ( 1 seul en ce moment donc ) sauf le dernier installé
…arrrff, je ne l'avais pas fait cette fois.
Des soucis voisins évoqués sur launchpad ou askubuntu, sans être 100% identiques :
⋅ https://bugs.launchpad.net/ubuntu/+sour … ug/1720036
⋅ https://bugs.launchpad.net/ubuntu/+sour … ug/1802617
⋅ https://askubuntu.com/questions/1006307 … -swap-file
⋅ https://askubuntu.com/questions/316486/ … ing-update
Encore une fois, je n'utilise pas de chiffrement donc la première réponse du dernier lien me tente…
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#43 Le 18/09/2020, à 17:44
- Coeur Noir
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Alors :
sudo apt-get remove cryptsetup
sudo update-grub
sudo grub-install /dev/sda
et au final :
django@ASGARD:~$ sudo update-initramfs -c -k all
update-initramfs: Generating /boot/initrd.img-5.4.0-45-generic
update-initramfs: Generating /boot/initrd.img-5.4.0-47-generic
plus de trace de l'ancien uuid - donc c'est lié à cryptsetup ?
Apparemment cryptsetup vient avec l'installation de l'utilitaire multisystem ( pour créer des clés de boot multi-OS ).
Les réinstaller ramène immédiatement le message
django@ASGARD:~$ sudo apt install multisystem
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés :
cpu-checker cryptsetup cryptsetup-bin cryptsetup-initramfs cryptsetup-run fatresize gtkdialog ipxe-qemu ipxe-qemu-256k-compat-efi-roms libaio1
libcacard0 libfdt1 libglade2-0 libiscsi7 libpmem1 libslirp0 libspice-server1 libusbredirparser1 libvirglrenderer1 libvte-common libvte9 msr-tools
ovmf qemu qemu-block-extra qemu-kvm qemu-system-common qemu-system-data qemu-system-gui qemu-system-x86 qemu-utils seabios syslinux syslinux-common
Paquets suggérés :
keyutils samba vde2 debootstrap
Les NOUVEAUX paquets suivants seront installés :
cpu-checker cryptsetup cryptsetup-bin cryptsetup-initramfs cryptsetup-run fatresize gtkdialog ipxe-qemu ipxe-qemu-256k-compat-efi-roms libaio1
libcacard0 libfdt1 libglade2-0 libiscsi7 libpmem1 libslirp0 libspice-server1 libusbredirparser1 libvirglrenderer1 libvte-common libvte9 msr-tools
multisystem ovmf qemu qemu-block-extra qemu-kvm qemu-system-common qemu-system-data qemu-system-gui qemu-system-x86 qemu-utils seabios syslinux
syslinux-common
0 mis à jour, 35 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 6962 ko/28,2 Mo dans les archives.
Après cette opération, 86,1 Mo d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] o
(…)
update-initramfs: Generating /boot/initrd.img-5.4.0-47-generic
cryptsetup: ERROR: Couldn't resolve device
/dev/disk/by-uuid/22faac8b-34aa-4425-98a7-184d0613ccff
django@ASGARD:~$
Dernière modification par Coeur Noir (Le 18/09/2020, à 17:54)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#44 Le 18/09/2020, à 18:37
- Coeur Noir
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Donc j'ai procédé aux mêmes manip's sur les 2 systèmes, en finissant par 20.04 :
⋅ virer cryptsetup et donc multisystem,
⋅ sudo update-grub
⋅ sudo grub-install /dev/sda ( uniquement depuis la 20.04 )
⋅ sudo update-initramfs -u -k all
uniquement sur la 16.04 :
⋅ sudo chmod a-x /etc/grub.d/30_os-prober
⋅ sudo update-grub
Nota :
⋅ les premières lenteurs de démarrage n'avaient rien à voir avec cette histoire de partition swap, mais avec un périphérique usb.
⋅ ça fait quelques dizaines d'heures que je n'ai pas revu telles lenteurs.
⋅ sous 20.04 le module ums-realtek du lecteur de cartes est blacklisté, pas sous 16.04.
⋅ ce test est-il fiable : diverses cartes micro SD sont lues/écrites sans pépin majeur* dans la fente micro SD de ce lecteur. Les mêmes micro cartes mises en adaptateur SD dans la fente SD de ce même lecteur ne montent pas du tout ?
* sans pépin majeur, mais dmesg montre quand même des erreurs d'I/O - et sous 16.04 donc car sous 20.04 bah sans module ums-realtek, lecteur de cartes inactif.
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#45 Le 18/09/2020, à 20:10
- moko138
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Bravo pour avoir identifié la cause :
multisystem > cryptsetup > "Couldn't resolve device"
!!!
= =
Désactiver les scripts 30_os-prober (sauf le maître) avait un sens tant que grub-pc (grub2) était affecté de ce bug qui faisait (dans le cas de plusieurs grubs) enfler mutuellement et sans mesure les fichiers /boot/grub/grub.cfg (parfois plusieurs dizaines de Mo chacun). Et rallongeait d'autant les démarrages.
Mais ça fait plusieurs années que ce bug n'existe plus !
Alors pourquoi conserves-tu ce chmod -x ?
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#46 Le 18/09/2020, à 21:05
- Coeur Noir
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Alors pourquoi conserves-tu ce chmod -x ?
Par habitude ? ( sous 14.04 et 16.04 c'était nécessaire - j'avais bien vu les grub.cfg enfler… )
Parce qu'il s'agissait d'un bug ? Résolu depuis quand ? En 2017 il était toujours là - et donc c'est depuis cette discussion que je désactive les 30_os-prober.
Si tu me dis que c'est safe, ma foi, ça fera une manip' de moins…
J'ai peut-être identifié la cause ( cryptsetup ) mais rien résolu du tout je pense, puisque dès que je réinstalle multisystem/cryptsetup, ça se remet à râler…
Dernière modification par Coeur Noir (Le 18/09/2020, à 23:18)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#47 Le 18/09/2020, à 21:20
- inbox
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Sans enlever de paquet, essaye ceci :
sudo swapoff -a
sudo update-initramfs -c -k all
sudo swapon -a
Un problème résolu ? Indiquez le en modifiant le titre du sujet.
Hors ligne
#48 Le 18/09/2020, à 21:22
- marcodel
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
salut
Désactiver les scripts 30_os-prober (sauf le maître) avait un sens tant que grub-pc (grub2) était affecté de ce bug qui faisait (dans le cas de plusieurs grubs) enfler mutuellement et sans mesure les fichiers /boot/grub/grub.cfg (parfois plusieurs dizaines de Mo chacun). Et rallongeait d'autant les démarrages.
Mais ça fait plusieurs années que ce bug n'existe plus !
tu es sur ?
j'ais eu ce bug cette annee sur une 20.04
perso j'ajoutes cette ligne dans /etc/default/grub des os secondaire
GRUB_DISABLE_OS_PROBER=true
a+
edit
j'ais reactiver os-prober sur un os secondaire >> update-grub
reboot sur os principal >> update-grub
grub.cfg a gonfle
pour moi le bug est toujours present
edit
Dernière modification par marcodel (Le 18/09/2020, à 22:44)
Hors ligne
#49 Le 18/09/2020, à 22:53
- moko138
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
Ma source : Babdu89 en ./viewtopic.php?pid=21935712#p21935712
Des *buntu en multi-amorçage, à grub de versions supérieures ou égales à v2.0 échappent au bug.
Mais si une au moins des *buntu utilise encore une version 1.9* de grub, alors le bug se manifestera.
= =
Par ailleurs, je rappelle l'autre solution anti-inflation,
la solution que tout le monde oublie bien qu'elle soit plus simple et plus légère :
un seul grub (*) pour tout les S.E.
___
(*) grub non bidouillé, donc avec os-prober fonctionnel.
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#50 Le 18/09/2020, à 22:57
- moko138
Re : Démarrage devenu un peu lent, Ubuntu ( budgie ) 20.04
marcodel,
quelles sont les versions de grub sur chacun des GNU/Linux présents ?
Il suffit d'un seul grub en v1.9*, par exemple celui d'une 12.04...
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne