Binary /bin/sgdisk wird nicht mehr gefunden, falscher Pfad?

[yummiweb]

Hallo,

ich nutze Proxomx VE u.a. für meinen Homeserver und mir ist kürzlich aufgefallen,
dass ich über die Konfigurationsoberfläche keine Disks mehr initialisieren kann.

Wenn ich unter "$mein_proxmox_host" > Disks > "Initialisiere Disk mit GPT" aufrufe erhalte ich folgende Fehlermeldung:
"command '/sbin/sgdisk /dev/sdb -U R' failed: open3: exec of /sbin/sgdisk /dev/sdb -U R failed: No such file or directory at /usr/share/perl5/PVE/Tools.pm line 429."

Tatsächlich ist "sgdisk" im angegebenen Pfad /sbin/ nicht mehr vorhanden, obwohl es laut Paketmanager installiert ist.
Stattdessen ist sgdisk unter /usr/sbin/ installiert.

Bevor ich jetzt einfach einen Link nach /sbin/ erstelle, würde ich gern wissen warum der Pfad eigentlich nicht mehr stimmt.

Wurde das gdisk bzw. sgdisk Installationsverzeichnis im Rahmen einer Aktualisierung (gdisk) geändert
und wurde dies noch nicht im Skript "/usr/share/perl5/PVE/Tools.pm" angepasst/berücksichtigt?

Oder ist hier irgendwie eine Verlinkung oder eine Umgebungsvariable "verlorengegangen" die neu gesetzt werden muss?
Wie sieht das bei euch aus?

Die Ermittlung der Ursache scheint mir wichtig, da dies ja auch Auswirkungen an anderer Stelle haben könnte.

Mein Proxmox VE Host wurde vor ca. 12 Monaten auf ein frisch installiertes Debian Jesse installiert, hier die Details:
Linux 4.15.18-21-pve #1 SMP PVE 4.15.18-48
PVE Manager Version pve-manager/5.4-13/aee6f0ec

Nachtrag:
Annähernd dasselbe Problem auf einer Buster/Proxmox VE 6 Testinstallation?
(Neuinstallation, kein Upgrade)
Nachtrag 2:
Bei letzterem Problem (Proxmox VE 6) lag es wohl an einem Konflikt mit einem merkwürdigem GPT/MBR.
Sfdisk im Terminal mir identischem Kommando ausgeführt ("sfdisk /dev/sdb -U R") lieferte die Meldung: "Found invalid GPT and valid MBR, converting MBR to GPT format in Memory". Dies schlug jedoch fehl. Dann die Disk per cfdisk komplett gelöscht, der Fehler blieb derselbe. Mit "sfdisk /dev/sdb -U R -g" funktionierte es dann. Nachdem die Disk einmal neu initialisiert war funktionierte es dann auch in der Weboberfläche.

Danke für eure Hilfe,
yummiweb

 

[dcsapak]

sgdisk wird (zumindest hier) nach /sbin installiert (so wie im code benutzt)
was sagt den

which sgdisk
dpkg -S sgdisk
dpkg -L gdisk

?

 

[yummiweb]

hallo,
hier die entsprechenden infos:

sudo which
/usr/sbin/sgdisk

sudo dpkg -S sgdisk
gdisk: /usr/share/man/man8/sgdisk.8.gz
gdisk: /usr/sbin/sgdisk

sudo dpkg -L gdisk
/.
/usr
/usr/lib
/usr/lib/.build-id
/usr/lib/.build-id/69
/usr/lib/.build-id/77
/usr/lib/.build-id/c6
/usr/sbin
/usr/sbin/cgdisk
/usr/sbin/gdisk
/usr/sbin/sgdisk
/usr/share
/usr/share/doc
/usr/share/doc/gdisk
/usr/share/doc/gdisk/changelog.Debian.gz
/usr/share/doc/gdisk/copyright
/usr/share/doc/gdisk-1.0.4
/usr/share/doc/gdisk-1.0.4/COPYING.gz
/usr/share/doc/gdisk-1.0.4/NEWS.gz
/usr/share/doc/gdisk-1.0.4/README.gz
/usr/share/man
/usr/share/man/man8
/usr/share/man/man8/cgdisk.8.gz
/usr/share/man/man8/gdisk.8.gz
/usr/share/man/man8/sgdisk.8.gz
/usr/lib/.build-id/69/7b35259da9d5040da3be450f5cfcfb2d48e544
/usr/lib/.build-id/77/9e9307c0b34f28a6841c14582d070fc8f28ce1
/usr/lib/.build-id/c6/1c06fd8924007fa577bf9be79f3ede1a28cd93

gruss yummiweb

 

[dcsapak]

das scheint nicht das normale 'gdisk' paket von debian zu sein, was sagt den

apt-cache policy gdisk

?

 

[yummiweb]

sudo apt-cache policy gdisk
gdisk:
Installiert: 1.0.4-1
Installationskandidat: 1.0.4-1
Versionstabelle:
*** 1.0.4-1 100
100 /var/lib/dpkg/status
1.0.1-1 500
500 ftp://ftp.de.debian.org/debian stretch/main amd64 Packages

uups…, sehe grad, dass in meinem ersten post geirrt habe.
das system ist natürlich auf stretch und nicht jessie.

gruss yummiweb

 

[dcsapak]

scheint kein offizielles debian paket zu sein da stretch die version 1.0.1-1 hat https://packages.debian.org/stretch/gdisk
irgendwelche anderen repositories konfiguriert?

 

[yummiweb]

/etc/apt/sources.list
(ohne ausgeklammerte)

deb ftp://ftp.de.debian.org/debian/ stretch main non-free contrib
deb-src ftp://ftp.de.debian.org/debian/ stretch main non-free contrib

deb http://security.debian.org/debian-security stretch/updates main contrib non-free
deb-src http://security.debian.org/debian-security stretch/updates main contrib non-free

deb http://deb.debian.org/debian stretch-updates main contrib non-free
deb-src http://deb.debian.org/debian stretch-updates main contrib non-free

deb http://download.proxmox.com/debian/pve stretch pve-no-subscription

in /etc/apt/sources.list.d/* ist nichts aktiv (ausgeklammert)

gruss yummiweb

 

[yummiweb]

dies ist der rest vom installationseintrag in der /etc/apt/sources.list:

# deb cdrom:[Debian GNU/Linux 9.6.0 _Stretch_ - Official amd64 NETINST 20181110-11:34]/ stretch main

Würde aber nicht ausschliessen wollen, dass dass ein für apple-mac (vor-)gebautes iso gewesen ist.

gruss yummiweb

 

[dcsapak]

ich würde das apt log durchsuchen (/var/log/apt/history*) um festzustellen wann denn die version 1.0.4 installiert wurde,
(sicher nicht von uns, und ich bezweifle dass debian in irgendein iso eine 'spezielle' version packt)

 

[yummiweb]

o.k., dann muss ich die logs jetzt mal auspacken und durchforsten.
das komische ist nur, dass ich gdisk definitiv nicht nachinstalliert habe und andere als der genannten quellen hatte ich auch nie installiert.

i.d.r. führe ich von hand ein einigermassen verlässliches protokoll über zusätzlich installierte pakete.

demzufolge installierte ich auf diesem system VOR der proxmox ve installation:
ksm-control-daemon, systemd-sysv, usbutils, postfix, lxdm

dann proxmox ve:
open-iscsi und proxmox-ve

und später:
mc, gparted, lvm2, cryptsetup, screen, nfs-kernel-server, portmap, samba-common, samba tdb-tools, tightvncserver, nut-server

entfernt habe ich folgende pakete:
os-prober, gimp*, libreoffice* und xsane*

das wars eigentlich schon und soweit ich mich erinnere, konnte ich die "initialisiere gpt" funktion über die webconfig noch bis mai/juni 2019 nutzen.

gruss yummiweb

 

[yummiweb]

meine protokolle sind offensichlich unvollständig.
die apt logs sind da unerbittlich ;-) und deine vermutung ist wohl richtig.

offenbar habe ich (oder wurde) ein separates gdisk paket installiert und da der quellpfad bei dieser aktion auf einen download ordner zeigt, wurde das paket offenbar per browser heruntergeladen und installliert (warum auch immer).
mal sehen ob ich im Browserverlauf noch was zum hergang finde.

aber unabhängig davon, wie müsste ich jetzt vorgehen?
gdisk per "apt remove gdisk" deinstallieren funktioniert nicht, dabei will er nämlich auch proxmox-ve und pve-manager zu deinstallieren.

o.k., das sind sicher schon fragen, die meine relative unerfahrenheit zeigen nehme ich an.

 

[dcsapak]

aber unabhängig davon, wie müsste ich jetzt vorgehen?
gdisk per "apt remove gdisk" deinstallieren funktioniert nicht, dabei will er nämlich auch proxmox-ve und pve-manager zu deinstallieren.

apt install gdisk=1.0.1-1

sollte funktionieren

 

[yummiweb]

"apt install gdisk=1.0.1-1" hat leider nicht funktioniert, als Ausgabe kam:
E: Version 1.0.1-1 für gdisk konnte nicht gefunden werden

Ich habe jetzt übergangsweise das apt paket gdisk-1.0.1-1 von packages.debian.org heruntergeladen und lokal auf einen testsystem (klon) installiert.
dort liegt die binary jetzt im regulären pfad und funktioniert dort auch erstmal wieder.

ich muss mich aber sicher noch eingehender damit beschäftigen, soll ja beim anstehenden upgrade auch alles funktionieren.
bisher ist es mir nämlich noch nicht gelungen von 5.4 auf 6.0 zu kommen.

vielen dank und gruss erstmal
yummiweb