| View previous topic :: View next topic |
| Author |
Message |
brokenHeart
n00b
Joined: 15 May 2013
Posts: 35
Location: versailles
|
 Posted: Wed Nov 16, 2016 7:48 pm Post subject: [Windows 10 WSL] Gentoo |
 |
|
Bonjour,
j'aime Gentoo mais j'utilise aussi Windows 10 et j'ai maintenant la possibilité d'installer les packages Ubuntu dans un shell.
Je n'aime pas trop apt-get et Ubuntu.
Est-il compliqué / envisageable de "Gentoo iser" un Ubuntu (LTS-14 10) afin de pouvoir utiliser emerge dans Windows ?
Peut-être existe-t-il déjà un projet dans ce sens ?
Excusez moi si je ne poste pas dans le bon forum.
Last edited by brokenHeart on Thu Nov 17, 2016 1:29 pm; edited 1 time in total |
|
| Back to top |
|
 |
El_Goretto
Moderator
Joined: 29 May 2004
Posts: 3169
Location: Paris
|
| Posted: Wed Nov 16, 2016 8:48 pm Post subject: |
|
|
Avoir la commande emerge est une chose, mais tout le contenu de l'arbre portage n'est pas compatible avec une autre distribution (de part ce qui fait que justement une distribution est une distribution: ses path, versions, standards "locaux" etc.), et a donc toutes les chances de péter la distribution hôte à moins de relire et éventuellement corriger chaque ebuild une à une.
Et on n'a même pas encore parlé de la spécificité d'une ubuntu dans un windows dans l'histoire. HAHAHAHA.
Sachant déjà que Cygwin est là depuis des années pour rendre disponible sous cet OS (non, je me jetez pas de petits cailloux pointus, c'est pas moi qui ai commencé!) des commandes et programmes venant du monde GNU/Linux, si tu es allergique à Ubuntu.
Bref, si tu aimes les défis, tu peux tenter le coup pour la culture (si tu casses et que tu aimes réparer après). Mais sous windows... warf, de la confiture aux cochons tout çà. 
_________________
-TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
| Back to top |
|
|
xaviermiller
Bodhisattva
Joined: 23 Jul 2004
Posts: 8708
Location: ~Brussels - Belgique
|
| Posted: Wed Nov 16, 2016 9:11 pm Post subject: |
|
|
La piste d'un "prefix" pourrait être intéressante, mais je ne n'ai pas l'impression qu'il y ait déjà un projet à ce sujet
_________________
Kind regards,
Xavier Miller |
|
| Back to top |
|
|
brokenHeart
n00b
Joined: 15 May 2013
Posts: 35
Location: versailles
|
| Posted: Wed Nov 16, 2016 9:37 pm Post subject: |
|
|
Merci pour cette réponse avisée.
Oui bien sur cela sous-entendrait de revoir les chemins mais je me fiche de casser l’hôte, la matériel n'est pas pris en compte, pas plus que X et les serveurs c'est a ses risques et périls.
Je vais peut être essayer dans une VM déjà ... Le truc est encore récent, le WSL (Windows Subsystem for Linux) n'est disponible au grand public que depuis août.
J'imagine que d'autres ont déjà eu la même idée que moi mais je n'ai rien trouvé sur le net.
Il s'agirait vraiment d'avoir un shell et les outils de développements, car c'est tout ce que propose pour l'instant Ubuntu Canonical sur Windows ...
On arrive aussi à lancer sshd, des programme Windows depuis ce shell avec un hack (cbwin qui remplace bash.exe par outbash.exe), y compris en ssh.
Cela demande toutefois qu'un utilisateur soit logué et un shell lancé, ce qui peut éventuellement être automatisé.
L'avantage serait d'avoir un système un peu plus sexy, robuste et intègre qu'Ubuntu et de bénéficier des ebuilds au lieu des binaires Ubuntu.
J'ai longtemps utilisé Cygwin car c'était la seule façon d'avoir du sshd sur un Windows ...
... et puis Microsoft vient de rejoindre la Linux foundation. http://www.numerama.com/tech/209271-microsoft-vient-de-rejoindre-la-linux-foundation.html  |
|
| Back to top |
|
|
brokenHeart
n00b
Joined: 15 May 2013
Posts: 35
Location: versailles
|
| Posted: Thu Nov 17, 2016 1:40 am Post subject: |
|
|
C'est pas dans la poche ^^
Tout est installé (vu d'un utilisateur windows) dans %localappdata%\lxss
... je ne suis pas seul à vouloir essayer ça
https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13393674-add-support-for-other-meta-distributions-gentoo (des gens inscrits à "insider" : beta users)
Ils ont eu + ou - les mêmes problèmes que moi :
1er problème : lors du détarage du stage3 les attributs étendus (--xattrs) ne sont pas bien gérés
PS: dans les version plus récentes de WSL (comme celles proposée aux insiders) de nombreuses améliorations du filesystem ont été apporté dont les fonctions relatives a XATTR.
| Code: | tar: setxattrat: Cannot set 'user.pax.flags' extended attribute for file './usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.3/cc1': Opération non supportée
tar: setxattrat: Cannot set 'user.pax.flags' extended attribute for file './usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.3/cc1plus': Opération non supportée |
2ème problème : impossible de faire un chroot
En plus, je ne suis pas bien sûr de la version du stage 3 (64 bit) que je dois prendre. systemd, hardened, lib ...
Je vais tester. En abscence de chroot, j'ai essayé d'être un peu plus violent mais ça à tout cassé.
Ce qui n'est pas bien méchant. Le shell se désinstalle en faisant (en mode admin dans une console cmd) :
| Code: | | lxrun /uninstall /full |
et se réinstalle en faisant :
ce qui ira télécharger un fichier lxss.tar.gz (+ 1 fichier sha256) qui contiendra toute l'arborescence de base du shell sur le Windows store.
puis la détarera/dgzipera dans le fameux %localappdata%\lxss avant de demander un nom d'utilisateur et un mot de passe ...
Le tar a été partiellement corrigé dans ma version (avant il parait que c'était pire et que même les liens symboliques sautaient).
Le problème de chroot semble avoir été corrigé depuis, malheureusement je n'ai pas la version insider de Windows.
Je vais encore essayer quelques trucs ...
Des gens d'Arch seraient intéressés aussi
Pour ceux qui voudraient en savoir plus :
https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/
https://blogs.msdn.microsoft.com/wsl/
Last edited by brokenHeart on Sat Nov 26, 2016 7:05 pm; edited 2 times in total |
|
| Back to top |
|
|
xaviermiller
Bodhisattva
Joined: 23 Jul 2004
Posts: 8708
Location: ~Brussels - Belgique
|
| Posted: Thu Nov 17, 2016 8:24 am Post subject: |
|
|
Bonjour,
Je ne pense pas qu'on puisse faire un "chroot" pour le moment, il faudra travailler en mode "prefix", c'est-à-dire que Gentoo va être une couche sur l'environnement *NIX existant (en s'installant dans /usr/local).
Jusqu'au jour où l'on pourra récupérer le "noyau" (un colinux ? un qemu ?)
_________________
Kind regards,
Xavier Miller |
|
| Back to top |
|
|
brokenHeart
n00b
Joined: 15 May 2013
Posts: 35
Location: versailles
|
| Posted: Thu Nov 17, 2016 11:27 am Post subject: |
|
|
Hello,
bon au fur et a mesure que j'avance et que je rencontre des messages d'erreurs je trouve plus de pistes ...
En résumé :
J'ai configuré dans Ubuntu l'utilisateur root :
| Code: | sudo passwd root
<root password>
sudo passwd -u root
su |
M'inspirant de https://github.com/Microsoft/BashOnWindows/issues/992 ...
... J'ai détaré mon stage3 dans le /root dans un sous répertoire /root/gentoo ...
Ce répertoire présente l'avantage d'être détaché du répertoire rootfs qui contient toute l'arborescence du système Linux et reste accessible dans Windows, même quand vous créez un nouveau rootfs.
Remarque : Si il est possible de visualiser les fichiers qui sont créés dans le répertoire root dans linux WSL, créer des fichiers dans le répertoire root dans Windows ne les rendra pas accessibles dans linux.
Sorti du bash dans l'explorateur Windows, renommage du répertoire rootfs en rootfs_ubuntu, puis sous cmd (mode admin) positionné en %localappdata%\lxss déplacer le répertoire root\gentoo | Code: | | move root\gentoo .\rootfs |
Comme on ne casse rien, le rollback vers ubuntu est simple. Dans l'explorateur de fichiers de windows renommer le rootfs contenant gentoo en (par exemple) rootfs_gentoo et le rootfs_ubuntu en rootfs. Se reconnecter à bash ...
A la connexion au rootfs gentoo quelques messages d'erreur "cosmétiques" :
| Code: | C:\Users\toto\AppData\Local\lxss>bash
Nous n’avons pas trouvé d’utilisateur par défaut. Corrigez en exécutant lxrun.exe /setdefaultuser
C:\Users\toto\AppData\Local\lxss>lxrun /setdefaultuser
Créez un compte d’utilisateur UNIX par défaut. Le nom d’utilisateur n’est pas tenu de correspondre à votre nom d’utilisateur Windows.
Pour plus d’informations, visitez : https://aka.ms/wslusers
Entrez un nouveau nom d’utilisateur UNIX : toto
La création de l’utilisateur UNIX a échoué. Ceci peut être effectué ultérieurement en exécutant lxrun.exe /setdefaultuser
C:\Users\toto\AppData\Local\lxss>lxrun /setdefaultuser
Créez un compte d’utilisateur UNIX par défaut. Le nom d’utilisateur n’est pas tenu de correspondre à votre nom d’utilisateur Windows.
Pour plus d’informations, visitez : https://aka.ms/wslusers
Entrez un nouveau nom d’utilisateur UNIX : root
Utilisateur UNIX trouvé : root
Utilisateur UNIX par défaut défini sur : root
C:\Users\toto\AppData\Local\lxss>bash
bash: eval: line 24: syntax error near unexpected token `newline'
bash: eval: line 24: `Usage: lesspipe <file>' |
- Vérifier les droits sur les fichiers, l'utilisateur (root.root) et si le setuid bit est correctement positionné sur un fichier comme /bin/su et la racine du linux ...
Continué l'instal en suivant le wiki AMD64 ... Le move ayant constitué en quelque sorte un workaround à l'impossibilité de chroot er ...
mirrorselect introuvable => récupéré la ligne dans le make.conf d'un autre Gentoo.
| Code: | emerge-webrsync
!!! Section 'x-portage' in repos.conf has location attribute set to nonexistent directory: '/usr/portage'
!!! Section 'gentoo' in repos.conf has location attribute set to nonexistent directory: '/usr/portage'
!!! Invalid Repository Location (not a dir): '/usr/portage'
Fetching most recent snapshot ...
Trying to retrieve 20161116 snapshot from ftp://ftp.free.fr/mirrors/ftp.gentoo.org ...
Fetching file portage-20161116.tar.xz.md5sum ...
Fetching file portage-20161116.tar.xz.gpgsig ...
Fetching file portage-20161116.tar.xz ...
Checking digest ...
Getting snapshot timestamp ...
Syncing local tree ...
|
Là, vous avez le temps d'aller prendre un café, voir deux ...
Bon, c'est marrant aussi de voir le répertoire usr/portage se remplir peu à peu sinon ...
| Code: | Number of files: 208,643 (reg: 181,187, dir: 27,456)
Number of created files: 208,642 (reg: 181,187, dir: 27,455)
Number of deleted files: 0
Number of regular files transferred: 181,187
Total file size: 417.37M bytes
Total transferred file size: 417.37M bytes
Literal data: 417.37M bytes
Matched data: 0 bytes
File list size: 4.00M
File list generation time: 0.028 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 181.67M
Total bytes received: 3.58M
sent 181.67M bytes received 3.58M bytes 300.98K bytes/sec
total size is 417.37M speedup is 2.25
Cleaning up ...
Performing Global Updates
(Could take a couple of minutes if you have a lot of binary packages.)
* IMPORTANT: 12 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items. |
| Code: | eselect profile list
Available profile symlink targets:
[1] default/linux/amd64/13.0 *
[2] default/linux/amd64/13.0/selinux
[3] default/linux/amd64/13.0/desktop
[4] default/linux/amd64/13.0/desktop/gnome
[5] default/linux/amd64/13.0/desktop/gnome/systemd
[6] default/linux/amd64/13.0/desktop/kde
[7] default/linux/amd64/13.0/desktop/kde/systemd
[8] default/linux/amd64/13.0/desktop/plasma
[9] default/linux/amd64/13.0/desktop/plasma/systemd
[10] default/linux/amd64/13.0/developer
[11] default/linux/amd64/13.0/no-multilib
[12] default/linux/amd64/13.0/systemd
[13] default/linux/amd64/13.0/x32
[14] hardened/linux/amd64
[15] hardened/linux/amd64/selinux
[16] hardened/linux/amd64/no-multilib
[17] hardened/linux/amd64/no-multilib/selinux
[18] hardened/linux/amd64/x32
[19] hardened/linux/musl/amd64
[20] hardened/linux/musl/amd64/x32
[21] default/linux/uclibc/amd64
[22] hardened/linux/uclibc/amd64 |
1er gros plantage ...
| Code: | echo "Europe/Paris" > /etc/timezone
emerge --config sys-libs/timezone-data
Configuring pkg...
* Updating /etc/localtime with /usr/share/zoneinfo/Europe/Paris
ebuild-ipc: daemon process not detected
* The ebuild phase 'config' has exited unexpectedly. This type of behavior
* is known to be triggered by things such as failed variable assignments
* (bug #190128) or bad substitution errors (bug #200313). Normally, before
* exiting, bash should have displayed an error message above. If bash did
* not produce an error message above, it's possible that the ebuild has
* called `exit` when it should have called `die` instead. This behavior
* may also be triggered by a corrupt bash binary or a hardware problem
* such as memory or cpu malfunction. If the problem is not reproducible or
* it appears to occur randomly, then it is likely to be triggered by a
* hardware problem. If you suspect a hardware problem then you should try
* some basic hardware diagnostics such as memtest. Please do not report
* this as a bug unless it is consistently reproducible and you are sure
* that your bash binary and hardware are functioning properly.
ebuild-ipc: daemon process not detected
* The ebuild phase 'die_hooks' has exited unexpectedly. This type of
* behavior is known to be triggered by things such as failed variable
* assignments (bug #190128) or bad substitution errors (bug #200313).
* Normally, before exiting, bash should have displayed an error message
* above. If bash did not produce an error message above, it's possible
* that the ebuild has called `exit` when it should have called `die`
* instead. This behavior may also be triggered by a corrupt bash binary or
* a hardware problem such as memory or cpu malfunction. If the problem is
* not reproducible or it appears to occur randomly, then it is likely to
* be triggered by a hardware problem. If you suspect a hardware problem
* then you should try some basic hardware diagnostics such as memtest.
* Please do not report this as a bug unless it is consistently
* reproducible and you are sure that your bash binary and hardware are
* functioning properly. |
1 ère solution testée : https://forums.gentoo.org/viewtopic-p-7926990.html
Remplacer dans /usr/lib/python2.7/site-packages/portage/locks.py _default_lock_fn = fcntl.lockf par fcntl.flock ne fonctionne pas chez moi ...
EDIT : encore un effet du problème de droit que je n'avais pas remarqué. Avec les bon droits, la manip fonctionne et me semble moins "violente" que la suivante et permets de passer ce premier plantage, mais un emerge plus conséquent provoque à nouveau le "2eme plantage" (celui de vim) ...
Donc je conserve la méthode 2 pour résoudre le problème d' IPC ...
| Code: | emerge -av vim
* IMPORTANT: 12 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] app-eselect/eselect-vi-1.1.7-r1::gentoo 0 KiB
[ebuild N ] app-eselect/eselect-ctags-1.18::gentoo 0 KiB
[ebuild N ] dev-util/ctags-5.8::gentoo USE="-ada" 365 KiB
[ebuild N ] app-editors/vim-core-7.4.769::gentoo USE="acl nls -minimal" 11,907 KiB
[ebuild N ] app-editors/vim-7.4.769::gentoo USE="acl nls -X -cscope -debug -gpm -lua -luajit -minimal -perl -python -racket -ruby (-selinux) -tcl -vim-pager" PYTHON_TARGETS="python2_7 python3_4" 0 KiB
[ebuild N ] app-vim/gentoo-syntax-20160530::gentoo USE="-ignore-glep31" 19 KiB
Total: 6 packages (6 new), Size of downloads: 12,290 KiB
Would you like to merge these packages? [Yes/No] yes
>>> Verifying ebuild manifests
>>> Emerging (1 of 6) app-eselect/eselect-vi-1.1.7-r1::gentoo
* vi.eselect-1.1.7.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ]
>>> Unpacking source...
>>> Unpacking vi.eselect-1.1.7.bz2 to /var/tmp/portage/app-eselect/eselect-vi-1.1.7-r1/work
>>> Source unpacked in /var/tmp/portage/app-eselect/eselect-vi-1.1.7-r1/work
>>> Preparing source in /var/tmp/portage/app-eselect/eselect-vi-1.1.7-r1/work ...
* Applying eselect-vi-1.1.7-prefix.patch ... [ ok ]
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/app-eselect/eselect-vi-1.1.7-r1/work ...
>>> Source configured.
Traceback (most recent call last):
File "/usr/lib/portage/python2.7/ebuild-ipc.py", line 282, in <module>
sys.exit(ebuild_ipc_main(sys.argv[1:]))
File "/usr/lib/portage/python2.7/ebuild-ipc.py", line 279, in ebuild_ipc_main
return ebuild_ipc.communicate(args)
File "/usr/lib/portage/python2.7/ebuild-ipc.py", line 136, in communicate
lock_obj = portage.locks.lockfile(self.ipc_lock_file, unlinkfile=True)
File "/usr/lib64/python2.7/site-packages/portage/locks.py", line 113, in lockfile
raise PermissionDenied(func_call)
portage.exception.PermissionDenied: open('/var/tmp/portage/app-eselect/eselect-vi-1.1.7-r1/.ipc_lock')
* The ebuild phase 'configure' has exited unexpectedly. This type of
* behavior is known to be triggered by things such as failed variable
* assignments (bug #190128) or bad substitution errors (bug #200313).
* Normally, before exiting, bash should have displayed an error message
* above. If bash did not produce an error message above, it's possible
* that the ebuild has called `exit` when it should have called `die`
* instead. This behavior may also be triggered by a corrupt bash binary or
* a hardware problem such as memory or cpu malfunction. If the problem is
* not reproducible or it appears to occur randomly, then it is likely to
* be triggered by a hardware problem. If you suspect a hardware problem
* then you should try some basic hardware diagnostics such as memtest.
* Please do not report this as a bug unless it is consistently
* reproducible and you are sure that your bash binary and hardware are
* functioning properly. |
mais positionner _enable_ipc_daemon sur False dans /usr/lib64/python2.7/site-packages/_emerge/AbstractEbuildProcess.py fait l'affaire ... (à adapter à votre version active de Python 3.4, 3.5)
Thx to Sazpaimon dans les commentaires de https://github.com/Microsoft/BashOnWindows/issues/992 qui propose plusieurs autres corrections ...
et j'ai installé mon vi *presque* sans problème (le premier truc que je fais, bah oui jsuis oldschool j'aime pas nano) ...
Avec toutefois quelques erreurs non bloquantes lors des configure (peut-être normales) :
| Code: | checking default tty permissions/group... can't determine - assume ptys are world accessible
...
checking for getpseudotty... no
|
Pour lesquelles je n'ai pas cherché de correctifs ...
... et un blocage à la fin sur app-vim/gentoo-syntax-20160530 lors du merge qui n'a jamais voulu passer la ligne
| Code: | * Updating documentation tags in /usr/share/vim/vim74
^C
Exiting on signal 2 |
mais j'ai mon vi
| Code: | eselect vi list
Available vi implementations:
[1] vim *
[2] busybox |
Bon, c'est lent, on passe au travers d'une API, j'ai pas encore regardé les perf, si les options de compilations étaient correctement prises en compte, etc ...
| Code: | emerge --config sys-libs/timezone-data
Configuring pkg...
* Updating /etc/localtime with /usr/share/zoneinfo/Europe/Paris |
Il y a encore des trucs comme :
| Code: | ps -aux
Error: /proc must be mounted
To mount /proc at boot you need an /etc/fstab line like:
proc /proc proc defaults
In the meantime, run "mount proc /proc -t proc"
root@MYHOST:~# mount proc /proc -t proc
mount: only root can use "--types" option (effective UID is 1000) |
ou 
| Code: | rc-status
* Caching service dependencies ...
Service `netmount' needs non existent service `net' [ ok ]
Runlevel: sysinit
devfs [ stopped ]
dmesg [ stopped ]
kmod-static-nodes [ stopped ]
sysfs [ stopped ]
tmpfiles.dev [ stopped ]
udev [ stopped ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed/wanted
Dynamic Runlevel: manual |
Donc pas mal de trucs à résoudre / corriger / prendre en compte mais ça parait plus jouable qu'en commençant l'expérience ...
Je vais certainement m'inspirer de ce qu'Ubuntu a fait (bashrc, fstab, etc ...)
| Code: | en_US ISO-8859-1
fr_FR.UTF-8 UTF-8
# ...
fr_FR ISO-8859-1
fr_FR@euro ISO-8859-15 |
| Code: | locale-gen
* Generating locale-archive: forcing # of jobs to 1
* Generating 4 locales (this might take a while) with 1 jobs
* (1/4) Generating en_US.ISO-8859-1 ... [ ok ]
* (2/4) Generating fr_FR.ISO-8859-15@euro ... [ ok ]
* (3/4) Generating fr_FR.ISO-8859-1 ... [ ok ]
* (4/4) Generating fr_FR.UTF-8 ... [ ok ]
* Generation complete
|
| Code: | eselect locale list
/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_COLLATE to default locale: No such file or directory
Available targets for the LANG variable:
[1] C
[2] POSIX
[3] en_US
[4] en_US.iso88591
[5] fr_FR
[6] fr_FR.iso88591
[7] fr_FR.iso885915@euro
[8] fr_FR.utf8
[9] fr_FR@euro
[10] french
[ ] (free form)
root@MYHOST:~# eselect locale set 8
/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_COLLATE to default locale: No such file or directory
Setting LANG to fr_FR.utf8 ...
Run ". /etc/profile" to update the variable in your shell.
root@MYHOST:~# . /etc/profile
MYHOST ~ # |
ping ne fonctionne pas, mais le réseau si, sshd n'est pas visible dans rc-status pourtant il serait lancé mais n'est pas joignable même en local ???
EDIT : tous les problèmes signalés à la ligne précédente sont dus à un problème de droit ...
Une installation propre faite en s'assurant qu'après le détarage et la copie les droits/l'utilisateur à la racine et les setuid (dans /bin par exemple) sont bien conservés arrangent considérablement les choses, toutefois le support correct d'openrc pour gentoo n'étant pas implémenté correctement dans init il reste nécessaire de simuler pour sshd (entre autre) son fonctionnement :
| Code: |
root@MYHOST:/# /etc/init.d/sshd start
* You are attempting to run an openrc service on a
* system which openrc did not boot.
* You may be inside a chroot or you may have used
* another initialization system to boot this system.
* In this situation, you will get unpredictable results!
* If you really want to do this, issue the following command:
* touch /run/openrc/softlevel
* ERROR: sshd failed to start |
| Code: |
root@MYHOST:/# touch /run/openrc/softlevel
root@MYHOST:/# /etc/init.d/sshd start
ssh-keygen: generating new host keys: RSA DSA ED25519
* Starting sshd ... [ ok ]
root@MYHOST:/# rc-status
Runlevel: sysinit
devfs [ stopped ]
dmesg [ stopped ]
kmod-static-nodes [ stopped ]
sysfs [ stopped ]
tmpfiles.dev [ stopped ]
udev [ stopped ] [ stopped ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed/wanted
Dynamic Runlevel: manual
sshd [ started ] |
Apparemment le démarrage est géré de la façon suivante :
https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-and-ubuntu-interoperability/
Pas mal de bugs seront corrigés par une prochaine mise à jour et le sont déjà d'après ce que j'ai pu lire, pour les utilisateurs béta d'insider.
Voilà, j'en suis là ... Happy WSL pour les Gentoo users ...
Last edited by brokenHeart on Sat Nov 26, 2016 7:01 pm; edited 7 times in total |
|
| Back to top |
|
|
brokenHeart
n00b
Joined: 15 May 2013
Posts: 35
Location: versailles
|
| Posted: Fri Nov 18, 2016 11:23 am Post subject: |
|
|
Hello,
En guise de conclusion, globalement cela fonctionne. A part le plantage que j'ai eu au début, toutes les autres compilations que j'ai pu faire jusqu'à présents sont passées sans problèmes.
D'après ce que j'ai compris, comme il n'y a pas véritablement de boot, bash.exe va créer/lancer un fichier init dans l'arborescence linux qui va se charger de lancer ce que Ubuntu ou Microsoft ont prévu de lancer, créer des fichiers dans dev lancer les services, etc ... Cette solution donne accès au "userland", le reste (l'interraction avec le matériel - ce qui passerait par le kernel) passe au travers d'une API incomplète pour le moment. ifconfig fonctionne imparfaitement et à bas niveau de nombreuses attentes des Gentoo modernes ne semblent pas satisfaites, ce qui devrait pouvoir s'arranger au travers d'adaptations restant à trouver et/ou des améliorations que l'équipe MS apportera à son API.
Idéalement il faudrait quelqu'un qui connaisse bien le démarrage d'Ubuntu/Debian et de Gentoo car à priori Microsoft a concentré son effort sur les distributions dérivées de Debian.
Comme il n'est pas possible, d'accéder au processeur ou même aux process (si ce n'est pas un effet de bord de mon installation approximative) la compilation se fait sur un processeur. Sazpaimon (déjà cité plus haut) dans un thread sur le blog du github ( https://github.com/Microsoft/BashOnWindows/issues/992 ) expose quelques unes de ses considérations sur le sujet (dans les com.).
A un moment je me suis rendu compte que je n'avais pas les bons droits sur les fichiers / les répertoires, ce qui à sans doute compromis le fonctionnement de pas mal de choses.
sshd se lance (après avoir corrigé quelques droits et recréé quelques répertoires, sans doute est-ce propre à mon installation) et le fichier de config nécessitera quelques adaptations pour autoriser les connexions, je l'ai fait fonctionner dans Ubuntu mais pas dans Gentoo. Il doit être possible de s'inspirer de http://superuser.com/questions/1111591/how-can-i-ssh-into-bash-on-ubuntu-on-windows-10 pour parvenir au résultat
Cela peut offrir l'avantage à un développeur de ne pas avoir à installer de machine virtuelle et de faire ses développements web ou autre sur une même machine, tout en ayant accès au filesystem windows depuis Linux et vice-versa.
Il serait possible de lancer des commandes linux dans ce shell à partir de Windows et de faire le contraire aussi ...
Le premier truc à optimiser ce sont vraiment les compilations, trouver les bonnes options ...
L'avantage aussi de pouvoir sauvegarder facilement tout son environnement en copiant son répertoire rootfs et d'avoir de nombreuses configurations.
Je vais refaire le truc plus proprement ...
Bon weekend à tous
Last edited by brokenHeart on Tue Nov 22, 2016 7:06 pm; edited 1 time in total |
|
| Back to top |
|
|
brokenHeart
n00b
Joined: 15 May 2013
Posts: 35
Location: versailles
|
| Posted: Mon Nov 21, 2016 8:13 pm Post subject: |
|
|
Hello,
j'ai continué et progressé encore un peu. J'ai surtout commencé par réinstaller proprement en vérifiant que les fichiers appartenaient bien a root et avait les droit corrects. Il faudrait peut-être que j'écrive une procédure propre .. 
mais une prochaine mise à jour windows et de WSL pourrait corriger certains de ces problèmes ...
##########################
SSH :
sshd fonctionne très bien, et me permets en sftp d'accéder à l'intégralité de mes fichiers Windows à distance.
Pour parvenir à le faire fonctionner il faut juste ajouter : | Code: | | UsePrivilegeSeparation no |
à son /etc/ssh/sshd_config
Puis créer un fichier softlevel pour openrc : | Code: | | touch /run/openrc/softlevel |
créer un utilisateur autre que root
lancer rc sysinit, rc boot qui remplissent très imparfaitement leurs fonctions mais suffisent à initialiser certaines "choses nécessaires" qui permettent ensuite à /etc/init.d/sshd start de démarrer et s'arrêter proprement.
##########################
LAMP (updated) :
J'ai aussi installé mysql 5.32, php 5.6, Apache 2.4.23-r2 ...
APACHE (MYSQL et PHP : RAS) :
M'inspirant de la configuration du binaire d'Ubuntu j'ai installé Apache en mode prefork (-threads faisant normalement parti des USEs flags par défaut)
| Code: | (dans WSL Ubuntu, oui il en sont à la 2.4.7 et PHP 5.9)
# source /etc/apache2/envvars
# apache2 -V
Server version: Apache/2.4.7 (Ubuntu)
Server built: Jul 15 2016 15:34:04
Server's Module Magic Number: 20120211:27
Server loaded: APR 1.5.1-dev, APR-UTIL 1.5.3
Compiled using: APR 1.5.1-dev, APR-UTIL 1.5.3
Architecture: 64-bit
Server MPM: prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=256
-D HTTPD_ROOT="/etc/apache2"
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="mime.types"
-D SERVER_CONFIG_FILE="apache2.conf" |
Ce qui donne chez nous : | Code: | | USE="apache2_mpms_prefork" emerge -av apache |
Modifier ensuite dans /etc/init.d/apache2
| Code: | depend() {
#need net
use mysql dns logger netmount postgresql
after sshd
} |
Pour éviter :
| Code: | /etc/init.d/apache2 start
* /etc/init.d/apache2 uses runscript, please convert to openrc-run.
* Caching service dependencies ... [ ok ]
* /etc/init.d/net.eth1 uses runscript, please convert to openrc-run.
* Bringing up interface eth1
SO_SNDBUF: Invalid argument
* 192.168.1.16 ...
SO_SNDBUF: Invalid argument [ !! ]
* ERROR: net.eth1 failed to start
* ERROR: cannot start apache2 as net.eth1 would not start |
et enfin ajouter dans le /etc/apache2/httpd.conf après User apache \ Group apache :
| Code: |
# supprime les warnings AH00076: Failed to enable APR_TCP_DEFER_ACCEPT
AcceptFilter http none
AcceptFilter https none
#
# Emprunté à /etc/apache2/apache2.conf d'Ubuntu
# Si il n'existe pas, créer le dossier /run/apache2
#
Mutex file:/run/apache2 default
|
Apache tourne ensuite comme un charme avec PHP, le plus ennuyeux étant quand même l'absence de cette instruction "Mutex file" qui est bloquante dans WSL.
Comme pour SSHD il est nécessaire d'avoir lancé rc sysinit et rc boot pour que ce service fonctionne correctement.
J'ai aussi installé phpmyadmin et tout fonctionne normalement.
Beaucoup de problèmes avec apache découlent
1/ de la pile réseau qui n'est conforme
2/ de CONFIG_SYSVIPC=y absent du "kernel" 3.4.0+  voir "System V IPC is missing" https://github.com/Microsoft/BashOnWindows/issues/1016
(en cas de problème supprimer le /run/apache2.pid + /etc/init.d/apache2 stop avant de relancer)
| Code: | Runlevel: boot
hwclock [ started ]
modules [ started ]
fsck [ started ]
root [ started ]
mtab [ started ]
swap [ started ]
localmount [ started ]
procfs [ started ]
binfmt [ started ]
sysctl [ started ]
bootmisc [ started ]
hostname [ started ]
termencoding [ started ]
keymaps [ stopped ]
loopback [ stopped ]
swapfiles [ started ]
tmpfiles.setup [ started ]
urandom [ started ]
Runlevel: default
dcron [ started ]
net.eth1 [ stopped ]
netmount [ stopped ]
local [ started ]
Runlevel: nonetwork
local [ started ]
Runlevel: shutdown
killprocs [ stopped ]
savecache [ stopped ]
mount-ro [ stopped ]
Runlevel: sysinit
devfs [ started ]
dmesg [ stopped ]
kmod-static-nodes [ started ]
sysfs [ started ]
tmpfiles.dev [ started ]
udev [ stopped ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed/wanted
modules-load [ started ]
Dynamic Runlevel: manual
sshd [ started ]
apache2 [ started ]
dcron [ started ]
local [ started ] |
##########################
PERL (Updated)
Un autre gros problème est lié à perl. Lors de l'emerge de modules perl les .pm, .pod, .so ne sont pas écrits :
Normalement on devrait avoir (par exemple) :
| Code: | equery f DBD-mysql
* Searching for DBD-mysql ...
* Contents of dev-perl/DBD-mysql-4.32.0-r2:
/usr
/usr/lib64
/usr/lib64/perl5
/usr/lib64/perl5/vendor_perl
/usr/lib64/perl5/vendor_perl/5.22.2
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/Bundle
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/Bundle/DBD
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/Bundle/DBD/mysql.pm
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/DBD
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/DBD/README.pod
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/DBD/mysql
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/DBD/mysql.pm
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/DBD/mysql/GetInfo.pm
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/DBD/mysql/INSTALL.pod
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/auto
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/auto/DBD
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/auto/DBD/mysql
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/auto/DBD/mysql/mysql.so
/usr/share
/usr/share/doc
/usr/share/doc/DBD-mysql-4.32.0-r2
/usr/share/doc/DBD-mysql-4.32.0-r2/ChangeLog.bz2
/usr/share/doc/DBD-mysql-4.32.0-r2/README.pod.bz2
/usr/share/doc/DBD-mysql-4.32.0-r2/TODO.bz2 |
Alors qu'on a :
| Code: | equery f DBD-mysql
* Searching for DBD-mysql ...
* Contents of dev-perl/DBD-mysql-4.37.0:
/usr
/usr/lib64
/usr/lib64/perl5
/usr/lib64/perl5/vendor_perl
/usr/lib64/perl5/vendor_perl/5.22.2
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/auto
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/auto/DBD
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/auto/DBD/mysql
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/auto/DBD/mysql/.packlist
/usr/share
/usr/share/doc
/usr/share/doc/DBD-mysql-4.37.0
/usr/share/doc/DBD-mysql-4.37.0/Changes.bz2
/usr/share/doc/DBD-mysql-4.37.0/README.md.bz2 |
voir ça (autre version) :
| Code: | equery f DBD-mysql
* Searching for DBD-mysql ...
* Contents of dev-perl/DBD-mysql-4.32.0-r2:
/usr
/usr/share
/usr/share/doc
/usr/share/doc/DBD-mysql-4.32.0-r2
/usr/share/doc/DBD-mysql-4.32.0-r2/ChangeLog.bz2
/usr/share/doc/DBD-mysql-4.32.0-r2/README.pod.bz2
/usr/share/doc/DBD-mysql-4.32.0-r2/TODO.bz2 |
Autrement dit perl-cleaner --reallyall peut détruire une config et littéralement nettoyer tout les .pm, .pod et autres .ph auquel il touchera, tout comme un emerge de dépendances dev-perl (pas de problème avec les virtual) ...
M'inspirant de http://www.nntp.perl.org/group/perl.perl5.porters/2016/09/msg239952.html sur mon no-multilib amd64 Per- 5.22 j'ai corrigé ce problème en interdisant l'utilisation de nlink par Perl.
En root (Le fichier est en 444)
chmod 644 /usr/lib64/perl5/5.22.2/x86_64-linux/Config.pm
remplacer dont_use_nlink => undef, par dont_use_nlink => 'define',
chmod 444 /usr/lib64/perl5/5.22.2/x86_64-linux/Config.pm
Cela semble fonctionner :
| Code: |
equery f DBD-mysql
* Searching for DBD-mysql ...
* Contents of dev-perl/DBD-mysql-4.37.0:
/usr
/usr/lib64
/usr/lib64/perl5
/usr/lib64/perl5/vendor_perl
/usr/lib64/perl5/vendor_perl/5.22.2
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/Bundle
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/Bundle/DBD
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/Bundle/DBD/mysql.pm
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/DBD
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/DBD/mysql
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/DBD/mysql.pm
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/DBD/mysql/GetInfo.pm
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/DBD/mysql/INSTALL.pod
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/auto
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/auto/DBD
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/auto/DBD/mysql
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/auto/DBD/mysql/.packlist
/usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux/auto/DBD/mysql/mysql.so
/usr/share
/usr/share/doc
/usr/share/doc/DBD-mysql-4.37.0
/usr/share/doc/DBD-mysql-4.37.0/Changes.bz2
/usr/share/doc/DBD-mysql-4.37.0/README.md.bz2 |
A titre de test j'ai lancé un perl-cleaner reallyall qui s'est déroulé sans problèmes ...
PS: Ce problème est résolu dans les builds proposés aux insiders. J'ai teste une version récente de WSL, et il n'y a plus de problème.
##########################
Puis j'ai compilé entre autres icedtea et à cette occasion j'ai trouvé un nouveau bug du filesystem impactant le fonctionnement de mv.
Pour le comprendre j'ai du patcher un peu l'ebuild et je pense que pour le contourner je vais aussi modifier l'ebuild en attendant que les dev Microsoft corrigent leur filesystem.
MV BUG
Sous linux, le comportement normal de mv est le suivant :
| Code: | $ mkdir -p a/b/c
$ mkdir -p b/c/d
$ touch b/c/d/bla
$ mv -vi b/c/d/ a/b/c/
« b/c/d/ » -> « a/b/c/d »
$ ll a/b/c/d
total 0
-rw-r--r-- 1 toto toto 0 23 nov. 23:31 bla
$ ll b/c/
total 0 |
lors du mv, seul le répertoire surnuméraire du path source par rapport au path de destination est déplacé avec son contenu
le reste du path source reste à sa place ...
Dans le filesystem de WSL on obtient un message d'erreur :
| Code: | $ mv b/c/d/ a/b/c/
mv: impossible de déplacer «b/c/d/» vers «a/b/c/d»: Aucun fichier ou dossier de ce type |
En jouant à ça dans Ubuntu, le premier coup, j'ai même planté le service Windows lxssManager : deadlock, impossible de rentrer dans bash, impossible de tuer le process Windows : obligé de rebooter Windows.
Reproduit aussi bien dans Gentoo qu'Ubuntu. Cela pose problème notamment lors de l'emerge de nss avec l'option nss-pem (USE par défaut)
| Code: | unpack nss-3.14.1-add_spi+cacerts_ca_certs.patch: file format not recognized. Ignoring.
>>> Unpacking nss-pem-20140125.tar.bz2 to /var/tmp/portage/dev-libs/nss-3.23/work
mv: cannot move ‘nss/lib/ckfw/pem/’ to ‘/var/tmp/portage/dev-libs/nss-3.23/work/nss-3.23/nss/lib/ckfw/pem’: No such file or directory
* ERROR: dev-libs/nss-3.23::gentoo failed (unpack phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 115: Called src_unpack
* environment, line 3003: Called die
* The specific snippet of code:
* mv "${PN}"/lib/ckfw/pem/ "${S}"/lib/ckfw/ || die; |
Lors de l'organisation des sources avant compilation ebuild.sh fait un
| Code: | | mv nss/lib/ckfw/pem/ /var/tmp/portage/dev-libs/nss-3.23/work/nss-3.23/nss/lib/ckfw/ |
qui ne passe pas ...
en enlevant le / terminal du chemin de la source
| Code: | | mv nss/lib/ckfw/pem /var/tmp/portage/dev-libs/nss-3.23/work/nss-3.23/nss/lib/ckfw/ |
cela fonctionnerait dans WSL, tout comme plus haut fonctionnerait
comme la fin du chemin est en dur dans l'ebuild, une petite sauvegarde, un petit coup d'édition de l'ebuild, un petit | Code: | | emerge --digest -v nss |
et hop ça passe
Problème résolu dans la build-14901 mais il faut faire parti d'insider pour bénéficier du patch.
https://msdn.microsoft.com/en-us/commandline/wsl/release_notes#build-14901
#########################
GHC (BLOQUANT)
installer en mode USE="binary" ne résout pas le problème pour les compilations s'appuyant sur ghc.
| Code: | | ghc: timer_create: Function not implemented |
https://github.com/Microsoft/BashOnWindows/issues/307
Ce problème est en cours de résolution par Microsoft mais n’apparaît toujours pas dans les release notes
Je n'ai pas encore trouvé de workaround.
##########
Je vais aussi probablement passer sur systemd pour faciliter la soudure avec l'init du WSL mais je ne connais pas systemd (mais openrc à peine plus).
Avant cela je vais quand même essayer de travailler encore l'init avec openrc, ou s6, voir ce qu'il est possible de faire avec udev sans tmpdevfs.
Sinon le fait d'être sur no-multilib ne change apparemment pas grand chose.
La prochaine version du WSL devrait permettre de faire tourner Ubuntu 16.04 or celui-ci est basé (je crois) sur systemd.
Certains sont arrivés à faire tourner X sur leur WSL Ubuntu, j'ai bien envie de tenter le coup avec Gentoo au moins avec LXDE.
Upstart de la 14.04 ne semble pas pris en charge correctement dans le WSL actuel, peut-être ont-il fait l'impasse pour orienter leurs efforts dés maintenant vers systemd et la 16.04. |
|
| Back to top |
|
|
brokenHeart
n00b
Joined: 15 May 2013
Posts: 35
Location: versailles
|
| Posted: Wed Feb 22, 2017 5:56 pm Post subject: |
|
|
Hello,
N'ayant pas eu trop de temps à consacrer à l'expérimentation je suis néanmoins passé en Windows Insider "fast ring" (actuellement Version 15031.rs2_release.170204-1546) et je viens de tester la compilation d'un world sans aucun problème, à quelques warning près lié à xattr. J'ai installé GHC en binary, car même avec un core i5 la compilation est très lente, mais les binaires en dépendant et mis à jour semblent se compiler, ce qui était jusqu'alors un problème bloquant en raison de l'absence d'un appel système.
La plupart des problèmes évoqués précédemment ont disparu. Reste le démarrage qui produit beaucoup de messages d'erreur, lançant manuellement un sysinit, boot et default à peine modifiés.
Par contre j'ai du passer en profile no-multilib pour pouvoir compiler gcc 4.9 ...
Cela confirme donc qu'il vaut mieux utiliser un stage no-multilib pour démarrer l'installation, au moins dans un contexte 64bit compte tenu de l'API du kernel imposé.
Pas eu l'occasion de suivre le github de bashonwindows, une des features intéressante serait AMHA fuse et de pouvoir monter des filesystems étrangers dans WSL. Sinon l'interopérabilité a bien progressé. Je ne suis néanmoins pas arrivé à distance à lancer un shell powershell depuis ssh mais certaines commandes Powershell fonctionnent ce qui permet de mélanger du bash et du PS.
Dans l'autre sens (windows => Linux) il faudrait que j'y travaille de façon à pouvoir installer le lancement de bash (de sshd et autres) en service Windows.
J'imagine que des Ubuntistes ou d'autres Gentooistes y ont déjà travaillé ...
De plus il y a probablement des librairies Ubuntu qu'il pourrait être intéressant de porter, ayant vu des appels de l'init du bash de lxss vers ces librairies absentes passer, mais même sans ça, ça tourne ...
Pour ceux qui souhaiteraient bénéficier des dernières avancées de Windows 10 sans pour autant souscrire au programme Insider (et on ne pourrait pas leur en vouloir) le "Windows 10 Creators Update" est planifié pour Avril 2017 et devrait contenir nombre des mises à jour corrigeant les problèmes que vous rencontrez peut-être si vous utilisez WSL.
J'espère vraiment que Microsoft va continuer ce projet et pas l'abandonner comme tant d'autres avant lui. |
|
| Back to top |
|
|
xaviermiller
Bodhisattva
Joined: 23 Jul 2004
Posts: 8708
Location: ~Brussels - Belgique
|
| Posted: Fri Feb 24, 2017 8:40 am Post subject: |
|
|
Merci pour ton retour d'expérience !
_________________
Kind regards,
Xavier Miller |
|
| Back to top |
|
|
brokenHeart
n00b
Joined: 15 May 2013
Posts: 35
Location: versailles
|
| Posted: Sat Jun 03, 2017 4:01 pm Post subject: |
|
|
Hello,
Depuis j'ai réinstallé Windows (à l'occasion de l'achat d'un disque M2) et j'ai eu l'occasion de re-dérouler tout cela.
Beaucoup de choses ne sont toujours pas corrigées sur un Windows 10 familial 14393.1198 (public post creator-update et non-insider donc ...) et les workarounds mentionnés plus haut restent utiles.
grep :
la dernière version de grep (2.27-r1 au moment ou j'écris ces lignes https://packages.gentoo.org/packages/sys-apps/grep) interdit certaines compilations et j'ai du la downgrader en 2.25.
Problème constaté également par la communauté Arch https://github.com/Microsoft/BashOnWindows/issues/1578 et rencontré aussi bien avec un système x86_64 multilib que no-multilib
| Code: | | emerge -av =sys-apps/grep-2.25 |
et puis j'ai masqué la version actuelle et les futures pour le moment
| Code: | | echo ">=sys-apps/grep-2.27-r1" >> /etc/portage/package.mask/grep |
vi (cosmétique et anecdotique) :
Sinon, j'en ai profité pour résoudre mon problème d'install qui ne se terminait pas avec vi et restait bloqué à la fin sur | Code: | | * Updating documentation tags in /usr/share/vim/vim80 |
même si cela n'empêchait vi ni de fonctionner, ni d'être enregistré dans la liste des packages installés.
Il existe un lien symbolique gentoo-syntax.txt vers //usr/share/vim/vimfiles/doc/gentoo-syntax.txt dans /usr/share/vim/vim80/docs
Après arrêt de l'emerge qui est bloqué, le défaire et le refaire proprement | Code: | root@HOST:/usr/share/vim/vim80/doc# unlink gentoo-syntax.txt
root@HOST:/usr/share/vim/vim80/doc# ln -s /usr/share/vim/vimfiles/doc/gentoo-syntax.txt gentoo-syntax.txt |
permet de relancer l'emerge
qui s’achèvera normalement ...
perl :
un update @world me demande d'upgrader perl-5.24.1-r1 vers perl-5.24.1-r2
L'emerge plante avec une masse de "Can't locate XXX.pm in @INC"
Une rapide analyse me permet de constater que si les .pm sont bien présents dans l'arborescence de work il ne sont pas accessibles par le @INC déclaré.
Des liens qui ne se sont pas fait ?
Peut être en modifiant l'ebuild et en rajoutant peu a peu les chemins qui manquent dans l'INC ou en essayant de comprendre ce qui plante.
Il pourrait s'agir du bug mentionné plus haut concernant la création des liens et corrigé au niveau du système en intervenant sur nlink dans le config.pm. http://search.cpan.org/~xsawyerx/perl-5.26.0/ext/File-Find/lib/File/Find.pm#CAVEAT
Si il est possible de transmettre cette option à emerge ou de mettre cette option dans l'ebuild cela pourrait résoudre le problème, mais bon, c'est peut-être autre chose ... 
En attendant j'ai masqué cette maj et les suivantes :
| Code: | | echo ">=dev-lang/perl-5.24.1-r2" >> /etc/portage/package.mask/perl |
sshd (Rapide update)
Pour utiliser sshd il faut :
- modifier | Code: | | /etc/ssh/sshd_config |
pour ajouter | Code: | | UsePrivilegeSeparation no |
- avoir créé en root un utilisateur autre que root avec un password :
| Code: | root@HOST #useradd -m -G users,wheel,audio -s /bin/bash larry
root@HOST #passwd larry
|
puis lancer le démon | Code: | | /etc/init.d/sshd start |
- Dans Windows il faut arrêter les services "SSH Server Broker" et "SSH Server proxy" qui ne servent que pour les développeurs Windows et n'ont rien à voir avec WSL mais qui bloquent l'accès au port de son démon ssh (ou alors il faut choisir un autre port pour sshd).
Il faut aussi ouvrir un port (22 TCP si on utilise la configuration par défaut) dans le firewall Windows ("règles de trafic entrant") puis si on le souhaite, par la suite, affiner en n'autorisant que certaines machines/certains réseaux à utiliser ce port.
Ensuite si on souhaite faire du su ou sudoer après installation de sudo, il faut que root ait un password et/ou configurer sudo. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
French
