2
Bonjour,
J'essaie de compiler mon noyau et je bloque. J'ai peu d'expérience en la matière et je pense que la solution est très bête, mais vraiment j'ai cherché et je ne comprends pas, d'autant que j'ai réussi à passer cette étapê sans rencontrer d'erreur auparavant.
En résumé , j'ai désintallé les sources du noyau et nettoyé mon /usr/src dans lequel trainaient des tas de vieilles choses inutiles, puis j'ai de nouveau installé les sources du noyau. Elles apparaissent bien et je crée un lien vers /usr/src/linux :
# cd /usr/src
# ln -sfn linux-4.12.14-lp151.28.48/ linux
# ls
linux linux-4.12.14-lp151.28.48
# cd linux
# ls -a
. .config .mailmap Documentation README.SUSE certs firmware ipc mm security usr
.. .get_maintainer.ignore COPYING MAINTAINERS arch crypto fs kernel net sound virt
.cocciconfig .gitattributes CREDITS README block drivers init lib samples tools
Simplement à partir de là aucune des commandes habituellement utilisées pour préparer ou effectuer une compilation ne fonctionne :
# make clean
make: *** No rule to make target 'clean'. Stop.
# make mrproper
make: *** No rule to make target 'mrproper'. Stop.
# make menuconfig
make: *** No rule to make target 'menuconfig'. Stop.
# make
make: *** No targets specified and no makefile found. Stop.
Un
cp /boot/config-$(uname -r) /usr/src/linux/.config
ne change rien.
Une idée d'où peut venir le problème ? J'ai cherché sur le net et je n'ai rien trouvé qui me semble correspondre à mon cas.
4
Ah, mais c'est que ça s'annonce pas simple...
# sh amd-driver-installer-catalyst-13.1-legacy-linux-x86.x86_64.run
Created directory fglrx-install.RubEZz
Verifying archive integrity... All good.
Uncompressing AMD Catalyst(TM) Proprietary Driver-8.97.100.7...
=====================================================================
AMD Catalyst(TM) Proprietary Driver Installer/Packager
=====================================================================
Detected configuration:
Architecture: x86_64 (64-bit)
X Server: X.Org 6.9 or later 64-bit
[...]
Une fenêtre s'affiche, où j'ai le choix entre "install Driver 8.97 on X.Org 6.9 or later 64-bit" et "Generate Distribution Specific Driver Package". Si je fais le premier choix, j'obtiens ce message d'erreur :
# cat /usr/share/ati/fglrx-install.log
Check if system has the tools required for installation.
fglrx installation requires that the system have kernel headers. /lib/modules/4.12.14-lp151.28.48-default/build/include/linux/version.h cannot be found on this system.
One or more tools required for installation cannot be found on the system. Install the required tools before installing the fglrx driver.
Optionally, run the installer with --force option to install without the tools.
Forcing install will disable AMD hardware acceleration and may make your system unstable. Not recommended.
Je n'ai aucune idée de comment je pourrais forcer l'install, et il manque les kernel-headers... J'ai essayé de creuser de ce côté. J'ai cru comprendre que les kernel-headers ne se faisaient plus depuis quelque temps en tant que paquets séparés, mais qu'on les avait avec les sources du noyau.
J'ai essayé d'activer les dépôts de source, d'installer les bibliothèques de dev et les sources du noyau, un peu à l'aveugle car je n'y connais à peu près rien.
Je n'ai pas compris comment installer les sources du noyau par les dépôts de Yast (je ne vois aucun paquet dans Source Repository).
Je suis passé par cette page. J'arrive visiblement à installer les sources (Yast me dit "Installation was successfull"), mais
# zypper se kernel-*
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+---------------------------------+---------------------------------------------------------------+-----------
| kernel-debug | A Debug Version of the Kernel | srcpackage
| kernel-debug | A Debug Version of the Kernel | package
| kernel-debug-base | A Debug Version of the Kernel - base modules | package
| kernel-debug-base-debuginfo | Debug information for package kernel-debug-base | package
| kernel-debug-debuginfo | Debug information for package kernel-debug | package
| kernel-debug-debugsource | Debug sources for package kernel-debug | package
| kernel-debug-devel | Development files necessary for building kernel modules | package
| kernel-debug-devel-debuginfo | Debug information for package kernel-debug-devel | package
| kernel-default | The Standard Kernel | srcpackage
i+ | kernel-default | The Standard Kernel | package
| kernel-default-base | The Standard Kernel - base modules | package
| kernel-default-base-debuginfo | Debug information for package kernel-default-base | package
| kernel-default-debuginfo | Debug information for package kernel-default | package
| kernel-default-debugsource | Debug sources for package kernel-default | package
i | kernel-default-devel | Development files necessary for building kernel modules | package
| kernel-default-devel-debuginfo | Debug information for package kernel-default-devel | package
i | kernel-devel | Development files needed for building kernel modules | package
| kernel-docs | Kernel Documentation | package
| kernel-docs | Kernel Documentation | srcpackage
| kernel-docs-html | Kernel Documentation (HTML) | package
i+ | kernel-firmware | Linux kernel firmware files | package
| kernel-firmware | Linux kernel firmware files | srcpackage
| kernel-kvmsmall | The Small Developer Kernel for KVM | srcpackage
| kernel-kvmsmall | The Small Developer Kernel for KVM | package
| kernel-kvmsmall-base | The Small Developer Kernel for KVM - base modules | package
| kernel-kvmsmall-base-debuginfo | Debug information for package kernel-kvmsmall-base | package
| kernel-kvmsmall-debuginfo | Debug information for package kernel-kvmsmall | package
| kernel-kvmsmall-debugsource | Debug sources for package kernel-kvmsmall | package
| kernel-kvmsmall-devel | Development files necessary for building kernel modules | package
| kernel-kvmsmall-devel-debuginfo | Debug information for package kernel-kvmsmall-devel | package
i | kernel-macros | RPM macros for building Kernel Module Packages | package
| kernel-obs-build | package kernel and initrd for OBS VM builds | srcpackage
| kernel-obs-build | package kernel and initrd for OBS VM builds | package
| kernel-obs-build-debugsource | Debug sources for package kernel-obs-build | package
| kernel-obs-qa | Basic QA tests for the kernel | srcpackage
| kernel-obs-qa | Basic QA tests for the kernel | package
i | kernel-source | The Linux Kernel Sources | package
| kernel-source | The Linux Kernel Sources | srcpackage
| kernel-source-vanilla | Vanilla Linux kernel sources with minor build fixes | package
| kernel-syms | Kernel Symbol Versions (modversions) | srcpackage
i | kernel-syms | Kernel Symbol Versions (modversions) | package
| kernel-vanilla | The Standard Kernel - without any SUSE patches | srcpackage
| kernel-vanilla | The Standard Kernel - without any SUSE patches | package
| kernel-vanilla-base | The Standard Kernel - without any SUSE patches - base modules | package
| kernel-vanilla-base-debuginfo | Debug information for package kernel-vanilla-base | package
| kernel-vanilla-debuginfo | Debug information for package kernel-vanilla | package
| kernel-vanilla-debugsource | Debug sources for package kernel-vanilla | package
| kernel-vanilla-devel | Development files necessary for building kernel modules | package
| kernel-vanilla-devel-debuginfo | Debug information for package kernel-vanilla-devel | package
Toujours pas de sources du noyau installées. Et toujours la même erreur si j'essaie d'installer le driver d'AMD.
Si je choisis "Generate Distribution Specific Driver Package", c'est pas mieux et je ne crois pas que je pourrais aboutir à quelque chose de viable. Je mets ce qui suit pour la forme, mais ça me semble inutile.
Le choix est restreint entre RedHat, Suse et "Packages for other distributions". Si je choisis "SuSe/SUSE-autodetection", le processus de génération du driver est très rapide mais ne crée aucun fichier. Voir ce log étrange :
# cat /usr/share/ati/fglrx-install.log
Auto detection mode:
Build the RPM package now ...
Package /home/akar/Desktop/ has been successfully generated
Install or update the RPM package as follows:
zypper install
Si je choisis "SuSE/SUSE 121-AMD64" (la version la plus récente proposée), le processus de génération semble se lancer mais ne progresse pas.
Si je suis "Packages for other distributions" :
# sh amd-driver-installer-catalyst-13.1-legacy-linux-x86.x86_64.run --listpkg
Created directory fglrx-install.sB4KQp
Verifying archive integrity... All good.
Uncompressing AMD Catalyst(TM) Proprietary Driver-8.97.100.7...
=====================================================================
AMD Catalyst(TM) Proprietary Driver Installer/Packager
=====================================================================
List of generatable packages:
Package Maintainer(s): Aric Cyr <aric.cyr@gmail.com>
Mario Limonciello <superm1@gmail.com>
Status: *UNVERIFIED*
Debian Packages:
Debian/sid
Debian/unstable
Debian/etch
Debian/stable
Debian/lenny
Debian/testing
Debian/experimental
Package Maintainer(s): Niko Mirthes <nmirthes@gmail.com>
Michael Larabel <michael@phoronix.com>
Status: *UNVERIFIED*
Fedora Packages:
Fedora/FC3
Fedora/FC4
Fedora/FC5
Fedora/FC6
Fedora/F7
Fedora/F8
Fedora/F9
Fedora/F10
Fedora/RHEL3
Fedora/RHEL4
Package Maintainer(s): Anssi Hannula <anssi@mageia.org>
Status: *UNVERIFIED*
Mageia Packages:
Mageia/1
Mageia/2
Package Maintainer(s): Dmitry Mikhirev <dmikhirev@mandriva.org>
Status: *UNVERIFIED*
Mandriva Packages:
Mandriva/2007.0
Mandriva/2007.1
Mandriva/2008.0
Mandriva/2008.1
Mandriva/2009.0
Mandriva/2009.1
Mandriva/2010.0
Mandriva/2010.1
Mandriva/2010.2
Mandriva/2011.0
Mandriva/2012.0
Package Maintainer(s): AMD
Status: Verified
RedHat Packages:
RedHat/RHEL5
RedHat/RHEL6
RedHat/RHEL5_64a
RedHat/RHEL6_64a
Package Maintainer(s): Emanuele Tomasi <tomasi@cli.di.unipi.it>
Status: *UNVERIFIED*
Slackware Packages:
Slackware/Slackware
Package Maintainer(s): Sebastian Siebert <freespacer@gmx.de>
Status: *UNVERIFIED*
SuSE Packages:
SuSE/SLE10-IA32
SuSE/SLE10-AMD64
SuSE/SLE11-IA32
SuSE/SLE11-AMD64
SuSE/SUSE113-IA32
SuSE/SUSE113-AMD64
SuSE/SUSE114-IA32
SuSE/SUSE114-AMD64
SuSE/SUSE121-IA32
SuSE/SUSE121-AMD64
SuSE/SUSE-autodetection
Package Maintainer(s): Alberto Milone <alberto.milone@canonical.com>
Status: *UNVERIFIED*
Ubuntu Packages:
Ubuntu/gutsy
Ubuntu/hardy
Ubuntu/intrepid
Ubuntu/jaunty
Ubuntu/karmic
Ubuntu/lucid
Ubuntu/maverick
Ubuntu/natty
Ubuntu/oneiric
Ubuntu/precise
Ubuntu/source
For example, to build a Debian Etch package, run the following:
% ./amd-driver-installer-<version>-<architecture>.run --buildpkg Debian/etch
Je n'ai rien essayé de plus, les distributions proposées remontent au plus tard à autour de 2013. D'après ce que je crois deviner, pour générer un package pour une distribution, j'ai besoin de sources et de bibliothèques spécifiques à celle-ci, ça me dépasse techniquement...
11
~> sudo modprobe radeon radeon.modeset=1
modprobe: ERROR: could not insert 'radeon': Invalid argument
Je viens de découvrir l'existence de Wayland. Je ne suis pas sûr de bien avoir compris de quoi il s'agissait (je sors de plus de dix ans sans Linux, et mes compétences en informatique restent extrêmement limitées).
J'ai tenté d'ouvrir une session avec Wayland + KDE. Freeze instantané sur l'écran de login, pas moyen d'accéder à un tty... =>Hard reboot.
Penses-tu que ma carte graphique pourrait être mieux prise en compte si j'utilisais Gnome avec Wayland ? Je peux toujours tester avec un compte utilisateur créé pour l'occasion, mais Gnome prend tout de même beaucoup de place (même si je devrais rester large avec 20 Go pour ma partition système) et d'expérience après c'est difficile de désinstaller un environnement de bureau car on se trouve empêtré dans tout un tas de dépendances...
Et crois-tu que ça vaille la peine de tester 15.2 pour voir ? J'ai gardé 80 Go non alloués en fin de disque
Ce qui m'épate, c'est de ne pas avoir trouvé une seule distribution avec laquelle ma carte graphique fonctionne correctement dans ma configuration sans bidouillage, alors que c'est un vieux modèle éprouvé, avec un driver qui a dû bien faire ses preuves.
12
Exact.
J'ai oublié de préciser que j'ai toujours au démarrage le message "No UMS support in radeon module!"
Non, ca plante toujours au même endroit, comme à la première install.
Je viens de tester Leap Live-KDE :
- Avec les paramètres par défaut, écran noir habituel.
- J'arrive sur le bureau en ajoutant nomodeset comme d'hab.
# lspci -nnk |grep -iA3 vga
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV730/M96-XT [Mobility Radeon HD 4670] [1002:9488]
Subsystem: Apple Inc. Device [106b:00b6]
Kernel modules: radeon
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] RV710/730 HDMI Audio [Radeon HD 4000 series] [1002:aa38]
J'obtiens le même résultat si je remplace nomodeset par radeon.dpm=0.
13
Rien de flagrant, l'animation des fenêtres reste saccadée, idem pour les vidéos.
J'ai ça :
# lspci -nnk |grep -iA3 vga
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV730/M96-XT [Mobility Radeon HD 4670] [1002:9488]
Subsystem: Apple Inc. Device [106b:00b6]
Kernel modules: radeon
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] RV710/730 HDMI Audio [Radeon HD 4000 series] [1002:aa38]
15
Encore merci pour ton aide Chalu. Je me suis basé sur cette page pour "réparer" mon disque.
J'ai scanné le disque :
root@debian:~# badblocks -sv -b 512 /dev/sda >> /tmp/badblocks.txt
Checking blocks 0 to 976773167
Checking for bad blocks (read-only test) 37.37% done, 1:00:00 elapsed. (0/0/0 errors.done
Pass completed, 16 bad blocks found. (16/0/0 errors)
et j'ai obtenu la liste des secteurs défectueux :
# cat /tmp/badblocks.txt
563647792
563647793
563647794
563647795
563647796
563647797
563647798
563647799
563647800
563647801
563647802
563647803
563647804
563647805
563647806
563647807
Que j'ai corrigés en adaptant le script donné par LDVC sur aplu.fr à mon cas :
# cat /home/user/script-reallocation-secteurs
#!/bin/bash
# script forblocs.sh qui répare automatiquement les blocs entre 563647792 et 563647807.d'après https://www.aplu.fr/v2/post/2016/01/07/forcer-un-disque-a-reallouer-des-secteurs-defectueux
for i in `seq 563647792 563647807`;
do
clear
echo $i" / 117231407"
sleep 0.04
hdparm --yes-i-know-what-i-am-doing --write-sector $i /dev/sda
hdparm --read-sector $i /dev/sda
done
exit
J'ai perdu la fenêtre de console contenant l'exécution du script (je ne peux pas la recopier), mais tout semblait bien s'être bien passé.
J'ai vérifié les secteurs individuellement :
# hdparm --read-sector 563647792 /dev/sda
/dev/sda:
reading sector 563647792: succeeded
6942 296f 05e9 e62a 009c 05a4 a011 0aa3
008c 461d 8572 7d54 6337 3215 15ab 5ff7
e35c 5e37 59de bc50 bb9b e02b 8d13 362d
5d86 bc69 f9bc bdf9 fdef 2dfa b1db 4dca
d72a c259 c464 9ab1 c466 a59a 7956 fc50
5e27 a880 15ee a027 494c 0204 3312 e519
e955 b6cb 32ea 7a7f 6936 ee48 1d52 e001
8fb5 6605 ff73 e1d8 201c 2c3c e083 e405
9678 7894 fc00 f418 ad14 e843 250c 047f
c2a9 16ea 389a 5386 ef57 5839 1386 1866
0e22 4cbd 1fab 6de5 ca85 fbcd 5f53 09bb
d331 0beb d3df f518 395c 8a58 5908 eee8
df81 b877 eb17 6085 b6c7 3d3f 5b95 5458
a8b3 4768 df75 d52a a7a8 1bb5 11be 9bde
baff 3f58 690c a838 3ac1 2aac c81b 33e3
2eb9 1638 3089 1596 a050 e01d 3032 e293
d28e cd10 3659 052a 74e5 313e 5cf9 32c8
496d cade da66 5078 3650 3ca1 973d f41e
353a 5706 a1c0 bc76 eae3 971a 3ef1 081d
578f 054b e025 8a0e 2ab1 44b4 bb1b 3ab9
f596 936c 7b3d df0e e5aa aa37 c41d 84a3
7d97 e7f2 bf07 f8d1 7d3e 9192 ab35 495f
96ef a49f f3d9 95ba 7874 b2e8 b3c7 318c
9128 cae2 7aa4 aee1 3bc6 9244 ba08 a022
16b6 bfa5 f7cb 9784 99d4 278d 18e5 3f11
439e d9b5 1973 a4e8 5a5a a2a8 61d7 0353
1ba5 73b1 4ca4 56aa 3187 6e86 f1c7 7fd7
8f0e 380e 6ae1 e430 1003 abc0 3905 8069
f5ff 4ff4 030e a351 639b 8d86 4907 e2a7
1f63 b18e 1c00 ee18 ad14 e81d 12c7 4363
a084 2047 fe3b 8bab 7057 b3a0 b45d f2d6
5311 1323 3360 8a12 4e27 935b be7f de96
Idem pour les secteurs suivants jusqu'à 563647798. Mais
# hdparm --read-sector 563647799 /dev/sda
/dev/sda:
reading sector 563647799: SG_IO: bad/missing sense data, sb[]: 70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 37 00 00 00 00 00 00 00 00 00 00 00 00 00 00
succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
Idem jusqu'à 56364801. Puis de nouveau test réussi jusqu'au dernier secteur. Moralité, plus que trois secteurs défaillants.
J'ai essayé de les rectifier à la main :
# hdparm --yes-i-know-what-i-am-doing --write-sector 563647799 /dev/sda
/dev/sda:
re-writing sector 563647799: succeeded
Et là on dirait que c'est bon (?)
# hdparm --read-sector 563647799 /dev/sda
/dev/sda:
reading sector 563647799: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
Idem pour les autres secteurs récalcitrants.
Je ne comprends pas tout, mais j'ai l'impression que tout est corrigé à présent...
Il ne reste plus qu'à tout réinstaller sur mon Mac, avec un beau dd tout propre
J'ai également trouvé ceci (le script scanne puis corrige tout seul), je vais essayer de l'utiliser pour réparer un dd externe qui fait des siennes et que j'ai dû péniblement reformater, mais qui s'obstine à mal fonctionner.