grub2: recovery mode - sysvinit

[michaa7]

EDIT: hatte ich vergessen: system debian/sid(uction) tagesaktuell)/EDIT

2 installationen auf einen system: update-grub generiert (nun wieder, siehe anderes posting) einträge für das grub bootmenü. Im älteren system, welches aber bereits mit systemd bootet, werden dennoch für jeden kernel noch ein alternativer booteintrag generiert, der das booten über sysvinit erlaubt. Das hat mir schon verschiedenlich weitergeholfen wenn systemd verwurstelt war.

Für das neue system werden diese einträge nicht erzeugt (bei ausführung von update-grub vom alten system aus. Das alte system ist immer noch mein hauptsystrem).
Nun bin ich auf der suche nach einer einstellung (in grub? os-prober? wo-auch-immer) die das ermöglicht. Die einstellung in /etc/default/grub den recoverymode betreffend ist dafür aber nicht hilfreich. Da jedoch auch ein editieren der bootzeile (hinzufügen von "init=/sbin/init.sysvinit") in *diesem* system kein booten mit sysvinit ermöglicht frage ich mich ob meine vage erinnerung richtig ist, dass dies bereits bei der *installation* festgelegt wird und danach nicht mehr eingerichtet werden kann (was sehr bedauerlich wäre. Hoffentlich irre ich mich ).

Kurz: Gibt es eine möglichkeit

1: überhaupt ein systemd system *nachträglich* mit der fähigkeit auszustatten, ggf. mit sysvinit zu booten?
2: kann update-grub die entsprechenden einträge dann generieren?

[rendegast]

sysvinit-core und libpam-systemd / systemd-shim installieren.
Das Generieren und die Darstellung kann über grub.d/ und default/grub-Optionen geregelt werden.

[michaa7]

1. Ich will nicht systemd durch sysvint ersetzt, das würde aber durch installation von sysvinit-core erzwungen.

2. Ich habe mehr als eine stunde die configfiles durchforstet und nichts gefunden was irgendwie die erstellung von sysvinit booteinträgen regelt. Bist du sicher dass dein tipp mehr als eine hoffnungsfrohe vermutung ist?

[rendegast]

1. Ich will nicht systemd durch sysvint ersetzt, das würde aber durch installation von sysvinit-core erzwungen.

Nein, sysvinit-core conflicts mit systemd-sysv, nicht mit systemd.




Aua, es hängt an einem "Fehler" in grub.d/10_linux (und 20_linux_xen):
Dort gibt es eine Vorgabe SUPPORTED_INITS mit einem /lib/sysvinit/init.
Das gibt es aber nicht mehr so in debian, dort gibt es nur mehr /sbin/init, entweder sysv oder als systemd-Link.


Es müßte sysvinit-core installiert werden, um überhaupt sysv zu machen.
Dann könnte entweder ein Link
/lib/sysvinit/init -> /sbin/init
konstruiert werden oder in obiger Datei ist SUPPORTED_INITS entsprechend zu modifizieren.
Leider ist ein einfacheres, systemkonformes Einwirken über /etc/default/grub[.d/] nicht vorgesehen.
(Beides hat sein Problem, der Link würde auf systemd zeigen wenn sysvinit-core deinstalliert würde,
die Dateiänderung betrifft eine Systemdatei, was bei Upgrades zu beachten wäre.)

Anm.: Das alte Paket sysvinit lieferte
/lib/sysvinit/init
/lib/sysvinit/telinit -> init

[smutbert]

Für das neue system werden diese einträge nicht erzeugt (bei ausführung von update-grub vom alten system aus. Das alte system ist immer noch mein hauptsystrem).

Werden denn diese Einträge vom/im grub des neuen Systems erzeugt?

[michaa7]

Nein, sysvinit-core conflicts mit systemd-sysv, nicht mit systemd.

Recht du hast , da hab ich beim lesen geschlurt.

Aber im weiteren verstehe ich deine erklärungen nicht ausreichend. Vor allem weil auch im alten system, von dem aus ich ja grub die einträge erzeugen lasse sysvinit-core *nicht* installiert ist (aber vermutlich zu beginn mal installiert war. Ob das den entscheidenden unterschied macht kann ich deinen erklärungen nicht entnehemen. Ist das so?) Sonst sollte es doch genügen grub.d/10_linux (und 20_linux_xen) sorgfälltigst angepaßt soweit es pfade und devices betrifft vom alten ins neue system zu kopieren. Ich werde mir das morgen mal anschauen was der vergleich der jeweiligen dateien an unterschieden hergibt.

Werden denn diese Einträge vom/im grub des neuen Systems erzeugt?

update-grub rufe ich im alten system auf. Und dieses system beherbergt grub. Ob dann im verlauf grubdateien des neuen system ein rolle spielen ist mir nicht klar. Aber irgendwie gehe ich davon aus, sonst dürfte es ja diesen unterschied garnicht geben. Aber einen testlauf von neuen system aus will ich vermeiden, weil dann ja die liste im alten systen ihre gültigkeit verliert.

[KP97]

Das wird aus Deinem Beitrag mit "altem und neuem System" nicht klar, aber wenn das neue System auf einer eigenen Partition liegt, brauchst Du dort überhaupt keinen Grub.
Das Booten besorgt ja der Grub im alten System.
Also den Booteintrag für das zusätzliche System anpassen, os-prober ist ja wohl installiert.

Ist das ein alter Rechner ohne UEFI, ansonsten wäre grub-efi-amd64 das richtige Paket.

[michaa7]

Aua, es hängt an einem "Fehler" in grub.d/10_linux (und 20_linux_xen):
Dort gibt es eine Vorgabe SUPPORTED_INITS mit einem /lib/sysvinit/init

Die betreffenden zeilen sind in beiden systemen identisch. Insoweit erscheint mir deine analyse nicht den kern des problems zu treffen, nämlich warum funktioniert die gleiche konfiguration auf beiden systemen unterschiedlich?

Auch ist sysvinit-core in keinen der beiden systeme installiert.

[michaa7]

Aua, es hängt an einem "Fehler" in grub.d/10_linux (und 20_linux_xen):
Dort gibt es eine Vorgabe SUPPORTED_INITS mit einem /lib/sysvinit/init

Die betreffenden zeilen sind in beiden systemen identisch. Insoweit erscheint mir deine analyse nicht den kern des problems zu treffen, nämlich warum funktioniert die gleiche konfiguration auf beiden systemen unterschiedlich?

Auch ist sysvinit-core in keinen der beiden systeme installiert.

Das wird aus Deinem Beitrag mit "altem und neuem System" nicht klar, aber wenn das neue System auf einer eigenen Partition liegt,

vermutlich verstehe ich dein frage nicht so ganz, wo, wenn nicht in einer eigene partition soll das zweite system den sonst liegen. Und ja, es ist nicht nur eine egene partition, sondern sogar ein ganz andere physikalische festplatte.

Also den Booteintrag für das zusätzliche System anpassen, os-prober ist ja wohl installiert.

Es hat früher immer ohne händischen booteintrag funktioniert, das möchte ich so wieder haben

[KP97]

... wo, wenn nicht in einer eigene partition soll das zweite system den sonst liegen. Und ja, es ist nicht nur eine egene partition, sondern sogar ein ganz andere physikalische festplatte.

Genau darum ging es mir.
Aber Deine Antworten an mögliche Helfer lassen (wie meistens) zu wünschen übrig, daher werde ich künftig auf Beiträge verzichten.

[michaa7]

meine güte, was hab ich denn jetzt wieder falsch gemacht. Wo wenn nicht in einer eigenen partition soll denn ein zweitsystem liegen? Ahhh ok, ist ohne UEFI (ich seh das halt andersrum, hätte es erwähnt wenn's mit wäre, ok, diesbezüglich bin ich nicht up-to-date.

[rendegast]

Auf den beiden funktionierenden Systemen gibt es
/lib/sysvinit/init
/lib/sysvinit/telinit -> init
(auf das die 10_linux von grub reagiert)
?
Ich vermute über das mittlerweile nicht mehr bereitgestellte Paket sysvinit.

Code: Alles auswählen

locate sysvinit/init
dpkg-query -S sysvinit/init

[michaa7]

Ok, da kommen wir -vermutlich- der sache näher:

Im alten system finde ich *alles* so vor wie von dir aufgelistet. Im neuen system *nichts davon*. Es scheint also am fehlenden sysvinit paket zu liegen.

Jetzt kann ich das so akzeptieren, oder ich schaue was passiert wenn ich versuche das jüngste sysvinit aus den snapshots zu installieren, ob das überhaupt noch geht (immerhin existiert das ja alles noch im alten, aber so tagesaktuellen system wie das neue ohne sysvinit!).
Es war halt ein paar mal sehr hilfreich noch so booten zu können. Die recoverykonsole war längst nicht so hilfreich (wobei ich nicht weiß ob der recovery mode das gleiche oder etwas anderes ist?)
Andererseits kann das ja auch keine dauerlösung sein ... aber solange es funktioniert? Mal schaun am WE.

Danke soweit.