Newsgroup: it.comp.os.linux.iniziare
Titolo: Spazio disco incoerente (?)

Ciao,
da qualche giorno avviando il PC con Linux Mate 20.04.2 ho problemi con 
lo spazio disco. A parte i programmi già caricati non ho aggiunto molti 
documenti, eppure mi da rimanenti solo 2gb di spazio.
Ho fatto già una pulizia con apt autoremove e autoclean e poi con 
bleachbit (root). Inoltre ho avviato una live e controllato il disco con 
"dischi".  Allego immagine con i valori ottenuti, tramite caja:
 
https://ibb.co/898mpB5
 
 
Suggerimenti?
Grazie.


Eh, ma quel 'qualcosa di illeggibile' è normale? Magari hai il disco 
corrotto? Prova a fare un controllo disco (gsmartcontrol?).
 
Ciao!
-- 
Tilt


ma ti riferisci alla differenza fra lo spazio nominale dei file e quello effettivamente occupato sul disco?
quello è normale. ogni file ha bisogno intanto di spazio per i metadata (inode) inoltre può occupare un numero intero di blocchi. 
se ad esempio il block size è 4k, un file di un solo byte occuperà sul disco 4k.
 
 


 
 
-- 
bye
!(!1|1)
 


Installato ma non mi da particolari errori. C'è qualche procedura 
particolare per un controllo più approfondito?
 


Mi sembra comunque esagerata la differenza, ext3/ext4 possibile che 
siano così inefficienti? File system alternativo?


https://ibb.co/ccKsqxW
 
 
Suggerimenti?

Il 06/05/21 13:19, Hurricane ha scritto:

   Secondo me hai degli sparse file che stanno preallocando una grossa 
parte dello spazio disco.  Cercali, per essere sicuro.
 
 
   Ciao,
 
 
Alessandro
 

 Suggerimenti?
 
Così non è molto chiaro però.
Se il disco non ha problemi ti consiglio di prendere
jdiskreport
http://www.jgoodies.com/freeware/jdiskreport/
 
(vuole java)
che ti mostra anche la lista dei file più grandi che hai.
Per quello che ti serve non c'è miglior software credo.
 
bye
 
-- 
"S'io m'intuassi, come tu t'inmii." - Dante - Paradiso IX,81

 lo swap è su partizione o usi un file?
 
# swapon -s
Filename				Type		Size	Used Priority
/dev/sdc2                              	partition	8388604	0	-2
 
 


Intanto io posterei un bel output di:
 
df -h
 
Che non fa mai male...
Lanci, copi il testo, tutto, e lo incolli in risposta.


Cosa sono e come si cercano/eliminano?
Grazie.

 df -h
 
File system     Dim. Usati Dispon. Uso% Montato su
udev             16G     0     16G   0% /dev
tmpfs           3,2G  2,0M    3,2G   1% /run
/dev/sdc1        48G   44G    1,4G  98% /
tmpfs            16G  956K     16G   1% /dev/shm
tmpfs           5,0M  4,0K    5,0M   1% /run/lock
tmpfs            16G     0     16G   0% /sys/fs/cgroup
/dev/loop1       56M   56M       0 100% /snap/core18/1997
/dev/loop0      157M  157M       0 100% /snap/chromium/1193
/dev/loop2       65M   65M       0 100% /snap/gtk-common-themes/1514
/dev/loop4       63M   63M       0 100% /snap/gtk-common-themes/1506
/dev/loop6       56M   56M       0 100% /snap/core18/1988
/dev/loop3       33M   33M       0 100% /snap/snapd/11402
/dev/loop5       33M   33M       0 100% /snap/snapd/11588
/dev/loop7       16M   16M       0 100% /snap/ubuntu-mate-welcome/611
/dev/loop8       16M   16M       0 100% /snap/ubuntu-mate-welcome/617
/dev/loop9      128K  128K       0 100% /snap/software-boutique/54
/dev/sdc3       442G  398G     45G  90% /media/tukij/KB-SSD-HD
/dev/sdc4       427G  373G     33G  92% /media/tukij/KB-PRG-HD
tmpfs           3,2G   44K    3,2G   1% /run/user/1000
 
 

 /dev/sdc1 48G 44G 1,4G 98% / 
 
forse è meglio se fai una 'du -h -d1 /' e poi esplorare via via i percorsi.


Bene, ora prova a dare:
 
du -xsh /* 2>/dev/null|sort -h
 
Stessa cosa di prima: copi e incolli in risposta...


Dimenticavo...
Il comando sopra lancialo da root.
 
su -
---> password root
ecc ecc
 
oppure:
 
sudo su -
---> password utente
e via

 du -xsh /* 2>/dev/null|sort -h
 
# du -xsh /* 2>/dev/null|sort -h
0	/bin
0	/Collegamento a archives
0	/dev
0	/lib
0	/lib32
0	/lib64
0	/libx32
0	/proc
0	/sbin
0	/sys
4,0K	/cdrom
4,0K	/mnt
4,0K	/srv
16K	/lost+found
36K	/snap
56K	/media
700K	/tmp
2,0M	/run
16M	/etc
222M	/opt
227M	/boot
1,8G	/var
8,6G	/usr
9,4G	/home
23G	/root
 

 du -h -d1 /
 
# du -h -d1 /
16K	/lost+found
227M	/boot
16M	/etc
du: impossibile accedere a '/proc/35547/task/35547/fd/3': File o 
directory non esistente
du: impossibile accedere a '/proc/35547/task/35547/fdinfo/3': File o 
directory non esistente
du: impossibile accedere a '/proc/35547/fd/4': File o directory non 
esistente
du: impossibile accedere a '/proc/35547/fdinfo/4': File o directory non 
esistente
0	/proc
4,0K	/srv
222M	/opt
9,4G	/home
du: impossibile accedere a '/run/user/1000/gvfs': Permesso negato
2,0M	/run
0	/sys
925G	/media
0	/dev
4,0K	/cdrom
23G	/root
8,6G	/usr
700K	/tmp
4,0K	/mnt
1,8G	/snap
8,0K	/.sblivesystemwrite
1,8G	/var
970G	/
 
Cosa dovre capire o modificare dopo aver dato questo comando?


Ottimo...
Come vedi su 48 GB o quanto erano, quasi la metà del malloppo sta nella
dir "/root"...
 
Ecco perché non si vedeva dalla torta di Fileflight, ed ecco perché
marcava 20 GB totali per la root "/" invece di 48 GB, probabilmente
avendo permessi di utente semplice non riusciva a scansionare la dir
"/root".
 
Cosa ci sarà dentro "/root" di così ingombrante da occupare 20 GB ??
 
Io inizierei a cercare lì dentro, come hai già fatto adesso, sempre
da utente root ovviamente...
 
du -xsh /root/* 2>/dev/null | sort -h
 
Occhio però, tu ora sai che la "cartella" /root contiene 23GB di roba,
col comando sopra scandaglierai SOLO le sottocartelle ottenendo quanto
pesa ogni sotto-cartella, ma potrebbe esserci un file grosso
direttamente nella cartella, del tipo:
 
/root/sono-bello-grosso-e-du-non-mi-vede.qualcosa
 
du non lo vedrà quel file, perché va a controllare solo il peso delle
sottocartelle, però non sarà difficile fare la differenza delle
dimensioni.
 
Dopo aver lanciato du come sopra, se vuoi andare a neuroni spenti
(mai una buona idea...) puoi usare il comando "find".
Se serve ti giro il comando preciso, ma una sana googolata a questo
punto non farebbe neanche male.
 
O volendo c'è anche un tool tipo ncdu (dovrai installarlo credo):
 
ncdu /root
 
lancialo sempre come root per i soliti problemi di permessi a scendere
in percorsi "preclusi" all'utente semplice proprio come /root.

 23G /root
 
hai 23g nella /root, che è la home di root e non contiene file utili al sistema.
indaga li dentro, l'avrai usata come appoggio o forse c'è qualche altra roba che ti sei dimenticato di avere.


Se non avesse detto di aver usato i tool di autoremove
sarei quasi sicuro che ha parecchi GB di vecchi kernel...


 sarei quasi sicuro che ha parecchi GB di vecchi kernel...
 
Imho c'ha delle immagini.. 23 giga son 23 giga mica pizza e fichi ciao
 
-- 
Yoda
 

 dimensioni.
 
Scusa pero' anche un semplicissimo "ls -la -R /root/" potrebbe dire
nolte cose ciao
(dato da root o con sudo, dico per Hurricane)
 
-- 
Yoda
 


Chissà, ad ogni modo con du e find o più speditivamente:
 
ncdu /root
 
Cosa c'è si vede.
Trepidiamo per sapere quale fosse l'arcano ingombrante...
 
Io in root tengo una subdir "build" in cui compilo alcuni
programmi a mano. E in effetti alla lunga anche quel poco
va a far volume, tempo fa avevo dovuto tirare una riga e
spostare il tutto in un disco esterno, ora lì ho sui 5GB
di roba.
 
Tra i più ingomranti vedo che c'è scribus, il kernel linux,
e l'immancabile ffmpeg, ho anche lì l'installer di
VMware-Workstation ".bundle", i driver nvidia e altra roba
che mi sembra meno invadente...
Però nel caso dell'OP, si ricorderebbe di una directory del
genere, io anche se non ricordavo troppo bene cosa ci fosse
dentro, sapevo di averla predisposta e che la possibilità che
lieviti nel tempo c'è.

Il 07/05/21 11:49, Hurricane ha scritto:

https://it.wikipedia.org/wiki/File_sparso
 
 
   Non sono distinguibili dai file regolari. Infatti è un meccanismo 
di 
preallocazione che sui filesystem supportati è usato per tutti i file.
 
   Si notano quando hai, ad esempio, due file da 300GB su un filesystem 
da 500GB ma il filesystem non è totalmente pieno, oppure quando su un 
filesystem da 10GB hai un file da 8GB ma ne puoi creare un altro da 2,5GB.
 
   I blocchi dati sul filesystem sono occupati solamente quando arrivano 
i veri dati da scrivere, altrimenti sono soltanto, in un certo senso, 
prenotati, ma non veramente associati al file.
 
   In questi casi è frequente avere delle forti discrepanze sui dati 
di 
occupazione del disco forniti dai vari strumenti di misura, perché 
alcuni contano la dimensione dichiarata dei file, mentre altri quella 
realmente allocata e usata.
 
 
   Ciao,
 
 
Alessandro
 

 lieviti nel tempo c'è.
 
-- 
Yoda
 


L'opzione -R non serve dato che si è usato prima "du", poi se i files
sono tanti, andare a cercare quelli grossi (perché interessano solo
quelli probabilmente... sì ci potrebbero essere anche tantissimi files
piccoli che arrivano a fare 20 GB, ma in prima battuta lo escluderei,
poi comunque si vede per esclusione: se non c'è un file grosso... ce ne
saranno tanti piccoli...).
 
Togliendo l'opzione -R metti a fuoco solo la dir /root, escludendo le
subdir (sempre perché le vedi già da "du -sh").
 
A quel punto ok, ls -la è utile. Ma non così comodo per trovare i file
grandi, a quel punto meglio lanciare:
 
ls -lahS |less
 
Così l'output è già ordinato con i file più grandi in cima e non devi
ravanare a cercare quelli più grossi manualmente, poi la redirezione
dell'output in pipe su less ti consente di dare un'occhiata a tutto
l'output, che se i files sono tanti, quelli in cima si perdono nel
terminale...
 
Infine, c'è il discorso di du, che usato senza la "-s" (summarize),
mostra anche i files:
 
du -h . 2>/dev/null |sort -rh|less
 
però per conto mi fa un po' di casino perché considera sia le cartelle
che i files...
 
Il meglio è:
 
ncdu
 
Output pulito, a colpo d'occhio capisci subito qual è la cartella
più ingombrante e considera anche i files della dir corrente. Non
considera invece quelli delle sottodirectories. Che per lo scopo
è la cosa più sensata per avere un colpo d'occhio più pulito.
Inoltre la schermata di output pur essendo testuale è navigabile
con le freccine:
se vedo una dir grossa mi ci sposto sopra con su/giù e ci entro
con dx, la schermata a quel punto mostra l'interno della dir grossa,
con subdir e files ordinati per dimensione dal più grande...
Mi sembra un tool molto valido per lo scopo.

 Suggerimenti?
 
Oltre ai consigli che ti hanno dato, dai un occhio a /var/log/journal.
 


Confermo ncdu è il tool giusto!
Ho trovato una directory Trash, nella root, di circa 24gb che conteneva 
l'impossibile. Eliminata. Ora ho 26gb liberi!
Grazie a tutti!
 
https://ibb.co/vsdPRMf
 
https://ibb.co/jz4WWdW
 

 Grazie a tutti! 
 
uhm, quindi si desumono due cose:
- usi l'interfaccia grafica come root (male!)
- bastava svuotare il cestino :-)
 


No, non è così. Ho fatto varie pulizie e svuotamenti di cestino. se 
linux non lo fa non è colpa mia.
Che c'entra l'interfaccia grafica usata come root? Come la cancellavo la 
directory in oggetto?
Male perché?


Ci sono circa 300mb di file. Li posso cancellare?

 Male perché?
 
perché non è una buona prassi. avvii tutti i programmi come super user che non è proprio igienico.
poi per carità, non è mica vietato e ci può essere anche l'esigenza. però è meglio ovviare puntualmente con gksu.
 
 


Sì ricordo anch'io quell'aspetto.
Bisognerebbe anche capire le motivazioni di sicurezza che spingono
ad utilizzare una dir dell'utente. Non si sa mai, mi dirai, ma alla
fine in tanti casi può essere uno scrupolo non molto utile.
 
Di recente ho dovuto compilare a mano il kernel e non ricordo più bene
ma di certo non l'ho fatto a mano.
 
Mi sono tirato giù la dir del kernel di slackware-current nonostante
io abbia la 14.2, poi da lì dentro mi sono creato i pacchetti del
kernel, modulli, firmware, headers sorgenti e tutto. Volendo c'è anche
lo script bash per automatizzare l'operazione...
 
-------
/root/build/k
├── build-all-kernels.sh
├── kernel-configs
│   ├── config-generic-5.10.4
│   ├── config-generic-5.10.4.x64
│   ├── config-generic-smp-5.10.4-smp
│   ├── config-huge-5.10.4
│   ├── config-huge-5.10.4.x64
│   └── config-huge-smp-5.10.4-smp
├── kernel-firmware
│   ├── kernel-firmware.SlackBuild
│   └── slack-desc
├── kernel-generic.SlackBuild
├── kernel-headers.SlackBuild
├── kernel-modules.SlackBuild
├── kernel-source.SlackBuild
├── linux-5.10.4.tar.sign
├── linux-5.10.4.tar.xz
├── slack-desc
│   ├── slack-desc.kernel-generic-smp.i686
│   ├── slack-desc.kernel-generic.i586
│   ├── slack-desc.kernel-generic.x86_64
│   ├── slack-desc.kernel-headers
│   ├── slack-desc.kernel-huge-smp.i686
│   ├── slack-desc.kernel-huge.i586
│   ├── slack-desc.kernel-huge.x86_64
│   ├── slack-desc.kernel-modules-template
│   ├── slack-desc.kernel-source
│   ├── slack-desc.kernel-source.vanilla
│   └── slack-desc.kernel-template
└── usr
    └── src
 
5 directories, 26 files
-----------------------
 
Alla fine ottengo i pacchetti in /tmp:
---------------------
ls -1 /tmp/kernel-*5*
/tmp/kernel-firmware-20201230_f580dc2-noarch-1.txz
/tmp/kernel-generic-5.10.4-x86_64-1.txz
/tmp/kernel-headers-5.10.4-x86-1.txz
/tmp/kernel-modules-5.10.4-x86_64-1.txz
/tmp/kernel-source-5.10.4-noarch-1.txz
--------------------------------------
 
L'avevo fatto per via di libvirt / qemu, che si appoggiava ad un modulo
buggato nella versione del kernel della salck 14.2...
Così ho risolto.
 
Per la velocità non ti so dire, secondo me, così a naso
conviene mettere hardware più veloce, si fà prima e funziona
davvero!  ;D
 
Scherzi a parte, può darsi che configurare il kernel per questioni
di velocità fosse una pratica che portasse a qualche evidenza su
hardware molto datato anni e anni fa. Però non ti so dire sinceramente.
 
Ti posso dire che se passi da KDE ad un WM come "dwm" allora sì,
ti sembra di volare. Dico sembra perché poi i programmoni pesanti
restano sempre tali, ma sì, un po' meno tutto sommato.

 hardware molto datato anni e anni fa. Però non ti so dire sinceramente. 
 
mah io ho sempre pensato che, a meno di avere hw particolari o esigenze particolari, compilare un kernel custom per cercare le performance fosse un esercizio abbastanza inutile.
un tempo c'era più discrezionalità fra avere moduli dinamici o compilati staticamente, ma sin dal 2.6 è una questione di lana caprina.

 programmi a mano. E in effetti alla lunga anche quel poco
 
Per quello scopo si usa /usr/src e
magari *non* l'utente root.
Oppure si compila proprio nella home
dell'utente "builder".
 
Insomma, lanciare un "make" oppure
un "./configure" da root sembra
alquanto pericoloso.
 
bye,
 
-- 
 
piergiorgio


Sarà ma sembra anche parte ad esempio della guida all'installazione
del software attraverso gli slackbuilds del repo SBo, che rappresenta
la community credo più nutrita di "mantenitori" di pacchetti per
slackware extra ufficiali.
 
https://slackbuilds.org/howto/
 
 
In particolare:
 
Step 4 - Execute the SlackBuild Script (as root)
 
 
 
Francamente non vedo grossi problemi a meno che in uno script non ci sia
un "rm -r" che vada ad agire su qualcosa contentente "/".
 
Ma lanciare un make da root a cosa dovrebbe portare di pericoloso?
O un configure?
 
Sì, sono script e potenzialmente fanno cose, e se non si controlla
cosa fanno di preciso potrebbe essere rischioso lanciarli come root
perché quel qualcosa lo farebbero con tutti i permessi e i privilegi
di amministratore... Potenzialmente è come regalare uno Zippo a Nerone.
 
Ma in teoria.
 
In pratica se io prendo un programma conosciuto, aperto, su cui hanno
già smanettato mille persone, difficilmente incapperò in un configure
o in un make che fa cose strane e pericolose.
 
Per contro sovente può capitare che lanciando uno script di compilazione
da utente semplice, per un motivo o per l'altro siano richiesti permessi
di root, e a quel punto devi loggarti come root e rilanciare il
configure, make ecc o lo script di compilazione.

 configure, make ecc o lo script di compilazione.
 
Non e` affatto vero, non scriviamo cose
"poco" vere (per non dire "molto" false).
Se questo succede, vi sono altri, grossi,
problemi.
Ci sono persino build system che si
*rifiutano* di funzionare da root.
 
Non esiste *nessuna* ragione per cui un
programma dovrebbe essere compilato da root.
 
Solo l'installer richiede root, ovviamente.
 
Mai visto un programma che richieda i permessi
di root per essere compilato.
 
bye,
 
-- 
 
piergiorgio


Ad esempio ci sono programmi che richiedono la creazione
di un utente particolare in fase di prebuild e per farlo
serve root.
Poi è vero che la maggior parte delle necessità si hanno
in fase di installazione come permessi però tanto per fare
un esempio ci sta anche quel caso.

 un esempio ci sta anche quel caso.
 
Anche se fosse, cosa di cui dubito,
lo si fa solo ed esclusivamente per
quel caso e solo per la creazione
dell'utente.
 
Tutto il resto lo si fa come utente
normale, senza permessi particolari.
 
Dato che costa lo stesso ed e` piu`
sicuro, non vedo perche` non farlo.
 
bye,
 
-- 
 
piergiorgio


Architecture: amd64
Depends: libfakeroot (>= 1.23-1), libc6 (>= 2.15)
Description-it: strumento per simulare i privilegi di superutente
 fakeroot fornisce un falso "ambiente root" usando trucchetti LD_PRELOAD e
 SysV IPC (o TCP). Mette wrapper intorno a getuid(), chown(), stat() e altre
 funzioni di manipolazione di file, in modo che gli utenti non privilegiati
 possano, ad esempio, popolare archivi .deb con file il cui proprietario è
 root; svariati strumenti di compilazione utilizzano fakeroot per questo
 compito in modo predefinito.
 .
 Questo pacchetto contiene il comando fakeroot e il demone che si ricorda i
 falsi proprietari/permessi dei file manipolati dai processi fakeroot.
Description-md5: db2730aa4872dbe27ff20c4aad3c5429
Multi-Arch: foreign
Tag: devel::lang:perl, devel::library, devel::packaging, implemented-in::c,
 implemented-in::perl, implemented-in::shell, interface::commandline,
 role::devel-lib, role::program, role::shared-lib, scope::utility,
 suite::debian
Section: utils
Priority: optional
Filename: pool/main/f/fakeroot/fakeroot_1.23-1_amd64.deb
Size: 85824
MD5sum: cafcde66c012b6100b8834de221d8ad0
SHA256: e671d4fbf01230393897f3dc8a5b5699905431f1fff914320e82ba829a9420ad
-cite-
 
-- 
Yoda
 

 Debian ha fatto fakeroot.. eccolo se volete dargli un'occhiata ciao
 
"fakeroot" c'e`, ovviamente, anche su Fedora... :-)
 
bye,
 
-- 
 
piergiorgio

 Ci sono circa 300mb di file. Li posso cancellare?
 
Si', ma tipicamente li fai cancellare da systemd. Almeno sulla mia 
distro, editi il file /etc/systemd/journald.conf e vai a decommentare la 
riga SystemMaxUse. Io per esempio lascio 200 mb per i file:
 
SystemMaxUse=100M
 
Tieni conto che sono due giorni che lo uso, che ebbi pochi giorni fa il 
problema di trovare questa directory strapiena, oltre 13 giga, e quindi 
non so se in certi casi non funzioni, comunque sembra ok.
 
https://unix.stackexchange.com/questions/139513/how-to-clear-journalctl
 


A memoria non lo uso così spesso caja come root... Sarà anche un 
problema di percezione. Ma bleachbit l'ho usato sicuramente come root ma 
il cestino, selezionato, evidentemente lo ha ignorato. E' un bug del 
programma?

 Ma bleachbit l'ho usato sicuramente come root
 
Ecco il bug!
No! Quella roba si usa come utente semplice. Vedo che va a ripulire
cache di programmi come browsers e altro... Ma il browser non lo usi
come root, non lo devi usare come root, assolutamente. L'utente root
serve per poche cose, come l'installazione di programmi, l'aggiornamento
di sistema, la configurazione di script di avvio o altri pezzi di
sistema che richiedono i privilegi di amministrazione.
 
Per tutte le altre operazioni usa l'utente semplice.
 
Quindi a prescindere dai bug di quel programma, quello vero di bug è
lanciarlo come root.

 l'esigenza. però è meglio ovviare puntualmente con gksu.
 
Vorrei aggiungere che di default in Ubuntu il super user non esiste.
Anche se 'non è mica vietato crearlo', a mio avviso per chi si è
avvicinato da poco ad Ubuntu e/o lo conosce poco, vale la pena, perché
si scoprirà che è proficuo farlo, cercare di adattarsi alle
particolarità del sistema prima di avventurarsi in personalizzazioni
spinte.
 
Io penso che in questo thread il problema di base ruota attorno all'uso
del terminale e sulla ritrosia ad usarlo ...
 
C'è chi si chiede perché usare approcci di 50 anni fa quando ora
esistono gli ambienti grafici e c'è chi, non conoscendo il terminale,
persa sia scomodo e molto lento da usare a causa della digitazione.
 
In realtà dopo un breve periodo di ambientamento si scopre quanto sia
rapido ed esente da errori digitare nel terminale avvalendosi delle
combinazioni di tasti rapidi, del tasto Tab per il completamento
automatico dei percorsi dei file, e come sia facile tramite la history
dei comandi (↑↓) richiamare le istruzioni che erano state digitate
precedentemente senza doverle riscrivere, oppure ricercare
ricorsivamente comandi già digitati prima premendo più volte [Ctrl]+R. 
 
La riga di comando del terminale è tuttora lo strumento più potente a
disposizione dell'amministaratore del sistema e vale sempre la pena
perdere un po' di tempo per conoscela scoprendo così la sua versatilità
e anche quanto dialoghi utilmente con l'utente.
 
In Ubuntu l'amministratore, root, non esiste ma l'utente può acquisire i
privilegi del super user anteponendo 'sudo' ai comandi. Volendo
mantenere più a lungo questi super poteri l'utente può usare il comando
'sudo -i'. ('exit' per terminare.)
 
L'uso del Terminale richiede comunque uno sforzo iniziale di
apprendimento e questo potrebbe rivelarsi uno scoglio insormontabile per
gli intelletti pigri ...
 
'gksu' su Ubuntu 20.04, questa è la distro del thread, non è disponibile
(deprecato da tempo). 
Al suo posto nel file manager si può usare 'admin://' per acquisire i
diritti di amministratore.
 
Esempio: volendo modificare il file /etc/apt/sources.list lo si può
aprire come root dando nel terminale il comando
 
$ sudo gedit /etc/apt/sources.list
 
oppure lanciare il file manager Nautilus (con Caja non so ...), premere
[Ctrl]+L e digitare nella barra dei percorsi che compare
 
admin:///etc/apt/
 
A quel punto, previa password, si potrà cliccare sul file 'sources.list'
appena apparso e l'editor di testo lo aprirà come amministratore di
sistema, quindi il file non sarà solo leggibile ma sarà possibile anche
modificarlo e salvarlo.
 

 Ma in teoria. 
 
in generale, è lo sviluppatore che ti dice cosa lanciare come superuser e cosa no. solitamente solo il "make install" ha bisogno di sudo ed è lì che solitamente si concentrano le operazioni che richiedono privilegi.
lanciare script come superuser quando le istruzioni dicono di farlo con utente normale non è sensatissimo, ecco.
poi se la build lo richiede è un altro discorso.
 
 
 

 $ sudo gedit /etc/apt/sources.list
 
Forse meglio utilizzare pkexec
 
$ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit /etc/apt/sources.list
 
 
https://qastack.it/ubuntu/287845/how-to-configure-pkexec
 
 


Sì il problema è che la build non cade dalle nuvole così, tanto per...
ma è pensata per adattare la pacchettizzazione del software e la
successiva installazione all'ambiente in cui dovrà essere installato
e in cui il programma si troverà a lavorare.
È proprio per questo che la teoria e la pratica vanno un attimo fatte
dialogare. Se tu prendi un software e dai il classico vecchio configure
make e make install, non sempre (anzi quasi mai) otterrai
un'installazione ordinata e aderente alla tua distribuzione.
 
Io ho fatto l'esempio del repo SBo di Slackware, in quanto lì il tema è
piuttosto sentito (slackware non è debian, e il parco software ufficiale
che mette a disposizione è di gran lunga meno ricco, così assume una
certa rilevanza il repository esterno SBo in cui si trova "la ricetta"
per costruirsi i pacchetti non inclusi nel parco software ufficiale. Il
tutto è gestibile facilmente con diversi tool, io uso "sbopkg" più
qualche altro alias/script, sbover per vedere la versione del software
e sboreq per vedere quali altre dipendenze richiede, oppure sqg che crea
la coda di dipendenze già pronta).
Ebbbene, questo repo contiene appunto gli slackbuilds che sono degli
script bash che prendono i sorgenti spacchettano danno i permessi ai
files contenuti, secondo quanto è conveniente all'ambiente slackware,
settano alcune variabili tipo "PREFIX", anche qui adattando l'installazione
dei vari files nelle directories previste da slackware, "DESTDIR" in modo
da non installare il programma ma da buttare tutto in una cartella di
pacchettizzazione, poi si controlla i permessi dei files e la proprietà,
ed ecco che serve root, per chown e chmod, poi si aggiunge un file dscrittivo,
slack-desc, un eventuale script doinst.sh che si occupa di fare eventuali
cose in più, come ad esempio la creazione di un utente richiesto da certi
softwares viene messa in doisnt.sh o creare certi links ecc ecc...
E infine crea il pacchetto di installazione tgz, txz o quel che si vuole.
Gli script di build credo siano sottoposti al testing e quindi
pubblicati su SBo...
 
Poi i bug possono sempre esserci per carità. Personalmente però devo
dire di non aver mai trovato grossi problemi, almeno non relativi alla
sicurezza. Qualche volta ho segnalato qualche miglioria ad esempio sui
pacchetti per i driver nvidia, ma non succedeva granché, saltava fuori
solo un errore, correggibile anche a mano ex post.
 
Comunque dicevo, la questione del build da root è sentita anche lì e
questo si legge anche nella FAQ:
 
https://slackbuilds.org/faq/#root
 
------------------------------------
Do I have to run the script as root?
 
    Well, yes and no. The package must be built as root in order for the
    ownership and permissions to be set correctly (any usage of the
    chown command inside the script will fail otherwise), but you can
    certainly test a script by running it as a normal user. You might
    consider temporarily commenting any chown lines in the script if
    you're trying to test it as a normal user.
 
    Don't bother whining about "security issues" or such from
    building as root. If you don't trust us to check the scripts for
    malicious activity, then please move along.
-----------------------------------------------
 
Quindi puoi usare i builds anche da utente semplice, ma li devi
un'attimo modificare e non è garantito che funzionino, infatti si parla
di "testare"...
 
Non è la Bibbia, altre distribuzioni con sistemi simili tipo i pkgbuild
di Arch che si trovano su AUR mi pare girino da utente semplice, poi una
volta creato il pacchetto si installano con pacman, ovviamente da root.

 Vorrei aggiungere che di default in Ubuntu il super user non esiste.
 
   Si, esiste, non può funzionare Linux senza utente(0).
   Però ha il login disabilitato.
 
 
Alessandro