mirror of https://framagit.org/kyodev/kyopages.git
+new lb apprentissage
This commit is contained in:
parent
00c8df9a93
commit
7bad3af548
|
@ -0,0 +1,779 @@
|
|||
# formation live-build
|
||||
|
||||
* 19/05/2017
|
||||
|
||||
```
|
||||
<arpinux> attention au flood :P
|
||||
[----------------------
|
||||
Bienvenue @tou-te-s sur ce chan pour la première session de formation empirique live-build Debian :)
|
||||
le but de cette formation est de vous guider dans le processus de configuration, de construction et
|
||||
de diffusion d'un live Debian.
|
||||
la session commence maintenant et se poursuit tout le week-end afin de vous permettre de construire,
|
||||
tester, puis revenir ici pour résoudre d'éventuels soucis ou ajouter des options de configuration.
|
||||
il y aura quelques pauses, en fonction de l'heure mais aussi de l'activité de chacun et/ou de mes 5 enfants :D
|
||||
pour me présenter rapidement : arpinux aka arnault, dev autodidacte qui ne sait pas coder en C, maintainer/builder
|
||||
de https://arpinux.org/livarp , https://handylinux.org , https://lescahiersdudebutant.fr/dflinux.html et
|
||||
https://kissballad.arpinux.org/kiss0s.html . rédacteur principal de https://lescahiersdudebutant.fr
|
||||
et anarchiste assumé.
|
||||
je bidouille live-build depuis 2011 et non, la documentation officielle et les mans ne sont pas à jour car ça
|
||||
bouge trop vite et ils ne sont pas des tonnes à assurer la documentation. donc je me propose de vous aider
|
||||
à y voir plus clair dans les options et les possibilités de live-build.
|
||||
si vous avez déposé vos sources de build sur git ou cloud quelque part, n'hésitez à filer le lien pour que je
|
||||
puisse cloner, jeter un œil aux fichiers et tester avec vous :)
|
||||
si vous êtes là, c'est que vous avez construit au moins 1 live et que vous avez des questions, alors je vous
|
||||
en prie, c'est le but, soyez pas timide :)
|
||||
-----------------------]
|
||||
```
|
||||
|
||||
## principe live-build
|
||||
```
|
||||
<arpinux>
|
||||
l'installeur étant buggé pour l'instant le processus par défaut initialisé par le udeb
|
||||
live-build et le processus en ligne appelé sont en conflit. en fait, l'installation fait
|
||||
cohabiter deux programmes en très gros.
|
||||
le premier programme, live-build, construit le live, il fonctionne en local. on peut configurer
|
||||
les dépôts en local, ça ne le gêne pas
|
||||
|
||||
le second programme, l'installeur fait appel aux dépôts en ligne, donc si il y a la moindre
|
||||
différence dans les processus initiés par ces deux programmes, on se retrouve avec un bug de
|
||||
l'installeur au final
|
||||
c'est rare car les tâches sont normalement bien séparées mais lors de l'installation d'un
|
||||
liveCD de type 'live' c'est le système du squaqhfs qui est copié sur le système donc à ce
|
||||
moment, les versions se "croisent" si je puis dire
|
||||
|
||||
la configuration intégrée dans le live (modifiée par nos soins) et la configuration appelée
|
||||
par l'installeur, en UEFI, j'ai remarqué que le preseed n'était pas pris en compte au même
|
||||
moment par l'installeur effectivement, alors qu'en démarrage BIOS, oui.
|
||||
donc ça confirme que la différence vient du traitement efi
|
||||
```
|
||||
|
||||
## conseil
|
||||
```
|
||||
<arpinux>
|
||||
le principe de synchronisation des configuration :
|
||||
un dossier de build contenant les sources + un dossier en ligne sur cloud ou serveur + le /home
|
||||
d'une machine de test 3 dossiers à synchroniser pour être certain que le dossier de build soit à jour
|
||||
comme l'indiquait coyotus, il arrive parfois que des applications changent l'adresse de leur fichier
|
||||
de conf le cas ~/.blah.cfg -> ~/.config/blah.cfg est le pus courant effectivement
|
||||
pourquoi ?
|
||||
car la normalisation veut que les programmes placent leur configuration par défaut dans /etc/xdg
|
||||
qui est le dossier système qui correspond à ~/.config pour l'utilisateur
|
||||
un peu comme le /usr/share/icons/ correspond à votre ~/.icons
|
||||
un changement d'adresse provoque immanquablement une mauvaise lecture de la configuration
|
||||
sauf chez conky, merci les devs, qui sait même traduire tes anciennes conf !!! je voulais le préciser
|
||||
quand même :D
|
||||
et donc, une machine test/dédié permet de ne pas se soucier de ce genre de détails tant que votre
|
||||
machine test tourne comme vous voulez, c'est que les conf sont lues un bug qui apparaît dans votre
|
||||
machine test vous renseigne sur le bug à venir de votre build de la même façon :)
|
||||
donc prenez soin de tester le plus possible. il vaut mieux tester sur la machine dédiée, plutôt
|
||||
que de refaire des builds à l'aveugle car on est sûr que "ça va passer" :)
|
||||
je me suis fait avoir assez souvent par arrogance :/
|
||||
pour les dossiers systèmes et les paquets c'est la même chose mais pas de synchronisation
|
||||
les tests et vérifications se situent au niveau du terminal,
|
||||
donc pour les paquets, le plus important est de s'assurer de ne pas installer de truc superflus
|
||||
c'est pourquoi il faut régulièrement faire les mises à jour, bien sûr, mais surtout, envoyer un
|
||||
apt autoremove --purge si des paquets ne sont plus nécessaires dans le système test,
|
||||
ils seront potentiellement en conflit dans le futur build si vous ne lez retirez pas
|
||||
```
|
||||
|
||||
## live-wrapper
|
||||
```
|
||||
<arpinux> alors pour rassurer, effectivement, ce sera le nouvel outil pour faire des live debian
|
||||
<arpinux> mais live-build est maintenu
|
||||
<arpinux> et fabrique des live similaires
|
||||
<arpinux> hormis cette compatibilité uefi après personnalisation sur une install sans réseau ...
|
||||
<arpinux> en fait, live-wrapper n'accepte pas de conf locale pour l'instant
|
||||
<arpinux> pas sur le modèle du chroot.includes de live-build
|
||||
<arpinux> il est conçu pour choper du paquet
|
||||
<arpinux> alors d'où tu veux
|
||||
<arpinux> mais du paquet
|
||||
<arpinux> donc c'est un outil de fork plus que personnalisation
|
||||
<arpinux> il impose l'utilisation de dépôts externe pour modifier le comportement des applications
|
||||
<arpinux> par exemple
|
||||
<arpinux> avec live-build
|
||||
<arpinux> pour modifier le menu fluxbox,
|
||||
<arpinux> il faut modifier le ficher /config/includes.chroot/etc/skel/.fluxbox/menu et voilà
|
||||
<arpinux> rien de plus
|
||||
<arpinux> donc en gros, un copier coller de ton menu et hop
|
||||
<arpinux> simplissime si tu sais où le coller
|
||||
<arpinux> avec live-wrapper
|
||||
<arpinux> la modification doit s'effectuer au niveau du menu par défaut de fluxbox
|
||||
<arpinux> donc fork du paquet fluxbox dans un dépôt externe + utilisation de ce dépôt pour faire ton live
|
||||
<arpinux> c'est une autre façon de travailler
|
||||
<arpinux> plus professionnel je dirais :)
|
||||
<arpinux> dans le cas de live-wrapper, les compétences de maintainer de dépôts sont obligatoire
|
||||
<arpinux> avec live-build
|
||||
<arpinux> faut savoir lire et faire des copier coller
|
||||
<starsheep> Donc avec live-wrapper tu ne peux rien personnaliser tant que tu n'as pas une infrastructure réseau
|
||||
<arpinux> tu peux toujours utiliser un dépôt en local starsheep , mais il faudra de toute façon un dépôt en ligne à un moment pour les users
|
||||
<arpinux> ou alors tes mods risquent d'être écrasées par une mise à jour debian
|
||||
<arpinux> oui ... bien lire le chapitre "ce qui ne fonctionne pas" ! :D
|
||||
<arpinux> sinon, c'est la haine
|
||||
<arpinux> genre tu te modifies tout plein de .desktop dans /usr/share/applications .....
|
||||
<arpinux> ah non, mais c'est excellent comme outil
|
||||
<arpinux> mais comme le reste ça devient une "affaire de spécialistes"
|
||||
<arpinux> par principe, tout fichier appartenant à un paquet est potentiellement écrasable
|
||||
<arpinux> donc modifier un .desktop ou un menu dans /etc/xdg ne sert à rien
|
||||
<arpinux> il sera écrasé
|
||||
<arpinux> donc il faut passer par les dossier de personnalisation prévus
|
||||
<arpinux> pour l'utilisateur, c'est le /etc/skel
|
||||
<arpinux> les paquets ne déposent rien là-dedans
|
||||
<arpinux> c'est le dossier qui forme le /home/$USER lors de l'installation
|
||||
<arpinux> et aussi le /home/$USER du live
|
||||
<arpinux> donc c'est l'endroit idéal.
|
||||
<arpinux> mais ça ne suffit pas toujours
|
||||
<kyodev> d'ac et live-wrapper ne permet pas d'exploiter /etc/skel ?
|
||||
<arpinux> genre pour modifier le grub, le fstab ou ce genre d chose
|
||||
<arpinux> alors si, avec un paquet externe qui irait peupler le /etc/skel
|
||||
<arpinux> voilà, toute la conf user dans un paquet
|
||||
<arpinux> pareil pour la conf système
|
||||
<arpinux> la plupart des programmes acceptent les configuration de type /etc/apt/sources.list.d
|
||||
<arpinux> le ".d"
|
||||
<starsheep> Donc plus de copier-coller dans live-wrapper
|
||||
<arpinux> non starsheep
|
||||
<starsheep> mais modifier le $HOME via des paquets c'est dégueulasse
|
||||
<starsheep> donc faut quand même une autre méthode
|
||||
<arpinux> mais en ajoutant de la conf système dans les ".d" des dossiers système,n on peut aussi modififer le comportement sans forker les paquets
|
||||
<arpinux> et oui starsheep , c'est pourri
|
||||
<arpinux> donc pour faire propre faut forker les paquets
|
||||
<starsheep> donc avec live-wrapper faut créer des paquets avec des fichiers de conf dans /etc
|
||||
<arpinux> donc faut maintenir un dépôt
|
||||
<arpinux> par le biais d'un paquet, oui starsheep
|
||||
<starsheep> Mais si le logiciel n'accepte pas de conf dans etc mais juste dans le $HOME, ben faut reprogrammer
|
||||
<starsheep> ou je me trompe ?
|
||||
<arpinux> d'où les deux paquets, pour le user et pour le sys
|
||||
<arpinux> la modification user d'un côté et les mods système de l'autre
|
||||
<arpinux> sinon, pour finir avec live-wrapper, ils vont peut-être ajouter une fonction de personnalisation en local, mais rien pour l'instant
|
||||
<arpinux> donc je continue d travailler avec live-build
|
||||
<arpinux> qui est en plus maintenant maintenu par Raphael Hertzog
|
||||
<arpinux> cool d'avoir un français qui dev dessus :)
|
||||
<arpinux> il a d’ailleurs déjà filé un coup de main à Patrick D'Emmabuntüs Debian Edition pour rendre l'EmmaDE compatible UEFI sur Jessie :)
|
||||
<arpinux> devant ce silence, je me dois d'indiquer que la seconde raison qui m'a poussé à faire cette session
|
||||
<arpinux> c'est le cassage de mythe du dev
|
||||
<arpinux> les gars comme Raphael sont accessibles, il faut le savoir
|
||||
<arpinux> donc même si vous débutez et que vous voulez un coup de main, n'hésitez pas à contacter les dev
|
||||
<arpinux> un peu comme en politique ... faudrait pas hésiter à harceler nos députés ;)
|
||||
<arpinux> ce sont des humains :)
|
||||
```
|
||||
## synchronisation
|
||||
```
|
||||
<coyotus> comment tu fais pour exporter tes modif sur git pour avoir tes sources à jours en temps réel ?
|
||||
<starsheep> git push ? ^^
|
||||
<coyotus> depuis le dossier de build ou l'env de test ?
|
||||
<arpinux> même pas git perso ... je fonctionne avec un cloud openmailbox.
|
||||
<arpinux> mais pour la synchro
|
||||
<arpinux> je fonctionne au cloud à la main
|
||||
<arpinux> entre la machine test et la machine de build
|
||||
<arpinux> oui
|
||||
<arpinux> c'est automatisable
|
||||
<arpinux> genre git push depuis ta machine de test et git pull depuis ton dossier de build
|
||||
<arpinux> mais ça impose l'installation de git sur la machine test
|
||||
<arpinux> alors que justement
|
||||
<arpinux> la machine test doit rester la plus fidèle possible à l'installation par défaut du user
|
||||
<arpinux> pour ça que j'utilise un cloud
|
||||
<arpinux> par exemple
|
||||
<arpinux> juste avant le build
|
||||
<arpinux> j'archive sur la machine test mon ~/.mozilla , ~/.config ...
|
||||
<arpinux> j'upload sur cloud
|
||||
<arpinux> je récupère sur la machine de build
|
||||
<arpinux> je mets à jour les dossiers dans le build et hop
|
||||
<arpinux> ça laisse le système de teste vierge
|
||||
<arpinux> car c'est ça le piège
|
||||
<starsheep> Tu fonctionnes en 3 temps alors ?
|
||||
<arpinux> quand on geek souvent, on se dit que modifier la bonne ligne suffit, mais comme tu l'as dit tout à l'heure, une modification de syntaxe peut aussi intervenir sans ton "consentement" et donc, tu ne le reportera pas dans le build, sauf à synchroniser les dossiers
|
||||
<starsheep> Tu build un premier coup, tu balances sur la machine de test, tu fais ta config et tu balance le $HOME pour créer le skel et tu rebuild ?
|
||||
<arpinux> en gros starsheep oui :)
|
||||
<starsheep> heeeeeeeein
|
||||
<starsheep> ah ben je viens de comprendre un truc
|
||||
<starsheep> et avec une VM et un partage de fichier ça ne peut pas être plus simple ?
|
||||
<arpinux> mais im ne faut pas non plus tout prendre dans le home de ton test
|
||||
<arpinux> genre la résolution de l'écran
|
||||
<arpinux> les icpnes du bureau
|
||||
<starsheep> ah oui oui
|
||||
<arpinux> le cache ...
|
||||
<starsheep> c'était pour résumer
|
||||
<arpinux> bref .. il y a un gros tri à faire ...
|
||||
<arpinux> oui :)
|
||||
<arpinux> mais c'est le principe
|
||||
```
|
||||
## aparté
|
||||
```
|
||||
<starsheep> alors pour le skel je comprends. Mais /usr/share il n'est pas modifié par les paquets lui ?
|
||||
<arpinux> si on peut
|
||||
<arpinux> mais sans ajouter de programmes qui seront appelés plus tard
|
||||
<arpinux> par exemple
|
||||
<arpinux> si tu veux coller ta version de conky dans le build
|
||||
<arpinux> tu peux
|
||||
<arpinux> - forker le paquet et l'appeler depuis la liste des paquets
|
||||
<arpinux> - forker ton paquet et l'ajouter en dur dans le build
|
||||
<arpinux> - forker le binaire et l'ajouter à la main
|
||||
<arpinux> Mais
|
||||
<arpinux> dans le cas 1, il faudra configurer apt pour lui indiquer par pinning de préférer ton conky à celui d debian lors de la prochaine mise à jour
|
||||
<arpinux> dans le cas 2, idem, mais en plus, tu ne pourras pas mettre ton conky à jour
|
||||
<arpinux> dans le cas 3, ton conky sera écrasé dès le build par l'installation du 'vrai' conky
|
||||
<arpinux> donc tu dois forker + renommer
|
||||
<arpinux> ou alors
|
||||
<arpinux> forker + placer ailleurs
|
||||
<starsheep> ok
|
||||
<arpinux> genre .usr/local/bin
|
||||
<starsheep> aaaaah ok
|
||||
<arpinux> dans le cas de DFLinux ou nos autres projets, le soucis ne se pose pas
|
||||
<starsheep> c'est pour ça que dans kissos tu as un /usr/local/share
|
||||
<arpinux> carnos programmes sont des ajouts et non des forks
|
||||
<starsheep> pour dwm-kissed
|
||||
<arpinux> oui starsheep, et aussi pour respecter l'architecture de base : ajout externe > local
|
||||
<starsheep> ajout externe ?
|
||||
<starsheep> En dehors des paquets ?
|
||||
<arpinux> oui
|
||||
```
|
||||
## séparation binary/chroot
|
||||
```
|
||||
<arpinux> et donc un autre aspect pratique que je souhaitais souligner à propos de live-build,c'est la séparation binary/chroot visible dans plusieurs dossiers/fichiers.
|
||||
<arpinux> live-build permet de séparer les applications installées dans le live de celles effectivement intégrées dans la distribution finale
|
||||
<starsheep> binary c'est pour le live et chroot pour l'installation ?
|
||||
<arpinux> donc le live 2 en 1 :)
|
||||
<arpinux> le principe est d'intégrer des programmes qui seront présent dans le live, mais pas dans la session installée et inversement :)
|
||||
<arpinux> ainsi, vous pouvez avoir sur un même cd, gparted disponible en live pour vérifier vos disques, mais pas dans la version installée
|
||||
<arpinux> plusieurs avantages : la disponibilité dans le live de nombreux programmes sans pour autant alourdir le système installé
|
||||
<arpinux> l'installation de nombreux programmes dans le système installé sans alourdir lechargement ni les menus du live
|
||||
<arpinux> l'équilibre est à trouver selon l'objectif du live
|
||||
<arpinux> mais vous voyez de suite le panel des possibilités :)
|
||||
<starsheep> yep
|
||||
<arpinux> l’extrême étant de faire un live qui n'a rien à voir avec le système installé au final
|
||||
<arpinux> et c'est possible de façon "transparente"
|
||||
<arpinux> cad sans que le user du live puisse le voir
|
||||
<starsheep> Il n'y a pas moyen de faire un truc commun aux deux sans faire doublon dans les sources ?
|
||||
<arpinux> un système live jessie stable pour tourner tranquille, mais qui renvoi à l'installation d'un sid
|
||||
<arpinux> car les binary/chroot
|
||||
<arpinux> sont des options disponibles aussi pour les miroirs consultés lors du build
|
||||
<arpinux> donc live-build peut appeler des paquets de différents branches de debian pour le live indépendamment des paquets du système final
|
||||
<kyodev> genre tu appâtes le chaland et crac! sid :o)
|
||||
<arpinux> yes ! :D
|
||||
<arpinux> sans aller jusque là, ça a le mérite de pouvoir éviter la surcharge du live en en supprimant toutes les applications non-essentielles par exemple
|
||||
<arpinux> un live-ultra-light installant un système complet :)
|
||||
<arpinux> l'inverse est possible aussi. un live ultra-complet pour montrer de quoi est capable debian, mais plusieurs formats d'installation
|
||||
<arpinux> car oui
|
||||
<arpinux> on peut aussi installer plusieurs système différents depuis le même live
|
||||
<arpinux> en dehors de la distinction binary/chroot
|
||||
<arpinux> oui
|
||||
<arpinux> ça en fait des possibilités :)
|
||||
<arpinux> alors pour ceux que ça branche, voilà le principe
|
||||
<arpinux> vous trouverez dans les sources de DFLinux https://git.framasoft.org/dflinux/DFiso le dossier /config/includes.binary/isolinux
|
||||
<arpinux> c'est la config du menu syslinux au boot du live
|
||||
<arpinux> le fichier install.cfg liste les entrées de menu pour l'installation. il indique lefichier preseed de préconfiguration à utiliser, on en a parlé au début.
|
||||
<arpinux> il suffit de coller plusieurs entrées, avec un appel à des preseed différents :)
|
||||
<arpinux> on peut coller une liste de paquets dans le preseed, donc....
|
||||
<arpinux> potentiellement une autre distro
|
||||
<arpinux> et autant de sitro que d'entrées de menu syslinux
|
||||
<arpinux> multi-possibilités ce live-build :)
|
||||
```
|
||||
### installer depuis live
|
||||
```
|
||||
<starsheep> Tu n'as toujours pas trouvé pour appeler les preseed depuis le live ?
|
||||
<starsheep> Pour ne pas retourner sur syslinux pour installer le système
|
||||
<arpinux> pour installer sans retourner sur syslinus, il y a le lanceur d'installation de bureau
|
||||
<arpinux> mais je ne l'intègre jamais
|
||||
<arpinux> j'explique
|
||||
<arpinux> le lanceur de bureau existe et permet effectivement de lancer l'installation sur le disque depuis une session live
|
||||
<arpinux> le soucis
|
||||
<arpinux> si pendant l'installation, le user ouvre son navigateur ou toute autre application rameuse
|
||||
<arpinux> il peut freezer son interface graphique
|
||||
<starsheep> oui c'est un reproche récurrent qui est fait à DFLinux (et avant HandyLinux)
|
||||
<arpinux> l'installation continuera en background
|
||||
<arpinux> mais il n'aura aucun retour ni interaction possible
|
||||
<starsheep> ah ouai pas con
|
||||
<starsheep> dangereux ce machin
|
||||
<arpinux> donc le dernier 'installation termniée, cliquez ok" ... bah tant pis ...
|
||||
<arpinux> et c'est pas trop grave si c'est ça
|
||||
<arpinux> en revanche, dans le cas d'un dual boot
|
||||
<arpinux> alors là
|
||||
<arpinux> bah dommage ....
|
||||
<arpinux> répare ton MBR
|
||||
<arpinux> :/
|
||||
<starsheep> t'as pété ton grub ^^
|
||||
<starsheep> nooon pas le MBR !!!!
|
||||
<starsheep> :D
|
||||
<arpinux> et c'est vraiment le truc tellement con pour un tout petit confort que je ne le fais jamais :)
|
||||
<starsheep> Trop de mauvais souvenirs :p
|
||||
<arpinux> c'était rigolo sur ubuntu de frimer en navigant et installant ... jusqu'au moment ou ça freeze ...
|
||||
<arpinux> et tu frimes moins
|
||||
<arpinux> non, vraiment, c'est une feature à éviter
|
||||
<arpinux> comme le "--interractive"
|
||||
<arpinux> l'option qui permet d'ouvrir une console pendant le build ....
|
||||
<arpinux> l'arme absolue ...
|
||||
<arpinux> alors oui
|
||||
<arpinux> on peut virer oute les autres options, ne laisser que celle-là
|
||||
<arpinux> et lors du passage en 'interractive',
|
||||
<arpinux> bah tu construis ton livesystème directementdans le chrrot
|
||||
<arpinux> tu fais ton live en temps réel à la main
|
||||
<arpinux> c'est une possibilité
|
||||
```
|
||||
## les hooks
|
||||
```
|
||||
<arpinux> donc les hooks sont des scripts qui s'exécutent dans le chroot juste avant de le quitter et de le compresser en squashfs
|
||||
<arpinux> même moment que interractive
|
||||
<arpinux> mais en automatique
|
||||
<arpinux> c'est pour le fignolage
|
||||
<arpinux> :)
|
||||
<starsheep> ok !
|
||||
<arpinux> on peut potentiellement faire tout ce qu'on veut
|
||||
<arpinux> pas de limite
|
||||
<starsheep> Je les oublie toujours ceux là
|
||||
<arpinux> openbar dans le chroot
|
||||
<roodinux> pourquoi ils ont des chiffres les hooks ? Si on ajoute celui que tu proposes dans le tutto on le nomme avec une valeur particulière ?
|
||||
<arpinux> l'ordre d'exécution
|
||||
<arpinux> ils s'exécutent dans l'ordre, tout simplement
|
||||
<arpinux> donc pratique si une action en demande un autre :)
|
||||
<roodinux> celui pour prendre en compte les ‘proposed-updates’ tu le nomme comment ?
|
||||
<arpinux> sans numéro particulier dans les sources car il peut se lancer n'importe quand
|
||||
<arpinux> proposed-update.chroot
|
||||
<arpinux> un autre fichier à tout faire
|
||||
<arpinux> c'est une option du fichier preseed dont on a déjà parlé
|
||||
<arpinux> -late-command
|
||||
<arpinux> c'est une option passée à l'installeur debian
|
||||
<arpinux> et qui permet de lancer des commandes sur le système fraîchement installé avant le reboot
|
||||
<arpinux> c'est la dernière chance de modifier le système avant que l'utilisateur prenne la main dessus
|
||||
<arpinux> dans les sources et le tuto support, il ne fait pas grand chose hormis fixer la date d'installation et virer 3 paquets inutiles au cas ou l'installeur ne l'ai pas fait
|
||||
<starsheep> après on ne peut même plus balancer de virus
|
||||
<starsheep> pas drôle
|
||||
<arpinux> depuis les dépôts externe, si, mais c'est mal
|
||||
<arpinux> :)
|
||||
<starsheep> :)
|
||||
<arpinux> faut voir le process de build en 3 temps
|
||||
<arpinux> installation du système de base dans un chroot
|
||||
<arpinux> copie du chroot modifié (le includes.chroot) dans le chrrot de build
|
||||
<arpinux> compression du chroot et build du live
|
||||
<starsheep> le système de base c'est donc Debian dans ce cas
|
||||
<arpinux> le hook se fait juste avant la fin du 2
|
||||
<arpinux> oui starsheep , plus les paquet listés dans le build
|
||||
<arpinux> ensuite viennent les modifs du includes
|
||||
<arpinux> ensuite les hooks système
|
||||
<arpinux> ensuite les hooks perso
|
||||
<arpinux> puis la compression en squasjfs
|
||||
<arpinux> squashfs
|
||||
<starsheep> et enfin les -late-command
|
||||
<arpinux> non starsheep
|
||||
<arpinux> les late-command, c'est à l'installation
|
||||
<arpinux> les hooks ,c'est lors du build
|
||||
<arpinux> oui, il y a vraiment énormément de façon de modifier son live, même après le build
|
||||
```
|
||||
|
||||
## simulation de build
|
||||
|
||||
* avec suivi git
|
||||
* irc 20/05/2017
|
||||
|
||||
```
|
||||
[20:04:44] <arpinux> attention au flood ....
|
||||
```
|
||||
```
|
||||
[-----------------------------------------------------------------------
|
||||
Bonsoir et bienvenue dans la session de simulation de construction d'une ISO personnalisée Debian :D
|
||||
- but de la session de travail : décomposer la personnalisation et suivre les modifications apportées
|
||||
aux sources du build au fur et à mesure
|
||||
- outils utilisés :
|
||||
- je travaille sur dépôt git, donc l'outil approprié serait ... git, mais vous pouvez aussi télécharger les sources en
|
||||
archives zip https://git.framasoft.org/arpinux/dfl-apprentissage/repository/archive.zip?ref=master puis suivre les
|
||||
différentes modification en ligne directement depuis la page des commits du projet
|
||||
https://git.framasoft.org/arpinux/dfl-apprentissage/commits/master
|
||||
- si vous utilisez git, vous pouvez cloner les sources depuis un 'git clone https://arpinux@framagit.org/arpinux/dfl-apprentissage.git'
|
||||
puis suivre la progression avec 'git pull' à chaque étape.
|
||||
|
||||
je vais partir d'un live vide puis ajouter par section les différents éléments.
|
||||
pour l'exemple, je ne construirai pas de live compatible efi, car l'option est encore en travaux, et le but principal est de bien
|
||||
suivre une construction, pas de tester la compatibilité UEFI :)
|
||||
vous pourrez personnaliser plus finement votre environnement après la session, je ne rajouterais que peu d'éléments, ceux qui me
|
||||
semblent les plus pertinents pour commencer avec live-build.
|
||||
le contenu de cette session sera ensuite disponible sous forme de wiki+archives pour consultation hors ligne.
|
||||
|
||||
notez que le processus simulé ce soir n'est pas fixé et que ce n'est qu'un exemple ... vous êtes libre ! :D
|
||||
-----------------------------------------------------------------------]
|
||||
```
|
||||
```
|
||||
git clone https://arpinux@framagit.org/arpinux/dfl-apprentissage.git
|
||||
|
||||
```
|
||||
```
|
||||
<arpinux> donc cd ./dfl-apprentissage
|
||||
<arpinux> puis git pull
|
||||
<arpinux> quand j'ai fait les modifs :)
|
||||
<arpinux> je vais tout expliquer au fur et à mesure :)
|
||||
<arpinux> donc la première chose à ajouter dans les sources d'un build, ce sont les premiers scripts de config et de construction
|
||||
<arpinux> situés dans le dossier /auto des sources
|
||||
<arpinux> il n'est pas encire là :)
|
||||
<arpinux> donc le premier ajout
|
||||
<arpinux> quand le réseau voudra bien me l'uploader ..
|
||||
<arpinux> vous pouvez git pull ou visitez les commits https://git.framasoft.org/arpinux/dfl-apprentissage/commits/master
|
||||
<arpinux> le fichier 'build" est celui livré par défaut dans live-build
|
||||
<arpinux> le fichier 'build" est celui livré par défaut dans live-build
|
||||
<arpinux> le "clean" est modifié pour nettoyer plus
|
||||
<arpinux> pour y voir plus clair sur les modifications des sources
|
||||
<kyodev> on aurait pu faire lb config?
|
||||
<naguam> dans config il y a --architectures "i386" \ normal ? que pas autres
|
||||
<arpinux> alors le lb config sans arguments, c'est pour faire une debian netinstall
|
||||
<arpinux> et pour voir toutes les possibilités en bloc
|
||||
<arpinux> le sujet de ce soir, c'est partir de rien et ajouter le strict nécessaire à la personnalisation
|
||||
<arpinux> dans ce cas, un lb config à vide ne sert à rien
|
||||
<arpinux> donc 3 nouveaux fichiers et le plus important étant le auto/config
|
||||
<arpinux> script qui va définir les arguments lancés à lb build
|
||||
<arpinux> donc les options de ce script que vous pouvez parcourir
|
||||
```
|
||||
```
|
||||
<arpinux> pour la liste complète des options acceptés, un man lb config renseignera
|
||||
<arpinux> mais le but de ce soir est vraiment d'en faire le minimum pour un résultat optimal
|
||||
<arpinux> donc dans les options indiquées dans auto/config, on remarque la ligne "architecture" qui permet de construire un live avec une arch différente de celle du système hôte
|
||||
<arpinux> notez qu'il n'es pas possible de build une amd64 depuis un i386 mais l'inverse, oui
|
||||
<arpinux> on va déjà se concentrer sur le processus global pas à pas et ne pas détailler chaque option de suite sinon ce sera sans fin et surtout illisible pour quelqu'un qui aimerait suivre le tuto
|
||||
<arpinux> comme je disais, la liste complète des options est dispo dans le man, mais il n'est pas totalement à jour
|
||||
<arpinux> donc pour vérifier celles que vous voudriez modifier dans les sources de ce soir,
|
||||
<arpinux> on peut se reporter aux fameux "test à vide" effectué hier ou simplement se contenter de celui que je fournis et qui vous permettra de build sereinement sans trop vous poser de question au début :)
|
||||
<arpinux> le plus important reste la personnalisation
|
||||
<arpinux> les paquets à installer
|
||||
<arpinux> et le final
|
||||
<arpinux> la custo du bureau de base :)
|
||||
<arpinux> pour se faire Son ISO
|
||||
<arpinux> :)
|
||||
```
|
||||
```
|
||||
<arpinux> donc la suite de la personnalisation réside dans les applications à installer
|
||||
<arpinux> ce soir, on va faire simple, on va coller les mêmes apps dans le live et dans le système final
|
||||
<arpinux> mais il est possible de séparer les paquets pour avoir des applications en plus/moins dans le live et le système installé, on y reviendra au final
|
||||
<arpinux> donc la liste des paquets se trouve dans le dossier config/package-lists/
|
||||
<arpinux> qui arrive :)
|
||||
<arpinux> alors effectivement, dans la liste que je vais poster, on pourrait encore simplifier
|
||||
<arpinux> et vous pourrez d'ailleurs le faire
|
||||
<arpinux> je push ... j'arrive :)
|
||||
<arpinux> vous pouvez pull depuis les sources
|
||||
<arpinux> ou visitez les commits https://git.framasoft.org/arpinux/dfl-apprentissage/commits/master
|
||||
```
|
||||
```
|
||||
git pull
|
||||
```
|
||||
```
|
||||
<arpinux> il y a deux listes
|
||||
<arpinux> la liste live* a été ajoutée automatiquement par live-build
|
||||
<arpinux> elle contient des paquets présents dans le live et qui ne seront pas installés
|
||||
<arpinux> vous comprenez que vous pouvez éditer cette liste
|
||||
<arpinux> et y ajouter tout les applications que vous voudriez voir dans le live et pas dans le système
|
||||
<arpinux> attention
|
||||
<arpinux> donc cette liste live* est ajoutée par live-build
|
||||
<arpinux> mais vous pouvez en coller une autre
|
||||
<arpinux> en fait tout fichier placé ici /config/package-lists/live* avec l'extension .live
|
||||
<arpinux> sera prit en compte par live-build
|
||||
<arpinux> donc vous pouvez faire des listes à thème si vous voulez
|
||||
<arpinux> genre multimedia.live ....
|
||||
<arpinux> et là vous auriez du me stopper car ne n'est pas l'extension live, mais le nom ....
|
||||
* arpinux le boulet
|
||||
<arpinux> :D
|
||||
<arpinux> mais si vous avez les sources devant les yeux, vous avez capté le truc :)
|
||||
<arpinux> bref
|
||||
```
|
||||
```
|
||||
<arpinux> l'autre liste, la *.chroot, est destinée aux paquets installés dans le live + dans le système installé
|
||||
<arpinux> donc la seconde liste avec les applications
|
||||
<arpinux> elle est détaillée car je n'ai pas mis de gros méta-paquets
|
||||
<arpinux> le système des dépendances debian permet de réduire la liste à 5 ou 6 paquets grace aus "taskel"
|
||||
<arpinux> mais ça fait des live assez gros
|
||||
<arpinux> comme les live officiel en fait
|
||||
<arpinux> donc pour éviter ça, on ne colle pas des trucs genre gnome-desktop :)
|
||||
<arpinux> mais plutôt les composants séparés
|
||||
<arpinux> donc je vous invite à ouvrir cette liste madebian.list.chroot
|
||||
<arpinux> vous pouvez supprimer ou ajouter des applications en prenant soin de vérifier qu'elles se trouvent bien dans les dépôts stretch :)
|
||||
<arpinux> la liste d'origine fournie donne un temps de build de 2h en gros, avec un système final fonctionnel
|
||||
<arpinux> bureau xfce/firefox/transmission/cups ... le nécessaire :)
|
||||
<arpinux> mais je vous laisse quelques minutes pour bien mater le fichier, et le modifier à votre guise
|
||||
<arpinux> vous pouvez yu aller, ça ne gênera pas la suite des ajouts ,quoique vous modifiez :)
|
||||
<arpinux> voilà, j'espère que vous avez eu le temps de modifier votre liste, vous pourrez y revenir tout à l'heure :)
|
||||
```
|
||||
```
|
||||
<arpinux> passons à une truc débile et rigolo
|
||||
<arpinux> la bannière de l'installeur graphique :)
|
||||
<arpinux> et donc, avant de taper dans les trucs longs et embêtant
|
||||
<arpinux> un petit plaisir de sucto
|
||||
<arpinux> la bannière
|
||||
<arpinux> le truc qui va s'afficher en haut pendant l'installation
|
||||
<arpinux> et qui dire
|
||||
<arpinux> dira
|
||||
<arpinux> "tu installe ma distro" :D
|
||||
<arpinux> un peu d'ego ne fait pas de mal si il ne fait pas d'ombre à l'autre :)
|
||||
<arpinux> c'est dans le dossier config/includes.installer/usr/share/grahics/
|
||||
<arpinux> qui n'est pas encore là :)
|
||||
<arpinux> vous pouvez git pull ou visiter les commits :)
|
||||
<arpinux> oui, je sais, c'est futile
|
||||
<arpinux> mais ça rassure aussi l'utilisateur de savoir que le builder s'est un peu fait chier à personnaliser son truc et n'a pas juste balancé 2 walls et 3 applis :)
|
||||
<arpinux> c'est pas anodin :)
|
||||
```
|
||||
```
|
||||
<arpinux> passons à plus sérieux
|
||||
<arpinux> le menu de boot du live
|
||||
<arpinux> il est contrôlé par syslinux
|
||||
<arpinux> pour le personnaliser, vous pouvez changer les labels des entrées , le fond et même en rajouter
|
||||
<arpinux> par exemple
|
||||
<arpinux> lister plusieurs entrées avec différentes langues activées par défaut
|
||||
<arpinux> car les options passées à syslinux sont comme les options de grub
|
||||
<arpinux> on va voir de suite un custo simple
|
||||
<arpinux> ça se passe dans /config/includes.binary/isolinux/
|
||||
<arpinux> qui arrive :)
|
||||
<arpinux> vous pouvez git pull ou visitez les commits https://git.framasoft.org/arpinux/dfl-apprentissage/commits/master
|
||||
<arpinux> le nouveau dossier intègre un menu pour le live et un fond d'écran
|
||||
<arpinux> mais vous pouvez aussi personnaliser le label d'installation, le titre principal etc
|
||||
<arpinux> vous aurez des exemples plus complet sur DFLinux
|
||||
<arpinux> donc le fichier live.cfg
|
||||
<arpinux> vous pouvez voir que ce fichier contient le label "tester debian" en premier
|
||||
<arpinux> avec un ^
|
||||
<arpinux> c'est pour indiquer la touche d'accès rapide au clavier
|
||||
<arpinux> le raccourcis quoi ..
|
||||
<arpinux> la dernière ligne de chaque section indique les options passées au kernel
|
||||
<arpinux> append boot = ....
|
||||
<arpinux> c'est là que vous pouvez spécifier la langue du live
|
||||
<arpinux> le fichier install.cfg n'est pas dans ces sources car on ne le personnalise pas, il sera ajouté par live-build et donc, on aura bien une entrée 'install' dans le menu final :)
|
||||
<kyodev> ligne e: option, c: console
|
||||
<kyodev> c'est qui qui fait?
|
||||
<arpinux> un fichier qui se nomme stdmenu.cfg
|
||||
<arpinux> qui n'est pas présent dans ces sources mais dans celles de DFLinux
|
||||
<arpinux> on n'y touche pas ce soir, donc il n'est pas dans ces sources
|
||||
<arpinux> donc je termine sur la custo du menu
|
||||
<arpinux> pour les couleurs, la disposition etc, franchement, c'est la galère car c'est tout en code de taré
|
||||
<arpinux> (terme technique assumé)
|
||||
<arpinux> donc faites simple, ce sera mieux :)
|
||||
<arpinux> et puis, ce n'est pas non plus l plus important, le tout étant d'avoir la bonne langue au démarrage :)
|
||||
```
|
||||
```
|
||||
<arpinux> on va attaquer maintenant le plus cool
|
||||
<arpinux> la custo directe du système et du user
|
||||
<arpinux> ça se passe dans /config/includes.chroot/
|
||||
<arpinux> ce dossier représente la racine du système installé :)
|
||||
<arpinux> donc c'est le moment de se faire plaisir et d'y ajouter tout ce qu'on veut :)
|
||||
<arpinux> avec quelques restrictions cependant
|
||||
<arpinux> badadd n1
|
||||
<arpinux> les trucs écrasés ....
|
||||
<arpinux> si vous ajoutez dans ce dossier, un élément qui appartient déjà à un paquet
|
||||
<arpinux> il sera écrasé par le paquet lors du build
|
||||
<arpinux> par exemple
|
||||
<arpinux> vous voulez coller votre version de "ffmpeg"
|
||||
<arpinux> mais si vous ajoutez
|
||||
<arpinux> config/includes.chroot/usr/bin/ffmpeg
|
||||
<arpinux> il sera écrasé par le vrai lors de l'install
|
||||
<arpinux> vous pouvez coller le votre dans /usr/local/bin :)
|
||||
<arpinux> il ne sera pas écrasé
|
||||
<arpinux> et vous pourrez vous en servir sans soucis depuis un alias approprié :)
|
||||
<arpinux> badadd n2
|
||||
<arpinux> le paquets perso
|
||||
<arpinux> live-build gère ses paquets avec apt
|
||||
<arpinux> donc dépendances, sécurité, mise à jour et tout ce qui va bien
|
||||
<arpinux> live-build vous permet d'ajouter des paquets perso dans le dossier /config/packages
|
||||
<arpinux> c'est super :)
|
||||
<arpinux> mais attention
|
||||
<arpinux> c'est dpkg qui installe les paquet de /packages
|
||||
<arpinux> donc avec tout ce que ça implique :)
|
||||
<arpinux> pas de suivi des mises à jour et pas de gestion des dep
|
||||
<arpinux> donc faire attention
|
||||
<arpinux> en fait apt télécharge les paquets, puis dpkg installe les paquets, dont ceux que tu as ajouté à la main
|
||||
<arpinux> badadd n3
|
||||
<arpinux> les copyrights
|
||||
<arpinux> gaffe si vous voulez diffuser votre live
|
||||
<arpinux> ce que vous y ajoutez est de votre responsabilité
|
||||
<arpinux> donc respectez les licences, créditez les auteurs, palcez des liens dans un README
|
||||
<arpinux> bref
|
||||
<arpinux> soyez responsables de ce que vous diffusez
|
||||
<arpinux> je sais que ça fait un peu vieux con de dire ça
|
||||
<arpinux> mais les débutants ou les curieux de linus méritent de recevoir un truc propre :)
|
||||
<arpinux> linux*
|
||||
<arpinux> ce n'est pas parce que c'est free et gratuit que ça doit être "passable" ;)
|
||||
<arpinux> donc pour illustrer la custo
|
||||
<arpinux> un exemple tout bête
|
||||
<arpinux> les wallpapers perso :)
|
||||
<arpinux> bah oui ... c'est quand même super cool d'avoir ses walls dans sa distro :)
|
||||
<arpinux> vous pouvez git pull, et profitez de quelques walls de Péhä :)
|
||||
<arpinux> un dernier stade avant de build :)
|
||||
<arpinux> je vous laisserais ajouter ce que vous voulez dans le includes.chroot mais avant
|
||||
<arpinux> un point sur les paquets selon ceux que vous avez ajoutés/retirés
|
||||
<arpinux> si comme dans les sources, vous installé libdvdcss2
|
||||
<arpinux> vous devez ajouter des dépôts externes
|
||||
<arpinux> c'est geekland à expliquer alors que c'est simple en voyant ... alors je montre :)
|
||||
<arpinux> les paquets listés doivent être sur un dépôt
|
||||
<arpinux> logique
|
||||
<arpinux> si ils ne sont pas chez debian, il faut indiquer les dépôt + la clé d'authentification
|
||||
<arpinux> soit en un commit pour faire simple
|
||||
<arpinux> vous pouvez git pull et voir apparaître le dossier config/archives :)
|
||||
<arpinux> 2 fichiers pour les dépôts videolan : un pour le liven et un pour le système installé
|
||||
<arpinux> 2 fichiers pour la clé videolan : idem que pour l'autre :)
|
||||
<arpinux> donc si vous voulez par exemple, le dépôt TOR
|
||||
<arpinux> bah pareil, vous ajoutez les dépôts sous forme d'adresse + le fichier avec la clé dans le même dossier
|
||||
<arpinux> avec les mêmes extensions *.binary pour le live et *.chroot pour le système installé
|
||||
<arpinux> donc c'est fini pour la custo de base ...
|
||||
```
|
||||
```
|
||||
<arpinux> pour un premier build fonctionnel , pas de custo du user en phase 1
|
||||
<arpinux> pourquoi
|
||||
<arpinux> car il faut d'abord choper les valeurs par défaut avant de les modifier
|
||||
<arpinux> les valeurs distribuées par le système que vous venez de créer
|
||||
<arpinux> donc le meilleur moyen
|
||||
<arpinux> c'est de build
|
||||
<arpinux> lancer le live
|
||||
<arpinux> personnaliser en live
|
||||
<arpinux> puis faire une archive des mods
|
||||
<arpinux> donc généralement
|
||||
<arpinux> archiver le ~/.config
|
||||
<arpinux> le ~/.mozilla sivous voulez mais attention à bien vider le cache et les pass !!!
|
||||
<arpinux> puis récupérer ces archives pour les placer des includes.chroot/etc/skel afin de personnaliser votre utilisateur :)
|
||||
<arpinux> et vous retrouverez vos préférences en live
|
||||
<arpinux> autre solution
|
||||
<arpinux> ...
|
||||
<arpinux> pour la custo user
|
||||
<arpinux> si vous utilisez le même environnement que celui qui sera dans le live
|
||||
<arpinux> vous pouvez récupérer certaines de vos préférences directement
|
||||
<arpinux> attention
|
||||
<arpinux> pensez que le live , s'il est public, comportera vos préférences
|
||||
<arpinux> donc pas de .ssh
|
||||
<arpinux> PAS DE .SHH !!!
|
||||
<arpinux> :D
|
||||
<arpinux> bref
|
||||
<arpinux> je ne peux pas lister Vos fichiers sensibles mais vous avez compris le principe :)
|
||||
<arpinux> et c'est aussi pour ça que pour ce soir, je ne vous conseille pas de custo le user
|
||||
<arpinux> autant vous concentrer sur les applications à installer
|
||||
```
|
||||
```
|
||||
<arpinux> donc si vous êtes partant, on peut lb build :D
|
||||
<arpinux> depuis les sources, vous pouvez envoyer la commande
|
||||
<arpinux> sudo lb build
|
||||
<arpinux> plus sûr
|
||||
<arpinux> donc voilà, avec ces sources https://git.framasoft.org/arpinux/dfl-apprentissage , vous avez une armature pour un live simple sur xfce, que vous pouvez agrémenter avec le tuto live-build et faire votre distro
|
||||
<arpinux> j'espère avoir été clair et simple
|
||||
<arpinux> et que vous avez vu le processus en global
|
||||
<arpinux> :)
|
||||
```
|
||||
```
|
||||
<arpinux> pour ajouter des dépôts debian supplémentaires, comme les dépôts externes, tu places un fichier avec l'adresse dans /config/archives
|
||||
<arpinux> tu n'as pas besoin de coller la clé :)
|
||||
<arpinux> pour les préférences apt/pinning
|
||||
<arpinux> tu ajoute ton preferences dans config/includes.chroot/etc/apt/preferences.d/preferences
|
||||
<arpinux> et voilà :)
|
||||
<arpinux> la ligne "experimentale" sera prise en compte lors du build et à l'installation et sera ajouté à /etc/apt/sources.list.d/experimental.list
|
||||
```
|
||||
```
|
||||
<roodinux> donc si je je veux mettre un .mozilla
|
||||
<arpinux> c'est dans config/includes.chroot/etc/skel/.mozilla
|
||||
<arpinux> et il vient de ton système ?
|
||||
<roodinux> ok, j'ai compris ça. de la clé live que j'ai testé tout à l'heure...
|
||||
<arpinux> :)
|
||||
```
|
||||
```
|
||||
<roodinux> donc quand tu veux ajouter une config dans le skeleton, tu recréer l’arborescence des fichiers si je comprends bien...
|
||||
<arpinux> oui, comme si includes.chroot/ était la racine du système
|
||||
<arpinux> sauf pour /home qui reste vide
|
||||
<arpinux> c'est pour ça qu'on colle dans /etc/skel pour le user
|
||||
<roodinux> ok... surtout que c'est un user live qui ne conservera rien...
|
||||
<roodinux> enfin si la config reste pour les deux en live et après install
|
||||
<kyodev> on peut activer la persistances des données, non?
|
||||
<arpinux> oui, on peut aussi pré-configurer un 'vrai' user avec un login/pass etc, mais c'est un peu plus hard en config :)
|
||||
<arpinux> et j'avoue que je suis pas fan de la persistance
|
||||
<arpinux> rien de plus facile à perdre qu'une clé usb ...
|
||||
<arpinux> donc je préfère le live 'pure'
|
||||
```
|
||||
```
|
||||
<roodinux> Aïe et si l'écran se met en veille utilisateur: humain ? mot de passe?
|
||||
<arpinux> live
|
||||
```
|
||||
|
||||
## un essai de bidouille live sid
|
||||
```
|
||||
#!/bin/sh
|
||||
set -e
|
||||
lb config noauto \
|
||||
--apt-indices "true" \
|
||||
--apt-recommends "true" \
|
||||
--apt-secure "true" \
|
||||
--apt-source-archives "false" \
|
||||
--architectures "amd64" \
|
||||
--archive-areas "main contrib non-free" \
|
||||
--backports "false" \
|
||||
--binary-images "iso-hybrid" \
|
||||
--bootloader "syslinux" \
|
||||
--clean \
|
||||
--debian-installer "netinst" \
|
||||
--debian-installer-gui "true" \
|
||||
--distribution "sid" \
|
||||
--system "live" \
|
||||
--iso-application "PengouinSid" \
|
||||
--iso-volume "PengouinSid" \
|
||||
--linux-package "linux-image" \
|
||||
--firmware-binary "true" \
|
||||
--firmware-chroot "true" \
|
||||
--source "false" \
|
||||
--security "false" \
|
||||
--updates "false" \
|
||||
--verbose \
|
||||
--win32-loader "false" \
|
||||
"${@}"
|
||||
```
|
||||
```
|
||||
<arpinux> le live fonctionne
|
||||
<arpinux> l'install aussi :D
|
||||
<arpinux> erreur au chargement des noyaux
|
||||
<arpinux> je continue quand même
|
||||
<arpinux> ah .. il trouve pas de disque dur ...
|
||||
<PengouinBSD> ahhh, très bien :p
|
||||
<arpinux> :/
|
||||
<PengouinBSD> enfin, non, mais bon, t'as compris :D
|
||||
<arpinux> oui :)
|
||||
<arpinux> alors pour construire un live sid ... peut être passer par un live ç vide stretch, mais avec un hook, un seul, pour exécuter une dist-upgrade du chroot vers sid avant la fin du chroot :)
|
||||
<arpinux> donc un installeur stretch, mais qui copie un système sid
|
||||
<arpinux> parce que normalement, pour installer une sid, on prend la netinstall testing, on passe en mode expert install et on demande à choper la version unstable dans les options
|
||||
<arpinux> mais il n'y a pas de live sid proprement dit
|
||||
<lagout> sid seul n est pas utilisable en tant que tel
|
||||
<lagout> y à pas asser de paquet
|
||||
<arpinux> mais c'est marrant que live-build accepte de build en sid quand même
|
||||
<arpinux> enfin "marrant" ....
|
||||
<arpinux> une autre idée
|
||||
<arpinux> choper ta config, mais en collant "stretch"
|
||||
<arpinux> et en plus
|
||||
<arpinux> dans config/archives
|
||||
<arpinux> on rajoute la ligne des dépôts sid
|
||||
<arpinux> :)
|
||||
<arpinux> donc juste remplace "sid" par "stretch" dans auto/config
|
||||
<arpinux> et ajouter dans config/archives
|
||||
<arpinux> sid.list.chroot et sid.list.binary
|
||||
<arpinux> avec deb http://ftp.fr.debian.org/debian/ unstable main contrib non-free
|
||||
<lagout> PengouinBSD: c est ça qui est drole
|
||||
<arpinux> ah si
|
||||
<arpinux> j'ai changé "netinst" par "live" pour l'installeur
|
||||
<PengouinBSD> arpinux, si je ne me trompe, ça va faire quand même une install qui dure 2 * + de temps, non ?
|
||||
<arpinux> cad ? 2*+ de temps ?
|
||||
<PengouinBSD> beh, oui, y'a la phase d'install stretch puis sid
|
||||
<arpinux> non
|
||||
<arpinux> pas comme j'ai fait
|
||||
<arpinux> pas de hook
|
||||
<arpinux> en ajoutant la ligne sid dans archives
|
||||
<arpinux> je dis à live-build de le prendre en compte directement dans le build
|
||||
<PengouinBSD> pourtant il récupère bien tous les packages en interrogeant les dépôts Sid !
|
||||
<arpinux> mais tout en précisant d'utiliser le système de base stretch (donc tous les paquets dispo)
|
||||
<arpinux> l'option --distribution "stretch" indique à live-build de tout mettre en place avec les outils stretch
|
||||
<arpinux> la ligne dans archives indique qu'il peut choper aussi des paquets de sid
|
||||
<arpinux> ce n'est pas pareil que de dire directement à l'installeur de bosser sur sid
|
||||
<arpinux> là il taf que stretch
|
||||
<arpinux> et si il peut
|
||||
<arpinux> il chope du sid
|
||||
<arpinux> théoriquement, ça devrait marcher :SD
|
||||
<arpinux> :D
|
||||
<arpinux> il build là
|
||||
<arpinux> il va bien chercher l'installeur chez stretch
|
||||
<arpinux> build stretch/sid terminé
|
||||
<arpinux> live fonctionnel
|
||||
<arpinux> je tente l'install ??
|
||||
<arpinux> install lancée ....
|
||||
<arpinux> pas de module noyau ....
|
||||
<arpinux> ça commence mal....
|
||||
<arpinux> aucuen carte ethernet trouvée ....
|
||||
<arpinux> bon bah non .... abort install
|
||||
<arpinux> haha
|
||||
<arpinux> à jouer avec stretch/sid alors que debian est prévu comme 'stable' ... jte jure ...
|
||||
<PengouinBSD> hihihihihihi
|
||||
* PengouinBSD "love exciting way :p!"
|
||||
<arpinux> ça t'amuse de me faire build nawak hein ???!!!
|
||||
<arpinux> :D
|
||||
<PengouinBSD> YESSS!
|
||||
<PengouinBSD> XD
|
||||
<arpinux> alors pourquoi ça ne fonctionne pas
|
||||
<arpinux> si on utilise distribution "sid", il manque des paquets
|
||||
```
|
|
@ -22,6 +22,7 @@ pages:
|
|||
- config: "live-build/config.md"
|
||||
- live-build/preseed-stretch.md
|
||||
- live-build/liens.md
|
||||
- apprentissage: live-build/live-build-apprentissage.md
|
||||
- trucs:
|
||||
- trucs/iso-sur-usb.md
|
||||
- trucs/rmadison.md
|
||||
|
|
Loading…
Reference in New Issue