Re: Verwisseling sda en sdb
Hoi Sjoerd, Op 12-07-2022 om 14:00 schreef Sjoerd: Paul van der Vlis: Sjoerd: Martijn van de Streek: Diederik de Haas: Paul van der Vlis: tune2fs -l /dev/sdb8 | grep UUID lsblk -o +UUID blkid Niettemin, als sda en sdb tijdens het opstarten zijn verwisseld, is dat bij al deze drie methoden eveneens het geval. Nee, het zou altijd goed moeten zijn. Tenminste, als /dev/sdb8 correct is op het moment dat bovenstaand commando wordt uitgevoerd. Op de eerste schijf heb ik 4 partities, op de tweede schijf 8. # tune2fs -l /dev/sdb8 | grep UUID tune2fs: No such file or directory while trying to open /dev/sdb8 Couldn't find valid filesystem superblock. # tune2fs -l /dev/sda8 | grep UUID Filesystem UUID: 4ea8879c-14ba-4cc7-aa04-dcca4b55d131 En dit is de UUID van de 8e partitie op de tweede schijf. De bedoeling is dus dat in /etc/fstab het UUID van het correcte filesysteem staat voor b.v. root. Klopt allemaal. # sda2 UUID=c3e1cf6f-2f04-42f6-948d-346f2ba7188e / ext4 defaults,discard,noatime,nodiratime 0 1 Nu was het punt dat ik die verwisseling nogal griezelig vond. Doe ik bijvoorbeeld een 'grub-install /dev/sda', dan wordt grub op de verkeerde schijf geïnstalleerd! Dat is eigenlijk geen probleem. Hij moet alleen wel naar het juiste verwijzen, dus uitvoeren met de juiste /boot/grub . Je kunt grub op beide schijven installeren. Dat doe ik ook altijd met software RAID1. Als de ene schijf defect is, doet grub het ook met de andere. En na een 'update-grub' zijn hd0 en hd1 in /boot/grub/grub.cfg ook overal verwisseld. De vraag is of ik dan nog in de andere geïnstalleerde OS'en kan komen. Ah, er zijn ook andere OS-en geinstalleerd. Ben daar nog druk mee aan het experimenteren. Heb voor de zekerheid een rescue-usb-stick achter de hand. Maar de oorzaak van dit gedoe zou het volgende kunnen zijn. In testing zit momenteel geen VirtualBox. Naar het voorbeeld van iemand in de Engelse debian-user-list heb ik VirtualBox uit sid in testing geïnstalleerd. Het werkte een poosje goed, maar er zijn nu nogal wat dependency-problemen. Honderden packages die niet ge-update kunnen worden. Ook opties als '--fix-broken-install' en de oplossingen die Aptitude biedt, weten er geen raad mee. Tja, dat weet ik zo ook niet. Het lijkt me best redelijk wat je hebt gedaan. Maar Virtualbox is wel een speciaal pakket. Zelf gebruik ik tegenwoordig geen Virtualbox meer, maar virt-manager. Probeer ik VirtualBox weer te deïnstalleren, dan wil apt een hele reeks programma's die ik liever niet kwijt raak, waaronder de hele 'kde-full', mee verwijderen. Doe even "apt install kde-full", dan is het handmatig geïnstalleerd. Dus het is een beetje een puinhoop geworden. En mogelijk heeft ook die verwisseling van sda en sdb daarmee te maken. Ik weet het niet. Maar ik heb ook Stable nog achter de hand, daar kan ik mee verder. En daarna ga ik Testing maar opnieuw installeren. Alle kans dat het dan weer als vanouds werkt. Dus wou ik dit punt verder maar laten rusten. Ik begrijp het. Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: Verwisseling sda en sdb
Paul van der Vlis: > Sjoerd: > > Martijn van de Streek: > > > Diederik de Haas: > > > > Paul van der Vlis: > > > > > > > > > > tune2fs -l /dev/sdb8 | grep UUID > > > > > > > > lsblk -o +UUID > > > > > > blkid > > > > Niettemin, als sda en sdb tijdens het opstarten zijn verwisseld, > > is dat bij al deze drie methoden eveneens het geval. > > Nee, het zou altijd goed moeten zijn. Tenminste, als /dev/sdb8 correct > is op het moment dat bovenstaand commando wordt uitgevoerd. Op de eerste schijf heb ik 4 partities, op de tweede schijf 8. # tune2fs -l /dev/sdb8 | grep UUID tune2fs: No such file or directory while trying to open /dev/sdb8 Couldn't find valid filesystem superblock. # tune2fs -l /dev/sda8 | grep UUID Filesystem UUID: 4ea8879c-14ba-4cc7-aa04-dcca4b55d131 En dit is de UUID van de 8e partitie op de tweede schijf. > De bedoeling is dus dat in /etc/fstab het UUID van het correcte > filesysteem staat voor b.v. root. Klopt allemaal. # sda2 UUID=c3e1cf6f-2f04-42f6-948d-346f2ba7188e / ext4 defaults,discard,noatime,nodiratime 0 1 Nu was het punt dat ik die verwisseling nogal griezelig vond. Doe ik bijvoorbeeld een 'grub-install /dev/sda', dan wordt grub op de verkeerde schijf geïnstalleerd! En na een 'update-grub' zijn hd0 en hd1 in /boot/grub/grub.cfg ook overal verwisseld. De vraag is of ik dan nog in de andere geïnstalleerde OS'en kan komen. Ben daar nog druk mee aan het experimenteren. Heb voor de zekerheid een rescue-usb-stick achter de hand. Maar de oorzaak van dit gedoe zou het volgende kunnen zijn. In testing zit momenteel geen VirtualBox. Naar het voorbeeld van iemand in de Engelse debian-user-list heb ik VirtualBox uit sid in testing geïnstalleerd. Het werkte een poosje goed, maar er zijn nu nogal wat dependency-problemen. Honderden packages die niet ge-update kunnen worden. Ook opties als '--fix-broken-install' en de oplossingen die Aptitude biedt, weten er geen raad mee. Probeer ik VirtualBox weer te deïnstalleren, dan wil apt een hele reeks programma's die ik liever niet kwijt raak, waaronder de hele 'kde-full', mee verwijderen. Dus het is een beetje een puinhoop geworden. En mogelijk heeft ook die verwisseling van sda en sdb daarmee te maken. Maar ik heb ook Stable nog achter de hand, daar kan ik mee verder. En daarna ga ik Testing maar opnieuw installeren. Alle kans dat het dan weer als vanouds werkt. Dus wou ik dit punt verder maar laten rusten.
Re: Verwisseling sda en sdb
Op 11-07-2022 om 18:59 schreef Sjoerd: Martijn van de Streek: Diederik de Haas: Paul van der Vlis: tune2fs -l /dev/sdb8 | grep UUID lsblk -o +UUID blkid Niettemin, als sda en sdb tijdens het opstarten zijn verwisseld, is dat bij al deze drie methoden eveneens het geval. Nee, het zou altijd goed moeten zijn. Tenminste, als /dev/sdb8 correct is op het moment dat bovenstaand commando wordt uitgevoerd. De bedoeling is dus dat in /etc/fstab het UUID van het correcte filesysteem staat voor b.v. root. Verder is het uiteraard niet bedoeling dat er twee grub's zijn geïnstalleerd, in elk geval niet die verschillende dingen doen. Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: Verwisseling sda en sdb
Martijn van de Streek: > Diederik de Haas: > > Paul van der Vlis: > > > > > > tune2fs -l /dev/sdb8 | grep UUID > > > > lsblk -o +UUID > > blkid Niettemin, als sda en sdb tijdens het opstarten zijn verwisseld, is dat bij al deze drie methoden eveneens het geval.
Re: Verwisseling sda en sdb
Diederik de Haas schreef op ma 11-07-2022 om 17:00 [+0200]: > On Monday, 11 July 2022 16:23:28 CEST Paul van der Vlis wrote: > > Als je ext4 gebruikt, dan kun je achter het UUID komen met iets > > als: > > tune2fs -l /dev/sdb8 | grep UUID > > of ``lsblk -o +UUID`` > > Met '+UUID' voeg je die kolom toe aan de standaard output. > Je kan ook andere kolommen toevoegen of helemaal zelf de output > kolommen > bepalen door geen '+' te gebruiken. Je kunt ook "blkid" gebruiken. Die laat UUIDs en labels van alle filesystems die het kan vinden zien. -- Martijn
Re: Verwisseling sda en sdb
On Monday, 11 July 2022 16:23:28 CEST Paul van der Vlis wrote: > Als je ext4 gebruikt, dan kun je achter het UUID komen met iets als: > tune2fs -l /dev/sdb8 | grep UUID of ``lsblk -o +UUID`` Met '+UUID' voeg je die kolom toe aan de standaard output. Je kan ook andere kolommen toevoegen of helemaal zelf de output kolommen bepalen door geen '+' te gebruiken. signature.asc Description: This is a digitally signed message part.
Re: Verwisseling sda en sdb
Op 10-07-2022 om 19:45 schreef Sjoerd: Geert Stappers: Uit het oorspronkelijke bericht: In fstab worden alle partities die gemount worden, aangeduid met 'UUID=...'. Het 'UUID=...' gebeuren is juist om verwisseling te voorkomen. Ik herinner me dat ik ooit met die UUID's ben begonnen omdat het opstarten al helemaal vastliep. Na een tweede of derde poging lukte het dan wel. Dat verschijnsel was hiermee verholpen. Maar als ik in /dev/disk/by-uuid kijk, dan zie ik dat de UUID's ook daar net naar de verkeerde partities linken, bijvoorbeeld naar sda8 i.p.v. sdb8. Wanneer het een keer wel goed gaat, dan kloppen die links ook weer. Normaal gebruik je in /etc/fstab geen UUID's van disks volgens mij. Maar UUID's van filesystemen. Het maakt dan niet uit welke disk het is. Als je ext4 gebruikt, dan kun je achter het UUID komen met iets als: tune2fs -l /dev/sdb8 | grep UUID Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: Verwisseling sda en sdb
Geert Stappers: > Uit het oorspronkelijke bericht: > In fstab worden alle partities die gemount worden, aangeduid met 'UUID=...'. > > Het 'UUID=...' gebeuren is juist om verwisseling te voorkomen. Ik herinner me dat ik ooit met die UUID's ben begonnen omdat het opstarten al helemaal vastliep. Na een tweede of derde poging lukte het dan wel. Dat verschijnsel was hiermee verholpen. Maar als ik in /dev/disk/by-uuid kijk, dan zie ik dat de UUID's ook daar net naar de verkeerde partities linken, bijvoorbeeld naar sda8 i.p.v. sdb8. Wanneer het een keer wel goed gaat, dan kloppen die links ook weer. > Ik lees in die observaties dat het om een moderne computer gaat. Hij is van oktober 2014, 'PC op maat' samengesteld en in elkaar gezet door Paradigit.
Re: Verwisseling sda en sdb
On Sun, Jul 10, 2022 at 03:30:01PM +0200, Diederik de Haas wrote: > On Saturday, 9 July 2022 20:15:11 CEST Diederik de Haas wrote: > > On Saturday, 9 July 2022 18:05:11 CEST Sjoerd wrote: > > > Het volgende vreemde verschijnsel doet zich voor. (Debian testing) > > > Meestal, maar niet altijd, zie ik dat sda en sdb verwisseld zijn. > > > > Je kan/mag er NIET van uit gaan dat de letters constant naar dezelfde schijf > > wijzen. De kernel 'probed' (ontdekt) je hardware en kent er dan een letter > > aan. Ik neem aan dat de eerste die succesvol geïdentificeerd is, sda wordt. > > > > Maar er kunnen diverse factoren zijn die ervoor zorgen dat de identificatie > > van een schijf de ene keer langer duurt dan de andere. Mogelijk dat `dmesg` > > een indicatie geeft waarom het soms langer duurt dan verwacht. > > Wat een geweldig advies! Misschien moet ik er zelf ook eens naar luisteren ... > > Maw: Ik ben ook tegen dit 'probleem' aangelopen en had sdb1 gemount, terwijl > ik sda1 had moeten mounten. Doe ook jullie voordeel met disklabels. Zie ook manual page mount(8), zoek op label. Alvast een stukje: The device names of disk partitions are unstable; hardware reconfiguration, and adding or removing a device can cause changes in names. This is the reason why it's strongly rec‐ ommended to use filesystem or partition identifiers like UUID or LABEL. Currently supported identifiers (tags): Groeten Geert Stappers -- Silence is hard to parse
Re: Verwisseling sda en sdb
On Sun, Jul 10, 2022 at 06:31:37PM +0200, Sjoerd wrote: > Diederik de Haas schreef: > > Je kan/mag er NIET van uit gaan dat de letters constant naar dezelfde > > schijf > > wijzen. De kernel 'probed' (ontdekt) je hardware en kent er dan een letter > > aan. Ik neem aan dat de eerste die succesvol geïdentificeerd is, sda wordt. > > Hm, ik ben het nooit eerder tegengekomen, het is iets van de laatste tijd. Uit het oorspronkelijke bericht: In fstab worden alle partities die gemount worden, aangeduid met 'UUID=...'. Het 'UUID=...' gebeuren is juist om verwisseling te voorkomen. > > Maar er kunnen diverse factoren zijn die ervoor zorgen dat de identificatie > > van > > een schijf de ene keer langer duurt dan de andere. Mogelijk dat `dmesg` een > > indicatie geeft waarom het soms langer duurt dan verwacht. > > Hieronder wat ik er in dmesg van kan vinden. > > In beide gevallen is scsi 0:0:0:0 de SSD en scsi 1:0:0:0 de HD (ST1000..., > merk Seagate). > In het eerste geval wordt sd 0:0:0:0 sda genoemd en sd 1:0:0:0 sdb. > Maar in het tweede geval is dat net andersom. > > Wanneer het wel goed gaat: > > [1.094925] scsi 0:0:0:0: Direct-Access ATA Samsung SSD 840 BB6Q PQ: 0 > ANSI: 5 > [1.095090] ata2.00: configured for UDMA/133 > [1.095240] scsi 1:0:0:0: Direct-Access ATA ST1000DM003-1ER1 CC43 PQ: 0 > ANSI: 5 > [1.095457] ata3.00: configured for UDMA/100 > [1.096784] scsi 2:0:0:0: CD-ROM ASUS DRW-24F1ST a 1.00 PQ: 0 ANSI: 5 > [1.136600] sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 > TB/932 GiB) > [1.136603] sd 1:0:0:0: [sdb] 4096-byte physical blocks > [1.136606] sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 > GB/233 GiB) > [1.136610] sd 1:0:0:0: [sdb] Write Protect is off > [1.136613] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 > [1.136613] sd 0:0:0:0: [sda] Write Protect is off > [1.136616] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [1.136624] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, > doesn't support DPO or FUA > [1.136626] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, > doesn't support DPO or FUA > > Wanneer sda en sdb zijn verwisseld: > > [1.110698] scsi 0:0:0:0: Direct-Access ATA Samsung SSD 840 BB6Q PQ: 0 > ANSI: 5 > [1.110736] ata3.00: configured for UDMA/100 > [1.112067] ata2.00: configured for UDMA/133 > [1.112188] scsi 1:0:0:0: Direct-Access ATA ST1000DM003-1ER1 CC43 PQ: 0 > ANSI: 5 > [1.113064] scsi 2:0:0:0: CD-ROM ASUS DRW-24F1ST a 1.00 PQ: 0 ANSI: 5 > [1.155960] sd 1:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 > TB/932 GiB) > [1.155963] sd 1:0:0:0: [sda] 4096-byte physical blocks > [1.155970] sd 1:0:0:0: [sda] Write Protect is off > [1.155973] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [1.155983] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, > doesn't support DPO or FUA > [1.155984] sd 0:0:0:0: [sdb] 488397168 512-byte logical blocks: (250 > GB/233 GiB) > [1.155992] sd 0:0:0:0: [sdb] Write Protect is off > [1.155994] sd 0:0:0:0: [sdb] Mode Sense: 00 3a 00 00 > [1.156004] sd 0:0:0:0: [sdb] Write cache: enabled, read cache: enabled, > doesn't support DPO or FUA > Ik lees in die observaties dat het om een moderne computer gaat. Groeten Geert Stappers -- Silence is hard to parse
Re: Verwisseling sda en sdb
Diederik de Haas: > Sjoerd: > > Paul van der Vlis: > > > Is het UEFI? > > > > Nee, nog altijd BIOS. > > Misschien nog eens een idee om dit op UEFI over te zetten? > > In de BIOS is te kiezen uit: > > > > - UEFI > > - LEGACY+UEFI > > > > En de laatste is dus geselecteerd. > > Maar dit lijkt me nog een hele operatie. > > Volgens mij komt dat neer op je systeem helemaal opnieuw installeren. > Dus ja, dat is een hele operatie. Nou, ik kom her en der op het internet instructies tegen om het systeem 'in place' op UEFI over te zetten. Bijvoorbeeld hier voor Ubuntu: https://serverfault.com/questions/963178/how-do-i-convert-my-linux-disk-from-mbr-to-gpt-with-uefi/963179#963179 En hier voor RedHat: www.redhat.com/sysadmin/bios-uefi Backups zijn wel noodzakelijk, en de procedure vind ik er niet eenvoudig uitzien. > En ik ben er vrij zeker van dat dat geen verschil zal maken mbt je 'probleem'. Dan is het minder dringend.
Re: Verwisseling sda en sdb
Diederik de Haas schreef: > Je kan/mag er NIET van uit gaan dat de letters constant naar dezelfde schijf > wijzen. De kernel 'probed' (ontdekt) je hardware en kent er dan een letter > aan. Ik neem aan dat de eerste die succesvol geïdentificeerd is, sda wordt. Hm, ik ben het nooit eerder tegengekomen, het is iets van de laatste tijd. > Maar er kunnen diverse factoren zijn die ervoor zorgen dat de identificatie > van > een schijf de ene keer langer duurt dan de andere. Mogelijk dat `dmesg` een > indicatie geeft waarom het soms langer duurt dan verwacht. Hieronder wat ik er in dmesg van kan vinden. In beide gevallen is scsi 0:0:0:0 de SSD en scsi 1:0:0:0 de HD (ST1000..., merk Seagate). In het eerste geval wordt sd 0:0:0:0 sda genoemd en sd 1:0:0:0 sdb. Maar in het tweede geval is dat net andersom. Wanneer het wel goed gaat: [1.094925] scsi 0:0:0:0: Direct-Access ATA Samsung SSD 840 BB6Q PQ: 0 ANSI: 5 [1.095090] ata2.00: configured for UDMA/133 [1.095240] scsi 1:0:0:0: Direct-Access ATA ST1000DM003-1ER1 CC43 PQ: 0 ANSI: 5 [1.095457] ata3.00: configured for UDMA/100 [1.096784] scsi 2:0:0:0: CD-ROM ASUS DRW-24F1ST a 1.00 PQ: 0 ANSI: 5 [1.136600] sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) [1.136603] sd 1:0:0:0: [sdb] 4096-byte physical blocks [1.136606] sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/233 GiB) [1.136610] sd 1:0:0:0: [sdb] Write Protect is off [1.136613] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [1.136613] sd 0:0:0:0: [sda] Write Protect is off [1.136616] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [1.136624] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [1.136626] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Wanneer sda en sdb zijn verwisseld: [1.110698] scsi 0:0:0:0: Direct-Access ATA Samsung SSD 840 BB6Q PQ: 0 ANSI: 5 [1.110736] ata3.00: configured for UDMA/100 [1.112067] ata2.00: configured for UDMA/133 [1.112188] scsi 1:0:0:0: Direct-Access ATA ST1000DM003-1ER1 CC43 PQ: 0 ANSI: 5 [1.113064] scsi 2:0:0:0: CD-ROM ASUS DRW-24F1ST a 1.00 PQ: 0 ANSI: 5 [1.155960] sd 1:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) [1.155963] sd 1:0:0:0: [sda] 4096-byte physical blocks [1.155970] sd 1:0:0:0: [sda] Write Protect is off [1.155973] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 [1.155983] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [1.155984] sd 0:0:0:0: [sdb] 488397168 512-byte logical blocks: (250 GB/233 GiB) [1.155992] sd 0:0:0:0: [sdb] Write Protect is off [1.155994] sd 0:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [1.156004] sd 0:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Re: Verwisseling sda en sdb
On Saturday, 9 July 2022 20:15:11 CEST Diederik de Haas wrote: > On Saturday, 9 July 2022 18:05:11 CEST Sjoerd wrote: > > Het volgende vreemde verschijnsel doet zich voor. (Debian testing) > > Meestal, maar niet altijd, zie ik dat sda en sdb verwisseld zijn. > > Je kan/mag er NIET van uit gaan dat de letters constant naar dezelfde schijf > wijzen. De kernel 'probed' (ontdekt) je hardware en kent er dan een letter > aan. Ik neem aan dat de eerste die succesvol geïdentificeerd is, sda wordt. > > Maar er kunnen diverse factoren zijn die ervoor zorgen dat de identificatie > van een schijf de ene keer langer duurt dan de andere. Mogelijk dat `dmesg` > een indicatie geeft waarom het soms langer duurt dan verwacht. Wat een geweldig advies! Misschien moet ik er zelf ook eens naar luisteren ... Maw: Ik ben ook tegen dit 'probleem' aangelopen en had sdb1 gemount, terwijl ik sda1 had moeten mounten. signature.asc Description: This is a digitally signed message part.
Re: Verwisseling sda en sdb
On Saturday, 9 July 2022 20:16:36 CEST Sjoerd wrote: > Nee, sda is een SSD van 256 GB, sdb een harde schijf van 1 TB. Voor de kernel zijn dat dezelfde categorie schijven, vandaar dat de schijfaanduiding bij allebei sdX is. > > Is het UEFI? > > Nee, nog altijd BIOS. > Misschien nog eens een idee om dit op UEFI over te zetten? > In de BIOS is te kiezen uit: > > - UEFI > - LEGACY+UEFI > > En de laatste is dus geselecteerd. > Maar dit lijkt me nog een hele operatie. Volgens mij komt dat neer op je systeem helemaal opnieuw installeren. Dus ja, dat is een hele operatie. En ik ben er vrij zeker van dat dat geen verschil zal maken mbt je 'probleem'. signature.asc Description: This is a digitally signed message part.
Re: Verwisseling sda en sdb
Paul van der Vlis schreef: > Waarom die sda en sdb soms verwisseld zijn weet ik ook niet, misschien > een timing issue. Vertel misschien wat het voor apparaten zijn, zitten > er USB apparaten bij? Nee, sda is een SSD van 256 GB, sdb een harde schijf van 1 TB. > En wat is de bootvolgorde in het bios? 1. USB-stick, maar er is geen USB aangesloten; 2. Die SSD. Ik heb de eerste uit de bootvolgorde verwijderd en de SSD op 1 gezet. Maar opnieuw gaat het nu eens goed en dan weer niet. > Is het UEFI? Nee, nog altijd BIOS. Misschien nog eens een idee om dit op UEFI over te zetten? In de BIOS is te kiezen uit: - UEFI - LEGACY+UEFI En de laatste is dus geselecteerd. Maar dit lijkt me nog een hele operatie.
Re: Verwisseling sda en sdb
On Saturday, 9 July 2022 18:05:11 CEST Sjoerd wrote: > Het volgende vreemde verschijnsel doet zich voor. (Debian testing) > Meestal, maar niet altijd, zie ik dat sda en sdb verwisseld zijn. Je kan/mag er NIET van uit gaan dat de letters constant naar dezelfde schijf wijzen. De kernel 'probed' (ontdekt) je hardware en kent er dan een letter aan. Ik neem aan dat de eerste die succesvol geïdentificeerd is, sda wordt. Maar er kunnen diverse factoren zijn die ervoor zorgen dat de identificatie van een schijf de ene keer langer duurt dan de andere. Mogelijk dat `dmesg` een indicatie geeft waarom het soms langer duurt dan verwacht. signature.asc Description: This is a digitally signed message part.
Re: Verwisseling sda en sdb
Hoi Sjoerd, Op 09-07-2022 om 18:05 schreef Sjoerd: Het volgende vreemde verschijnsel doet zich voor. (Debian testing) Meestal, maar niet altijd, zie ik dat sda en sdb verwisseld zijn. Bijvoorbeeld, bij een 'df' zie ik dat '/' op sdb2 zit, terwijl ik weet dat ik op sda2 zit. In gparted zie ik dat sda en sdb overal verwisseld zijn. Bij een 'blkid' zijn sda en sdb ook verwisseld. Dat is o.a. duidelijk te zien omdat ik sda1 t/m sda4 en sdb1 t/m sdb8 heb, maar 'blkid' laat sdb1 t/m sdb4 en sda1 t/m sda8 zien. Zelfs in /dev/disk/by-uuid zijn de links naar sdaX en sdbX verwisseld. Wanneer het een keer wel goed gaat, kloppen die links wel weer. Na een 'update-grub' zijn hd0 en hd1 in /boot/grub/grub.cfg ook overal verwisseld. Het is wel zo dat alles werkt. Maar als ik b.v. sdb8 wil mounten, dan komt de melding dat die niet bestaat; sdb8 is alleen te bereiken via sda8. Enig idee hoe dit kan? In fstab worden alle partities die gemount worden, aangeduid met 'UUID=...'. Ja, daarom gaat het goed. Waarom die sda en sdb soms verwisseld zijn weet ik ook niet, misschien een timing issue. Vertel misschien wat het voor apparaten zijn, zitten er USB apparaten bij? En wat is de bootvolgorde in het bios? Is het UEFI? Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Verwisseling sda en sdb
Het volgende vreemde verschijnsel doet zich voor. (Debian testing) Meestal, maar niet altijd, zie ik dat sda en sdb verwisseld zijn. Bijvoorbeeld, bij een 'df' zie ik dat '/' op sdb2 zit, terwijl ik weet dat ik op sda2 zit. In gparted zie ik dat sda en sdb overal verwisseld zijn. Bij een 'blkid' zijn sda en sdb ook verwisseld. Dat is o.a. duidelijk te zien omdat ik sda1 t/m sda4 en sdb1 t/m sdb8 heb, maar 'blkid' laat sdb1 t/m sdb4 en sda1 t/m sda8 zien. Zelfs in /dev/disk/by-uuid zijn de links naar sdaX en sdbX verwisseld. Wanneer het een keer wel goed gaat, kloppen die links wel weer. Na een 'update-grub' zijn hd0 en hd1 in /boot/grub/grub.cfg ook overal verwisseld. Het is wel zo dat alles werkt. Maar als ik b.v. sdb8 wil mounten, dan komt de melding dat die niet bestaat; sdb8 is alleen te bereiken via sda8. Enig idee hoe dit kan? In fstab worden alle partities die gemount worden, aangeduid met 'UUID=...'.
