[Boot] ACPI Error & Exception, start job, & AMD Grpahics

Support Debian
Tags: #<Tag:0x00007f74f6e35720>
#9

C’est bizarre ouais, j’ai du sdb5/6 dans le blkid et du sdc5/6 dans le fstab pour les UUID correspondants (ext4 et swap).

Du coup mis à part l’erreur en commentaire, je vois que le md0p3 qui est obsolète.
Mais ca me shoote le montage de mon nas quand je la commente.

J’ai testé l’option nomodeset après avoir installé les drivers sinon, j’obtiens un autre message d’erreur :

No UMS support in radeon module!

Je vais peut-être essayer de réinstaller avec buster du coup, vu que c’est une nouvelle installation, je ne perds qu’un peu de temps.

#10

pour l’uuid de resume c’est /etc/initramfs-tools/conf.d/resume

$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID="60e41088-15f8-4d62-93ba-4bfcbf36c48f"
#11

Aucune importance puisque les UUID sont utilisés, et normal car le nommage des disques au démarrage n’est pas déterministe.

Quels drivers ?

#12

Effectivement c’était bien ça ! Merci.

J’ai un soucis avec ma CG aussi, l’écran saute a chaque mouvement de souris avec les drivers d’installés.
Je les avais donc désinstallés pour l’instant.
Avec les drivers et l’option nomodeset l’écran ne saute plus mais j’ai un autre message d’erreur.

Du coup une idée pour cette histoire de ligne commentée et obsolète du fstab qui me shoote le montage du nas ?

Dans mon explorateur de fichier j’ai ce message

An error occurred while accessing 'Documents on 192.168.1.47', the system responded: mount: seul le superutilisateur peut monter //192.168.1.47/Documents sur /media/nas/docs

Je ne comprends pas le rapport avec la ligne en question.

#13

**[quote=“Weemix, post:12, topic:75682, full:true”]

Avec les drivers et l’option nomodeset l’écran ne saute plus mais j’ai un autre message d’erreur.
[/quote]

ce qui est plus important c’est que l’affichage graphique fonctionne

#14

Oui, c’est pour ça que sans les drivers ce n’était pas trop gênant, même si on sentait quelques saccades sur des changements de fenêtres.

#15

si le montage n’est pas fait ça parait compréhensible

liste les montages en cours

 mount
#16

Oui, le montage n’est pas fait.
C’est justement ma question : pourquoi est-ce que commenter une ligne de swap empêche le montage du nas qui se faisait correctement avant ? C’est là que je pige pas ^^

$ 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=8170768k,nr_inodes=2042692,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,noexec,relatime,size=1643064k,mode=755)
/dev/sdb5 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
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)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
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=17453)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1643060k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
#17

Délai d’activation du réseau ? Besoin d’ajouter l’option _netdev (cf. man mount) ?

Quels drivers ?

#18

le NAS est il toujours à l’adresse 192.168.1.47

sudo arp -n

sudo nmap -T4 -sP 192.168.1.0/24

#19

Je ne pense pas, après un test le problème reste le même. Et pourquoi avant de commenter la ligne obsolète le nas montait correctement (comme sous ubuntu auparavant) ?

//192.168.1.47/dev       /media/nas/dev      cifs    _netdev,credentials=/home/weemix/.smbcredentials,iocharset=utf8,sec=ntlm,vers=1.0 0 0

Les drivers propriétaires de ma CG (Sapphire R9 270X) via le paquet firmware-amd-graphics.
Avec le driver et l’option nomodeset ou sans le driver j’ai l’impression que c’est le même comportement.
Juste avec le driver l’écran saute constamment et donne mal au crane rapidement.

Oui :

Adresse                  TypeMap AdresseMat          Indicateurs           Iface
192.168.1.47             ether   00:11:32:5e:e3:5b   C                     enp30s0
192.168.1.254            ether   00:78:9e:71:85:9c   C                     enp30s0

Dès que je décommente cette ligne le montage s’effectue.
Avec mount -a le montage fonctionne quand la ligne est commentée.

#21

cifs-utils est bien installé?

apt list cifs-utils

#22

oui :

cifs-utils/stable,now 2:6.7-1 amd64  [installé]
#23

Parce que le délai induit par cette ligne faisait attendre suffisamment longtemps pour que le réseau soit opérationnel.

Ce ne sont pas des drivers mais des firmwares. Très différent. Un firmware est chargé sur le périphérique, alors qu’un driver s’exécute sur le système hôte.
Les firmwares sont utilisés par les pilotes du noyau. L’option nomodeset neutralise les pilotes dépendant de KMS comme le pilote (libre) radeon, donc avec cette option les firmwares ne sont pas utilisés.

As-tu essayé le noyau des backports, plus récent et gérant peut-être mieux ce GPU ?
As-tu testé d’autres modes graphiques (résolution, fréquence) ?

#24

Pour moi un firmware c’est un microgiciel dans un matériel.

Le paquet que j’ai installé, ne s’est pas installé sur ma CG ? Mais sur mon OS ? Ce n’est donc pas un driver ?

En base résolution (1440900) au lieu de la résolution native (25601440) le driver (firmware ?) ne fait plus sauter l’écran. EDIT : J’ai joué avec les fréquences également, sans succès.
Concernant le noyau des backports, j’avoue ne pas bien comprendre de quoi il est question.

EDIT : Nouvellement inscrit je ne peux plus poster de messages avant demain :confused:

Toujours pas :cry:

Je ne dis pas que ça n’est pas une bonne façon de faire, juste que ça ne fonctionne pas actuellement. Je n’ai peut-être pas encore assez creusé, je tenterai à nouveau un peu plus tard dans la soirée.

Est-ce qu’il est possible de voir les logs du démarrage ? Car je vois quelques lignes avec un failed rouge sur le montage, mais j’ai pas le temps de les lire. (un message en jaune aussi, peut-être un warning)

Un grand merci à tous les deux en tout cas pour votre temps et vos connaissances ! :wink:

#25

une piste intéressante à propos de NAS et Systemd

#26

Effectivement.

Il est installé sur le système hôte. Mais l’utilité des firmwares qu’il contient est d’être chargé sur les périphériques. En effet les firmwares de nombreux périphériques ne sont pas résidents dans une mémoire non volatile de ces derniers mais doivent être chargés par l’OS (en l’occurrence, par le pilote) à chaque démarrage. Pour l’OS, un firmware n’est qu’un “blob” (objet binaire) sans signification, contrairement à un programme exécutable ou un pilote (module).

Ce sont peut-être les timings du mode graphique choisi pour la résolution 2560*1440 qui ne sont pas bien supportés par l’écran. Y a-t-il d’autres fréquences disponibles pour cette résolution ?

L’archive stretch-backports contient des paquets plus récents de testing rétroportés pour stretch. Tu devrais pouvoir facilement trouver des informations avec un moteur de recherche.

1 J'aime
#27

pourtant, avec Systemd temporiser le montage pour les équipements réseau est aussi la solution indiqué par Arch
Si votre périphérique externe nécessite une autre unité systemd chargée (par exemple, le réseau pour un partage réseau), vous pouvez utiliser x-systemd.requires=x combiné avec x-systemd.automount pour reporter l'automation jusqu'à ce que l'unité soit disponible

https://wiki.archlinux.fr/Fstab#Appareils_externes

systemctl status network-online.target
● network-online.target - Network is Online
   Loaded: loaded (/lib/systemd/system/network-online.target; static; vendor preset: enabled)
   Active: active since Fri 2018-01-19 14:39:41 CET; 3h 9min ago
     Docs: man:systemd.special(7)
           https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget

janv. 19 14:39:41 debian systemd[1]: Reached target Network is Online.

donc essayer avec

x-systemd.requires=network-online.target,x-systemd.device-timeout=10

pour le journal

journalctl -xb | grep mount

les erreurs

journalctl -xb -p err

#28

J’ai réussi à installer la dernière version du paquet firmware-amd-graphics, mais ça ne résout pas le problème.
Ce qui est étrange c’est lorsque je connecte à la fois en DisplayPort et en HDMI, tout va bien.
Dès que je remets une seule sortie ça ressaute.

Merci pour le journal, avec le message d’erreur j’ai réussi à trouver un sujet plus ou moins similaire.
En ajoutant l’option suivante ça fonctionne presque parfaitement : comment=systemd.automount
Encore un petit message d’erreur lors de la première ouverture mais ça ne bloque pas le montage.

//192.168.1.47/dev       /media/nas/dev      cifs    credentials=/home/weemix/.smbcredentials,iocharset=utf8,sec=ntlm,vers=1.0,comment=systemd.automount        0       0

Je n’ai plus vraiment le temps de me pencher là dessus avant le week-end prochain, ça ira bien comme ça en attendant.
Merci pour vos contributions !

#29

Ce n’est pas (seulement) les firmwares des backports que je te suggérais d’installer mais le noyau.

linux-image-4.14.0-0.bpo.3-amd64 actuellement.