lilo "optional" geht nicht mehr?

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
TuxPeter
Beiträge: 1965
Registriert: 19.11.2008 20:39:02
Lizenz eigener Beiträge: MIT Lizenz

lilo "optional" geht nicht mehr?

Beitrag von TuxPeter » 25.06.2017 12:21:28

Hallo Debianfreunde,

ich habe ein HDD im Desktop-PC, die über einen Schalter (2-polig, für 5 u. 12V-Leitung) stillgelegt/aktiviert werden kann. Damit es kein versehentliches "hotplug" gibt, ist der an der Rückwand.
Auf der meist ausgeschalteten Platte gibt es u.a. auch ein Bootloader mit Lilo, weil ich es (mit Lilo, mit Grub schon) nicht hinbekommen habe, beides wahlweise mit einem einzigen Lilo zu starten. Dieses System wird dann bei Bedarf hiermit gestartet (aus der lilo.conf des Hauptsystems)

Code: Alles auswählen

other  = /dev/sdc
        label = "alte Platte"
        optional
#     unsave
        loader = chain
Das "optional" hat bisher bewirkt, dass auch die ausgeschaltete Platte z.B. nach einem Kernel-update und automatischem lilo-Lauf die "alte Platte" bootbar blieb. Jetzt in Stretch muss ich den lilo-Lauf mit eingeschalteter Platte wiederholen. Da nützt auch zusätzlich "unsave" nichts, weshalb es wieder auskommentiert wurde.
Kennt ihr eine Möglichkeit zu bewirken, dass der lilo-Lauf auf dem Hauptsystem wie bisher den "other ..." Abschnitt in Ruhe lässt, auch wenn die betreffende HDD ausgeschaltet ist? Dafür sollte doch "optional" da sein, wie ich es verstanden habe.

KP97
Beiträge: 3432
Registriert: 01.02.2013 15:07:36

Re: lilo "optional" geht nicht mehr?

Beitrag von KP97 » 25.06.2017 17:23:09

In meiner "Vor-UEFI-Zeit" habe ich außer extlinux auch ganz gerne lilo benutzt, weil lilo so flexibel ist.
Wenn ich Dich richtig verstehe, hast Du auf dem Hauptsystem lilo und auch mehrere Partitions?
Taucht die "alte Platte" unter /media auf, oder wohin wird gemountet? Ist die auch in der fstab eingetragen?

Ich hatte mir damals zur lilo.conf folgende Info notiert:
# Chainloading
# other = /dev/sda6
# label = Windows
# wird nur bei NICHT-Linuxsystemen benötigt

# Fremdsysteme können auch mit dem eigenen Kernel gestartet werden.
# Wichtig ist die Pfadangabe des Kernels.
# /boot/vmlinuz-4.7.0-rc5
#
# oder auch der Kernel des Fremdsystems
# /media/Mate/boot/vmlinuz-4.4-x86_64
#
# Ein zusätzlicher Bootloader wird nicht benötigt
-----------------------------------------------------------------------------
Muster:
#image = /media/Mate/boot/vmlinuz-4.4-x86_64
# initrd = /media/Mate/boot/initramfs-4.4-x86_64.img
# label = Mate
# root = /dev/sda6
# append = "quiet mce=0 selinux=0 fsck.mode=skip"
Meine ersten beiden Partitionen waren ein Sid mit eigenem Kernel ohne initrd, die 3. Partition war ein fremdes Mate mit Standardkernel und initrd.
Ein chainload habe ich nie benutzt, sondern immer nur die einzige lilo.conf nach den vorigen Angaben erweitert.
Ich hoffe, das ist einigermaßen verständlich, probier einfach mal etwas rum.

TuxPeter
Beiträge: 1965
Registriert: 19.11.2008 20:39:02
Lizenz eigener Beiträge: MIT Lizenz

Re: lilo "optional" geht nicht mehr?

Beitrag von TuxPeter » 25.06.2017 20:31:52

Danke für die Antwort!
Das booten verschiedener Systeme auf einem HDD ging auch bei mir immer problemlos und so, wie Du das beschrieben hast, egal ob Windows oder Linux. Das booten verschiedener Systeme auf verschiedenen HDDs hat bei mir bisher nur mittels chainloading geklappt*), wofür die verkettete HDD natürlich ihren eigenen bootloader braucht, egal welchen.

Das Chain-Loading für den zeitweilig ausgeschalteten HDD wurde beim Eintragen von "optional" früher immer beibehalten, jetzt (aber noch vor stretch --> stable) nicht mehr. Das ist zwar nicht wirklich wichtig, aber etwas unbequem, weil da immer ein zusätzlicher Systemstart mit Lilo-lauf nötig ist.

Früher ging das so: Platte einschalten, Rechner mit gewünschtem System booten.
Jetzt: Platte einschalten, Standardsystem booten, Lilo-Lauf, runterfahren, gewünschtes System booten.

Danach hat man allerdings Ruhe, bis zum nächsten Update. Der dafür, falls ein Kernel-Update dabei ist, auch einen händischen Lilo-Lauf mit obigem Procedere braucht.

*) natürlich muss das 2. System vor dem Lilo-Lauf gemountet sein. Das geht aber nur, wenn der betreffende Datenträger zugreifbar ...

Antworten