hilow
Bonjour,
Je suis développeur sous Windows. Je ne connais pas Linux. J'ai récemment installé Fedora Core 5 (2.6.15-1.2054_FC5) avec interface KDE dans une machine virtuelle VMware sous Win2K. Tout allait bien (install ok, démarrage ok, kde ok, accès internet ok), jusqu'à ce que je fasse quelques install et mise à jour utiles à l'install des vmware tools (que je n'ai finalement pas eu le temps d'installer car problème avant ça).
Donc, voici ce que j'ai fait par yum : install de gcc, install de kernel-devel 2.6.18-1.2200.fc5 et maj vers kernel même version. Puis, reboot.
Surprise : au redémarrage, tout va bien jusqu'à udev (udev ok), puis j'ai un écran noir pendant environ 1/4 d'heure avant d'accéder à l'écran d'ouverture de session directement (sans jamais voir la partie graphique du démarrage avec jauge démarrant les services en détail).
Après ça, je me log en root et tout semble ok à première vue... Sauf que visiblement j'ai un problème d'accès réseau (et donc internet) car
- Firefox ne se connecte à rien : ni via nom de domaine ni IP directe
- Yum info me renvoie : "Connot find a valid baseurl for repo: core
- KYum : je peux lister les package installés mais un "List updates" me renvoie la même erreur que yum
- Add/Remove software me donne un "Unable to retrieve software information" fatal
- L'utilitaire "Software updater" : idem
Par contre, un "Contrôle du périphérique réseau" me montre bien un eth0 activé avec matériel en état ok.
Aussi, dans les services, côté LAN, Lisa n'est pas démaré : pour test, si j'essaye de le démarrer, ça tourne sans fin sans jamais y arriver.
Enfin, si je redémarre sur le 2.6.15 via le menu Grub, tout marche bien (tout ce qui est listé ci-dessus fonctionne correctement) et si je regarde via KYum les package installés, kernel et kernel-devel 2.6.18 sont bien installés.
Voilà 🙁
Que dois-je faire docteur ?
tintamar
Je n'ai pas rencontré les mêmes problèmes (mon réseau fonctionne bien) que toi, par contre au démarrage il cherche vainement du sata (je n'ai que de l'ide) et du coup rallonge considérablement le temps de démarrage de la machine.
les logs:
Oct 17 10:03:52 lphe1pc47 kernel: ata1: SATA max UDMA/133 cmd 0xFE00 ctl 0xFE12 bmdma 0xFEA0 irq 169
Oct 17 10:03:52 lphe1pc47 kernel: ata2: SATA max UDMA/133 cmd 0xFE20 ctl 0xFE32 bmdma 0xFEA8 irq 169
Oct 17 10:03:52 lphe1pc47 kernel: scsi0 : ata_piix
Oct 17 10:03:52 lphe1pc47 kernel: ata1: port is slow to respond, please be patient
Oct 17 10:03:52 lphe1pc47 kernel: ata1: port failed to respond (30 secs)
Oct 17 10:03:52 lphe1pc47 kernel: ata1: SRST failed (status 0xFF)
Oct 17 10:03:52 lphe1pc47 kernel: ata1: SRST failed (err_mask=0x100)
Oct 17 10:03:52 lphe1pc47 kernel: ata1: softreset failed, retrying in 5 secs
Oct 17 10:03:52 lphe1pc47 kernel: ata1: SRST failed (status 0xFF)
Oct 17 10:03:52 lphe1pc47 kernel: ata1: SRST failed (err_mask=0x100)
Oct 17 10:03:52 lphe1pc47 kernel: ata1: softreset failed, retrying in 5 secs
Oct 17 10:03:52 lphe1pc47 kernel: ata1: SRST failed (status 0xFF)
Oct 17 10:03:52 lphe1pc47 kernel: ata1: SRST failed (err_mask=0x100)
Oct 17 10:03:52 lphe1pc47 kernel: ata1: reset failed, giving up
Oct 17 10:03:52 lphe1pc47 kernel: scsi1 : ata_piix
Oct 17 10:03:52 lphe1pc47 kernel: ata2: port is slow to respond, please be patient
Oct 17 10:03:52 lphe1pc47 kernel: ata2: port failed to respond (30 secs)
...
quelqu'un aurait-il un argument à donner au kernel lors du boot pour éviter cela ?
merci
VINDICATORs
un blème avec "apic" passe comme argument noapic ou nolapic à grub!
hilow
VINDICATORs wrote:un blème avec "apic" passe comme argument noapic ou nolapic à grub!
Heu, tu réponds au problème SATA de tintamar ou à moi, dis ? Le mieux serait peut-être de séparer les threads par sujet, hum (enfin, pour plus de lisibilité je veux dire) 😉
VINDICATORs
sans doute au deux 😛
ça mange pas de pain de tester 😉
alors il faut éditer la seconde ligne du noyau sur lequel tu boot avec la touche "e" (une fois pour entrer en mode édition et une autre pour modifier!)
là tu mets noapic comme dans l'exemple donnée si dessous 😉!
title Fedora Core (2.6.18-1.2200.fc5smp)
root (hd0,6)
kernel /boot/vmlinuz-2.6.18-1.2200.fc5smp ro root=LABEL=/1 rhgb noapic quiet###<-----MODIFICATION ICI!!!!!!!!!!!
initrd /boot/initrd-2.6.18-1.2200.fc5smp.img
hilow
VINDICATORs wrote:kernel /boot/vmlinuz-2.6.18-1.2200.fc5smp ro root=LABEL=/1 rhgb noapic quiet
Merci VINDICATORs, mais 'noapic' ajouté comme ci-dessus, puis 'b' pour booter et apparemment idem, pas de changement... Ca fait cinq minutes que j'attends sur l'écran noir (juste avec curseur en forme de croix sur l'écran) et pas encore atteint l'écran d'ouverture de session.
Sais pas encore pour le côté réseau (puisque boot en cours et long long long), mais fort à parier que ce sera pareil aussi.
VINDICATORs
fait un ctrl alt + F1 pour voir si il en dit pas plus!
hilow
Alors, si je bascule en console plein écran, j'obtiens périodiquement (toutes les 30, 40 secondes, sans rien faire) un message qui me dit : "security_compute_av: unrecognized class 57". Si je me logue en tant que root, ça continue ttes les 40 secondes environ.
Dois-je taper des commandes particulières ?
VINDICATORs
je croit que c'est un blème avec ton vmwar alors!
faudrait voir de ce coté là!
hilow
Mais si je boot sur le kernel 2.6.15-1.2054_FC5, il n'y a aucun problème... en étant pourtant dans la même machine virtuelle VMware
tintamar
de mon côté, l'option noapic n'a rien donné non plus ...
pbochart
De mon côté non plus, sauf si je désactive SELinux ! :-o
Pourtant je ne tourne pas dans une session virtuelle...... Actuellement, c'est mon serveur de test que j'ai mis à jour en premier ....
Pour mon laptop, je vais attendre un peu .... :-?
Ce problème es un peu enuyant car cela coupe toute connection réseau :-x
hilow
pbochart wrote:De mon côté non plus, sauf si je désactive SELinux !
Parfait pour moi dans la mesure où ce Fedora ds VMware est une plate-forme de test de scripts Perl CGI et compilation d'outils divers écrits en FreeBASIC : donc je me fous complètement de la sécurité ; d'ailleur je ne me log qu'en root, imaginez 🙂
Alors, donc, j'ai essayé ce que tu dis (désactiver SELinux) et tout marche OK : pas d'attente au boot, plus d'écran noir au démarrage des services, réseau OK.
Je laisse comme ça en attendant un nouveau build qui règlera ce problème.
Par contre, c'est vrai qu'en dehors de mon cas particulier, pour une vraie install, c'est chaud de rester comme ça.
tintamar : finalement pas sûr que tu ais le même problème, mais une idée comme ça pour ton sata : et si tu l'active dans le BIOS ton SATA, est-ce que ça pose problème ?
hilow
Bien, des nouvelles. Projetant d'installer un Fedora en multi-boot cette fois, j'ai tenté de régler mon problème... Et ça a simplement réussi en me tapant le long process d'un "yum -y upgrade", puis réactivation de SELinux mode "Enforcing". Au premier redémarrage, il a réappliqué la politique : une dizaine de minutes.
Maintenant tout est ok (boot et réseau) et sécurisé donc !
Peut-être que l'un d'entre vous résoudra son prob. avec la même manip 🙂
circajet7
je l'ai fait et sa marche 😃
note : pour désactiver selinux o boot : il faut ajouter "selinux=0" tout à la fin de la 2ème ligne de la config du kernel que vous bootez (comme avec le noapic au début de ce sujet)
ex :kernel /boot/vmlinuz-2.6.18-1.2200.fc5smp ro root=LABEL=/1 rhgb quiet selinux=0
hilow
cool 8-)
basik
Niveau sécurité c'est pas un peu risqué de désactiver selinux?
cybervirem
Hi,
SELinux, c'est de la sécurité interne à ton os, si je puis dire. Ca permet, en gros, de restreindre les accès d'un process à certaines ressources, en fonction d'un domaine et d'un type d'objet. En clair, c'est utile pour un serveur afin de limiter les dommages que pourrait causer une appli qui exploiterait une faille.
SELinux, ne sert pas de firewall...
Cordialement
hilow
basik,
L'objectif du fil était justement d'arriver à booter en réactivant SELinux après mise à jour du kernel... Ce qui fut réussi en faisant un gros yum upgrade.
Quant à l'étape intermédiaire (sans SELinux), elle n'était pas une solution mais une obligation transitoire. Enfin, s'il avait fallu rester comme ça et bien cela aurait été au cas par cas, selon l'usage de chacun de Fedora : dans mon cas et pour ce Fedora précis (dans une vmware), l'objectif de cette install étant extrêmement ciblé (tests CGI sur LAN et compilations via gcc).
--
cybervirem,
Merci de ces précisions qui confirment que dans un cas comme le mien, le risque aurait été limité : puisque je n'installe aucun package inconnu.
Néanmoins, d'avoir résolu la réactivation de SELinux me rassure pour cette autre install Fedora que je compte faire : cette fois, hors vmware, en tant qu'OS principal d'une machine.
Bonne journée
