Problemen met diskpartitie-namen in Mint 19.3

[aartje]

Mijn systeem is :
Desktop A740GM-M moederbord, bios American Megatrends Inc. 080014,
AMD Athlon(tm) II X4 640 Processor, NVIDIA GeForce GT 1030, 8GB geheugen.

Disken:
Samsung SSD 830 128GB
Samsung SSD 860 500GB
Hitachi HDP72503 Harddisk 320GB

DVDwriter LG GH24NSD1

OS : Mint Mate 19.3 64 bit

Wat me opvalt is dat het lijkt of, bijna iedere keer als je boot,
de disknamen veranderen van de drie SSD's/HD. Dus "sda" wordt "sdb",
"sdb" wordt "sdc" of wat dan ook. Dit viel vooral op nadat ik even
de nieuwe Mint 21 had opgestart met een Live-DVD.
Daarna kon ik  mijn Mint Mate 19.3 niet meer opstarten en moest
uiteindelijk na veel gegoochel met SATA kabeltjes (ik dacht dat het
daaraan lag) met een Live-DVD van Mint 19.3 mijn grub herstellen.

Ik ben me bewust van het feit dat al er al tijden met UUID's wordt
gewerkt ipv bijvoorbeeld /dev/sda1 en /dev/sdb2. Dat gaat ook bijna
altijd goed.
De oude benaming  voor de diskpartities wordt hier en daar nog steeds
gebruikt, doe maar eens een "df"

Ook bij een "grub-install /dev/sda" weet je niet naar welke fysieke
harddisk je het schrijft.  Ik vraag me af of je dat dan ook voor de
zekerheid naar alle disken zou moeten doen.

Ik gebruik de "dump" en "restore" commando's al tientallen jaren
in diverse Linux/Unix-systemen omdat ik dat de ideale manier vind
om een "full" of "incremental" backup te doen. Maar het dump-commando
gebruikt ook de "dev/sda1" benaming voor zijn boekhouding en dat gaat
ook fout als de namen van de partities steeds veranderen.

Mijn vraag is dan ook of er toch een manier is om de diskbenaming vast
te zetten op één of andere manier. Zou dat in de BIOS ingesteld kunnen
worden ? Of zou dat op een andere manier kunnen bij het opstarten ?

PS. Ik denk dat dit evengoed voor een Ubuntu-systeem geldt.

[emvedeesje]

Waarschijnlijk heb je met die nieuwe Live-DVD toch commands uitgevoerd welke een actieve GRUB op een andere plaats gezet hebben.

Wat als eerste telt:  het BOOT-ORDER in BIOS.
De eerste schijf in de lijst wordt sda.
En dan moet je de kabel volgen van de Sata-0 naar die schijf.

Ook bij een "grub-install /dev/sda" weet je niet naar welke fysieke harddisk je het schrijft.

Dat weet je dus wél: zie hierboven.

Maak best eens een lijstje welke schijf aan welke poort op het moederbord hangt.
En start eens gparted op je Mate 19.3 daar zie je echt wie sda is en wat er op sda enz. staat.

Ik werk al jaren met Mint en heb nog nooit meegemaakt dat sda zomaar verandert in sdb.

Advies Backup: verdiep je in Timeshift + gebruik hem.

Nog een advies: experimenteer niet op je werkpaard, doch organiseer een testbak daarvoor.

groeten van Michael

[vanadium]

Juist omdat de apparaatnaam niet meer stabiel is in moderne hardware wordt sinds jaar en dag wordt de UUID gebruikt in plaats van de apparaatverwijzing. Als je toch eens een apparaatnaam behoeft, dan zit er niets anders op dan eerst de naam van de dag op te zoeken (blkid). Neen, die apparaatbenaming kan je niet vastzetten.

@emvdeesje, ik denk niet dat je dat kunt veralgemenen. Linux wijst apparaatnamen toe, en ik heb pas een /dev/sda als ik een USB stick inplug.

[emvedeesje]

@emvdeesje, ik denk niet dat je dat kunt veralgemenen. Linux wijst apparaatnamen toe, en ik heb pas een /dev/sda als ik een USB stick inplug.

Dat klopt helemaal, maar zover heb ik het niet willen drijven in mijn antwoord.

groeten van Michael

[bart85]

Heb je in grub default config GRUB_DISABLE_LINUX_UUID op true of false staan?

Code: [Selecteer]

cat /etc/default/grub | grep "GRUB_DISABLE_LINUX_UUID"
Als de optie op false staat moet hij UUID gebruken in de configuratie.

[aartje]

@emvdeesje
Dank voor je reactie. Als je maar één harde- of ssd-schijf in je systeem hebt dan verandert
de "sd" naam niet. Als je er meerdere hebt verandert dit wel (wisseling).
Bv. mijn SSD (Samsung 830 128 GB) zit op SATA 1 maar heeft op dit moment als naam
/dev/sdb .
Op SATA 2 zit mijn Samsung SSD 860 500GB en die heeft nu als naam /dev/sdc .
Op SATA3 zit niks (verdachte poort).
Op SATA 4 zit een Hitachi HD van 320GB en die heeft nu als naam /dev/sda .
Op SATA5 zit een DVD-Writer (LG), als je er een DVD met filesysteem in stopt
wordt dat /dev/sr0.
Als ik de computer opnieuw boot wordt de volgorde van namen weer anders (sda, sdb, sdc)
Alles gaat verder prima, eigenlijk alleen het oude dump/restore niet.
Dat vind ik jammer omdat het bomvast is en bij mij onder heel veel soorten Unix/Linux
altijd goed gewerkt heeft sinds de jaren 70. Het werkt op filesysteemniveau met inodes
en is voor mij al tientallen jaren de ideale backupmanier.
Alleen de adminstratie voor de incrementele dumps werkt met de "sd"partitienamen
( /var/lib/dumpdates ). In de professionele Unix-wereld was dit de standaard backupmanier.
Maar professioneel ben ik er al een jaar of 20 uit.

@vanadium
Dank je voor het antwoord. Het is dus niet abnormaal gedrag.

@bart85

 cat /etc/default/grub | grep "GRUB_DISABLE_LINUX_UUID"
#GRUB_DISABLE_LINUX_UUID=true

Er staat dus "true"  maar wel met een commentaar-hash ervoor (?)

[bart85]

Voor het handmatig aankoppelen kun je labels gebruiken

Onderstaand noemt de partitie sda1 mydisk

Code: [Selecteer]

sudo tune2fs –L mydisk /dev/sda1
Aankoppelen kan heel eenvoudig met de commandline:

Code: [Selecteer]

sudo mount LABEL=mydisk /path/to/directory
In /etc/fstab:

Code: [Selecteer]

LABEL=mydisk /path/to/directory ext4 defaults 0 0Waarbij bestandssysteem ext4 is en default config.

[aartje]

Dat kan ook. Het mounten van mijn diskpartities is geen probleem, ze
worden netjes zoals in /etc/fstab aangegeven gemount mbv UUID-nummers.
Het probleem is dat sda, sdb en sdc niet bij iedere boot overeen komen met
dezelfde UUID's

[aartje]

Hier is trouwens  al iets over gezegd in 2014 :

https://groups.google.com/g/linux.debian.bugs.dist/c/27_GdBXlF10

Misschien zou er eens een nieuwe versie moeten komen die met UUID-
gerelateerd namen werkt. Ik heb begrepen dat er niet meer een actieve
maintainer bestaat die zich bezig houdt met het onderhouden van dump/restore.
Als ik niet twintig jaar geleden gestopt zou zijn met programmeren zou ik zelf
naar de sources  kunnen kijken, maar die kennis en kunde ben ik helaas ik kwiijt...

En niets ten nadele van "timeshift", "tar", "rsync" en dergelijke programma's
maar ze kunnen bij lange na niet wat dump/restore kan.
Bv. backup van specialfiles als symbolische links, hard links, special block- en raw-devices
etc.etc.
Het nadeel van dump/restore is wel dat het alleen met ext2/3/4 filesystemen werkt.

[emvedeesje]

Als je maar één harde- of ssd-schijf in je systeem hebt dan verandert de "sd" naam niet. Als je er meerdere hebt verandert dit wel (wisseling).

Bij mij zitten er steeds 2 schijven in, en gedurende de 10 jaar dat ik nu met linux werk (3 j ubuntu, 7 j mint) en een wisseling heb ik nog nooit meegemaakt.
Nota bene ondertussen zelfs in meerdere opvolgende desktops.

Jij bijt je hier hardnekkig in vast, doch er zal op jouw computer toch ergens iets grondig mis zijn.
Waarschijnlijk zit er ook ergens een denkfout in je systeem...
 
Mijn voorstel is:
- haal alle extern gekoppelde USB schijven los
- weet heel goed welke schijf wie is door gparted in een Live-versie op te starten.
(je kan ze in gparted ook een label geven, dat maakt het helder)

- wacht nog even tot Mint 21 officieel uit komt en installeer deze als volgt:
Op de schijf waarop je wil gaan installeren:
- ik adviseer: neem de SSD 128GB
- maak via de nieuwe live-21-versie met gparted een nieuwe partitietabel aan op die SSD 128GB (schijf is nu volledig leeg)
- hang deze SSD 128GB aan de SATA0, dus als eerste
- zorg ervoor dat in de Bios deze SSD 128GB aan de SATA0 op de eerste plaats staat, dan wordt dat al zeker sda
(hier staat deze volgorde: 1=USB 2=DVD 3=SATA0 4=SATA1)
- check dit via gparted in een Live-versie: sda sdb sdc
- installeer op deze SSD 128GB sda en zet tezelfdertijd de opstartlader op sda

En daarna het koppelen van de andere partities op een juiste manier via een nieuw topic.

Verder zou ik je ook adviseren om na de nieuwe installatie je standpunt omtrent backup te herzien.
- gebruik Timeshift voor het OS
- installeer een backup programma enkel voor je data
Totaal van elkaar gescheiden dus.

Hier:
Staat data enkel op een aparte partitie (geen home partitie)
Start ik manueel een maandelijkse Timeshift van het OS.
Wordt maandelijks een incrementele backup genomen van de datapartitie via FreeFileSync, op afwisselende doelen.
Een dagboek wordt bijgehouden van alle veranderingen welke ik aanbreng in het OS.

Resultaat:
Een vlot en veilig systeem volgend uit veel ervaringen.
Op die manier heb ik het ook geïmplementeerd en draait het eveneens vlot bij een kennis...

groeten van Michael

[aartje]

@emvedeesje
Dank je wel voor je uitgebreide antwoord. Ik weet echter al tientallen jaren hoe ik een Linux en/of Unix-systeem moet
installeren en een disk moet partitioneren Dat er bij jou geen verandering van disk(partitie)namen optreedt wil nog niet zeggen
dat het bij anderen niet anders kan zijn. Bij het booten van het systeem wordt bepaald welke disk sda, sdb, sdc heet en worden
de symbolische links gemaakt naar de echte partitities (special files). Bij velen (de meeste?) zal /dev/sda altijd met dezelfde
disk te maken hebben, maar dat is niet gegarandeerd en is bij velen ook niet zo.
De partities hebben  een  vaste (!)UUID-aanduiding en die is wel vast en die worden ook genoemd in /etc/fstab en worden
gebruikt om de partities te mounten. Daardoor gaat (bijna?) alles ook wel goed.

Er is eigenlijk nauwelijks een probleem, alleen met programma's die gebruik  maken van de ouderwetse "/dev/sda1" namen kan
er een probleem zijn. Dat is dus in mijn geval met het dump-commando. Dat zou een kleine verandering moeten krijgen zoals
bv. in deze tekst wordt beschreven :
=======================================================================
Peace of text out of https://groups.google.com/g/linux.debian.bugs.dist/c/27_GdBXlF10

"i think the least messy way out is to rework the dumpdates stuff to
stop canonicalising the memorised device name, and instead park
whatever the user gave us for the device lookup. ie: if you dump -u /dev/sdy
then "/dev/sdy" will be saved, just as before, but if you
dump -u LABEL=foobardiddly then dumpdates will hold "LABEL=foobardiddly".

pro: 100% backwards compatible, and minimal amount of code change.
contra: you cannot mix incremental dumps of /dev/sdxyz with UUID=whatever
and expect dump to find one by the other. i think that's quite acceptable
a limitation, as long as it makes it into the documentation."
=============================================================

[peer]

wellicht kun je in je programma een check inbouwen die de UIID -/dev/sda combinatie check en evt. aanpast.

sudo blkid geeft info met uiid en /dev/sda

[vanadium]

Als je maar één harde- of ssd-schijf in je systeem hebt dan verandert de "sd" naam niet. Als je er meerdere hebt verandert dit wel (wisseling).

Bij mij zitten er steeds 2 schijven in, en gedurende de 10 jaar dat ik nu met linux werk (3 j ubuntu, 7 j mint) en een wisseling heb ik nog nooit meegemaakt.
Nota bene ondertussen zelfs in meerdere opvolgende desktops.

Ik herhaal, je veralgemeent hier weer. Dat dat bij jou zo is, betekent niet dat dit bij iemand anders ook zo is. Het hangt af van je computer.

Jij bijt je hier hardnekkig in vast, doch er zal op jouw computer toch ergens iets grondig mis zijn.

Ik denk het niet. Opnieuw, sedert vele jaren is men overgestapt op UUID (of Label) om een partitie te identificeren, juist omdat apparaatnamen kunnen veranderen.

@aartje, op de link[/quote] die je gaf in vorige post zie ik dat het wel degelijk mogelijk is de UUID te gebruiken met dump en restore. Alleen staat dat niet behoorlijk in de documentatie. Afstappen van die apparaatnamen is de enige oplossing hier.

[aartje]

Ik denk het niet. Opnieuw, sedert vele jaren is men overgestapt op UUID (of Label) om een partitie te identificeren, juist omdat apparaatnamen kunnen veranderen.

@aartje, op de link die je gaf in vorige post zie ik dat het wel degelijk mogelijk is de UUID te gebruiken met dump en restore. Alleen staat dat niet behoorlijk in de documentatie. Afstappen van die apparaatnamen is de enige oplossing hier.

@vanadium Dank voor je reactie. Ja dat je wel degelijk je UUID kan gebruiken heb ik ook opgemerkt. Er is alleen een maar...
In /var/lib/dumpdates wordt bijgehouden welke partitie je hebt gedumpt en helaas, als je je UUID gebruikt wordt daar
toch weer de dan bijbehorende /dev/sda1 (of zo) genoteerd en kom je toch weer in de problemen met een incrementele dump.
De vraag in die tekst was dan ook dat ipv /dev/sda1 (of zo) in /var/lib/dumpdates te noteren de naam van de UUID-naam te schrijven.
Ik heb hier een email naar de maintainer over gestuurd met de vraag of die wijziging in het formaat van /var/lib/dumpdates
doorgevoerd kon worden. Ik hoop dat er een antwoord op komt.

[vanadium]

Ik heb hier een email naar de maintainer over gestuurd met de vraag of die wijziging in het formaat van /var/lib/dumpdates
doorgevoerd kon worden. Ik hoop dat er een antwoord op komt.

Dat is inderdaad een zinvolle actie. Nu is dat heel oud gereedschap, en ik vraag me af of je niet beter een ander, meer "hedendaags" alternatief zoekt voor dump en restore.

[aartje]

Ja, het is al heel oud, ik ken het al van Unix 6. Nuldumps kan je er nog steeds mee maken
en ook kan je er ook makkelijk je data van je rootpartitie  mee copiëren naar
een grotere of kleinere partitie. Maar het zal eens tijd worden voor een andere manier van backup,
denk ik 
Mijn dank voor de reacties en ik laat dit topic nog even open.

[aartje]

@vanadium
Ik heb verder gekeken op de debian-site en daar gevonden dat er wel degelijk een nieuwe
versie van dump (en restore) bestaat , 0.4b47-4. De /var/lib/dumpdates schijnt hier wel met
de UUID naam te werken , zoals je al had opgemerkt .
Deze is echter aangemerkt als "testing" en "unstable". Ik heb de package (deb-formaat)
gedownload en proberen te installeren (onder Mint Mate 19.3) met gdebi.
Dit lukt niet omdat het in ieder geval libc6 versie hoger of gelijk aan 2.33 vereist en mijn
versie is 2.27-3.
Ik hoop dat de aangepaste versie van dump wel onder Mint 21 gaat werken en maak voorlopig
alleen nog maar backups met nuldumps van mijn root-filesysteem en de rest met timeshift (of iets dergelijks)

[emvedeesje]

Als je maar één harde- of ssd-schijf in je systeem hebt dan verandert de "sd" naam niet. Als je er meerdere hebt verandert dit wel (wisseling).

Bij mij zitten er steeds 2 schijven in, en gedurende de 10 jaar dat ik nu met linux werk (3 j ubuntu, 7 j mint) en een wisseling heb ik nog nooit meegemaakt.
Nota bene ondertussen zelfs in meerdere opvolgende desktops.

Ik herhaal, je veralgemeent hier weer. Dat dat bij jou zo is, betekent niet dat dit bij iemand anders ook zo is. Het hangt af van je computer.

Jij bijt je hier hardnekkig in vast, doch er zal op jouw computer toch ergens iets grondig mis zijn.

Ik denk het niet. Opnieuw, sedert vele jaren is men overgestapt op UUID (of Label) om een partitie te identificeren, juist omdat apparaatnamen kunnen veranderen.

@allen
Als dat werkelijk zo is, dan zou het gek zijn dat te ontkennen.
Dat was het allereerste dat ik er over hoorde via aartje, doch als Vanadium dat nu ook zegt, en peer denkt dat UUID zou kunnen gebruikt worden in dat programma, beschouw ik vanaf nu dat er zeker iets aan de hand is.
Dus excuseer mijn standpunt gebaseerd op slechts enkele installaties.

groeten van Michael

[vanadium]

@allen
Als dat werkelijk zo is, dan zou het gek zijn dat te ontkennen.
Dat was het allereerste dat ik er over hoorde via aartje, doch als Vanadium dat nu ook zegt, en peer denkt dat UUID zou kunnen gebruikt worden in dat programma, beschouw ik vanaf nu dat er zeker iets aan de hand is.
Dus excuseer mijn standpunt gebaseerd op slechts enkele installaties.

Tegenwoordig wordt randapparatuur voor een stuk tegelijk opgestart. Wie eerst klaar is, krijgt het eerste nummer. Dat is waarom het niet ongewoon is dat toewijzing van apparaatverwijzingen kunnen verschillen. Werkt het nu nog goed op jou toestel, dan moet je er rekening mee houden dat het bij een volgend toestel niet goed meer kan werken.

@aartje, in Ubuntu 22.04 is de versie nu 04b47-3, dus die komt binnenkort zeker mee met de nieuw Mint.

[emvedeesje]

Tegenwoordig wordt randapparatuur voor een stuk tegelijk opgestart. Wie eerst klaar is, krijgt het eerste nummer. Dat is waarom het niet ongewoon is dat toewijzing van apparaatverwijzingen kunnen verschillen. Werkt het nu nog goed op jou toestel, dan moet je er rekening mee houden dat het bij een volgend toestel niet goed meer kan werken.

Dat is fijn om te weten.
Zelf heb ik enkel Timeshift waarin specifiek naar een sdc gestuurd wordt.
Overal zijn partities hier gekoppeld via hun UUID.
Ik blijf dus alert en hou het in de gaten...

[vanadium]

Dat is fijn om te weten.
Zelf heb ik enkel Timeshift waarin specifiek naar een sdc gestuurd wordt.
Overal zijn partities hier gekoppeld via hun UUID.
Ik blijf dus alert en hou het in de gaten...

Gekoppeld via UUID? Dan hoef je zelfs niet alert te zijn: dat zal blijven werken, ook met Timeshift.   

[aartje]

@aartje, in Ubuntu 22.04 is de versie nu 04b47-3, dus die komt binnenkort zeker mee met de nieuw Mint.

@vanadium
Dat is goed om te weten ik wacht nog even op de nieuwere stabielere versie van Mint21 (gebaseerd op Ubuntu 22.04).
Er is nu net een betaversie uit en ik kan nog wel leven met mijn Mint 19.3.


Misschien probeer ik onder Mint 19.3 dump versie 04b47-3 eens te compileren, voor de sport...

[aartje]

Het is me gelukt om de 0.4b47 versie te compileren onder Mint 19.3. Maar dumpdates
neemt nog niet de goede UUID=xxx over maar toch de /dev/sdx formaat. Nu zie ik dat
op de debian-site dit pas aangepakt is bij versie 0.4b47-4 (unstable). Ik verwacht die voorlopig
nog niet bij Mint 21 en die sources vind ik ook even niet bij debian om te downloaden.

[bart85]

https://wiki.archlinux.org/title/persistent_block_device_naming#by-label

Hier  staat in beschreven hoe de partitie en disk rechtstreeks vanaf uuid of label te bereiken is. Ongeacht het sda of sdb word genoemd.

[aartje]

https://wiki.archlinux.org/title/persistent_block_device_naming#by-label

Hier  staat in beschreven hoe de partitie en disk rechtstreeks vanaf uuid of label te bereiken is. Ongeacht het sda of sdb word genoemd.

Maar voor de dump/restore commando's biedt dat geen uitkomst, de /dev/sdx versus UUID koppeling kan na iedere reboot veranderen
en het sdx formaat blijft in /var/lib/dumpdates. Pas na versie 0.4b47-4 wordt dumpdates na een dump aangepast dat je
ook incrementele dumps kan doen, na een nuldump.
Wel aardig om een er samenvattend verhaal over te lezen, dank je bart85