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

Mot de passe demandé en session live

moko138

Bonjour
À mon tour d'être coincé :
je viens de faire une session live persistante, à partir d'une iso de Xubuntu 12.04.4 32 bits qui m'a souvent servi. La somme md5 est toujours bonne.
Mais cette fois,
1) Login et mot de passe me sont demandés depuis le deuxième démarrage ;
2) Les trucs habituels ne marchent pas :
xubuntu / rien
xubuntu / xubuntu
ubuntu / rien
ubuntu / ubuntu
rien / rien
rien / xubuntu
Certains de ces couples donnent "mot de passe incorrect", les autres non ; tous ramènent la boîte de dialogue de connexion.

Si je bascule en console, même avant d'avoir rien tapé, je vois
3) que je suis déjà logué en tant que xubuntu@xubuntu ;
4) que je ne peux pas utiliser sudo, car :

xubuntu@xubuntu:~$ sudo lsblk
sudo: /etc/sudoers is owned by uid 1000, should be 0
sudo: no valid sudoers sources found, quitting
sudo: impossible d'initialiser le greffon de règles
xubuntu@xubuntu:~$

- -

Je peux bien sûr refaire ma live - et c'est probablement ce que je vais faire - mais
j'aimerais surtout savoir quelle est l'erreur à ne pas refaire.

Merci d'avance !

AJOUT 4/3/2017 :
Sans preuve, je suis enclin à croire que l'erreur initiale avait été de faire, depuis un système installé, un chown sur tout /media/casper-rw, alors qu'aujourd'hui (4/3/17), sur la nouvelle live, je n'ai fait le chown que sur un de ses sous-répertoires (cf. #12).

AJOUT novembre 2017, autre point-clef (cf. #9) :
Il faut demander 0 espace libre avant la seconde partition.
(Et - rappel - aligner les partitions sur les cylindres).

[supprimé]

root/root ?

moko138

(Captures d'écran ou autres infos, à suivre)

GR 34

Si c'est une persistante, tu as enregistré un paramètre à l'insu de ton plein gré lors du 1er démarrage ?

moko138

jojo81 a écritroot/root ?

J'essaie, mais si une *buntu live n'est utilisable qu'en root, ce n'est pas une *buntu ! (Mais quelque chose comme une toutoulinux).
Résultat :
root / root ==> "mot de passe incorrect",
root / rien ==> "mot de passe incorrect".

moko138

GR 34 a écritSi c'est une persistante, tu as enregistré un paramètre à l'insu de ton plein gré lors du 1er démarrage ?

Probable, mais quelle était l'erreur ?

Tamarou

Bonjour, sur une xubuntu 16.04.1 en live, je ferme la session et je teste :
Utilisateur = xubuntu
mdp = rien, laisser vide

Dans mon cas ça marche, mais si un mot de passe a été rentré à l'insu de ton plein grès ... alors.

moko138

Ce qui ne marche pas :
le login graphique,
sudo.
Ce qui marche : tout (semble-t-il) le reste en console.

- -

N.B. : La procédure suivie
C'est celle de gornthorn http://gornthorn.over-blog.fr/article-live-usb-en-mode-persistant-avec-l-integralite-de-la-cle-usb-74373994.html, avec alignement sur les cylindres comme conseillé par Babdu89 là ./viewtopic.php?pid=17492041#p17492041,
à quelques détails près :
- Le tuto du "Coin de Gorn dit :

Il est possible qu'il soit nécessaire de retirer la clé et de la rebrancher pour qu'elle soit "montée" ("reconnue") à nouveau.

mais je n'ai pas eu besoin de la retirer-rebrancher avant de supprimer le fichier casper-rw.

- Comme j'ai utilisé un disque et non une clef, j'ai fait la partition de persistance en ext4 et non en ext2,

- En raison du bug des versions récentes de gparted (*) (qui plante quand il lance fsck sur des FAT), bien qu'ayant commencé ma live persistante avec usb-creator-gtk de Trusty, je me suis rabattu sur le gparted 0.12.1 de CrunchBang pour réduire la FAT à 5 Go et créer la 2ème partition (casper-rw),

- J'ai demandé 4 Mio non alloué entre les partitions (7,84 Mio obtenus).
AJOUT : c'était une erreur ! puisqu'il faut
aligner les 2 partitions sur les cylindres ;
et 0 Mio entre les partitions.
FIN d'ajout.

- Enfin, dans CrunchBang, j'ai monté la partition en ext4 et, pour cela, j'ai fait un chown. Peut-être est-ce alors que j'ai corrompu /etc/sudoers ?
[center]= = = = =[/center]

_________________
(*) Test sur 4 versions
A) GParted v.0.18.0-1 (en session installée)
plante dès que je lui demande de réduire à droite une FAT32.

En session installée, xubuntu 14.04.5 (3.13.0-105-generic i686),
selon gparted 0.18.0-1, la situation initiale :
sda1 est en fat32
espace libre avant : 0 Mio
Taille : 1428 Mio
espace libre suivant : 0 Mio
- -
A1) Je demande :
alignement sur les Mio
espace libre avant : 0 Mio
Taille : 1400 Mio
espace libre suivant : 28 Mio
L'opération commence et en moins d'une seconde se fige sur "vérification du système de fichiers". Pas de trace de parted dans dmesg ni dans /var/log/kern.log ni dans /var/log/syslog.

A2) Je recommence :

moi@xub-14.04:~$ gksudo gparted /dev/sda
The process gpartedbin is already running.
Only one gpartedbin process is permitted.
moi@xub-14.04:~$

dans top, gpartedbin occupe 100% d'un CPU.

moi@xub-14.04:~$ sudo killall gpartedbin
[sudo] password for : 
moi@xub-14.04:~$

A3) Je recommence :

moi@xub-14.04:~$ gksudo gparted /dev/sda
======================
libparted : 2.3
======================

selon gparted 0.18.0-1, la situation initiale :
sda1 en fat32
espace libre avant : 0 Mio
Taille : 1428 Mio
espace libre suivant : 0 Mio
- -
Je demande :
alignement sur les Mio
espace libre avant : 0 Mio
Taille : 1400 Mio
espace libre suivant : 28 Mio

Cette fois, la fenêtre de gparted se ferme instantanément, mais le retour du terminal est détaillé :

moi@xub-14.04:~$ gksudo gparted /dev/sda
======================
libparted : 2.3
======================

(gpartedbin:3109): GLib-CRITICAL **: Source ID 6 was not found when attempting to remove it
#  J'abrège : il y en a 45 lignes identiques, à part le n° d'ID.
(gpartedbin:3109): GLib-CRITICAL **: Source ID 2874 was not found when attempting to remove it
Segmentation fault
moi@xub-14.04:~$

- -

A4) Nouvel essai, en demandant juste de "vérifier" sda1 :

moi@xub-14.04:~$ gksudo gparted
======================
libparted : 2.3
======================

Cette fois, clic droit sur sda1 "Vérifier". Cela suscite la ligne "Vérifier et réparer le système de fichiers (fat32) sur /dev/sda1"
Je valide...
Et de nouveau gparted se fige et gpartedbin occupe, selon top, 100,2% des CPU.

dmesg | tail -22
(...)
[ 2998.082430] gpartedbin[3109]: segfault at 61687337 ip b692aa1e sp bf8cee60 error 6 in libc-2.19.so[b68b6000+1a8000]

sudo cat /var/log/kern.log | tail
Mar 25 10:47:57 xub-14.04 kernel: [ 2998.082430] gpartedbin[3109]: segfault at 61687337 ip b692aa1e sp bf8cee60 error 6 in libc-2.19.so[b68b6000+1a8000]
moi@xub-14.04:~$

sudo cat /var/log/syslog | tail
Mar 25 10:17:01 xub-14.04 CRON[3005]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Mar 25 10:47:57 xub-14.04 kernel: [ 2998.082430] gpartedbin[3109]: segfault at 61687337 ip b692aa1e sp bf8cee60 error 6 in libc-2.19.so[b68b6000+1a8000]
moi@xub-14.04:~$

Un "sudo killall gpartedbin" est encore nécessaire.

A5) Un passage par testdisk ayant montré que la seconde FAT était différente de la 1ère (qui fonctionne), je fais écraser par testdisk la 2nde FAT, remplacée par la 1ère. Puis je redémarre (c'est demandé par testdisk) et je recommence :

A5.1) "Redimensionner"

gksudo gparted /dev/sda
======================
libparted : 2.3
======================
# "Redimensionner"

(gpartedbin:2670): GLib-CRITICAL **: Source ID 6 was not found when attempting to remove it
# (...) 48 lignes ne différant que par le n° d'ID.
(gpartedbin:2670): GLib-CRITICAL **: Source ID 1843 was not found when attempting to remove it
*** Error in `/usr/sbin/gpartedbin': malloc(): corrupted unsorted chunks 2: 0x09e7c800 ***
Aborted
moi@xub-14.04:~$

- -
A5.2) "Vérifier"

gksudo gparted /dev/sda
======================
libparted : 2.3
======================

# "Vérifier" est suivi d'un gel immédiat de gparted.
De nouveau je dois tenter d'arrêter le processus dans le terminal par Ctrl C,
et de nouveau top montre qu'il continue de mobiliser 100% d'un CPU, de sorte que je dois faire un sudo killall gpartedbin pour l'arrêter réellement.

[center]- -[/center]

B) Echec même avec la version ancienne 0.12.1. Exemple:

GParted 0.12.1 --enable-libparted-dmraid

Libparted 2.3
Déplacer /dev/sdc5 vers la gauche et l'agrandir de 2.00 Gio à 2.00 Gio 00:00:09 ( ERREUR )

calibrer /dev/sdc5 00:00:00 ( SUCCÈS )
(...) taille : 4 192 902 (2.00 Gio)

vérifier le système de fichiers sur /dev/sdc5 et corriger les problèmes (si possible) 00:00:02 ( SUCCÈS )
dosfsck -a -w -v /dev/sdc5
dosfsck 3.0.13 (30 Jun 2012)
dosfsck 3.0.13, 30 Jun 2012, FAT32, LFN
Checking we can access the last sector of the filesystem
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
71:53/00, 72:57/00, 73:41/00, 74:50/00, 75:20/00, 76:20/00, 77:20/00
, 78:20/00, 79:20/00, 80:20/00, 81:20/00
Not automatically fixing this.
Boot sector contents:
System ID "*****"
Media byte 0xf8 (hard disk)
512 bytes per logical sector
2048 bytes per cluster
34 reserved sectors
First FAT starts at byte 17408 (sector 34)
2 FATs, 32 bit entries
4177408 bytes per FAT (= 8159 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 8372224 (sector 16352)
1044137 data clusters (2138392576 bytes)
63 sectors/track, 255 heads
113017338 hidden sectors
4192902 sectors total
Reclaiming unconnected clusters.
Checking free cluster summary.
/dev/sdc5: 7 files, 1027754/1044137 clusters

agrandit la partition de 2.00 Gio à 31.40 Gio 00:00:02 ( SUCCÈS )
ancien début : 113 017 338 ancienne fin : (...)
ancienne taille : 4 192 902 (2.00 Gio)
nouveau début : 51 353 600 nouvelle fin : [inchangée]
nouvelle taille : 65 856 640 (31.40 Gio)

déplacer le système de fichiers vers la gauche 00:00:02 ( ERREUR )
utilise libparted
annuler la dernière modification de la table des partitions 00:00:03 ( SUCCÈS )
réduit [de fait, restaure] la partition de 31.40 Gio à 2.00 Gio 00:00:03 ( SUCCÈS )
(...) ancienne taille : 65 856 640 (31.40 Gio)
(...) nouvelle taille : 4 192 902 (2.00 Gio)

messages de libparted ( INFO )
GNU Parted cannot resize this partition to this size. We're working on it!

[center]= = = = =[/center]

Conclusion :
Notons pour gparted 0.18.0-1 :
"segfault at 61687337 ip b692aa1e sp bf8cee60 error 6 in libc-2.19.so"
"Error in `/usr/sbin/gpartedbin': malloc(): corrupted unsorted chunks"
GLib-CRITICAL **: Source ID xxxx was not found when attempting to remove it
Ces 3 bugs sont répertoriés sur launchpad depuis des années...

Et en pratique, comme gparted ne sait plus traiter une FAT, on peut
- soit utiliser une version plus ancienne de gparted (ça marche, malgré un échec de dosfsck, avec gparted 0.2.5-2 de 2006; et ça marche avec qtparted 0.4.5-2 de 2005: C'est avec les vieux isos qu'on fait les meilleures galettes ! À noter: l'alignement sur les Mio ne sera pas proposé; mais ça tombe bien: l'alignement sur les cylindres fonctionne mieux pour les clefs de boot) ;
- soit passer par windows ;
- soit traiter la fat32 en ligne de commande, en espérant que les commandes n'utilisent pas de lib boguée comme la libc-2.19.so (test à réaliser) ;
- soit sauvegarder les éventuelles données sur un autre support, lancer la version boguée de gparted, supprimer la partition fat32, et la recréer aux caractéristiques souhaitées.

moko138

Bon, ça marche sans mot de passe après avoir refait la live comme ceci :

1) Nettoyage du disque rotatif avec dd.

2) Création, avec gparted v.0.18.0-1 de Trusty, d'une partition fat32, avec étiquette, directement à la taille de 5120 Mio / 5 Gio, avec alignement sur les cylindres.
Fermeture de gparted.

3) Lancement par le terminal de

gksudo usb-creator-gtk

v.0.2.56.3ubuntu0.1 et gravure de l'iso de Xubuntu 12.04.4 32 bits ; persistance minimale: 1 Gio; grâce à gksudo, on ne me demande pas de donner mon mot de passe à la fin de la gravure pour écrire grub.

À ma surprise, après gravure, la partition fait toujours 5 Gio (selon fdisk et selon parted).

4) Bien que le disque soit visible dans le gestionnaire de fichiers, je le débranche. Le rebranche.
Constat :

sudo parted -l
(...) Disque /dev/sdb : 120GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Numéro  Début   Fin     Taille  Type     Système de fichiers  Fanions
 1      32,3kB  5371MB  5371MB  primary  fat32                démarrage

Bien qu'en fat, sdb1 ne monte pas automatiquement, (invisible par mount et par df). Normal puisque j'ai ainsi réglé les préférences du gestionnaire de fichier.

5) Montage à la main (d'un clic, sans sudo).

6) "je supprime le fichier "casper-rw" (touches shift+suppr)."

7) Je démonte sdb1 et relance gparted (toujours en v.0.18.0).

8) Création de sdb2, en ext4 (puisque c'est un disque rotatif), alignée sur les cylindres, étiquette casper-rw,
espace précédent: 0 Mio,
nouvelle taille: 109.351,
espace libre suivant: 0 (demandé).
(À suivre : capture du résultat).
- -

Et donc le disque live démarre normalement, je mets deux fichiers sur le bureau et déplace un pannneau de contrôle.
Après redémarrage : toujours pas de demande de mot de passe, les fichiers du bureau et la modification du pannneau de contrôle sont toujours pris en compte. 🙂
= =

Reste à tester la partition de persistance
Elle apparaît comme casper-rw dans thunar, où elle semble impossible à monter, mais en réalité, elle est montée comme /cow dans df -h et fonctionnne : je viens d'y copier 5,9 G.

moko138

Depuis 12.04 installée, voici comment apparaît le disque live :

ls -l /media 
drwxr-xr-x 13 root root 4096 nov.  14 01:44 casper-rw  # ext4
drwx------ 11  moi  moi 4096 janv.  1  1970 XUB12044   # vfat

Et tout le contenu de

ls -l /media/casper-rw

soit : boot, cdrom, etc, home, lost+found, media, rofs, root, tmp, usr, var
appartient à root root.

Plutôt que de modifier ces propriétés, je vais tenter d'y créer un répertoire /Data-xyz/.
- -

Redémarrage sur la live

cd /
sudo mkdir DATA12044
sudo chown 999:1000 DATA12044

(999 étant le propriétaire par défaut, en live).
J'y mets un sous-répertoire avec 2 jpg ; seront-ils accessibles depuis la session installée ?
- -

Redémarrage sur la session installée
Les jpg sont accessibles et
DATA12044 se trouve dans /media/casper-rw et
DATA12044 appartient à "999 moi".

Pour pouvoir créer de nouveaux répertoires dans /media/casper-rw/DATA12044, je dois encore faire

sudo mkdir mp3

sudo chown -Rv 999:$USER /media/casper-rw/mp3

Par contre... je n'arrive pas à y copier de fichier !
Donc à suivre.

GR 34

moko138 a écrit

sudo mkdir mp3

sudo chown -Rv 999:$USER /media/casper-rw/mp3

Par contre... je n'arrive pas à y copier de fichier !
Donc à suivre.

Rhooooooooooooo...

Tu ne confondrais pas chown avec chmod ??????????

sudo chmod -vR 999:$USER /media/casper-rw/mp3

moko138

Toujours pas de solution entièrement graphique. Sinon c'était tout bête :

Depuis une Debian wheezy installée,
Un clic droit sur casper-rw > "Monter" (la wheezy fonctionne, pour les montages, comme les *buntu jusqu'à 12.04, c'est-à-dire directement dans /media, et non dans /media/user),

Ensuite je dois passer en ligne de commande et utiliser sudo :

sudo cp -v mon-fichier  /media/casper-rw/home/xubuntu/Desktop/
sudo chown 999:$USER "/media/casper-rw/home/xubuntu/Desktop/mon-fichier"

Et quand je démarre sur la live, mes ajouts sont accessibles :

ls -l /home/xubuntu/Desktop/mon-fichier
-rw-r--r--  1  xubuntu xubuntu  123456***   mars 4   06:04   /.../mon-fichier

(remarquer le changement automatique de groupe.)
À noter : Desktop (5737 Mio) est plus lourd que la partition racine (5,0 Gio).
- -

À suivre : Depuis une *buntu 14.04 installée

moko138

À la réflexion, je suis enclin à croire que l'erreur initiale avait été de faire, depuis un système installé, un chown sur tout /media/casper-rw, alors qu'aujourd'hui je n'ai fait le chown que sur un de ses sous-répertoires.