Beiträge von su_lin_user

Hallo allerseits,

ein kleiner Nachtrag zu meiner eigenen letzten Frage:

Zitat von su_lin_user

Und was kann ich tun, damit sich grub2 bei der nächsten Gelegenheit nicht wieder die Booteinträge anderer Festplatten sammelt ?

Dazu gibt es einen perfekten Artikel für alle openSuse Interessenten.

Grub auf UEFI- und BIOS-Systemen einrichten und reparieren - LinuxCommunity

Auf UEFI-Systemen überschreibt eine OS-Installation einen bereits installierten Bootloader nicht mehr. Allerdings erscheinen dann meist zwei Bootmenüs…

www.linux-community.de

Gruß, su_lin_user

Hallo allerseits,

black_boot

Zitat von black_boot

Was du jetzt wieder mit markieren meinst, kann ich nicht nachvollziehen.

Tut mir leid, wenn ich gerade die Sache wieder unklarer gemacht habe. Eigentlich wollte ich nur wiederholen, was Du schon weiter oben geraten hast. Danke, dass Du die Sache trotzdem noch einmal wiederholst. Das kann nur zur festeren Gewissheit beitragen.

Feli

Zitat

Zitat von black_boot … wenn du ein update-grub hättest folgen lassen.

naja, wohl eher ein

Code

grub2-mkconfig -o /boot/grub2/grub.cfg

danke für den Tipp. Das werde ich noch mal ausprobieren.

Und was kann ich tun, damit sich grub2 bei der nächsten Gelegenheit nicht wieder die Booteinträge anderer Festplatten sammelt ?

Schönen Gruß, su_lin_user

Hallo,

ich habe mal einfach versucht die /etc/default/grub.old in grub umzubenennen, um zu sehen, ob damit wieder das Bootmenü auf den Stand vor dem Update ist. Das hat gar nichts gebracht, unverändert.

Was ich noch einmal nachfragen wollte:

Kann ich nach dem sonst alle Fragen geklärt sind versuchen die Linux-Version, die ich behalten möchte als bestimmendes System markieren, damit davon gebootet wird ? Danach dann die überflüssigen Distri's und deren Benutzer löschen ?

Wenn nichts mehr dagegen spricht, würde ich das dann so machen.

Gruß, su_lin_user

Hallo,

black_boot

Zitat

das tut er nur, wenn 'os-prober' auf aktiv geschaltet ist (in der Datei /etc/default/grub muß dazu einen Zeile GRUB_DISABLE_OS_PROBER=false stehen und ein update-grub ausgeführt werden.

Bei dem Update wurde die alte grub.cfg anscheinend unter grub.old aufbewahrt, bevor eine neue angelgt wurde.

linux@localhost:/etc/default> dir grub*
-rw-r--r-- 1 root root 1681 27. Aug 11:07 grub
-rw-r--r-- 1 root root 1386 17. Mai 15:35 grub.old

Allerdigs ist bei grub die Einstellung

GRUB_DISABLE_OS_PROBER="false" 

bei grub.old ist alles auf default, da gibt es den Parameter gar nicht.

Wenn ich nun grub lösche und grub.old auf grub umbenenne, kann ich dann davon ausgehen, wieder die vorherige Konfiguration zu haben ?

Gruß, su_lin_user

Hallo,

black_boot

Zitat

hä? Aus deinem 2. post

(im Original die # 19 und 20 (hier #4 und 5)

Das sind 1. ein device (Platte, o.ä.), nämlich /dev/sdd und 2. das DVD LW, /dev/sr0. Die SSD ist die nvme0n1. Auf /dev/ssd scheint nichts zu sein, keine Partition oder Dateisystem.

Entschuldige, das habe ich falsch interpretiert, da eine SSD on board für mich noch neu ist.

Ja, sdd ist leer. sr0 wäre das DVD-Laufwerk und ist auch leer.

nvme0n1 ist das SDD Laufwerk.

Korrektur Poste #10:

Zitat von su_lin_user

Neuigkeiten:

Also ich habe im Bootmanger der SSD (ssd, sr0) die Reaktionszeit von 72 sec. auf 7 sec. herabgesetzt. Danach hat Grub natürlich aktualisiert. ...

---> Korrektur

Also ich habe im Bootmanger der nvme0n1 die Reaktionszeit von 72 sec. auf 7 sec. herabgesetzt. Danach hat Grub natürlich aktualisiert. ...

Zitat von black_boot

wo in sda3 sind denn da die jeweiligen "/home" der verschiedenen Distri user?

Also ich habe überlegt, wie ich Dir das am besten zeigen kann.

tumb64_user1@linux:/home> ls -d */
lost+found/  suse_user1/  suse_user2/  tumb64_user1/  tumb_user1/  tumb_user2/

Zitat von black_boot

Du solltest doch mal das bootinfoscript (download, entpacken und ausführen) laufen lassen

Ich hab mal bei dem Open Build Service geschaut. Den bootinfoscript gibts für openSuse anscheinend nicht.

Grub2 ist anscheinend so gemacht, dass er alle auffindbaren Laufwerke nach Bootinformationen absucht und sammelt. Bis jetzt ist nur die Meldung erschienen. Vielleicht bleibt es auch nur dabei. Damit kann ich leben.

Schönen Gruß, su_lin_user

Hallo,

black_boot

Zitat

su_lin_user

Nein, die Benutzerdaten für Windows und Linux hatte ich beide auf sda. Natürlich getrennt wie man sieht.

Zitat

black_boot

Das ist nicht "zusehen".

Das ist nur am von mir gesetzten Label-Namen zu sehen. Für Dich kann das allein natürlich nicht verbindlich sein. (... das verstehe ich)

Zitat

black_boot

Zeige ein

Code

Code

mount /dev/sda3 /mnt && ls /mnt

Code

linux@localhost:~> sudo mount /dev/sda3 /mnt && ls /mnt
[sudo] Passwort für root: 
$RECYCLE.BIN  Desktop - Verknüpfung.lnk  System Volume Information

Zitat von black_boot

Empfehlung: eine separate "/home" legt man besser natürlich auch auf die schnelle nvme0n1. Ist diese "nicht groß genug" für die Nutzerdaten, kann man ja für solche Dateien (*.jpg, * .mp3, *.mp4 etc.) auf einer großen Platte entsprechende Verzeichnisse anlegen und die dann in den Verzeichnisbaum mounten z.B. ein /Bilder unter /home/benutzer1/Bilder. Und dieselbe /Bilder kann man auch bei einem weiteren /home/benutzer2/Bilder einbinden.

Der Grund, warum ich das /home von der schnellen SSD umziehen möchte ist, weil es sich aus meiner Erfahrung immer als praktikabel und vorteilhaft erwiesen hat, wenn die eigenen Daten auf einem extra Laufwerk liegen. Die Schnelligkeit ist für meine Zwecke nur zweitrangig.

Zitat

su_lin_user

Der oberste Eintrag der sichtbaren Bootreihenfolge, die von Grub2 anzeigt wird, hat wahrscheinlich nichts mit der führenden Distri zu tun ?

black_boot

doch hat er, aber nur, solange wie du keine Änderungen in

/etc/grub.d/* vorgenommen hast (die Nomenklatur dort bestimmt die Reihenfolge der grub Menüeinträge, 00_header 00_tuned 10_linux …)

Neuigkeiten:

Also ich habe im Bootmanger der SSD (ssd, sr0) die Reaktionszeit von 72 sec. auf 7 sec. herabgesetzt. Danach hat Grub natürlich aktualisiert. Grub2 hat bei der Aktualisierung alle nur auffindbaren LInux "Bootkommandos" der anderen Distris, von den anderen Laufwerken gesammelt und bei sich übernommen. Ich habe jetzt im Bootmanger auch die Auswahl z.B. Suse_Tumb_64 (siehe sdb9) zum Booten. Eigentlich wollte ich das gar nicht. Nur gut, dass die Windows Bootkommandos nicht auch noch übernommen wurden. (Dann wäre das Chaos perfekt). Ich war damit eigentlich zufrieden, dass der "neue Bereich" vom "alten Bereich" getrennt ist.

Außerdem kommt jetzt eine Fehlermeldung wenn ich - YAST - Bootmanger - öffne:

Zitat

Untersuchen von Festplatte /dev/nvme0n1 fehlgeschlagen

Unerwartete Situation im System festgestellt.

Klicken Sie unten, um weitere Details anzuzeigen (nur auf Englisch).

Continue despite the issue?

Command not found: "/usr/sbin/nvme list --verbose --output json"

Alles anzeigen

Was ist hier nun passiert ? (Meine Erfahrung zeigt ,,, am besten nie was verändern oder anfassen).

Gruß, su_lin_user

Hallo,

Zitat von black_boot

Windows war bei meiner Frage außen vor, es geht darum, ob du die verschiedenen "/home" alle auf einer Partition in getrennten Verzeichnissen hast.

Ja, jede Linux-Distri mountet /home auf sda3. Dadurch sind von jeder gebooteten Distri aus, auch die Benutzer der anderen Distris im /home Verzeichnis zu sehen.

Zitat von black_boot

das ist doch auch vollkommen uninteressant! Du willst von 4 auf sdb befindlichen Distris 3 löschen, dann mußt du für den CSM Bootmodus die verbleibende zur der den grub führenden Distri machen!

(Man kann z.B. mit dem bootinfoscript herausfinden, welches das aktuell führende System ist. Ich fürchte – weil du bei deiner Konstruktion selber nicht Bescheid weißt –, daß jedes System den grub jeweils in den selben MBR installiert hat, womit immer dasjenige den grub führt, in welchem zuletzt ein update-grub durchgeführt wurde)

Der oberste Eintrag der sichtbaren Bootreihenfolge, die von Grub2 anzeigt wird, hat wahrscheinlich nichts mit der führenden Distri zu tun ?

Hallo,

Zitat von black_boot

selbst Win7 schon reagiert "säuerlich" bei geänderten PC Komponenten, aber wenn du 's sagst…

Ich habe dabei nicht alles dazu gesagt. Weil Du sicherlich mit Deiner Aussage recht hast, kann ich nicht den Eindruck erwecken, bei mir sei das alles ganz anders.

Mir ist aufgefallen, dass Windows sofort aktiv wird, sobald man die benutzerspezifischen Einstellungen aktiv schaltet. Dann kommt sofort die Meldung, Windows hat bemerkt, dass sich die Hardwarekomponenten geändert haben; was soviel bedeuten soll, dass das Betriebssystem angeblich ohne Zulassung läuft. Deshalb verlangt Windows sofort den Registrier-Code. Stellt man den Schalter sofort wieder zurück ohne weiter etwas zu machen, gibt Win10 wieder Ruhe. Ich habe den Registrier-Code erst gar nicht eingegeben, da ich schon befürchtet habe - wie Du schon angedeutet hast - Windows dann systemische Probleme macht die man nicht mehr abschütteln kann. Dazu muss ich noch sagen, dass ich den meisten Kram von Win10 nie genutzt habe - also von Anfang an, nie aktiv geschaltet habe, da ich das alles nicht brauche. Ich brauche nur ein Betriebssystem das die Programme bedient und steuert.

Zitat von black_boot

nicht nur angeblich, hab 's selbst mehrfach getestet. Allerdings ohne zig weitere Partitionen wie z.B. extended (sdb4)

Schön, wenn man sich so gut auskennt, dass man es wagen kann. Ich fürchte daraus entstehende Probleme zu sehr.

Zitat von black_boot

meinst du Partititon, hier also sda3? Und dort hast du /home/user1 user2 user3 user4

Nein, die Benutzerdaten für Windows und Linux hatte ich beide auf sda. Natürlich getrennt wie man sieht.

Zitat von black_boot

das legst du dadurch fest, daß du das System, welches du behalten möchtest, bootest, und dort eben ein grub-install /dev/sdx ausführst (x wie oben beschrieben eruieren)

Ich weiß momentan nicht welche Distri die bestimmende ist. Kann ich mir das durch ein Kommando anzeigen lassen, ohne dass ich es erst neu festlege, wie Du beschrieben hast?

Zitat von black_boot

ja, natürlich nicht für den von dem System, welches du behalten möchtest. Die entsprechenden Partitionen (sdb6, sdb7, sdb8) löschst du mit z.B. gparted, die Unterverzeichnisse im /home mit rm -r /home/userx

Ja, dann ist das für mich klar. Ich wollte es nur noch einmal bestätigt haben, damit ich Dich wirklich richtig verstanden habe.

Also vielen Dank.

Hallo,

danke für Deinen Beitrag.

Zitat von black_boot

es existiert eine alte Platte mit MBR Partitionsschema und Windows darauf, diese Platte soll in einen neuen PC (mit EFI boot)

Ja, ich war auch lang im Zweifel darüber, ob das überhaupt funktionieren kann. Jetzt nach dem ich es ausprobiert habe. kann ich bestätigen ,dass es funktioniert hat, in der Konfiguration wie ich es als filetree gezeigt habe.

Zitat von black_boot

das wird vermutlich auf eine Neuaktivierung für Windows hinauslaufen (ziemlich sicher!) Außerdem mußt du dann zum Wechseln auf Windows den Bootmodus umschalten.

Ich verwende noch Win10. Da gibt es anscheinend noch keine Probleme. Ab Win11 könnte es sein, dass das von vornherein nicht funktioniert, da es secure boot und GPT UEFI erwartet. Wenn ich das "alte System" boote, muss ich das über das Bootmenü im Bios starten. Aber es geht.

Zitat von black_boot

du willst doch bestimmt möglichst einen Bootmanager verwenden, den vom System auf nvme0n1p2, oder? Dann kannst du Windows auch gleich neu installieren, Platte im GPT Schema. (man kann auch Windows mit mbr2gpt.exe entsprechend umwandeln, k.A., was dann mit so div. Partitionen auf der Platte passiert).

Mir war einfach nur wichtig, dass ich mein "altes System" vom nicht mehr vorhandenen PC weiter verwenden kann. Wenn man alt und neu vereint, erfordert das wieder viel Arbeit und Verständnis. Ich bin nur Anwender, deshalb fehlen mir die speziellen Fachkenntnisse die ein Administrator hat.

Ich habe gelesen, dass Windows angeblich aus einer MBR Boot-Partition eine GPT Boot-Partition machen kann. Ich habe das noch nicht versucht, und aus Erfahrung klappt das nie so, wie man es so einfach lesen kann. Deshalb lasse ich davon besser die Finger weg. Im Vordergrund steht für mich ... Hauptsache es funktioniert mal vorerst ohne Probleme.

Zitat von black_boot

du hast 4x SuSe (sdb6-9) und für alle nur 1x "/home" auf sda3? Du willst Suse_Tumb_64bit behalten?

Ja, ich habe die Benutzer der verschiedenen Distributionen alle auf dem gleichen Laufwerk. Jetzt möchte ich die unbenutzten, veralteten Distributionen und deren Benutzer löschen. Möglichst so, dass es danach keine Probleme mit den noch verbleibenden Distri's gibt.

Zitat von black_boot

wenn du das alte Bootverfahren beibehalten möchtest für Suse_Tumb_64bit, dann mußt du dafür sorgen, daß ebendieses den MBR "regiert", sprich: Boote es und führe `grub-install /dev/sdX` aus (X ist dann entsprechend der Plattenbezeichnung im neuen System)

Genau das war eine meiner brennenden Fragen. Wie stelle ich fest, welche Distri ist das Hauptsystem, und wie bestimme ich dann die von mir bestimmte Distri zum Hauptsystem.

Zitat von black_boot

wenn das mit grub so laufen soll (nicht alles zusammen vom System auf nvme0n1p2 aus, dann kannst du die Partitionen sdb6-8 und die zugehörigen "/home/$USER" löschen, falls da nicht noch sonstwo Daten von Wichtigkeit sind ("/home/$USER/…")

Ok, bei diesem Punkt war ich mir sehr unsicher was das alles auslösen kann. Wie Du es jetzt beschreibst erscheint es relativ einfach. Unter /home existieren keine wichtigen Daten, die ich sichern müsste. Ich habe den jetzt nicht mehr vorhandenen PC mit "altem MBR System" nur als Alternativ-PC verwendet. Trotzdem hat er mir noch wertvolle Dienste geleistet.

Also, wenn Du löschen sagst, meinst Du rm -r für die Benutzer?

Vielen Dank erst mal, das hat mir schon viel geholfen.

Hallo,

um mein Anliegen konkreter zu machen, zeige ich darunter den filetree von dem betreffenden PC.

linux@localhost:~> lsblk -o NAME,FSTYPE,FSVER,LABEL,UUID,MOUNTPOINTS,PARTTYPE
NAME       FSTYPE FSVER LABEL           UUID                                 MOUNTPOINTS PARTTYPE
sda                                                                                      
├─sda1     ntfs         Win_Daten       6E00DC5800DC293B                                 0x7
├─sda2     vfat   FAT32 Transfer        6370-8B23                                        0xc
└─sda3     ext4   1.0   Suse_Daten      36f888d7-b7af-4711-a419-2fbbb14da203             0x83
sdb                                                                                      
├─sdb1     ntfs                         F67A86027A85BFBB                                 0x7
├─sdb2     ntfs                         BCB6D564B6D51FA6                                 0x7
├─sdb3     ntfs                         5D7C652702341B77                                 0x7
├─sdb4                                                                                   0x5
├─sdb5     swap   1     Linux_Swap      7bd81ea3-4515-4437-8d94-4d5ada9c3dfa             0x82
├─sdb6     btrfs        Suse_Leap_15.1  35d6f6e2-513c-41e8-964d-e3d96118b2b3             0x83
├─sdb7     btrfs        Suse_Tumb_32bit cf1882f5-f695-4f5e-8c31-a33e4dc1e6d4             0x83
├─sdb8     btrfs        Suse_Leap_15.2  5d257700-aebf-4329-8813-82114ee5ef87             0x83
└─sdb9     ext4   1.0   Suse_Tumb_64bit eee0f27c-2f88-4ade-9266-b6573ecd969f             0x83
sdc                                                                                      
└─sdc1     ext4   1.0                   7f8e53ed-de1b-4bf7-b043-4f6031b9bb2f             0fc63daf-8483-4772-8e79-3d69d8477de4
sdd                                                                                      
sr0                                                                                      
nvme0n1                                                                                  
├─nvme0n1p1
│          vfat   FAT16 SYSTEM          4254-464B                            /boot/efi   c12a7328-f81f-11d2-ba4b-00a0c93ec93b
├─nvme0n1p2
│          ext4   1.0   ROOT            aa98023d-d89d-4189-a6a2-879f6bad9476 /           0fc63daf-8483-4772-8e79-3d69d8477de4
├─nvme0n1p3
│          swap   1     SWAP            9606fdf8-d458-4d80-8374-bda2e3cc9c45 [SWAP]      0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
└─nvme0n1p4
           ext4   1.0   HOME            786f72c5-09e9-4936-be83-23719c730f62 /home       0fc63daf-8483-4772-8e79-3d69d8477de4

Zur Erklärung:

Der PC ist von der Ausstattung in der Lage MBR Legacy und auch GPT UEFI zu booten. Daher existieren 2 Bereiche. Der eine neue Bereich gehört zu den neuen PC. Der andere Bereich stammt von einem nicht mehr vorhandenen alten PC.

1) neuer Teil unter GPT UEFI.

sdd (System, LInux)

SSD Laufwerk on Board als Systempartition. Momentan ist /home noch hier untergebracht, soll dann auf sdc umziehen.

sdc (/home)

HDD Laufwerk, 2TB partitioniert als ext4, noch leer, soll als Ersatz für /home auf sdd eintreten.

2) alter Teil unter MBR Legacy.

sdb (Systeme, Win/Linux)

HDD Laufwerk, 500GB.

sda (Win Daten/ /home Benutzer)

HDD Laufwerk, 2TB nur als Speicher für Benutzerdaten.

Unter 2) sollen auf sdb nicht mehr benutzte Partitionen (bzw. darauf enthaltene Distributionen) frei gemacht werden. Das wären z.B. sdb6, sdb7, sdb8. Ebenfalls sollen die den Distributionen zugeordneten Benutzer auf sda /home mit allem was dazugehört gelöscht werden.

Wer kann dabei helfen ? Ich selbst traue mir das nicht ganz zu, wegen Bedenken, das Restsystem könnte hinterher nicht mehr verwendbar sein.

Danke für eure Meldungen.