Bonjour.
Après un magnifique plantage de mon windows j ai décidé de retourern sur linux.
J ai donc lancé une clé bootable. Pas de problème.
Alors le voilà: mon pc est un portable. J ai un disque dur 500g separé en 3. 100 pour C:, 16 pour windows recovery system et 376 go pour D:.
Ne voulant pas perdre mes films sur D, j ai mis c en ext2 / et une partie en home puis le recovery en swap. (…)
Bonjour,
Cela intéressera surtout les lecteurs qui ont un dual-boot avec Windows 8. En effet, la fonctionnalité de redémarrage rapide ne démonte pas entièrement la partition NTFS, ce qui fait que si vous écrivez dessus sous Linux avec ntfs-3g puis que vous redémarrez sous Windows, ce dernier risque d'ignorer les écritures que vous avez faites entraînant ainsi un risque de pertes de données.
De mon côté, j'ai remarqué le problème lorsque j'ai vu windows lancer fréquemment des chkdsk au redémarrage (…)
Bonjour à tous;
Ma fille possède un acer aspire 7720Z sous ubuntu. Après mise à jour (passage de 11.10 à 12.04 ) problème.
L'écran de boot (plymouth ) s'affiche mais on a le message suivant :
Le disque support de / semble absent
Puis on retombe sur une console de secours.
En faisant un fdisk - l j'obtiens ceci :
Je précise que j'essaie vainement de booter sur une clé usb ( j'ai systematiquement droit à un boot error ).
Bonjour,
Étant un débutant et n'ayant qu'un laps de temps très limité je souhaiterais avoir un avis pour mon petit problème:
J'ai reçu au travail un portable avec une souche Linux Debian modifié et sécurisé où je n'ai pas de droits d'administrateur. Jusqu'ici rien d'exceptionnel.
Pour lancer mes codes de calcul j'utilise linux, en même temps pour le traitements de donnés j'utilise windows par le biais d'une VMWare. Mon problème vient du fait que ce portable est très puissant, mais (…)
Qu'il semble loin le temps, béni pour certains, maudits pour d'autres, où il était nécessaire de connaître les IRQs et DMAs de sa machine pour l'utiliser, où, loin du Plug'n'Pray, le matériel se contentait de laisser l'humain configurer…
Puis vint le Plug'n'Play, son compagnon l'ACPI permettant de (…)
Bonjour,
J'aimerais profiter du fait que mon X200 est capable de booter sur carte SD pour m'affranchir de la contrainte d'un multiboot classique. (Je souhaite une sorte de démarrage sans intervention humaine, une fois le bouton pressé)
Mon idée est de laisser l'OS propriétaire démarrer par défaut, sauf si la carte SD de boot est insérée, dans ce cas c'est ArchLinux qui devra se lancer.
J'aimerais donc savoir comment vous feriez pour lancer un Grub installé en local par le (…)
Bon, le titre trollesque, c'est juste pour attirer le chaland. En fait, c'est plus subtil.
Daniel Kahn Gillmor (alias dkg) a testé systemd sur Debian. Il y trouve des points positifs : la gestion des daemons, la gestion saine des états des processus, l'élimination de la redondance dans les scripts init, le démarrage des services réseaux. Bref, tout ce qui convient à un serveur robuste se trouve dans systemd.
Mais il est aussi inquiet. Principalement par deux choses :
Ces dernières semaines les personnes clés des principales distributions se sont réunies pour discuter des problèmes liés aux données d'exécution (runtime data) utilisées lors de la phase de démarrage et surtout de leurs emplacements.
Lors du démarrage d'un système GNU/Linux différents programmes (initscripts, dracut, mdadm, etc) ont besoin de stocker leurs données d'exécution dans l'arborescence et cela avant les éventuels montages annexes (/home, /usr ou /var). Ces données sont aussi utilisées par les programmes et daemons lors du fonctionnement du système.
Actuellement, les distributions utilisent différents subterfuges pour stocker ce type de données dans des dossiers cachés : /dev/.mdadm, /dev/.mount, /dev/.systemd, /dev/.udev, etc. Elles utilisent pour la plupart le répertoire /dev pour stocker les premières données, ce dossier est de type tmpfs et est disponible dès les premiers instants du démarrage.
À la suite des derniers montages (/home, /usr ou /var) les daemons sont lancés, ils utilisent principalement le dossier /var/run pour leurs données et cherchent les données liées au démarrage dans les différents dossiers /dev/.xxx ou autres selon les distributions.
Pour en finir avec cette cacophonie, les principales distributions ont décidé d'ajouter le dossier "run" à la racine. Ce dossier fera partie de l'arborescence initiale des prochaines versions, il contiendra les données contenues auparavant dans les dossiers /dev/.xxx, /var/run, /var/lock, /lib/init/rw, etc.
Cette décision est techniquement simple et simplifie la liaison entre les données liées au démarrage et les programmes, elle a souvent été envisagée mais repoussée pour des raisons politiques, des craintes d'intense flameware et la rupture avec la LSB/FHS.
Les développeurs de dracut, udev et systemd ont déjà mis à jour ces logiciels. Les distributions utiliseront le répertoire /run de façon progressive avec, dans un premier temps, des montages de type bind des anciens répertoires vers /run.
Lennart Poettering (Pulseaudio, avahi, systemd) a rédigé un mail pour faire le point sur cette réunion, annoncer le changement et les phases de mise en place.
Alors, LSB/FHS outragée, LSB/FHS brisée, LSB/FHS martyrisée… crouch, touch, pause, engage !
N. D. M. : Les principales distributions impliquées sont Debian, SuSE, Ubuntu et Fedora.