http://fr.rpmfind.net/linux/fedora/core/3/i386/os/RELEASE-NOTES-en.(...) In order to eliminate the redundancy inherent in providing a separate package for the kernel source code when that source code already exists in the kernel's .src.rpm file, Fedora Core 3 no longer includes the kernel-source package. Users that require access to the kernel sources can find them in the kernel .src.rpm file.
...
An exploded source tree is not required to build kernel modules against the currently in-use kernel.
For example, to build the foo.ko module, create the following file (named Makefile) in the directory containing the foo.c file:
Pour Novell, c'est discutable (mais ton argument est très très moyen).
Pour Red Hat qui ne sera pas LSB 2.0, c'est indiscutable. Pourquoi Red Hat va soutenir un concurrent ? Ça n'a pas de sens.
Ce n'est pas parce que tu soutiens LSB que tu soutiens toutes les distributions LSB. Surtout que toutes les distributions sont LSB.
Progeny utilise Linux, SuSE soutient Linux dont SuSE soutient Progeny. Ça n'a aucun sens ce type de raisonnement.
> Le projet a le soutien de quelques grands noms du monde informatique (Computer Associates, HP, ...). Bizarrement, parmi ces noms se retrouvent RedHat et Novell (alors que leurs distributions - RedHat et SuSE - ne font par partie du lot). Il y a aussi l'OSDL et le Free Standards Group.
LCC fait dans la confusion. Ils détournent ceux qui soutiennent LSB pour dire qu'ils soutiennent LCC.
Notons que presque toutes les distributions sont compatible LSB (La certification est payante, donc toutes les distributions n'ont pas le certificat même si elles sont compatibles).
SuSE 9.2 est la première distribution certifiée LSB 2.0.
> Manque de bol, c'est pas synchronisé avec les derniers patchs de Linus
T'as un snapshot quotidien de la branche Linus sur www.kernel.org !
Ce n'est pas le bout du monde de synchroniser ton patch.
> Donc comme j'explique plus bas, utiliser BitKeeper n'est pas une obligation mais permet d'etre sur de soumettre des patchs que Linus a de fortes chances de ne pas rejeter pour cause de desynchronisation avec son arbre.
Ça ne change rien. BitKeeper ou pas tu dois synchroniser ton patch.
Sans BitKeeper c'est moins pratique mais tout a fait réalisable sans grande difficulté.
Andrew Morton utilise Bk depuis peu de temps. Avant il faisait sans Bk et il en brasse des patchs.
Alan Cox n'utilise pas Bk.
etc.
Linus, pour développer, utilise aussi un PC avec un BIOS non libre, avec des périphériques dont les firmware sont non libre, etc. Linux n'en reste pas moins libre.
C'est pour l'image du libre que ce n'est pas terrible.
Pour allimenter le troll sur "je me prend pour un hacker de noyau donc je veux un outils pour hacker de noyau : http://www.darcs.net/(...)
Qui nous fait un Bk vs Arch vs Darcs pour les hackers de noyau ?
cat /etc/sysconfig/kernel
# UPDATEDEFAULT specifies if new-kernel-pkg should make
# new kernels the default
UPDATEDEFAULT=yes
# DEFAULTKERNEL specifies the default kernel package type
DEFAULTKERNEL=kernel
Donc, mets "UPDATEDEFAULT=no" et les nouveaux noyaux ne sont pas activé par défaut par grub (mais ils sont toujours installés et l'entrée dans grub.conf est ajoutée). C'est nouveau dans FC3.
Ça permet de faire des "petites choses" avant de monter la vrai partition racine.
Red Hat utilise ça depuis longtemps. Par exemple, ça permet d'indiquer la partition racine avec le label de la racine et non avec le périphérique réel. Si le disque bouge, il n'y a pas de problème.
Sans initrd :
root=/dev/hdc
Avec initrd :
root=LABEL=root
Si root passe de /dev/hdc à /dev/hdd, ça ne boote plus avec "root=/dev/hdc" mais ça boote toujours avec "root=LABEL=root".
La partition root peut se trouver n'importe où. Sur un lvm, une partition raid, etc... C'est initrd qui va initialiser et fouiller les périphériques, raid, lvm pour récupérer les label et utiliser le bon périphérique.
Avec udev, udev doit être initialisé avant de monter la partition root. Sauf si tu as un /dev avec déjà des nodes. Mais dans ce cas, c'est une "sous-utilisation" d'udev. Avec udev, /dev est un tmpfs mounté par initrd dans le ramfs initial.
udev minimum (sans /etc/udev/rules.d) est initialisé par initrd. Puis la partition root est montée. Puis la partition /dev dans le ramfs initial est déplacé dans la partition racine.
Avec FC3, on peut faire sans initrd mais il faut :
- ne pas utiliser les label par la partition racine
- avoir /dev static avec les nodes nécessaires au boot (/dev/partition_racine, /dev/null, /dev/console, etc).
- tous les drivers pour la partition root doivent être dans le noyau et pas en modules.
Les données, ce sont les données. Par exemple le contenu d'un fichier.
Les meta-données indiquent où trouver les données (c'est la table d'inode, des blocks libre, etc).
Ext3 est le seul FS a journaliser les données.
Exemple :
fd = open("toto") ;
write(fd, "data") ;
close (fd) (ou flush(fd)) ;
// coupure de courrant ou reset
Avec ext3, les données sont écrites, la taille du fichier est 4.
Avec xfs, jfs, reiserfs, les données peuvent ne pas être écrite et "pire" l'inode peut ne pas être créé. Si l'inode est créé, le fichier a une taille de 4 octets. Par contre rien ne garanti que les données sont écrites. Dans ces 4 octets il peut y avoir un bout d'un ancien /etc/passwd par exemple. C'est génant.
Si la coupure de courant ou le reset est fait avant le close() ou flush(), les données peuvent être écrite ou non. Par contre avec ext3 tu n'auras pas de mauvaises données. ext3 ne garantit l'ordre d'écriture que s'il y a un close() ou flush().
Donc :
fd = open("toto") ;
write(fd, "data") ;
seek(fd, quelque_part) // NB : ext3 mets les données à 0 si on va au-delà de la fin du fichier. Leur autres aussi sûrement (du moins s'il n'y a pas de coupure de courant ou reset).
write(fd, "data2") ;
// coupure de courant
"data2" peut être écrit alors que "data" n'est pas écrit. Si tu utilises un flush(), tu es sûr que "data" et "data2" sont écrits. ext3 journalise les données en premier (garanti que les données sont là) puis les méta-données.
C'est plus lent qu'un fs journalisé "classique" mais plus sûr. PostgreSQL (qui utilise flush comme d'autres SGBD, mais pas MySQL) sur ext3 est blindé.
Ça dépend du hardware. Avec SCSI il n'y a pas de problème sur coupure de courant.
> En fait si je soupçonne le FS, c'est qu'il est impossible de faire un fsck sur la partition incriminée (sous knoppix).
FC3 est en "avance" pour ext3.
Le ext3 de FC3 n'est pas compatible avec des vieilles versions de e2fsprogs.
> A vrai dire c'est la partition avec /home qui est partie en live, parfois c'est /boot, parfois /home (plus embêtant)
> Le plus rigolo c'est que quand le fsck semble pmarcher, certains dossiers disparaissent quand même, et se retrouve avec une taille négative (bref inutilisable)
Sous FC3 ou sous knoppix ?
> c'est vraiment mieux comme système de fichier ?
Il a ses défauts et qualité. Pas envis de troller.
> Pourquoi n'est-ce pas par défaut ?
Pour 4 "bonnes" raisons :
- ext3 est plus solide (normalement :-))
- ext3 est nfs compliant (flush)
- ext3 est principalement développé par Red Hat
- reiserfs ne supporte pas les attributs étendus et donc ne supporte pas SeLinux. Il parait qu'il y a un patch SuSE.
Il y a de "gros" problèmes de compatibilité ext3 avec FC3. Par exemple, si tu es sous knoppix il faut une e2fsck qui supporte :
- resize_inode dir_index attr_ext
C'est spécifique Linux 2.6 et c'est standard (sauf resize_inode qui n'est pas encore en upstream).
Tu pourrais être plus claire car là, j'ai l'impression que tu as un problème *depuis* knoppix et pas avec FC3.
Attention, FC3 ajoute l'attribut "attr_ext" aux FS ext3 et certains versions d'e2fsck de certaines distributions n'aiment pas ça.
Pour résumer, la cohabitation FC3 avec une autre distribution n'est pas facile car :
- Selinux par défaut
- resize_inode
Quoi d'autre ?
Avec le kernel standard ou tu as recompilé le kernel ?
Tu utilises les labels dans grub.conf (root=LABEL=/) ?
Ce n'est pas forcément un problème de FS.
Pour FC3, il faut :
- Un initrd fait par mkinitrd >= 4.1.18
- tmpfs de compilé dans le noyau
- ne pas désigner root avec un label pour raid
Ceci est valable avec tous les FS.
> genre je peux mettre du reiserFS alors que la FC3 ne me le propose pas à l'install ?
Pour utiliser reiserFS à l'installation :
linux reiserfs selinux=0
Ça tombe bien, tout le monde est déjà LSB.
La "force" de LCC n'est pas d'être LSB car toutes les distributions le sont déjà.
Le seul "hic" est que Red Hat ne sera pas LSB 2.0 (utilisent l'ABI c++ v6, LSB est a v5).
Temporairement, quelques uns vont dire qu'ils sont LSB 2.0 et que Red Hat ne l'est pas. La théorie que Red Hat veut forker Linux va être réveillée pour le plus grand bonheur des trolleurs.
Quand LSB sera basée sur l'ABI v6, tout sera "comme avant".
> En tout cas à moyen terme, un manque d'interopérabilité peut être dramatique pour l'image de Linux dans le grand public professionnel
Manque d'interopérabilité entre distributions ?
C'est un problème pour qui ?
Pour Red Hat et Novell qui dominent le marché de l'entreprise, ce n'est pas un problème pour avoir des certifications. Ils ont leur certification et sont contents.
Pour les petits qui veulent pénétrer le marché de l'entreprise, c'est beaucoup plus problématique. Oracle va peut-être certifier LCC comme ils le font pour Red Hat. Mais Oracle ne va pas le faire pour "seulement" Progeny, puis "seulement" TurboLinux, ...
Si les distributions LCC ne sont pas très proches, Oracle ne voudra pas les certifier. Trop de travail de support. On voit le paradoxe. Les objectifs de LCC ne sont pas compatible avec la diversité. S'il n'y a pas de diversité il n'y a pas de problème de compatibilité. Le rève de Red Hat et Novell :-). LCC est un concurrent de plus.
Voilà ce qu'apporte LCC. C'est comme United Linux.
À part SCO, United Linux avait quoi de mal ?
Je ne comprend pas pourquoi tout le monde critiquait United Linux et pas LCC (les deux sont/seront certifiés LSB).
Jusqu'à maintenant, il n'y a pas de différence entre United Linux et LCC.
Les deux :
- proposent plusieurs distributions (SuSE, Conectiva, TurboLinux, SCO) avec la même base
- sont LSB
L'annonce, en insistant sur LSB, veut faire croire que c'est différent, mais il n'y a pas de différence. United Linux était primcipalement l'oeuvre de SuSE. SuSE a toujours été LSB.
Contrairement à ce que fait croire l'annonce, Red Hat, Sun, Novell ne supporte pas LCC : http://www.mandrakesoft.com/lcc/faq(...) LCC invites all Linux companies to join. Red Hat, Novell, Sun, and Asianux have already been invited.
Je ne vois pas l'intérêt pour Red Hat, Novell ou Sun de supporter LCC. Leur position est "trop forte". Sinon ils devront reconnaitre qu'une ditribution Novell ou Red Hat est la même chose qu'un Progeny ou Mandrake. Ce n'est pas génial pour leur image qui est meilleur (en entreprise). Possible que SuSE(Novell) ait été calmé par son avanture United Linux.
Soit c'est dans /proc/stats (linux 2.4) ou /proc/diskstat (linux 2.6).
procinfo doit être utilisable m'est n'a pas été mis à jour pour linux 2.6 il semble.
Pour /proc/diskstat, de procinfo(8) :
major minor name noinfo read_io_ops blks_read write_io_ops blks_written
Pas avec yum 2.1 (fc3).
Mon système est à jour :
# rm -r -f /var/cache/yum/*
# yum update
...
repomd.xml 100% |=========================| 951 B 00:00
...
primary.xml.gz 100% |=========================| 620 kB 00:00
Si le système est à jour, il ne download que repond.xml et primary.xml.gz par repository.
Si Ces fichiers sont déjà en cache (et pas plus récent sur serveur), il ne les downloade pas.
Lorsqu'un fichier est downloadé il y a :
100% |=========================| ??? B
Lorsque c'est un traitement depuis le cache, c'est :
Base : ################################################## ???/???
En fesant attention à ces indicateurs, on voit que yum ne download presque rien.
Tout ce que downloade yum, est nécessaire pour sa tache.
Créer les chap-secrets et pap-secrets :
# Secrets for authentication using CHAP
# client server secret IP addresses
ton_compte * "ton_pass"
Puis faire un petit script qui sera lancé au boot :
#!/bin/bash
modprobe unicorn_pci_atm
sleep 60 # attente que la ligne soit up
# pppd tourne déjà ?
[ -f /var/run/ppp0.pid ] || exec pppd user ton_compte persist
2- PPPOETH
On peut aussi utiliser pppoeth (module unicorn_pci_eth).
Dans ce cas le nouveau ppp n'est pas nécessaire.
Il faut installer le paquet rp-pppoe (normalement déjà installé).
- recompiler tout le noyau sans CONFIG_REGPARAM.
- compiler et installer bewan (n'installes que unicorn_pci_eth.ko sinon kudzu se mélange parfois les pinceaux (c'est encore une erreur bewan)). Voir [*].
- lancer kudzu. Il va faire n'importe quoi mais ce n'est pas grave.
- Lancer system-config-network et configurer une ligne adsl pppoeth. Il insistera pour utiliser eth0, acceptes et continues.
- Ajouter à /etc/modprobe.conf :
alias dsl0 unicorn_pci_eth <== bewan existe dsl0 (encore une erreur bewan)
options unicorn_pci_eth PROTOCOL=pppoe VPI=8 VCI=35
options dsl0 PROTOCOL=pppoe VPI=8 VCI=35
Edites /etc/sysconfig/network-scripts/ifcfg-ton_fai pour avoir quelque chose comme ça (normalement il n'y a que le paramètre ETH à éditer) :
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
IPV6INIT=no
USERCTL=yes
PEERDNS=yes
TYPE=xDSL
DEVICE=ppp0
BOOTPROTO=dialup
PIDFILE=/var/run/pppoe-adsl.pid
FIREWALL=NONE
PING=.
PPPOE_TIMEOUT=80
LCP_FAILURE=3
LCP_INTERVAL=20
CLAMPMSS=1412
CONNECT_POLL=6
CONNECT_TIMEOUT=60
PERSIST=no
SYNCHRONOUS=no
DEFROUTE=yes
USER='ton_compte'
ETH=dsl0 <=== system-config-nework met eth0
PROVIDER=ton_fia
DEMAND=no
ONBOOT=yes
Pour activer la ligne "/sbin/ifup ton_fai" doit marcher. La ligne sera activée au boot.
J'utilise pppoatm car c'est un peu plus rapide.
[*]
installation de bewan :
Le driver est ici : http://www.bewan.fr/bewan/utilisateurs/telechargement/download.php?(...)
$ tar xfz A1012-A1006-A904-A888-0.8.7.tgz
$ cd unicorn/libm
$ make
$ cd ../unicorn_pci
$ KERNEL_SOURCES=/lib/modules/`uname -r`/build make modules
$ mkdir /lib/modules/`uname -r`/kernel/extra
$ cp unicorn_pci_((atm)|(eth)).ko /lib/modules/`uname -r`/kernel/extra
N'installes qu'un des deux modules (unicorn_pci_atm.ko ou unicorn_pci_eth.ko).
$ depmod -a
!!!! Ça doit être fait depuis le nouveau noyau sans CONFIG_REGPARAM !!!!
# Sources dans usr/src/linux avec FC3
Posté par itstimetogo . En réponse au message Sources dans usr/src/linux avec FC3. Évalué à 1.
Il n'y a plus de kernel-sourcecode.
http://fr.rpmfind.net/linux/fedora/core/3/i386/os/RELEASE-NOTES-en.(...)
In order to eliminate the redundancy inherent in providing a separate package for the kernel source code when that source code already exists in the kernel's .src.rpm file, Fedora Core 3 no longer includes the kernel-source package. Users that require access to the kernel sources can find them in the kernel .src.rpm file.
...
An exploded source tree is not required to build kernel modules against the currently in-use kernel.
For example, to build the foo.ko module, create the following file (named Makefile) in the directory containing the foo.c file:
obj-m := foo.o
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
Issue the make command to build the foo.ko module.
Passe /lib/modules/`uname -r`/build ou fait un lien :
ln -s /lib/modules/`uname -r`/build /usr/src/linux
N'oublies pas de mettre à jour le lien lorsque tu changes de noayu.
Pour compiler le noyau :
http://crab-lab.zool.ohiou.edu/kevin/kernel-compilation-tutorial-en(...)
[^] # Re: le soutien de quelques grands noms
Posté par itstimetogo . En réponse à la dépêche Conectiva, Mandrakesoft, Progeny et Turbolinux s'associent autour de la LSB 2.0. Évalué à -2.
Pour Red Hat qui ne sera pas LSB 2.0, c'est indiscutable. Pourquoi Red Hat va soutenir un concurrent ? Ça n'a pas de sens.
Ce n'est pas parce que tu soutiens LSB que tu soutiens toutes les distributions LSB. Surtout que toutes les distributions sont LSB.
Progeny utilise Linux, SuSE soutient Linux dont SuSE soutient Progeny. Ça n'a aucun sens ce type de raisonnement.
# le soutien de quelques grands noms
Posté par itstimetogo . En réponse à la dépêche Conectiva, Mandrakesoft, Progeny et Turbolinux s'associent autour de la LSB 2.0. Évalué à 4.
LCC fait dans la confusion. Ils détournent ceux qui soutiennent LSB pour dire qu'ils soutiennent LCC.
http://www.mandrakesoft.com/lcc/faq(...)
LCC invites all Linux companies to join. Red Hat, Novell, Sun, and Asianux have already been invited.
Red Hat et Novell ont été "invité".
Notons que presque toutes les distributions sont compatible LSB (La certification est payante, donc toutes les distributions n'ont pas le certificat même si elles sont compatibles).
SuSE 9.2 est la première distribution certifiée LSB 2.0.
# Pb corrigé
Posté par itstimetogo . En réponse au journal Update Kernel Fedora : Kernel panic : Attempted to kill keni!. Évalué à 1.
Le changelog (2.6.9-1.681_FC3) :
* jeu nov 18 2004 Dave Jones <davej@redhat.com>
- Update to 2.6.9-ac10, fixing the SATA problems (#139674)
- Update the OOM-killer tamer to upstream.
- Implement an RCU scheme for the SELinux AVC
- Improve on the OOM-killer taming patch.
- device-mapper: Remove duplicate kfree in dm_register_target error path.
- Make SHA1 guard against misaligned accesses
- ASPM workaround for PCIe. (#123360)
- Hot-plug driver updates due to MSI change (#134290)
- Workaround for 80332 IOP hot-plug problem (#139041)
- ExpressCard hot-plug support for ICH6M (#131800)
- Fix boot crash on VIA systems (noted on x86-64)
- PPC64: Store correct backtracking info in ppc64 signal frames
- PPC64: Prevent HVSI from oopsing on hangup (#137912)
- Fix poor performance b/c of noncacheable mapping in 4g/4g (#130842)
- Fix PCI-X hotplug issues (#132852, #134290)
- Re-export force_sig() (#139503)
- Various fixes for more security issues from latest -ac patch.
- Fix d_find_alias brokenness (#137791)
- tg3: Fix fiber hw autoneg bounces (#138738)
- diskdump: Fix issue with NMI watchdog. (#138041)
- diskdump: Export disk_dump_state. (#138132)
- diskdump: Tickle NMI watchdog in diskdump_mdelay() (#138036)
- diskdump: Fix mem= for x86-64 (#138139)
- diskdump: Fix missing system_state setting. (#138130)
- diskdump: Fix diskdump completion message (#138028)
- Re-add aic host raid support.
- Take a few more export removal patches from 2.6.10rc
- SATA: Make AHCI work
- SATA: Core updates.
- S390: Fix Incorrect registers in core dumps. (#138206)
- S390: Fix up lcs device state. (#131167)
- S390: Fix possible qeth IP registration failure.
- S390: Support broadcast on z800/z900 HiperSockets
- S390: Allow FCP port to recover after aborted nameserver request.
- Flush error in pci_mmcfg_write (#129338)
- hugetlb_get_unmapped_area fix (#135364, #129525)
- Fix ia64 cyclone timer on ia64 (#137842, #136684)
- Fix ipv6 MTU calculation. (#130397)
- ACPI: Don't display messages about ACPI breakpoints. (#135856)
- Fix x86_64 copy_user_generic (#135655)
- lockd: remove hardcoded maximum NLM cookie length
- Fix SCSI bounce limit
- Disable polling mode on hotplug controllers in favour of interrupt driven. (#138737)
[^] # Re: bk et linux
Posté par itstimetogo . En réponse au journal BitKeeper ou Arch. Évalué à 7.
T'as un snapshot quotidien de la branche Linus sur www.kernel.org !
Ce n'est pas le bout du monde de synchroniser ton patch.
> Donc comme j'explique plus bas, utiliser BitKeeper n'est pas une obligation mais permet d'etre sur de soumettre des patchs que Linus a de fortes chances de ne pas rejeter pour cause de desynchronisation avec son arbre.
Ça ne change rien. BitKeeper ou pas tu dois synchroniser ton patch.
Sans BitKeeper c'est moins pratique mais tout a fait réalisable sans grande difficulté.
Andrew Morton utilise Bk depuis peu de temps. Avant il faisait sans Bk et il en brasse des patchs.
Alan Cox n'utilise pas Bk.
etc.
[^] # Re: bk et linux
Posté par itstimetogo . En réponse au journal BitKeeper ou Arch. Évalué à 3.
Un patch est un patch. Tu l'envoies à Linus et il l'applique ou pas à son arbre.
Le dernier snapshots de Linus est ici :
http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/(...)
Il n'y a pas de problème de compatibilité, mais c'est plus chiant.
Si Linus utilisait Subversion et que quelqu'un veut lui "imposer" Arch, il y aurait les même désagréments.
# bk et linux
Posté par itstimetogo . En réponse au journal BitKeeper ou Arch. Évalué à 3.
C'est pour l'image du libre que ce n'est pas terrible.
Pour allimenter le troll sur "je me prend pour un hacker de noyau donc je veux un outils pour hacker de noyau :
http://www.darcs.net/(...)
Qui nous fait un Bk vs Arch vs Darcs pour les hackers de noyau ?
[^] # Re: Pas de panique
Posté par itstimetogo . En réponse au journal Update Kernel Fedora : Kernel panic : Attempted to kill keni!. Évalué à 2.
cat /etc/sysconfig/kernel
# UPDATEDEFAULT specifies if new-kernel-pkg should make
# new kernels the default
UPDATEDEFAULT=yes
# DEFAULTKERNEL specifies the default kernel package type
DEFAULTKERNEL=kernel
Donc, mets "UPDATEDEFAULT=no" et les nouveaux noyaux ne sont pas activé par défaut par grub (mais ils sont toujours installés et l'entrée dans grub.conf est ajoutée). C'est nouveau dans FC3.
[^] # Re: FS ou Kernel Panic
Posté par itstimetogo . En réponse au message Ext3 ca me saoule. Évalué à 1.
Red Hat utilise ça depuis longtemps. Par exemple, ça permet d'indiquer la partition racine avec le label de la racine et non avec le périphérique réel. Si le disque bouge, il n'y a pas de problème.
Sans initrd :
root=/dev/hdc
Avec initrd :
root=LABEL=root
Si root passe de /dev/hdc à /dev/hdd, ça ne boote plus avec "root=/dev/hdc" mais ça boote toujours avec "root=LABEL=root".
La partition root peut se trouver n'importe où. Sur un lvm, une partition raid, etc... C'est initrd qui va initialiser et fouiller les périphériques, raid, lvm pour récupérer les label et utiliser le bon périphérique.
Avec udev, udev doit être initialisé avant de monter la partition root. Sauf si tu as un /dev avec déjà des nodes. Mais dans ce cas, c'est une "sous-utilisation" d'udev. Avec udev, /dev est un tmpfs mounté par initrd dans le ramfs initial.
udev minimum (sans /etc/udev/rules.d) est initialisé par initrd. Puis la partition root est montée. Puis la partition /dev dans le ramfs initial est déplacé dans la partition racine.
Avec FC3, on peut faire sans initrd mais il faut :
- ne pas utiliser les label par la partition racine
- avoir /dev static avec les nodes nécessaires au boot (/dev/partition_racine, /dev/null, /dev/console, etc).
- tous les drivers pour la partition root doivent être dans le noyau et pas en modules.
[^] # Re: XFS
Posté par itstimetogo . En réponse au message Ext3 ca me saoule. Évalué à 2.
Les meta-données indiquent où trouver les données (c'est la table d'inode, des blocks libre, etc).
Ext3 est le seul FS a journaliser les données.
Exemple :
fd = open("toto") ;
write(fd, "data") ;
close (fd) (ou flush(fd)) ;
// coupure de courrant ou reset
Avec ext3, les données sont écrites, la taille du fichier est 4.
Avec xfs, jfs, reiserfs, les données peuvent ne pas être écrite et "pire" l'inode peut ne pas être créé. Si l'inode est créé, le fichier a une taille de 4 octets. Par contre rien ne garanti que les données sont écrites. Dans ces 4 octets il peut y avoir un bout d'un ancien /etc/passwd par exemple. C'est génant.
Si la coupure de courant ou le reset est fait avant le close() ou flush(), les données peuvent être écrite ou non. Par contre avec ext3 tu n'auras pas de mauvaises données. ext3 ne garantit l'ordre d'écriture que s'il y a un close() ou flush().
Donc :
fd = open("toto") ;
write(fd, "data") ;
seek(fd, quelque_part) // NB : ext3 mets les données à 0 si on va au-delà de la fin du fichier. Leur autres aussi sûrement (du moins s'il n'y a pas de coupure de courant ou reset).
write(fd, "data2") ;
// coupure de courant
"data2" peut être écrit alors que "data" n'est pas écrit. Si tu utilises un flush(), tu es sûr que "data" et "data2" sont écrits. ext3 journalise les données en premier (garanti que les données sont là) puis les méta-données.
C'est plus lent qu'un fs journalisé "classique" mais plus sûr. PostgreSQL (qui utilise flush comme d'autres SGBD, mais pas MySQL) sur ext3 est blindé.
Ça dépend du hardware. Avec SCSI il n'y a pas de problème sur coupure de courant.
[^] # Re: FS ou Kernel Panic
Posté par itstimetogo . En réponse au message Ext3 ca me saoule. Évalué à 1.
A été ajouté en upstream (2.6.10-rc1). Idem pour ext3-reservation qui fait aussi parti de FC3.
[^] # Re: XFS
Posté par itstimetogo . En réponse au message Ext3 ca me saoule. Évalué à 1.
Problème de script de boot ou e2fsck plus exigent.
Le fait d'atteindre fsck montre que le système a booté.
Tu avais des disques IDE ?
ext3 journalise les données, xfs (comme reiserfs) ne journalise que les méta-données. Si tu ne veux que journaliser les méta-données tu peux aussi.
# Pas de panique
Posté par itstimetogo . En réponse au journal Update Kernel Fedora : Kernel panic : Attempted to kill keni!. Évalué à 3.
> Si vous n'êtes pas téméraires garder votre ancien kernel.
Avec yum/up2date/apt, les nouveaux noyaux sont ajoutés. Ils ne remplacent pas l'ancien.
Avec rpm :
rpm -i kernel... => noyau ajouté
rpm -U kernel... => noyau mis à jour
On peut toujours réinstaller l'ancien noyau (depuis le CD1 par exemple) avec :
rpm -i --oldpackage --root /mnt/sysimage kernel-....rpm
Les anciens noyaux sont facilement accessibles depuis l'interface grub. Ils sont listés, suffit de scroller dans la liste et de taper <enter> .
[^] # Re: FS ou Kernel Panic
Posté par itstimetogo . En réponse au message Ext3 ca me saoule. Évalué à 2.
FC3 est en "avance" pour ext3.
Le ext3 de FC3 n'est pas compatible avec des vieilles versions de e2fsprogs.
> A vrai dire c'est la partition avec /home qui est partie en live, parfois c'est /boot, parfois /home (plus embêtant)
> Le plus rigolo c'est que quand le fsck semble pmarcher, certains dossiers disparaissent quand même, et se retrouve avec une taille négative (bref inutilisable)
Sous FC3 ou sous knoppix ?
> c'est vraiment mieux comme système de fichier ?
Il a ses défauts et qualité. Pas envis de troller.
> Pourquoi n'est-ce pas par défaut ?
Pour 4 "bonnes" raisons :
- ext3 est plus solide (normalement :-))
- ext3 est nfs compliant (flush)
- ext3 est principalement développé par Red Hat
- reiserfs ne supporte pas les attributs étendus et donc ne supporte pas SeLinux. Il parait qu'il y a un patch SuSE.
Il y a de "gros" problèmes de compatibilité ext3 avec FC3. Par exemple, si tu es sous knoppix il faut une e2fsck qui supporte :
- resize_inode dir_index attr_ext
C'est spécifique Linux 2.6 et c'est standard (sauf resize_inode qui n'est pas encore en upstream).
Tu pourrais être plus claire car là, j'ai l'impression que tu as un problème *depuis* knoppix et pas avec FC3.
Attention, FC3 ajoute l'attribut "attr_ext" aux FS ext3 et certains versions d'e2fsck de certaines distributions n'aiment pas ça.
Pour résumer, la cohabitation FC3 avec une autre distribution n'est pas facile car :
- Selinux par défaut
- resize_inode
[^] # Re: FS ou Kernel Panic
Posté par itstimetogo . En réponse au message Ext3 ca me saoule. Évalué à 1.
Évidemment, il ne faut pas deux FS avec le label '/'.
# FS ou Kernel Panic
Posté par itstimetogo . En réponse au message Ext3 ca me saoule. Évalué à 2.
> Kernel Panic ! (ext3 mount failed blablabla)
Quoi d'autre ?
Avec le kernel standard ou tu as recompilé le kernel ?
Tu utilises les labels dans grub.conf (root=LABEL=/) ?
Ce n'est pas forcément un problème de FS.
Pour FC3, il faut :
- Un initrd fait par mkinitrd >= 4.1.18
- tmpfs de compilé dans le noyau
- ne pas désigner root avec un label pour raid
Ceci est valable avec tous les FS.
> genre je peux mettre du reiserFS alors que la FC3 ne me le propose pas à l'install ?
Pour utiliser reiserFS à l'installation :
linux reiserfs selinux=0
[^] # Re: C'est un united linux bis (Was : C'est pas un united linux bis)
Posté par itstimetogo . En réponse au journal Conectiva, Mandrakesoft, Progeny, et Turbolinux. Évalué à 2.
La "force" de LCC n'est pas d'être LSB car toutes les distributions le sont déjà.
Le seul "hic" est que Red Hat ne sera pas LSB 2.0 (utilisent l'ABI c++ v6, LSB est a v5).
Temporairement, quelques uns vont dire qu'ils sont LSB 2.0 et que Red Hat ne l'est pas. La théorie que Red Hat veut forker Linux va être réveillée pour le plus grand bonheur des trolleurs.
Quand LSB sera basée sur l'ABI v6, tout sera "comme avant".
> En tout cas à moyen terme, un manque d'interopérabilité peut être dramatique pour l'image de Linux dans le grand public professionnel
Manque d'interopérabilité entre distributions ?
C'est un problème pour qui ?
Pour Red Hat et Novell qui dominent le marché de l'entreprise, ce n'est pas un problème pour avoir des certifications. Ils ont leur certification et sont contents.
Pour les petits qui veulent pénétrer le marché de l'entreprise, c'est beaucoup plus problématique. Oracle va peut-être certifier LCC comme ils le font pour Red Hat. Mais Oracle ne va pas le faire pour "seulement" Progeny, puis "seulement" TurboLinux, ...
Si les distributions LCC ne sont pas très proches, Oracle ne voudra pas les certifier. Trop de travail de support. On voit le paradoxe. Les objectifs de LCC ne sont pas compatible avec la diversité. S'il n'y a pas de diversité il n'y a pas de problème de compatibilité. Le rève de Red Hat et Novell :-). LCC est un concurrent de plus.
Voilà ce qu'apporte LCC. C'est comme United Linux.
À part SCO, United Linux avait quoi de mal ?
Je ne comprend pas pourquoi tout le monde critiquait United Linux et pas LCC (les deux sont/seront certifiés LSB).
[^] # Re: C'est un united linux bis (Was : C'est pas un united linux bis)
Posté par itstimetogo . En réponse au journal Conectiva, Mandrakesoft, Progeny, et Turbolinux. Évalué à 1.
Les deux :
- proposent plusieurs distributions (SuSE, Conectiva, TurboLinux, SCO) avec la même base
- sont LSB
L'annonce, en insistant sur LSB, veut faire croire que c'est différent, mais il n'y a pas de différence. United Linux était primcipalement l'oeuvre de SuSE. SuSE a toujours été LSB.
L'annonce en français :
http://www.mandrakesoft.com/company/press/briefs?n=/mandrakesoft/ac(...)
Contrairement à ce que fait croire l'annonce, Red Hat, Sun, Novell ne supporte pas LCC :
http://www.mandrakesoft.com/lcc/faq(...)
LCC invites all Linux companies to join. Red Hat, Novell, Sun, and Asianux have already been invited.
Je ne vois pas l'intérêt pour Red Hat, Novell ou Sun de supporter LCC. Leur position est "trop forte". Sinon ils devront reconnaitre qu'une ditribution Novell ou Red Hat est la même chose qu'un Progeny ou Mandrake. Ce n'est pas génial pour leur image qui est meilleur (en entreprise). Possible que SuSE(Novell) ait été calmé par son avanture United Linux.
Certificat lsb de United Linux :
http://www.opengroup.org/lsb/cert/display_product.tpl?CALLER=cert_p(...)
Conectiva (Powered by UnitedLinux v1.0) :
http://www.opengroup.org/lsb/cert/display_product.tpl?CALLER=cert_p(...)
SuSE Enterprise Server (powered by UnitedLinux) :
http://www.opengroup.org/lsb/cert/display_product.tpl?CALLER=cert_p(...)
Turbolinux Enterprise Server (powered by UnitedLinux) :
http://www.opengroup.org/lsb/cert/display_product.tpl?CALLER=cert_p(...)
[^] # C'est un united linux bis (Was : C'est pas un united linux bis)
Posté par itstimetogo . En réponse au journal Conectiva, Mandrakesoft, Progeny, et Turbolinux. Évalué à 0.
# /proc
Posté par itstimetogo . En réponse au message Accès disques à monitorer. Évalué à 1.
procinfo doit être utilisable m'est n'a pas été mis à jour pour linux 2.6 il semble.
Pour /proc/diskstat, de procinfo(8) :
major minor name noinfo read_io_ops blks_read write_io_ops blks_written
[^] # Re: Où est le problème ?
Posté par itstimetogo . En réponse au message x server message. Évalué à 1.
# Où est le problème ?
Posté par itstimetogo . En réponse au message x server message. Évalué à 1.
Il y a FC3 pour être plus à jour :
http://distrowatch.com/?newsid=02070(...)
[^] # Re: Début d'idée
Posté par itstimetogo . En réponse au message yum / apt-get. Évalué à 1.
Pas avec yum 2.1 (fc3).
Mon système est à jour :
# rm -r -f /var/cache/yum/*
# yum update
...
repomd.xml 100% |=========================| 951 B 00:00
...
primary.xml.gz 100% |=========================| 620 kB 00:00
Si le système est à jour, il ne download que repond.xml et primary.xml.gz par repository.
Si Ces fichiers sont déjà en cache (et pas plus récent sur serveur), il ne les downloade pas.
Lorsqu'un fichier est downloadé il y a :
100% |=========================| ??? B
Lorsque c'est un traitement depuis le cache, c'est :
Base : ################################################## ???/???
En fesant attention à ces indicateurs, on voit que yum ne download presque rien.
Tout ce que downloade yum, est nécessaire pour sa tache.
[^] # Re: L'enfer
Posté par itstimetogo . En réponse au message bewan adsl pci st. Évalué à 1.
Utilses "su -l"
> unicorn_pci_atm: Unknown symbol shutdown_atm_dev
> unicorn_pci_atm: Unknown symbol atm_dev_register
> unicorn_pci_atm: Unknown symbol atm_charge
Ajoutes le support ATM au noyau :
CONFIG_ATM=m
CONFIG_PPPOATM=m
# L'enfer
Posté par itstimetogo . En réponse au message bewan adsl pci st. Évalué à 2.
FC3 sera plus "cool" (surtout pour pppoatm).
Je n'ai pas une FC2 mais je pense que ça doit marcher.
Il y a deux méthodes :
1- PPPOATM
Il faut recompiler tout le noyau sans CONFIG_REGPARM (c'est un bug bewan). Vérifier que ATM est supporté par le noyau.
Il faut installer le nouveau ppp qui supporte pppoatm :
rpm -Uvh http://fr2.rpmfind.net/linux/fedora/core/development/i386/Fedora/RP(...)
Compiler bewan, installer bewan[*]. Lancer kudzu pour "qu'il te foute la paix" au prochain boot.
Puis configurer "normalement" ppp :
/etc/ppp/options :
lock
usepeerdns
debug
ipparam ppp0
noipdefault
noauth
default-asyncmap
defaultroute
hide-password
noaccomp
noccp
nobsdcomp
nodeflate
nopcomp
novj novjccomp
lcp-echo-interval 20
lcp-echo-failure 300
sync
maxfail 32000
persist
plugin /usr/lib/pppd/2.4.2/pppoatm.so 8.35
Créer les chap-secrets et pap-secrets :
# Secrets for authentication using CHAP
# client server secret IP addresses
ton_compte * "ton_pass"
Puis faire un petit script qui sera lancé au boot :
#!/bin/bash
modprobe unicorn_pci_atm
sleep 60 # attente que la ligne soit up
# pppd tourne déjà ?
[ -f /var/run/ppp0.pid ] || exec pppd user ton_compte persist
2- PPPOETH
On peut aussi utiliser pppoeth (module unicorn_pci_eth).
Dans ce cas le nouveau ppp n'est pas nécessaire.
Il faut installer le paquet rp-pppoe (normalement déjà installé).
- recompiler tout le noyau sans CONFIG_REGPARAM.
- compiler et installer bewan (n'installes que unicorn_pci_eth.ko sinon kudzu se mélange parfois les pinceaux (c'est encore une erreur bewan)). Voir [*].
- lancer kudzu. Il va faire n'importe quoi mais ce n'est pas grave.
- Lancer system-config-network et configurer une ligne adsl pppoeth. Il insistera pour utiliser eth0, acceptes et continues.
- Ajouter à /etc/modprobe.conf :
alias dsl0 unicorn_pci_eth <== bewan existe dsl0 (encore une erreur bewan)
options unicorn_pci_eth PROTOCOL=pppoe VPI=8 VCI=35
options dsl0 PROTOCOL=pppoe VPI=8 VCI=35
Edites /etc/sysconfig/network-scripts/ifcfg-ton_fai pour avoir quelque chose comme ça (normalement il n'y a que le paramètre ETH à éditer) :
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
IPV6INIT=no
USERCTL=yes
PEERDNS=yes
TYPE=xDSL
DEVICE=ppp0
BOOTPROTO=dialup
PIDFILE=/var/run/pppoe-adsl.pid
FIREWALL=NONE
PING=.
PPPOE_TIMEOUT=80
LCP_FAILURE=3
LCP_INTERVAL=20
CLAMPMSS=1412
CONNECT_POLL=6
CONNECT_TIMEOUT=60
PERSIST=no
SYNCHRONOUS=no
DEFROUTE=yes
USER='ton_compte'
ETH=dsl0 <=== system-config-nework met eth0
PROVIDER=ton_fia
DEMAND=no
ONBOOT=yes
Pour activer la ligne "/sbin/ifup ton_fai" doit marcher. La ligne sera activée au boot.
J'utilise pppoatm car c'est un peu plus rapide.
[*]
installation de bewan :
Le driver est ici :
http://www.bewan.fr/bewan/utilisateurs/telechargement/download.php?(...)
$ tar xfz A1012-A1006-A904-A888-0.8.7.tgz
$ cd unicorn/libm
$ make
$ cd ../unicorn_pci
$ KERNEL_SOURCES=/lib/modules/`uname -r`/build make modules
$ mkdir /lib/modules/`uname -r`/kernel/extra
$ cp unicorn_pci_((atm)|(eth)).ko /lib/modules/`uname -r`/kernel/extra
N'installes qu'un des deux modules (unicorn_pci_atm.ko ou unicorn_pci_eth.ko).
$ depmod -a
!!!! Ça doit être fait depuis le nouveau noyau sans CONFIG_REGPARAM !!!!