Netinst vs Businesscard

Support Debian
#1

Salut à tous,

j’e crois savoir que la différence entre les cd d’install de Debian 3.1 intitulés “netinst” et “businesscard”, respectivements de 30 et 110 Mo (+/-), réside dans le fait que l’un comprend le système de base alors que l’autre ne démarre que l’installateur. Juste?

Mais je me pose alors une question… Existera-t-il une différence lors de l’installation d’un système de base à partir du “netinst” par rapport au “businesscard”…?

J’entends par là, va-t-il télécharger des mises à jour du système de base ou n’existe-t-il aucunes mises à jour du système…?

Merci :wink:

#2

Il y a quand même une différence que j’ai constaté et que j’ai homis de signaler…

Lors d’une install avec les “netinst”, il m’a installé le noyau 2.6.8-2-386

Avec le businesscard", il m’a télécharger directement le 2.6.8-2-686

(J’utilise un P4)

En dehors de cela, je n’ai rien constaté… Juste qu’à mon souvenir il n’a rien télécharger sur security.debian mais tout dans debian… dc je présume qu’ils sont identiques… ???

#3

Personne… :question:

#4

Je suppose quoi toi qu’ils sont identiques mais je ne peux te le confirmer dsl

#5

A priori, n’importe quelle install debian est équivalente à n’importe quelle autre.
Il suffit de mettre les mêmes sources, la même sélection de paquets, les mêmes préfèrences, et d’équiper avec une connection au net qui marche, tu lances une réinstall de tous les paquets en même temps sur les deux machines, et tu as deux clones en terme de version et de liste de paquets installée.
Peu importe que tu sois parti d’une business card, d’une netinstall, ou comme je le fais le plus souvent, en debootstrap depuis une knoppix ou une ubuntu live: au final, tu te retrouves avec la même machine à configurer.
C’est pour tous les ex windowsiens qui continuent à avoir le reflexe “bon ben je vais réinstaller”: à partir du moment ou on a le net, dans une debian, tout se répare…
On a toutes les chances de se retrouver devant le même mur en repartant du même endroit et en suivant la même route, et la reinstallation n’est pas la solution.
Personnellement, mes disques vont de machine en machine avec l’evolution de la technologie, mais c’est la même debian depuis des années. J’attends le crash disque pour réinstaller (et encore, j’ai des backups).

#6

quote="MattOTop"Personnellement, mes disques vont de machine en machine avec l’evolution de la technologie, mais c’est la même debian depuis des années. J’attends le crash disque pour réinstaller (et encore, j’ai des backups).[/quote]Tu n’as pas de problème lorsque tu change de carte mere ou de proc? ton noyau est compiler pour un type de proc si tu le change ca ne pose pas trop de probleme???

#7

D’abord, je garde toujours un noyau générique, mais concernant les noyaux que tu compiles, tu peux garder une compatibilité générique, auquel cas ton noyau reste un peu gras, et il est juste optimisé pour un type de 386, tout en restant compatible avec les autres.
Personnellement, quand je fais le ménage (le plus souvent, j’ai une demie douzaine de noyaux), je laisse un noyau 386 générique installé en binaire, que je sais tourner à priori partout, et un deuxiême, optimisé pour mon proc courant, sans compatibilité, purgé des modules dont je sais ne pas avoir besoin, et affiné pour mettre en dur certains modules nécessaires au boot.
Et quand ca ne boote pas sur une nouvelle machine, je boote sur un livecd, je corrige le pb en chroot, et roule.
Non, sérieusement, à part des machines de test qui ne méritaient pas d’etre nettoyées autrement que par le vide, même mes serveurs au boulot changent de machine physique régulièrement (sauf les plus critiques bien sûr, qui eux tournent sur des machines récentes).

#8

Je comprends mieux maintenant c’est vrai que ca doit etre plus simple. Je n’ai qu’un seul noyau optimisé pour mon pc et non compatible ca risque d’etre dur si je doit changer de pc ou je peux reinstaller une nouvelle version d’un noyau pour le rendre compatible?

#9

En sarge, c’est grub qui est installé par défaut, et avec grub, tu n’a besoin que de faire des apt-get install/remove des noyaux que tu veux installer/supprimer, et la liste complète à jour t’est présentée automatiquement au démarrage.
A part la place, rien n’empêche d’avoir 50000 différents noyau comme choix au boot !

Et même avec lilo, tu as le choix de booter sur les deux derniers noyaux installés.

#10

C’est ce que je m’étais aperçu en recompilant mon kernel mais je virais toujours les ancies kernel une fois que le suivant recompiler fonctionnait correctement.

Une idée qui me trotte dans la tête (non c’est pas un cheval :laughing: ) si je suis en testing sur un noyau 2.6.11 par exemple et que je passe en 2.6.12 je peut etre en stable? et faire mes mises a jour tel quel ou je suis obliger de rester en testing?

je suis en 2.6.11 sous etch avec grub :slightly_smiling:

Merci pour ces réponses je vais ouvrir un autre file pour ma mise a jour car elle me pose quelques problèmes :slightly_smiling:

#11

le noyau n’a rien à voir (à priori) avec la version de debian.
Simplement, les noyaux les plus recents doivent passer par les etapes unstable avant d’arriver en testing puis en stable. Mais comme n’importe quel paquet debian, si tu va choper un paquet en sid pour l’installer avec dpkg -i sur une etch ou une sarge, il va verifier les dependances. Pour la plupart des paquets, c’est en général là que ca bloque parcequ’il te faut des paquets dépendant qui viennent de la sid, et donc, pour ce qui concerne le noyau, comme il n’a pas de dépendances notables, tu peux l’installer quelle que soit ta version de debian.

Enfin, ca c’est théorique parceque je ne boote toujours pas sur les 2.6.14 qui sont fournis actuellement :laughing:
Autre problême: les changement de gestion des peripheriques, quand tu passes d’un 2.4 a un 2.6, il faut penser à installer udev, et pour ce qui est des derniers noyaux, je pense qu’il y a une incompatibilité entre les 2.6.14 et la gestion de l’udev de la etch.
Enfin tout ca pour dire que le pire qui risque d’arriver, quand tu installes un noyau pas prévu pour ta version de debian, c’est que ca ne marche pas…