[Silvan]

Le istruzioni si riferiscono a come scompattare l’archivio rootfs su una SD card. Tuttavia non è sufficiente inserire la SD card e avviare come se fosse un PC ma sul tablet in oggetto occorre effettuare altre operazioni, come l’installazione del kernel (quello da utilizzare si dovrebbe trovare nella cartella /boot di rootfs).

In concomitanza con il rilascio della versione 2.0.10 dell’archivio sdk (che avverrà dopo il rilascio delle versioni livecd-light e livecd-gnome di cui mi sto occupando adesso) tornerò a fare dei test su questi dispositivi e spero di riuscire a scrivere delle minime note specifiche per ogni tipo di dispositivo che è stato testato.

[Silvan]

Ciao. La finestra di partizionamento mostra le dimensioni minime consigliate per le partizioni di sistema e swap. Quando entrambi i tipi di partizione esistono ed hanno una dimensione corretta si legge OK per il sistema e OK per lo swap. Nel tuo caso suppongo che avessi OK per il sistema per le partizioni home e root ma non OK per lo swap perchè la dimensione della partizione di swap era inferiore alla dimensione minima indicata. La dimensione minima è un valore raccomandato ma non strettamente obbligatorio, per questo motivo c’è il flag “Ignora il controllo sulla partizione swap”. Questo è il modo in cui è inteso il funzionamento, se invece la tua partizione di swap era più grande della dimensione raccomandata allora c’è un bug. Grazie per aver testato openmamba ed aver riportato qui questo eventuale problema.

(Translation: Hi. The partitioning dialog will print the suggested minimum sizes for system and swap partitions. When both types of partitions exist and have correct size you will read OK for system and OK for swap. In your case I suppose you got OK for system for both the home and root partitions, but you didn’t have OK for swap because the size of the swap partition was less than the suggested size. Swap minimum size is a recommendation but not a strict requirement, so this is why the “Ignore swap partition check” checkbox exists. This is the way it works, if your swap partition was bigger than the suggested size then it’s a bug. Thank you for reviewing openmamba and reporting this possible bug.)

[Silvan]

Anche a me dava quell’errore, forse perchè avevo la ISO di openmamba impostata come ‘live cd’. Dopo aver risposto ‘Forza la rimozione’ ho fatto lo shutdown della macchina virtuale ed ho controllato le impostazioni ed ho visto che aveva comunque sostituito la iso di openmamba con VBoxGuestAdditions.iso (altrimenti l’avrei fatto io a mano e a macchina spenta). Quindi ho riavviato la macchina virtuale ed ha funzionato.

[Silvan]

Anche a me dava quell’errore, forse perchè avevo la ISO di openmamba impostata come ‘live cd’. Dopo aver risposto ‘Forza la rimozione’ ho fatto lo shutdown della macchina virtuale ed ho controllato le impostazioni ed ho visto che aveva comunque sostituito la iso di openmamba con VBoxGuestAdditions.iso (altrimenti l’avrei fatto io a mano e a macchina spenta). Quindi ho riavviato la macchina virtuale ed ha funzionato.

[Silvan]

Ho fatto una prova con successo che descrivo di seguito. Da quanto scrivi i permessi sono giusti e quindi dovresti avere l’accesso alla cartella, a questo punto mi viene solo da pensare di verificare che la cartella dell’host che hai condiviso non sia vuota e sia effettivamente quella che ti aspetti.

Prova effettuata: su computer con openmamba e VirtualBox ho creato una macchina virtuale con openmamba ed ho fatto l’installazione. A sistema installato e avviato ho fatto ‘Installa Guest Additions…’ e lanciato lo script autorun.sh (richiede che sia installato kernel-mamba-headers). Ho messo il mio utente nel gruppo vboxsf come spiegato sopra, poi su ‘Dispositivi’ -> ‘Cartelle condivise…’ della macchina virtuale ho condiviso la cartella /tmp del mio host. Al riavvio vado su /media/sf_tmp e mi trovo dentro come atteso i file di /tmp e se faccio delle modifiche le vedo su entrambi i sistemi. La share viene montata automaticamente all’avvio della macchina virtuale:

[silvan@openmamba ~]$ mount

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

devtmpfs on /dev type devtmpfs (rw,nosuid,relatime,size=374204k,nr_inodes=93551,mode=755)

devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=4,mode=620)

tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)

/dev/sda2 on / type ext4 (rw,commit=0)

tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)

usbfs on /proc/bus/usb type usbfs (rw,devgid=30,devmode=664)

none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

none on /sys/fs/fuse/connections type fusectl (rw)

openmamba on /media/sf_openmamba type vboxsf (gid=1000,rw)

tmp on /media/sf_tmp type vboxsf (gid=1000,rw)

[Silvan]

Ci sono dispositivi esterni USB collegati quando si verificano i riavvii? O capita (anche) senza?

[Silvan]

Questo è perchè il pacchetto è presente nel ramo di sviluppo ma non su milestone2. Adesso l’ho importato in milestone2-updates e dovrebbe essere disponibile nel giro di un’ora.

[Silvan]

Il pacchetto indicato è un pacchetto sorgente, che probabilmente non è ciò che desideri. Non riscontro problemi ad installare il pacchetto “binario” nel modo canonico, ovvero con:

sudo smart install python-poppler

oppure

pkcon install python-poppler

oppure dall’interfaccia grafica di kpackagekit.

[Silvan]

Anch’io ho notato il problema su un macbook pro, avviato da chiavetta capita dopo qualche decina di minuti, sul sistema installato invece il problema pare non capitare almeno nel tempo di qualche ora, fino a ieri pensavo fosse dovuto a unionfs ma a quanto pare no. I riavvii potrebbero anche essere causati da un driver che rileva che qualche sensore è oltre la temperatura critica ma non mi sembra neanche questo il problema in questo caso. Sto continuando a monitorare il problema, nel frattempo se qualcuno ha elementi in più può tornare utile.

[Silvan]

*crash di kuser: devo verificare (sicuramente un bug fino a kde 4.6, forse 4.7, io ora sto usando il 4.8 e va)

Il comando usermod se non restituisce alcun output significa che ha avuto successo. Se invece ‘non accade nulla’ si riferisce al fatto che la cartella in questione continua a non essere visibile allora devo fare un riepilogo per capire dove ci siamo persi, e comincerei dall’output del comando:

groups

(mi aspetto che compaia il gruppo vboxsf)

e di:

ls -l /media

(mi aspetto che siano impostati i permessi per il gruppo vboxsf come postato precedentemente)

[Silvan]

Da quanto riporti, il gruppo si chiama ‘vboxsf’. Hai provato ad aggiungere l’utente con cui gira il desktop a questo gruppo?

Usando kuser di KDE oppure con il comando:

sudo usermod liveuser -A vboxsf

(liveuser se usi un sistema live, altrimenti lo sostituisci con il tuo nome utente)

[Silvan]

Il meccanismo su openmamba non è testato, ma ho letto delle informazioni qui: http://www.howtogeek.com/75705/access-shared-folders-in-a-virtualbox-ubuntu-11.04-virtual-machine/ relativamente al settaggio dei permessi.

La cartella /media/sf_Virtual_Openmamba in openmamba che permessi, utente e gruppo ha?

[Silvan]

The attached screenshot is the installer page for selecting non-linux (windows) partitions. All choices are preselected, so this can be the problem only if you unselected them by your choice. In this case anyway you shouldn't have got the Windows boot option and thus fall into the boot.mngr error, so I don't think this is the problem. If you would like to proceed with further testing, you may install openmamba again, and then we can try to detect and fix the problem from there.

[attachment=5235,174]

[Silvan]

So after installing openmamba you had the Windows choice but selecting it originated a “boot.mngr missing” message? If you (left) selected Windows as a boot choice during the installation it is not your fault. After openmamba (re)installation I would check that Windows partition is set as bootable. Other problems might depend on having more that one disk, but I don’t know if this is the case. In any case a copy and paste of the installation log might help us to understand the problem. Also I will test again dual-boot installation to be sure that this is not a general regression of this release.

[Silvan]

Dal report quello che non mi torna è il fatto che risultino effettuati gli aggiornamenti ma che sia ancora installato il vecchio kernel 3.2.11. Non viene proposto un aggiornamento all’ultima versione, ovvero kernel-mamba-3.2.21?

Poi vedo che c’è il crash di kded4 e ksmserver all’avvio ma non ho ulteriori informazioni, sarebbe utile il backtrace generato dopo aver installato ‘gdb’ (sarebbe da inviare via email sempre all’indirizzo di sopra) e se possibile anche il file .xession-errors nella home dell’utente che effettua il login in KDE.

Per assicurarmi che non manchino dei componenti fondamentali, proverei a dare i seguenti comandi:

sudo smart install desktop-base-kde4

sudo openmamba-update base

[Autore]

Articoli