Siduction Forum
Siduction Forum => Installation - Support => Topic started by: dsat on 2018/04/03, 13:31:13
-
Hi,
bei einem der letzten d-u vor ca. einer Woche ist wohl etwas schief gelaufen. Das debian-sid-System legt kein grub mehr an. Mit chroot von einem parallel installierten manjaro-System komme ich zwar noch auf das debian-System und es lässt sich offenbar auch noch (dist-)upgraden aber es erscheint sowohl nach einem (dist-)upgrade als auch nach einem reinstall von grub-pc folgende Fehlermeldung:
Fehler: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.PackageKit was not provided by any .service files
Es sieht zwar so aus als würde ein grub angelegt werden aber tatsächlich ist keiner da.
Die Platte ist mit GPT partitioniert, hat keine BIOS-Boot-Partition und das debian- System liegt auf einer btrfs-Partition.
Bisher war das kein Problem. Läßt sich das wieder irgendwie zurecht biegen?
Gruß dsat
-
Meines Wissens braucht Grub2 eine Bios-Boot-Partition vom Typ ef02, wenn es sich um eine GPT-Partitionstabelle handelt. :o
Wenn "das bisher ging", dann war da vielleicht jemand anders beteiligt. Deshalb müßtest du schon die Ausgabe von gdisk zeigen.
Man kann nachträglich diese ef02 an das Ende der Platte (part.128) mit gdisk einrichten. Danach wäre vor dem chroot deine btrfs-Partition zuerst zu mounten und das weitere Prozedere laut unserem Handbuch.
-
@unklarer
Überlege bitte bevor du was sagst, dein Geschichte ist UEFI. Er redet von grub-pc, und das ist mbr. Keine Bootpartion notwendig wenn man es denn so möchte.
Und in deinem Fall von UEFI wäre die richtige Partitions-ID EF00.
...
-
Hallo hsp,
ich wüßte nicht, wo meine Geschichte Uefi ist. Daran denke ich nicht mal im Traum ::) noch rede ich davon. :P
-
wir kommen der Sache näher. Möglicherweise habe ich ein tiefer liegendes Problem.
gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.3
Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!
Caution! After loading partitions, the CRC doesn't check out!
Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!
Warning! One or more CRCs don't match. You should repair the disk!
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: damaged
Found valid MBR and corrupt GPT. Which do you want to use? (Using the
GPT MAY permit recovery of GPT data.)
1 - MBR
2 - GPT
3 - Create blank GPT
Your answer:
Wat nu???
Edit:
fdisk /dev/sda
Willkommen bei fdisk (util-linux 2.32).
Änderungen werden vorerst nur im Speicher vorgenommen, bis Sie sich
entscheiden, sie zu schreiben.
Seien Sie vorsichtig, bevor Sie den Schreibbefehl anwenden.
Befehl (m für Hilfe): p
Festplatte /dev/sda: 223,6 GiB, 240057409536 Bytes, 468862128 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x00070014
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sda1 2048 262146047 262144000 125G 7 HPFS/NTFS/exFAT
/dev/sda2 262146048 329254911 67108864 32G 83 Linux
/dev/sda3 329254912 371197951 41943040 20G 7 HPFS/NTFS/exFAT
/dev/sda4 371197952 468858879 97660928 46,6G 5 Erweiterte
/dev/sda5 460468224 468856831 8388608 4G 82 Linux Swap / Solaris
/dev/sda6 * 371200000 423628799 52428800 25G 83 Linux
Partitionstabelleneinträge sind nicht in Festplatten-Reihenfolge.
Befehl (m für Hilfe): q
-
Please post the output of
apt policy packagekit policykit-1
-
Du hast kein GPT, das ist MBR. Darum mault auch gdisk rum. Benutze fdisk, dann wirst du sehen das alles in Ordnung ist.
Wie kommst eigentlich auf GPT?
...
-
apt policy packagekit policykit-1
packagekit:
Installiert: 1.1.9-1
Installationskandidat: 1.1.9-1
Versionstabelle:
*** 1.1.9-1 500
500 http://ftp.de.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
policykit-1:
Installiert: 0.105-20
Installationskandidat: 0.105-20
Versionstabelle:
*** 0.105-20 500
500 http://ftp.de.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
Edit:
gpt ist dann wohl eine fehlerhafte Annahme. Es ist mbr.
-
systemctl status packagekit
If not loaded or active
systemctl restart packagekit.service
-
systemctl status packagekit
Running in chroot, ignoring request: status
-
https://bbs.archlinux.org/viewtopic.php?pid=1649138#p1649138
-
ok, this is not an arch forum, but now from manjaro:
pacman -S packagekit policykit-1
Warnung: packagekit-1.1.9-1.1 ist aktuell -- Reinstalliere
Fehler: Ziel nicht gefunden: policykit-1
systemctl status packagekit
● packagekit.service - PackageKit Daemon
Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static; vendor preset: disabled)
Active: inactive (dead)
systemctl enable packagekit
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified.
Ich stehe auf dem Schlauch - Google translates: I stand on the hose
-
I have not used arch in a few years, maybe search
https://www.google.com/search?q=systemctl+status+packagekit+Running+in+chroot,+ignoring+request:+status&client=firefox-b-1&ei=icnDWrqgMJrijwTrhp-QDA&start=0&sa=N&biw=1920&bih=815
-
thanks a lot for today, piper, for now I'm finished. Tomorrow and for the rest of the week my job will occupy me. I'll come back when I checked and tried your recent link.
Regards dsat
-
Hi,
I followed the links and tried a lot of those suggestions but nothing solved the problem. So I'm going to make a clean install on one of the next days. That seems to be more efficient then to further investigate.
Thanks again, piper.
Regards dsat