Von 32bit- auf 64 bit-Kernel wechseln?

moonwalker99

Lt. Commander
Registriert
Jan. 2008
Beiträge
1.959
Ich habe hier eine Linux Mint 32bit DVD gebrannt. Die Installation auf einem 32bit-Rechner ist erledigt, jetzt habe ich noch einen 64bit-Rechner hier. Könnte ich theoretisch die Installation mit meiner 32bit DVD durchführen und hinterher einen passenden 64bit Kernel nachinstallieren? Oder muss ich mir eine 64 bit-DVD runterladen? Letzteres würde ich mir nämlich gerne ersparen.
 
Du solltest schon die 64bit-Version herunterladen & auch installieren.
Habe noch nicht davon gehört, dass man ein laufendes 32bit-System dazu überreden konnte, einen 64bit-Kernel zu installieren ...

Grüße
 
Kurz und knapp: Klappt nicht... eben weil, anders als unter Windows, quasi jedes Paket für 64Bit kompiliert wurde. Außerdem heißen die 32Bit-Pakete (als Fallback für 32Bit-Anwendungen, wie z.B. Wine) in einer 64Bit-Version anders als unter Linux-32Bit.

Falls es von Mint ein Micro-Image gibt... das wäre deine beste Chance, platzsparend zu laden. Ansonsten wechsel die Distri, von Ubuntu gibts z.B. Micro-Images.
 
Jop, das Vorhaben ist (quasi) unmöglich, zumindest wenn man danach noch ein normal funktionierendes System haben will...
 
Daaron schrieb:
Kurz und knapp: Klappt nicht... eben weil, anders als unter Windows, quasi jedes Paket für 64Bit kompiliert wurde. Außerdem heißen die 32Bit-Pakete (als Fallback für 32Bit-Anwendungen, wie z.B. Wine) in einer 64Bit-Version anders als unter Linux-32Bit.
OK, das klingt plausibel.

Wäre vielleicht schön, wenn ich die 32bit-DVD als live system nehmen könnte, um dann die 64bit-Pakete aus dem Internet installieren zu lassen. Wird aber vermutlich genauso wenig klappen.
 
Ne, eher nicht.
Wie gesagt, nimm einfach ne andere Distribution. Eine Distri, die es nur auf DVD gibt, fällt bei mir schlichtweg durch.
 
Daaron schrieb:
Ne, eher nicht.
Wie gesagt, nimm einfach ne andere Distribution. Eine Distri, die es nur auf DVD gibt, fällt bei mir schlichtweg durch.
Ist für einen Bekannten, der mit älteren Rechnern arbeitet und nicht viel Ahnung von Technik hat. Da ist Mint eine gute Wahl.

Hat jemand schon mal eine Installation mit einem USB-Stick durchgeführt?
 
genau heißt es:

64bit kernel 32bit userland linux

das Problem ist, dass es bei den ganzen binären (vorkompilieren) Distros nicht so einfach zu bewerkstelligen ist, da wohl evtl. ein paar zusätzliche libs installiert werden müssen

weiters müssen alle Kernel-module 64bittig sein, das kann man meines Wissens bei Debian, Ubuntu, Mint, etc. nicht explizit so einstellen

bei Gentoo z.B. ginge das, aber das ist eine ganz andere Geschichte

es ist also möglich und läuft auch - allerdings mit Aufwand verbunden



kurze Antwort: 64bit neu installieren

was verhoffst du dir denn von 64bit ?

hast du überhaupt genug RAM ?

64bit ist mit einem Overhead bzw. zusätzlichem Mehraufwand an Speicherbedarf verbunden

allerdings sind viele Programme und Prozesse unter 64bit natürlich etwas schneller als mit 32bit


um dem (dem zusätzliche Speicher- und Verwaltungsaufwand) entgegen zu wirken wurde dafür die x32-abi in das Leben gerufen:

http://en.wikipedia.org/wiki/X32_ABI

für die ganzen binären Distros gibt es hierfür glaub ich noch keine Beta, RC, etc.
 
moonwalker99 schrieb:
Ist für einen Bekannten, der mit älteren Rechnern arbeitet und nicht viel Ahnung von Technik hat. Da ist Mint eine gute Wahl.
Mint ist ein aufgeblasenes Ubuntu mit etwas modifizierter GUI... Von daher... alles was Mint kann, kann Ubuntu selbst auch.

Hat jemand schon mal eine Installation mit einem USB-Stick durchgeführt?
Nicht mit Mint, aber mit Debian, Ubuntu... und Windows 7 *G*
Geht alles einwandfrei, ist definitiv angenehmer als von ner CD/DVD, weil schneller.

Mein letztes Ubuntu hab ich sogar von ner 128MB großen uralten CompactFlash aus installiert (und die hat neben den Installer-Files noch ~100MB frei).
 
moonwalker99 schrieb:
Könnte ich theoretisch die Installation mit meiner 32bit DVD durchführen und hinterher einen passenden 64bit Kernel nachinstallieren?
Ja. Es ist sogar zu empfehlen, trotz 32bit-Userland einen 64bit-Kernel einzusetzen, wenn die CPU diese Betriebsart beherrscht. Leider bieten einige x86-Distris keinen 64bit-Kernel über ihr Paketssystem an.

moonwalker99 schrieb:
Oder muss ich mir eine 64 bit-DVD runterladen? Letzteres würde ich mir nämlich gerne ersparen.
Habe keine Ahnung von Mint. Stammt das nicht von Debian ab? Dann dürfest du via "apt-cache search ^linux-image" sehen können, welche Kernel deine Distri als Paket anbietet. Sonst kannst du dir den Kernel aus der 64bit-Distribution von Mint klauen und manuell installieren, aber davon würde ich dir angesichts deiner Fragestellung abraten.

Die jeweils ersten Antworten von Asinuss, MiesMosel, Daaron, Necareor sind falsch. Man brauch bei Linux abseits des Kernels kein einziges Programm und keine einzige Bibliothek in einer 64bit-Version, um ein 32bit-Userland auf einem 64-bit-Kernel zu betreiben. Kernel austauschen und fertig.
 
Zuletzt bearbeitet:
Ja, es ist aber reichlich sinnbefreit, einen 64Bit-Kernel mit 32Bit-Software zu koppeln. Dann bist du am Ende doch wieder bei Windows...
 
Grober Unfug @Daaron. Das Gegenteil ist der Fall. Linux profitiert intern massiv von den Fähigkeiten der 64bit-CPUs und bedient dadurch auch ein reines 32bit-Userland besser als ein 32bit-Kernel. Wann immer es die Hardware hergibt und Performance nicht völlig egal ist, sollte man diesen Effekt ruhig nutzen.
 
Die Regeln für den Adressraum gelten unter Windows genau wie unter Linux oder jedem anderen OS mit virtueller Speicherverwaltung. Ein 32Bit-GIMP wird auf einem 64Bit-Kernel genau so Speichernot bei großen Grafiken kriegen wie auf einem 32Bit-Kernel, und das obwohl ein Linux-Kernel, anders als Home-Windows, dank PAE nicht so schnell ins Speicherloch fällt.
Es ist immer ratsam, ein möglichst natives System zu basteln.

Übrigens hast du eine Sache vergessen: Eine echte 64Bit-Installation lagert in /usr/lib die 64Bit-Libs, die 32Bit-Libs liegen in /usr/lib32. /usr/lib64 ist ein Symlink auf /usr/lib. Eine 32Bit-Installation lagert im Zweifel 32Bit-Libs in /usr/lib und hat gleich mal gar kein /usr/lib64. Hier sind Konflikte vorprogrammiert, falls du doch mla auf 64Bit-Software setzen willst, um z.B. mehr Speicher alloziieren zu können.
 
freak01 schrieb:
...
64bit ist mit einem Overhead bzw. zusätzlichem Mehraufwand an Speicherbedarf verbunden
...
Von dem Overhead spürt man in der Regel absolut gar nichts und der größere Speicherbedarf kommt auch selten zum tragen. Viel wichtiger ist, dass ein x86-64-Prozessor im 64b Modus 16 General Purpose Rechenregister hat, statt 8 bei x86-32 bzw. im 32b Modus. Auf 64b auch im Userland würde ich nur verzichten, wenns bestimmte (proprietäre) Programme erfordern. Ehrlich gesagt fällt mir dazu aber nur der Flashplayer ein und ein 32b Flashplayer lässt sich ja auch in einem 64b-Firefox nutzen. (nspluginwrapper)
 
Genau deshalb gibt es seit dem Kernel 3.4 ein x32-Abi, das die Vorteile beider Welten vereint ;)

Nur 32-bit speicheradressen, dadurch hat man weniger Overhead beim Speicher, dafür kann ein Programm nur 4 GB virtuellen Speicher besitzen (was vllt. bei extrem speicherhungrigen Anwendungen zu wenig ist). Dafür hat man aber eben alle 16 Register.

Natürlich muss man da erstmal alle Tools für compilen, denn Distris gibts bis jetzt noch nicht, die das unterstützen.
 
@MountWalker:

etwas höheren Speicherverbrauch hab ich schon bemerkt, die höhere Geschwindigkeit ist für mich aber wichtiger - nur für Systeme mit wenig Speicher könnte das ein Problem darstellen und wenn man massiv Multitasking durchführt - darauf wollte ich hinaus

den Overhead hab ich selbst mit einem athlon 3200+ (bei 2 ghz) nicht bemerkt

einige Problemchen, die mir mit 64bit und Intel Hardware aufgefallen sind, waren:

wenn man größere Programme mit optimierten CFLAGS kompiliert, dass das System nicht oder schlecht reagiert - mit 32bit trat das nicht auf

weiters reagiert das System auch recht träge, wenn z.B. mehrere Gigabytes (neu) von einer auf eine andere Partition bzw. Platte kopiert werden

die letzteren zwei Punkte sollten also berücksichtig werden, wenn man viel mit i/o Transfers oder starker Auslastung (sämtlicher Register via Compiler ?) zu tun hat - ob das jetzt speziell mit Intel und 64bit zu tun hat oder ein generelles Problem mit 64bit ist, kann ich nicht sagen

jedenfalls wird es durch Benutzung von dem BFS ("Brain Fuck Scheduler") in Verbindung mit CFQ (i/o scheduler) tweaks um einiges besser






@stwe:

wenn das jetzt noch rückwärtskompatibel mit normalen 32bittigen binaries wäre, wäre das ganze für die breite Masse in naher Zukunft vermutlich sogar überlegenswert :)




das hab ich doch oben ausgeführt ;)

(also zumindest meines Wissens) gibt es von Gentoo bereits einen stage3 tarball mit gepatchtem glibc und gcc, die diese neue x32 abi unterstützen

mich würde allerdings interessieren, ob das mit gängigen liveCDs über chroot überhaupt funktioniert - wahrscheinlich wird eine spezielle liveCD dafür angeboten

hab mich damit ehrlich gesagt noch nicht so tiefgreifend auseinandergesetzt



für Ubuntu wird das ganze wohl noch erst diskutiert:

http://www.phoronix.com/scan.php?page=news_item&px=MTEwMTk
 
Zuletzt bearbeitet:
Daaron schrieb:
Die Regeln für den Adressraum gelten unter Windows genau wie unter Linux oder jedem anderen OS mit virtueller Speicherverwaltung. Ein 32Bit-GIMP wird auf einem 64Bit-Kernel genau so Speichernot bei großen Grafiken kriegen wie auf einem 32Bit-Kernel, und das obwohl ein Linux-Kernel, anders als Home-Windows, dank PAE nicht so schnell ins Speicherloch fällt.
Es ist immer ratsam, ein möglichst natives System zu basteln.

Nochmal zum mitmeißeln: Ein Kernel erledigt eine Menge Dienste für die normalen Programme. Das ist sein Job. Die Programme (meist über den Umweg libc) nutzen diese Dienste via Syscalls. Der 64bit-Kernel bietet 32bit-Programmen das gleiche Interface wie ein 32bit-Kernel, ABER der 64bit-Kernel kann INTERN sämtliche Vorteile der amd64-Plattform nutzen und ist deshalb a) bei einigen Syscalls und b) bei seiner internen Verwaltung teils um Welten effektiver. Ein paar (ältere) Benchmarks als Beispiele für ein 32bit-Userland auf unterschiedlichen Kerneln findest du hier.

NIEMAND hat behauptet, dass einzelne 32bit-Progamme plötzlich mehr Speicher sehen, rosarot leuchten oder besser duften, wenn man sie auf einem 64-bit Kernel laufen läßt. Du brauchst das alles nicht zu widerlegen.

BTW: Weil du mit PAE anfängst ... Wer auf einem Rechner, der eine 64bit-fähige x86-CPU und viel RAM hat, einen 32bit-Kernel mit PAE fährt, ist ganz offiziell pervers. Nicht meine Wortwahl, ich zitiere nur Linus.

Daaron schrieb:
Übrigens hast du eine Sache vergessen: Eine echte 64Bit-Installation lagert in /usr/lib die 64Bit-Libs, die 32Bit-Libs liegen in /usr/lib32. /usr/lib64 ist ein Symlink auf /usr/lib. Eine 32Bit-Installation lagert im Zweifel 32Bit-Libs in /usr/lib und hat gleich mal gar kein /usr/lib64. Hier sind Konflikte vorprogrammiert, falls du doch mla auf 64Bit-Software setzen willst, um z.B. mehr Speicher alloziieren zu können.
Nein, da habe ich nichts vergessen. Das interessiert den Kernel alles nicht. Die Suche der shared libraries ist eine reine Usermode-Angelegenheit.

Du kannst also auf deinem System die Bibliotheken sonstwo hinlegen, gern auch nach /hier/liegen/ganz/versteckt/meine/bibliotheken/ und der Umstieg von einem 32bit- auf eine 64bit-Kernel wird nichts am Funktionieren des Systems ändern. Mußt natürlich weiter den im ABI festgelegten Pfad zum dynamischen Linker beachten (z.B. /lib/ld-linux.so.2 ), wenn du deine Programme nicht alle neu linken und inkompatibel zum Rest der Welt machen willst.

Ich verstehe sowieso nicht, was du dir für Sorgen um 64bit-Bibliothenen machst. Hier im Thread ging es um ein reines 32bit-Userland. Da brauch man sowas nicht.

BTW:
Für dich sind Redhat-Systeme und deren Abkömmlinge für amd64-CPUs keine "echten 64Bit-Installation", denn diese Distris legen ihre Bibliotheken anders ab als du beschreibst. :) Du beschreibst, wie es in der Debian-Welt gehandhabt wird. Das sind Unterschiede im Design, nicht aber Anzeichen für "echte" oder "unechte" 64Bit-Installationen. Beides geht.
 
Zuletzt bearbeitet:
Zurück
Oben