Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Natty installé par Wubi

malbo

Pour ceux qui veulent essayer Natty en installant "dans Windows" (Wubi), il est possible de télécharger ce fichier (NON : voir post #15) wubi.exe (1,4 Mo) : https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/693671/+attachment/1908006/+files/wubi.exe
D'après ce que j'ai pu lire, ça ne fait pas longtemps que ça fonctionne l'install de Natty par Wubi, mais ça fonctionne. Je viens de réaliser ce type d'install dans mon PC Acer (depuis Win7) et dans mon PC Medion (depuis XP). Comme d'habitude, Wubi télécharge d'autorité la version 64 bits ou 32 bits suivant les possibilités du PC (si architecture compatible 64 bits, c'est ubuntu 64 bits qui est téléchargé sans qu'on puisse intervenir). C'est la version la plus fraîche de ubuntu (daily) qui est téléchargée et installée automatiquement.
Voir post #7 plus bas qui recommande d'installer Ubuntu dans la même partition que le système Windows.
ça ce n'est plus vrai (rédaction d'origine du post) : On peut installer ubuntu dans une partition de stockage NTFS (un autre disque que C: ), c'est ce que j'ai pratiqué dans mes deux installations.

Chewbacca

Yo dawg i've heard you like computing so we put an OS in your OS so you can compute while you compute 😃

Marche ici également, 32 bits x3

malbo

Je ne sais plus si c'était le cas avec les versions précédentes de Ubuntu mais il y a une vacherie pour ceux qui ont plusieurs disques durs. Moi, j'ai installé Ubuntu (partition hôte NTFS : sdb8) dans Win7 (sdb1). Donc, tout sur le disque sdb. Si je choisis de démarrer mon PC sur sda, j'ai Grub dans sda qui me propose un menu permettant de démarrer Windows sur sdb1. Et bien dans cette condition là, si je choisis Windows, puis ubuntu dans le sous-menu proposé par bootmgr de Win7, j'arrive à un blocage de Grub qui affiche :

Try (hd0,0): NTFS5 : No wubildr
Try (hd0,1): NTFS5 : No wubildr
Try (hd0,2): Extended :
Try (hd0,3): EXT2 : _

En fait, Grub parcourt le mauvais disque (sda) à la recherche de wubildr et il bloque parce qu'il ne risque pas de le trouver là puisqu'il se trouve sur le disque sdb. Pour résoudre le problème, il faut que je choisisse de démarrer le PC sur le disque sdb (avec le "boot menu", touche F12 de mon PC) pour que le problème soit résolu. Là, Grub parcourt bien ce disque sdb puisque Ubuntu démarre normalement.
L'état de mon partitionnement vu depuis Ubuntu :

~$ sudo fdisk -l

Disque /dev/sda: 500.1 Go, 500107862016 octets
255 têtes, 63 secteurs/piste, 60801 cylindres
Unités = cylindres de 16065 * 512 = 8225280 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identifiant de disque : 0x00037dc9

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sda1   *           3        3893    31254457+   7  HPFS/NTFS
/dev/sda2            3894       12771    71312535    7  HPFS/NTFS
/dev/sda3           12772       53256   325195732    5  Etendue
/dev/sda4           53257       60801    60605212+  83  Linux
/dev/sda5           12772       44855   257714698+   7  HPFS/NTFS
/dev/sda6           44856       46131    10249438+  83  Linux
/dev/sda7           46132       46776     5180931   82  Linux swap / Solaris
/dev/sda8           46777       53256    52050568+  83  Linux

Disque /dev/sdb: 1000.2 Go, 1000204886016 octets
255 têtes, 63 secteurs/piste, 121601 cylindres
Unités = cylindres de 16065 * 512 = 8225280 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identifiant de disque : 0xa9e4f6a8

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sdb1   *           1        3935    31607856    7  HPFS/NTFS
/dev/sdb2            3936        5210    10241437+   7  HPFS/NTFS
/dev/sdb3            5211        5975     6144862+  82  Linux swap / Solaris
/dev/sdb4            5976      121601   928765814+   5  Etendue
/dev/sdb5            5976        7887    15358108+  83  Linux
/dev/sdb6            7888       15536    61440561   83  Linux
/dev/sdb7           15537       16841    10482381    7  HPFS/NTFS
/dev/sdb8           16842      116404   799739260    7  HPFS/NTFS
/dev/sdb9          116405      121601    41744871    7  HPFS/NTFS

On voit bien que quand ça merde, Grub parcourt mon disque sda avec la correspondance suivante :
(hd0,0): NTFS5 >>> sda1
(hd0,1): NTFS5 >>> sda2
(hd0,2): Extended >>> sda3
(hd0,3): EXT2 : >>> sda4

Chewbacca

Ma pensée a ce sujet est que wubi ca reste quand même du bricolage.

A quoi ca sert d'utiliser linux en le bridant car il est dépendant d'une partoche NTFS et autre windowseries.

Wild_Child_87

C'est pire que tous Wubi.

malbo

Après la mise à jour de grub-pc, au redémarrage du PC, après le choix "ubuntu" dans le menu Windows, au lieu d'avoir le menu Grub de Ubuntu, je me retrouve avec "Minimal BASH-like" accompagné de l'invite de commande "grub>" comme ceci :

en haut de l'écran ------>                                       GNU GRUB version 1.99~rc1-XXXXX
Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions.
grub>

Il faut appliquer la recette déjà mise au point par bcbc pour la version précédente de Wubi : http://ubuntuforums.org/showpost.php?p=9932369&postcount=5
C'est cette ligne en particulier :

Otherwise another workaround is to boot a live CD, loop mount the wubi root.disk, edit the grub.cfg (gksu gedit /mountpoint/boot/grub/grub.cfg) and remove all lines above the first "menuentry".

C'est une procédure pour supprimer toute l'entête du grub.cfg du ubuntu malade. Moi, je ne sais pas le dire en une ligne aussi je détaille ça dans ce post : http://forum.ubuntu-fr.org/viewtopic.php?pid=3784793#p3784793
Au redémarrage du PC, on retrouve le menu Grub, plus rustique (en noir et blanc au lieu d'être sur fond coloré) mais qui fonctionne.

malbo

J'avais écrit dans le post #1 qu'on pouvait installer Ubuntu dans une autre partition NTFS que la partition système de Windows (en pratique, dans un autre disque que C: ) mais mes emmerdes du post #6 ainsi que ce rapport de Bug #742967 contredisent cela. C'est une vieille casserole de Wubi qui perdure : normalement et très logiquement, on devrait pouvoir installer Ubuntu dans une partition de stockage NTFS où on a de la place, mais non, ça merde encore et toujours. Il faut donc installer Ubuntu dans le disque C: si on veut être tranquille. Sinon, si on tient à installer ubuntu ailleurs que dans la partition système de Windows, le jour où ça merde, on peut être amené (ce n'est pas systématique) à faire la petite manip pas compliquée mais juste chiante que j'ai décrite dans le post #6

malbo

C'est écrit là : http://www.ubuntu.com/testing/natty/beta
Extrait :

Using Ubuntu 11.04 Beta 1 with WUBI is not recommended at this time
There is a known issue (746257) that prevents Ubuntu 11.04 Beta 1 from being used with WUBI at this time. Please consider waiting for a few more days for updated desktop images that fix this issue, or use the Live CD or USB images to try out Ubuntu 11.04 Beta 1.

En gros, Natty avec Wubi, c'est pas encore ça.
Pour ceux qui ont l'habitude de ce genre de chose, on peut quand même installer Ubuntu par Wubi en utilisant le fichier wubi.exe dont j'ai donné le lien dans le post #1. Par contre, après installation complète de Ubuntu, au 2ème redémarrage donc, Ubuntu ne démarre pas (c'est quasi systématique chez moi, sur les deux PC dans lesquels j'ai installé Ubuntu par Wubi) et la manip de coupage d'entête du grub.cfg que j'ai détaillée dans le post #6 est indispensable. A part, ça, une fois démarré, ça fonctionne aussi mal qu'un Ubuntu beta1 installé classique.

malbo

Les ennuis de démarrage de Natty installé par wubi peuvent être (du plus méchant au plus gentil) : plantage après qu'on a sélectionné ubuntu dans le menu proposé par Windows et validé ce choix par la touche Entrée (on est alors obligé de redémarrer au bouton marche-arrêt du PC), redémarrage automatique du PC , invite de commande Grub ( grub> )
Ces 3 types d'ennuis au démarrage se résolvent de la même manière : par la méthode brutale de "coupage de tête" du grub.cfg selon procédure détaillée ici : http://forum.ubuntu-fr.org/viewtopic.php?pid=3784793#p3784793
C'est à dire suppression de toute la partie qui précède la première "menuentry" (la première entrée du menu)
Pour les plus raffinés, il est possible d'utiliser une méthode plus ciblée sur le problème : au lieu de supprimer toute l'entête comme indiqué ci-dessus, il suffit de rajouter le symbole # devant les 6 lignes impliquées dans le bug (on appelle ça "commenter" ces lignes) qui sont celles-ci (x et y dépendent du disque et de la partition où est installé Ubuntu) :

insmod part_msdos
insmod ntfs
set root='(/dev/sdx,msdosy)'
search --no-floppy --fs-uuid --set=root UUID_Partition_Hôte_Ubuntu
loopback loop0 /ubuntu/disks/root.disk
set root=(loop0)

Ce qui donne après modif pour l'entête du grub.cfg :

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
set default="0"
if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}

function recordfail {
  set recordfail=1
  if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then save_env recordfail; fi; fi
}

function load_video {
true
}

#insmod part_msdos
#insmod ntfs
#set root='(/dev/sdx,msdosy)'
#search --no-floppy --fs-uuid --set=root UUID_Partition_Hôte_Ubuntu
#loopback loop0 /ubuntu/disks/root.disk
#set root=(loop0)
if loadfont /usr/share/grub/unicode.pf2 ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ]; then
  set timeout=-1
else
  set timeout=10
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
if background_color 44,0,30; then
  clear
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/10_lupin ###

Les # devant les 6 lignes font qu'elles ne sont pas prises en compte au démarrage et du coup, Ubuntu peut arriver à démarrer normalement. Cette méthode "douce" permet de maintenir un affichage du menu Grub plus esthétique (sur fond coloré) au lieu que le "coupage de tête" entraîne un affichage plus rustique en noir et blanc. Mais une fois Ubuntu démarré par l'une ou l'autre méthode, il n'y a aucune différence de fonctionnement.
Edit : la méthode douce est pompée du commentaire #1 de bcbc dans le rapport de bug #746257

malbo

Pour faire l'installation tout par internet de Natty Beta1, le plus fiable (Non : voir post #15) est de télécharger le petit fichier wubi-r205.exe (1518090 octets) à cette adresse : http://people.canonical.com/~evand/wubi/natty/wubi-r205.exe
Pour info (c'est juste pour bien l'identifier), son md5sum est là :

$ md5sum wubi-r205.exe
de3f148f5e91bc15756ba40b7f90ce74  wubi-r205.exe

Si vous vous faites caguer à extraire le wubi.exe qui se trouve dans ubuntu-11.04-beta1-desktop-i386.iso ou bien dans ubuntu-11.04-beta1-desktop-amd64.iso, vous trouverez le même md5sum. Donc pas besoin de télécharger à l'avance les gros fichiers .iso de 700 Mo. Juste le fichier wubi-r205.exe à lancer en tant qu'administrateur sous Windows et tout se fait automatiquement.

malbo

Malgré les efforts des développeurs, ce n'est toujours pas au point. Je veux dire qu'il n'est toujours pas possible d'avoir un Natty installé par Wubi qui soit parfait après l'install. Cependant, il semble qu'on ne soit plus obligé de couper l'entête comme je le décris dans le post #9 à condition d'utiliser la dernière version de wubi.exe. Donc pour faire l'installation tout par internet de Natty dans sa version la plus récente, il suffit de télécharger (Non : voir post #15) le petit fichier wubi-r207.exe (1526028 octets) ici : http://people.canonical.com/~evand/wubi/natty/wubi-r207.exe
On lance ce fichier exécutable depuis une session Windows avec pouvoir administrateur et c'est la version la plus fraîche (Daily Build) qui est installée par Wubi. Au deuxième redémarrage (après installation complète), on arrive bien cette fois à démarrer Ubuntu. J'ai dit que cette install bien que fonctionnelle n'est pas parfaite parce que le dossier /boot/grub n'est pas dans sa configuration définitive (il devrait contenir plus de 200 éléments or il n'en contient que deux ou trois) et le fichier wubildr - qui se trouve à la racine de la partition Windows après install - n'est pas dans sa configuration définitive non plus (bien qu'il soit à la même version 1.99~rc1-8ubuntu2 que grup-pc installé dans Ubuntu). De mes manips toutes récentes, il ressort que ces deux anomalies seront rectifiées à la future mise à jour du paquet grub-cfg (s'il n'y a pas une grosse louche de régression en accompagnement) : il devrait y avoir remplissage du dossier /boot/grub (plus de 200 éléments) et remplacement du fichier wubildr par un nouveau, différent du précédent.
L'état actuel du chantier est visible là : https://bugs.launchpad.net/wubi/+bug/742967
Colin Watson a qui se bug a été assigné pense avoir maîtrisé l'hydre Wubi et qu'on va voir ce qu'on va voir pour Ubuntu ubuntu-11.04-beta-2. On n'ose le croire, attendu qu'on galère avec ce type de problème depuis plus d'un an (sortie de Lucid), avec le même développeur aux manettes.

malbo

Parmi les mises à jour de ce matin, il y avait une mise à jour de grub-pc pour passer à l'indice 1.99~rc1-10ubuntu1. Dans le descriptif des évolutions contenues dans ce nouveau paquet grub-pc, j'ai trouvé ceci concernant Wubi : "On Wubi, don't ask for an install device, but just update wubildr using the diverted grub-install". J'en ai profité pour tendre un piège à Wubi en semant plein de fichiers wubildr d'une version ancienne de grub à la racine de toutes les partitions NTFS de mes deux disques durs (il y a des primaires et des logiques dans le tas) sauf pour la partition Windows dans lequel j'ai placé un wubildr déjà passé à l'indice 1.99~rc1-10ubuntu1. Le but : connaître le comportement de grub dans ce cas de figure. Résultat : tous les wubildr ont été remplacés par un wubildr au dernier indice de grub, y compris le wubildr de la partition Windows qui était pourtant déjà au dernier indice. Je le sais puisque tous ces fichiers sont identiques au wubildr mis à jour également qui se trouve sur la partition Windows (dont la taille a augmenté d'un octet : 147956 au lieu de 147955 octets). A l'issue de cette mise à jour, j'ai bien vérifié que tous ces wubildr nouveaux avaient bien le même md5sum. Ce nouveau fonctionnement de la mise à jour de grub-pc me parait impeccable et je ne pense pas qu'il y ait un dégât collatéral. On verra à l'usage.
Ma config (extrait utile) :

~$ df -h
Sys. de fichiers            Taille  Uti. Disp. Uti% Monté sur
/dev/loop0            4,6G  3,1G  1,4G  70% /
none                  1,9G  764K  1,9G   1% /dev
none                  2,0G  200K  2,0G   1% /dev/shm
none                  2,0G  320K  2,0G   1% /var/run
none                  2,0G     0  2,0G   0% /var/lock
/dev/sdb8             763G  421G  342G  56% /host
/dev/sdb1              31G   13G   18G  42% /media/Acer
-----
-----

la partition Windows est /dev/sdb1, la partition hôte dans laquelle se trouve ubuntu installé par Wubi est /dev/sdb8
L'espoir renaît que le bug #742967 soit effectivement résolu : https://bugs.launchpad.net/wubi/+bug/742967
C'est à dire qu'on pourra bien à l'avenir installer Ubuntu par Wubi dans une autre partition que la partition Windows et que les mises à jour de grub-pc sauront gérer tout ça.

Edit 1 : Cette manip étant faite, j'ai supprimé tous les wubildr que j'avais semés pour ne laisser qu'un seul fichier wubildr, celui qui est directement à la racine de la partition Windows, ce qui est la config normale après une installation nouvelle de Ubuntu par Wubi.
A savoir : les fichiers wubildr qui ne se trouvent pas directement à la racine d'une partition NTFS, ne sont jamais lus par Ubuntu (installé par Wubi).

Edit 2 : j'ai fait la même manip dans mon PC Medion en semant des wubildr à l'indice 1.99~rc1-8ubuntu2 de Grub dans toutes les partitions NTFS et aussi dans les partitions FAT32 (ces dernières n'étant pas montées "de base" car leur montage n'est pas mentionné dans le fstab, elles n'étaient pas montées lorsque j'ai demandé les mises à jour). Résultat : comme pour la manip décrite plus haut, tous les wubildr de toutes les partitions NTFS et FAT32 ont été remplacés par un wubildr au dernier indice de grub ( 1.99~rc1-10ubuntu1)

malbo

Pour installer Ubuntu 11.04 beta2 par Wubi, la procédure est inchangée (voir nota) : il faut télécharger (Non : voir post #15) depuis Windows le petit fichier wubi-r207.exe (1526028 octets) à l'adresse indiquée dans le post #11 ci-dessus et le lancement de ce petit exécutable va faire tout le boulot de téléchargement de l'image (Daily Build). Par acquit de conscience, je viens de vérifier que le fichier wubi.exe qui se trouve à l'intérieur de la Daily Build du 13 avril est bien strictement identique au wubi-r207.exe. C'est OK, le md5sum est bien le même :

$ md5sum wubi-r207.exe
2f66f8b0af370711e6bd9b3553a5c61d  wubi-r207.exe
$ md5sum wubi.exe
2f66f8b0af370711e6bd9b3553a5c61d  wubi.exe

Jusqu'à la sortie officielle de Ubuntu 11.04 (prévue pour fin Avril) et même après cette sortie officielle, pour installer Ubuntu 11.04 par Wubi, c'est toujours ce même fichier wubi-r207.exe qu'il faudra utiliser. Comme déjà maintes fois expliqué, le lancement de wubi-r207.exe va entrainer le téléchargement automatique de la version "du jour" (Daily Build) de Ubuntu 11.04.
Dans le post précédent, j'ai expliqué (et je confirme) qu'il est possible d'installer Ubuntu dans une autre partition NTFS que la partition Windows. Ce qui permet de réinstaller Windows (un mauvais jour où Windows ne veut plus démarrer) sans risquer dans l'affolement de perdre Ubuntu installé par Wubi.

nota : à l'usage des novices, je me suis fendu d'une procédure détaillée pour faire cette Installation "tout par internet" de Ubuntu 11.04 par Wubi : http://forum.ubuntu-fr.org/viewtopic.php?id=450498

malbo

A l'instant, je viens de faire une installation par Wubi en utilisant le petit fichier wubi-r207.exe (installation depuis Win7 dans VirtualBox). Ce n'est toujours pas parfait (on va voir pourquoi) mais au moins l'installation de Ubuntu 11.04 Beta2 avec Wubi va être fonctionnelle contrairement à ce qui s'est passé pour Beta1( voir post #8 ).

Détail des investigations post-installation :

Au redémarrage du PC, après le choix "ubuntu", je constate que le menu Grub affiche en titre la version 1.99~rc1-8ubuntu2, ce qui n'est pas la version la plus fraiche puisque le paquet installé est en version 1.99~rc1-12ubuntu1

Etat des lieux :

~$ ls -l /host/wubildr
-rwxrwxrwx 1 root root 148169 2011-04-14 08:49 /host/wubildr
~$ dir /boot/grub
gfxblacklist.txt  grub.cfg  grubenv
~$ ls -l /boot/grub/grub.cfg
-r--r--r-- 1 root root 3886 2011-04-14 09:48 /boot/grub/grub.cfg

Après les deux mises à jour proposées dans apt-get (paquets "gnome-user-share" et "xdg-user-dirs"), l'état est inchangé.

Commande d'installation de grub : je passe exprès cette commande apparemment débile (avec "x") parce qu'il semble nécessaire pour que cette commande d'installation de grub soit acceptée de mettre un caractère quelconque. Mais même si on met /dev/sda à la place de x, on obtient le même résultat parce que grub va détecter qu'il tourne dans Wubi et ne va pas réellement écrire dans le MBR du disque dur, il va seulement mettre à jour le ou les fichiers wubildr qui sont à la racine des parttions NTFS et FAT32.

~$ sudo grub-install x
[sudo] password for malbo: 
Installation finished. No error reported.

Etat après cette commande d'installation de Grub :

1) le fichier wubildr a été mis à jour et son contenu est différent :

~$ ls -l /host/wubildr
-rwxrwxrwx 1 root root 147956 2011-04-14 10:19 /host/wubildr

2) la directorie /boot/grub qui ne contenait que trois bricoles s'est remplie de 209 éléments

3) c'est normal et habituel, le ficher grub.cfg n'a pas été mis à jour :

~$ ls -l /boot/grub/grub.cfg
-r--r--r-- 1 root root 3886 2011-04-14 09:48 /boot/grub/grub.cfg

Au redémarrage du PC, le menu proposé par Grub affiche bien "1.99~rc1-12ubuntu1" dans son titre, c'est le résultat de la modification du fichier wubildr mise en évidence plus haut.

Commande de mise à jour de Grub :

~$ sudo update-grub
[sudo] password for malbo: 
Generating grub.cfg ...
etc..etc...
done

grub.cfg a bien été modifié et son contenu est différent:

~$ ls -l /boot/grub/grub.cfg
-r--r--r-- 1 root root 4192 2011-04-14 10:36 /boot/grub/grub.cfg

Le redémarrage se passe bien (le menu grub est juste comme avant l'update-grub)

Conclusion :

Pour avoir une installation parfaite, c'est à dire avec cohérence de l'indice de révision du fichier wubildr et de l'indice de révision du paquet grub installé, il est utile (mais pas forcément indispensable) de passer cette commande d'installation de grub, à l'allure inhabituelle (avec un "x") :

sudo grub-install x

suivie d'une mise à jour de grub :

sudo update-grub

Je dis que c'est utile parce que cette cohérence est le nouveau credo pour avoir un fonctionnement correct de Ubuntu 11.04 installé par Wubi (depuis la résolution du bug #742967 ), mais ce n'est pas indispensable car le bug ne se révèle pas systématiquement.

malbo

Pour faire une installation "tout par internet" de Natty, il vient d'y avoir une mise à jour du fichier exécutable de wubi. Il faut à présent télécharger le fichier wubi-r211-signed.exe : http://forum.ubuntu-fr.org/viewtopic.php?id=450498

frenchy82

Bonjour,

Je viens d'installer ubuntu via wubi sur deux nouveaux postes : un sous xp et l'autre sous 7.

Il faut relever que l'install est vraiment efficace. Aucun probleme a relever.

La seule difference que je peux relever est que sous seven, au demarrage on a donc le choix entre 7 et ubuntu (boot de windows). Si on selectionne ubuntu on arrive alors sous grub qui lui aussi laisse le choix entre ubuntu et 7

Sous xp on a pas le meme resultat. Une fois le choix réalisé sous la 1ere étape on accede directement à ubuntu
(pour xp j'ai utilise wubi.exe dont le lien est donné par ce post, pour 7 celui de la doc)
Savez vous si sous le grub (de Wubi) on peut masquerle choix de l'os même si plusieur OS coexistent?

malbo

frenchy82 a écrit Savez vous si sous le grub (de Wubi) on peut masquerle choix de l'os même si plusieur OS coexistent?

Je peux te jurer que c'est une sacrée mauvaise idée que de vouloir masquer ce menu proposé par Grub. En cas de bug à venir qui serait lié à une mise à jour du noyau, tu seras heureux de constater que tu peux démarrer en choisissant une autre entrée que la première entrée du menu. Cela fait plus d'un an que Wubi nous fait braire avec des problèmes d'instabilité au démarrage (Lucid = buggé, Maverick=buggé ; c'est le bug #742967 : https://bugs.launchpad.net/wubi/+bug/742967 ). Touché par la grâce (et par un coup de génie des développeurs), Wubi pour Ubuntu 11.04 n'est plus buggé alors évite de toucher au démarrage.

frenchy82

Ok, merci pour ta réponse et la comprend tout à fait.

Sous mon poste principal je n'ai que Ubuntu donc je n'ai pas ce choix mais en appuyant sur MAJ on accede au grub
Ce qui est seulement seulement "dommage" c'est de devoir selectionner 2 fois ubuntu pour acceder à l'os.(d'un autre cotés je reconnais que c'est lié au mode d'installation qui reste bien pratique pour le poste de mon taff)