Linux...

Anzeige

Ich habe die PPA's mal komplett rausgenommen, aber der Timeout-Fehler war immer noch drin.
Die PPA's waren also wohl die falsche Spur.

Möglicherweise müsste man den Timeout erhöhen, aber ich weiß noch nicht, wo bzw. ob das überhaupt ein server- oder client-seitiger Timeout ist.

Auf dem fraglichen Gerät (ein Netbook, Typ "Akoya mini e1210") ist noch ein Xubuntu 18.04.2 (32bit) drauf.
Das läuft auch recht gut, sogar mit Compiz (wenn man nicht allzu viele Effekte aktiviert).
Da gehen Sachen wie Wabbel-Fenster beim Verschieben, Fenster beim Öffnen reinbeamen oder beim Schließen abfackeln.
Beim Minimieren wie in eine Wunderlampe wellenartig in die Leiste reinsaugen
und beim Wiederherstellen gleichermaßen wieder rausdrücken.
Auch der 3D-Desktop-Würfel läuft gut.
Klar, braucht eigentlich alles kein Mensch,
sieht aber interessant aus und ich finde es erstaunlich,
dass es auf dem kleinen, alten Gerät läuft.

Was Bodhi betrifft, das hat in der Tat eine etwas gewöhnungsbedürftige Oberfläche,
aber ich mag es inzwischen sogar lieber als Mint und gerade auf dem alten Netbook ist es super.
Bodhi ist dort auch schneller als Xubuntu, wo doch manchmal kleine Wartezeiten entstehen.

 

Nun denn, du könntest ein paar Dinge probieren, die in der Vergangenheit den ein oder anderen Fehler beseitigten. Als nächstes würde ich wie schon geschrieben den Mirror wechseln.
Geht das nicht, ggf. das Paketmanagement aufräumen/reparieren.
Dazu am besten ein Terminal öffnen und folgendes eingeben:

sudo -s -H
apt-get clean
rm /var/lib/apt/lists/*
rm /var/lib/apt/lists/partial/*
apt-get update

Fehler tritt noch bei apt-get update auf? Dann den Status der Paketlisten auf ein Backup zurück spielen.

mv /var/lib/dpkg/status /var/lib/dpkg/status_bkup
cp /var/lib/dpkg/status-old /var/lib/dpkg/status
apt-get update
Klappte alles ohne Fehler dann:
rm /var/lib/dpkg/status_bkup
exit oder Terminal schließen

Tritt der Fehler immer noch auf, warte paar Tage. Keine Ahnung wie dann weiter.

 

Geht leider nicht:
Folgender Befehl wird verweigert:
rm /var/lib/apt/lists/*

Grund:
Das Entfernen von '/var/lib/apt/lists/*' ist nicht möglich: Ist ein Verzeichnis

Eine Überprüfung der Verzeichnisse
/var/lib/apt/lists/*
/var/lib/apt/lists/partial/*
ergab, dass da eh nichts drin ist.
Also "Eigenschaften" -> 0 Byte

Ich bin trotzdem alle Befehlszeilen durchgegangen.
Ergebnis:
Der Timeout-Fehler ist leider immer noch da.

 

Na gut, dann so im Terminal:
sudo rm -rf /var/lib/apt/lists/*
sudo apt-get update

Da gehen zwar die beiden darin befindlichen Ordner flöten, was ich nicht wollte, aber auch nicht weiter schlimm, da sie wieder neu angelegt werden.
Aber wie geschrieben, gehts dann immer nocht nicht, keine Ahnung. Ich vermute nach wie vor den Mirror als Fehlerursache.

 

Kurz OT. Wer mit Linux DVB-T 2HD sehen möchte das geht mit Ubuntu 18.04 ganz gut. Man muss ein Update für w-scan machen. Dann unter Kaffeine Gerät 1 nur auf Terrestrisch T2 stellen + Automatisch. Es werden alle freien Kanäle gefunden. Selbst auf meiner 12 Jahre alten Kiste läuft das Absolut ruckelfrei. OT aus.

 

@madmax25,
Im anderen Thread, ging es ausschließlich um die uefi Partition, nicht darum was mit grub ist. Grub hat mit Windows nix zu tun, ergo alles darum falsch im Win10 thread. Für was gibts den Linux Thread??
Und egal ob uefi oder nicht, den grub installiert man immer in die sda, ohne Partitionsangabe. Weißt du überhaupt was du so machst? Ich frage nur so....
So bspw. aus laufenden System

Code:

sudo grub-install

bzw. wenn es doch mal etwas härter kommt...

Code:

sudo apt-get --reinstall install grub-common grub-efi-amd64 os-prober

(ist ohne Secure Boot)
Geht gar nix mehr, musst du grub mit der Chrootmethode reparieren..

Und hat man uefi, mehrere Tuxe deaktiviert man in den "Nebentuxen", dort in der /etc/default/grub os-propper mittels extra Eintrag

Danach ein

Code:

sudo update-grub

gemacht. Vor allem im "Hauptgrub".

 

Als noch alles auf Ubuntu 16.04 basierte, lief der Grub doch auch auf /dev/sda1 ?!
Das erstaunt mich jetzt aber:
Bisher war es doch immer so, dass bei Legacy der Grub in /dev/sda (ohne Partitionsnummer) kam und bei UEFI in die efi-Partition (also /dev/sda1 oder /dev/sda2).

Chroot habe ich probiert im Live-System.
Damit habe ich das Ganze dann so richtig vor die Wand gefahren.

Das Seltsame ist, dass ich, solange alles auf Ubuntu 16.04 aufbaute, ich einfach nur zwei Distris installierte (eine davon war meistens Bodhi, weil da der Grub durch das graue Hintergrundbild leicht vom anderen unterscheidbar ist) und je nachdem, welchen Grub bzw. welches System ich als Default-System haben wollte, machte ich im gewünschten System einfach nur
sudo grub-install /dev/sda1
und
sudo update-grub

Anschließend war das zuletzt gebootete System immer zuerst im Grub und startete auch defaultmäßig und der Grub war auch der aus dem zuletzt gebooteten System.

Erst, seitdem ich auf Ubuntu 18.04 basierende Distris nutze, läuft es nicht mehr richtig.
Anscheinend funktioniert grub-install da anders, also in der Hinsicht, dass es automatisch auf der angegebenen Platte (also sda ohne Partitionsnummer) die efi-Partition findet und den Grub dort hin installiert.
Leider neige ich immer noch dazu, die 1 (bzw. die 2, wenn efi = sda2 ist) dazu zuschreiben, und das ist wohl genau der Moment, wo alles außer Kontrolle gerät, weil da außer Windows und Ubuntu noch ein dritter Eintrag im UEFI-BIOS namens Bodhi entsteht.
Wenn ich dann versuche, den Grub aus dem vorherigen System wieder zu installieren, gerät der anscheinend in den falschen Ordner, sodass ich den nicht mehr zurücktauschen kann.

 

@madmax25, hat man mehrere Tuxe (Linuxsysteme), kann man bei msdos-Partitionstabelle den grub auch in irgend eine Partition installieren. Richtig.
Man sollte allerdings dann auch ein Chainload durchführen. Näheres dazu - google... Sonst werden die grub Einträge bei neuen Kernels immer mehr und unübersichtlich. Von jeder Distri immer ein zusätzlicher Eintrag. Und das bei allen vorhandenen Grub Einträgen.

Du hast uefi wie du geschrieben. Ergo den alten msdos-crap zur Seite getan.
Darin installiert man den grub in die sda, war noch nie anders.
Allerdings regelt das eh alles der efibootmgr. Soll heißen, es ist im Prinzip bei uefi egal, was du zur sda angibst. Der efibootmgr findet die uefi Partition, erstellt darin einen Ordner für die Distri, namnes ubuntu oder bodhi oder wie bei mir manjaro. Darin befinden sich die Startdateien. Jene unterscheiden sich voneinander von Distri zu Distri.

Anders sieht das aus, wenn du eine uefi Partition auf externe Platte/ssd bringst, mit eigener uefi Partition. Das ist etwas verzwickter. Vor allem sollte man dann nichts ins NVRAM des Rechners schreiben lassen. Erreicht man mittels sudo grub-install --no-nvram

Vielleicht solltest du dein NVRAM mal kontrollieren und evtl. unnütze Einträge entfernen. Aber sei vorsichtig dabei. Man verschafft sich zuerst sich einen Überblick:
sudo efibootmgr

Will ich jetzt den eintrag ubuntu löschen, gehe ich wie folgt vor:

Code:

sudo efibootmgr -b 0001 -B

 

So habe ich das immer auf einem alten BIOS/Legacy-System gemacht.

Auf UEFI habe ich den Grub immer in die efi-Partition installiert.
Das sieht man am besten bei der System-Installation, wenn man "Etwas anderes" wählt.
Da gibt es unter der Partitionstabelle eine Einstellung, wo der Grub hin soll und da wähle ich immer die Partiton, wo auch der Windows-Bootmanager ist, also wie gesagt sda1.
Und da habe ich auf meinen UEFI-Rechnern schon immer die efi-Partition gewählt (das ist sda1 auf meinem HP-Laptop und sda2 auf meinem PC).

Selbst beim aktuellen Xubuntu oder Bodhi ist das so.
Warum beim Reparieren eines defekten Grub, dieser nun plötzlich in sda und nicht mehr in sda1 soll, ist mir ein Rätsel.

 

Man kann sich mit dir noch so viel Mühe geben, meistens ist es für die Katz.
Lies diverse Anleitungen (eine hatte ich oben verlinkt), da steht immer etwas von sda und nicht sdaX beim reparieren von grub unter uefi. Was dir daran ein Rätsel sein soll, nun ja, dein Problem.
Meinerseits ist alles dazu geschrieben.