Newsgroup: it.comp.os.linux.iniziare
Titolo: sda vs sdb

Ogni tanto "smanetto" col router (anche se il comportamento che sto per 
descrivere mi è capitato anche sul pc).
Perché quando connetto una pendrive alla porta usb qualche volta il s.o. 
me la vede come sda e altre volte come sdb?


la mappa come sdb quando sda è già occupato.


root@OpenWrt:~# ls -l /dev/sd*
brw-------    1 root     root        8,  16 Jun 19 12:12 /dev/sdb
brw-------    1 root     root        8,  17 Jun 19 12:12 /dev/sdb1
 
Io non vedo nessun sda.


Il che non esclude che in precedenza sda sia stato occupato.
Però... sono sicuro che sda e sdb non siano stati presenti insieme. 
Forse quando c'è stato sda, anche se poi espulso, il s.o. passa a sdb?

 Forse quando c'è stato sda, anche se poi espulso, il s.o. passa a sdb?
 
C'e' un qualcosa (chiavetta, disco..) di non montato ciao
(prova a dare "dmesg | tail")
 
-- 
Yoda
 

 Forse quando c'è stato sda, anche se poi espulso, il s.o. passa a sdb?
 
non so dire, dovresti indagare con dmesg. sono abbastanza certo che se assegna la b vuol dire che la a almeno è stata occupata, per togliermi la curiosità controllerei nel log cosa è accaduto alla rimozione.
 
 
 

Il 20/06/22 21:01, wuser ha scritto:

Prova col comando fdisk -l che ti elenca tutte le info dei dischi collegati.
 
angelo

 angelo
 
buongiorno, 
 
oltre a quanto giustamente suggerisci personalmente controllerei anche eventuali
regole impostate in /etc/udev/rules.d/
 
anche udev infatti ha una sua parte nell'assegnazione della lettera ad un
disco/partizione, potrebbe esserci quindi qualcosa che riserva /dev/sda ad un
precedente dispositivo collegato al sistema.
 
saluti.
 
-- 
◈  [WinterMute] @ [debian «-» bookworm | testing]  ◈
 

 un precedente dispositivo collegato al sistema.
 
E anche "grep sda /etc/fstab" ciao
 
-- 
Yoda
 

 me la vede come sda e altre volte come sdb?
 
Una motivazione plausibile è questa (non mia, ma di Aaron Toponce):
 
WARNING: Some motherboards will not present disks in a consistent manner to the
Linux kernel across reboots. As such, a disk identified as /dev/sda on one boot
might be /dev/sdb on the next. [...] So, rather than adding them to the pool by
their /dev/sd? names, you should use the /dev/disk/by-id/* names, as these are
symbolic pointers to the ever-changing /dev/sd? files.
 
Tieni conto che lo stesso discorso si applica a /dev/disk/by-label/* 
 
Enrico

symbolic pointers to the ever-changing /dev/sd? files.
 
Ho notato questa indecisione anche in clonezilla lanciato da
chiavetta, nello stesso PC per lo piů mi trovo il disco interno come
sda e quello esterno USB come sdb, ma qualche volta li trovo
invertiti.
 
-- 
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.

Addi' 22 giu 2022 08:00:27, Enrico Bianchi scrive:

Con le etichette e' (imho!) gia' piu' civile e (penso!) soprattutto
piu' sicuro. Mi spiego.
 
Nel portatile (di prova) con solo Debian bullseye, dopo aver ridotto
in installazione la /dev/sda2 ci ho installato una seconda bullseye.
L'installazione si e' perfettamente conclusa.
Quando pero' ho avviato la prima, al boot ha girato a vuoto per un
minuto e mezzo cercando una swap che non trovava. Ho dovuto cambiare
a manina l'UUID in /etc/initramfs-tools/conf.d/resume.
 
Questa e' la seconda volta che mi capita un UUID fasullo, la prima
molti anni fa era stata a causa d'un noto bug - cosi' m'avevano
detto qui su ICOL*
 
Ho 5 hd per un totale di 6.5 tera, piu' un usb da 1 tera. Con GPT ho
solo l'ultimo aggiunto e da cui scrivo, gli altri 4 col MBR e 14
partizioni ciascuno.
Uso sempre e solo /dev/b1..e14 (il GPT /dev/sda ne ha solo 5) e non
m'e' mai successo niente, neanche una sola volta.
 
Solo per l'usb uso le etichette, perche' l'assegnazione puo'
cambiare; eccolo in fstab:
LABEL=esterno_1  /mnt/u1  ext2  nodev,nosuid,noexec,noauto  0 2
LABEL=esterno_2  /mnt/u2  ext2  nodev,nosuid,noexec,noauto  0 2
LABEL=esterno_3  /mnt/u3  ext2  nodev,nosuid,noexec,noauto  0 2
LABEL=esterno_4  /mnt/u4  ext2  nodev,nosuid,noexec,noauto  0 2
 
In conclusione domando e dico: perche' non consigliano le etichette
invece dei selvaggi UUID? secondo me sono /molto/ piu' sicure e
certamente piu' malleabili ed espressive ciao
(anzi: sono le uniche sicure al 100%)
 
-- 
Yoda
 

 (anzi: sono le uniche sicure al 100%)
 
 
buongiorno, 
 
indubbiamente le etichette sono più user friendly rispetto all'uuid per identificare
una partizione/disco. 
immagino che il motivo principale della preferenza nell'utilizzo di UUID (o uno dei
motivi) rispetto alle etichette sia che queste ultime essendo assegnate dall'utente
sono "vulnerabili" all'errore umano a differenza di un metodo che prevede un
identificativo assegnato in modo univoco dal sistema.
in buona sostanza non credo proprio che le si possa definire sicure al 100%
 
ad ogni modo ho notato che l'argomento è (ed è stato) piuttosto dibattuto e che
quindi si trovano diverse risorse per poter approfondire. 
un esempio potrebbe essere questa pagina [1]
 
[1] 
https://superuser.com/questions/725207/mount-by-uuid-or-label
 


 (anzi: sono le uniche sicure al 100%)
 
No, sono sicure al 0%, perche` possono
benissimo esserci piu` dispositivi con
la stessa etichetta, per sbaglio od
anche intenzionalmente.
 
Gli UUID sono unici, quindi non si puo`
fare confusione.
Che e` l'obbiettivo principale.
 
bye,
 
-- 
 
piergiorgio


diversi router possono fare da disco di rete con dispositivi di 
memorizzazione collegati alle usb.

 Il problema non e` UUID di certo.
 
Sara' di parted, avrebbe dovuto e potuto almeno avvisare che
accorciando /dev/sda2 avrebbe ricreato piu' a monte /dev/sda3 che
e' la swap e dunque cambiato l'UUID. Anzi, penso che la colpa sia
di Anaconda (l'installer della Debian).
Uno alle prime armi avrebbe faticato parecchio prima di risolvere
la situazione.
 
-- 
bye, Yoda
 

Addi' 24 giu 2022 18:04:29, Adriano scrive:

Curiosita' tolta TNX e ciao
 
-- 
Yoda
 

 la situazione.
 
Io invece l'ho subita per due o tre reboot, senza degnare d'uno
sguardo cosa diceva a video e in dmesg, ma maledicendo i vari
e - per me! - assurdi e inutili suspend hybrid e compagnia bella.
 
Infatti la prima cosa che ho fatto e' stata questa:
-cite-
[~]root_#: systemctl mask \
sleep.target  \
suspend.target \
hibernate.target \
hybrid-sleep.target \
suspend-then-hibernate.target
-/cite-
 
ma inutilmente perche' al reboot la bullseye ha continuato
imperterrita andando come Proust alla ricerca della swap
perduta ciao a tutti
 
-- 
Yoda
 


Uno alle prime armi non si mette a fare
trasferimenti di partizioni o simili.
 
Quando fai quei lavori, che sono sconsigliati,
devi sapere esattamente e precisamente quello
che stai facendo.
Quindi non puoi trovare la scusa "alle prime
armi", devi prepararti.
 
Io mi sono trovato a dovere passare un sistema,
installato su partizione(i), ad uno su LVM+LUKS.
 
Per capire come fare ho creato un VM simile,
fatto prove, creato un *protocollo*, testato
e poi fatto l'operazione sul sistema reale.
 
La morale: se uno non sa come si fa, e` sempre
e comunque difficile e causa di errori.
 
bye,
 
-- 
 
piergiorgio

 trasferimenti di partizioni o simili.
 
Come no?! anzi fa di peggio, perche' accorcia Uindous invece
della bullseye ciao
 
-- 
Yoda
 

Addi' 24 giu 2022 19:25:33, Yoda scrive:

Ho verificato adesso che l'installer (Anaconda) della Debian da'
la precedenza al numero della partizione rispetto all'UUID, proprio
come avevo pensato/dedotto ieri:
PRIMA
1 EFI   0.5 giga
2 /     900 giga
3 swap    1 giga
 
DOPO
1 EFI   0.5 giga  ...intatta
2 /     450 giga  ...ridotta al 50%  (con i bullseye immutata)
3 swap    1 giga  ...ricreata -> dunque UUID cambiato
4 EFI   0.5 giga  ...inutilizzata e inutile, era per prova
5 /     450 giga  ...nuova, dove verra' installata la ii bullseye
 
-- 
bye, Yoda
 

 
 
Il che dovrebbe suggerirti che la
tua idea di avere piu` versioni
installate in parallelo non e`
una delle piu` brillanti...
 
Almeno non nel modo in cui tu
realizzi la cosa...
 
bye,
 
-- 
 
piergiorgio

Addi' 25 giu 2022 09:24:20, Piergiorgio Sartor scrive:

Son tutte e solo prove, il portatile un amico lo stava buttando, e'
(era!) d'una lentezza non sopportabile (hp col nuovo pentium, che
credo sia un i-non_so_quanto castrato, e 4 giga di memoria).
 
C'e' una bullseye con KDE e un'altra con la sola console a caratteri
senza la GUI; adesso ci faccio una terza nuova installazione
completa col velocissimo LXDE, per confrontarlo con KDE e per
mostrare all'amico mio la schiacciante superiorita' di Linux ciao
(e buon divertimento coi tuoi virtualizzati -- non li usero' MAI)
 
Postilla.
Nei portatili il collo di bottiglia e' l'hd (era! adesso hanno gli
SSD), che col formato 2.15" vanno tutti a 5400 g/min.
Dei miei 5 hd che ho nel pc fisso, uno solo va a 5400 g/min, gli
altri a 7200 (a 9600 non ne ho mai avuto). Be', l'avevo preso
perche' era in offerta, e' di 2 tera, ma e' inutilizzabile a causa
dei tempi morti in risposta, infatti lo tengo solo per backup.
 
-- 
Yoda
 

 di Anaconda (l'installer della Debian).
 
Anaconda è l'installer di RHEL/Fedora e derivate, non di Debian
 
Enrico

 SSD), che col formato 2.15" vanno tutti a 5400 g/min.
 
Io sul portatile avevo un disco da 7200prm (ovviamente ora ho un SSD) ;)
 
Enrico

 Io sul portatile avevo un disco da 7200prm (ovviamente ora ho un SSD) ;)
 
Era di gran lusso, come un hd da 3.5" a 10.000 g/min su un fisso, il
primo l'aveva fatto la Seagate, ma costava un occhio ciao
 
-- 
Yoda
 

Addi' 28 giu 2022 17:10:23, Enrico Bianchi scrive:

Si', anch'io l'ho conosciuto con la RH e infatti ricordo che m'ero
sorpreso di vedere che lo usava anche la Debian.
Piuttosto in effetti non sembra che lo usi ancora: in rete ho
guardato e ho visto che l'aveva adottato per la Sarge, che e'
proprio la prima Debian che installai (nel 2005 son passato dalla
Slack a Deb), ma sembra - cercando in rete - che adesso come dici tu
la Debian non lo usi piu' ciao
 
-- 
Yoda
 

 stesso nome
 
-- 
Yoda