Keine Inhalte auf der Portal Seite

O_Bertgen · August 1, 2017, 10:10am

Ah, da hab ich 3 Stunden zu spät nachgeschaut

Das gleiche wie mosu hätte ich jetzt auch vorgeschlagen.

Kleiner Tip noch: vorher die Datei fstab kopieren… auf einen Stick oder ins /home Verzeichnis.
Wenn bei der Änderung Rechtschreibfehler entstehen oder Leerzeichen fehlen, mag das System im
schlechtesten Fall nicht mehr booten und dann geht die Sucherei nach dem Fehler los.

Gruß,
Oliver

Moritz_Bunkus · August 1, 2017, 10:58am

Backups sind immer eine hervorragende Idee

uhbi · August 1, 2017, 9:20pm

Der Eintrag von nofail in der fstab hat den Server in den systemd gebootet. Allerdings war nicht die /home Partition das Problem sonder /boot. Hier sind die Ausgaben:

root@sv1:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/vg_ucs-root /       ext4    errors=remount-ro,user_xattr    0       1
# /boot was on /dev/sdb1 during installation
UUID=5owCF5-Dkcm-0RyK-JxOI-CBRH-Do7O-2tzH52     /boot   ext2    defaults,nofail,user_xattr      0       2
/dev/mapper/vg_ucs-home /home   ext4    defaults,user_xattr     0       2
/dev/mapper/vg_ucs-swap_1       none    swap    sw      0       0

# Internal Backup HDD NTFS-Format
/dev/sda1       /internalBackup ntfs    rw,user,uid=0,gid=46,umask=007,nls=utf8         0       0

# predefind entries
#/dev/sda1      /media/usb0     auto    rw,user,noauto  0       0
#/dev/sda2      /media/usb1     auto    rw,user,noauto  0       0

und

root@sv1:~# blkid
/dev/sda1: UUID="5AD2C8E040E18F63" TYPE="ntfs" PARTUUID="000d72ab-01"
/dev/sdb1: UUID="5owCF5-Dkcm-0RyK-JxOI-CBRH-Do7O-2tzH52" TYPE="LVM2_member" PARTUUID="0009606a-01"
/dev/sdb5: UUID="kbfJ1l-wMzS-m0uX-5eJQ-8qj5-S2Hs-vcwNd5" TYPE="LVM2_member" PARTUUID="0009606a-05"
/dev/mapper/vg_ucs-root: UUID="53f3fed5-7e0a-439a-aca0-89936e701cfe" TYPE="ext4"
/dev/mapper/vg_ucs-swap_1: UUID="e71c5844-06a2-4b4d-9b45-c41e34241de8" TYPE="swap"
/dev/mapper/vg_ucs-home: UUID="bb5f3c6f-21b4-4c9d-9abc-f802dd8a8782" TYPE="ext4"

Viele Grüße
Uwe

Moritz_Bunkus · August 2, 2017, 8:14am

Die UUID zeigt ja auf eine Partition, deren Typ in der Partitionstabelle als “LVM2 member” angegeben ist. Das sollte nicht sein; man mountet keine LVM-Member-Partitionen. Natürlich kann es sein, dass da trotzdem ein normales Dateisystem drauf ist, aber ganz koscher erscheint mir das nicht.

Bitte noch mal folgende Ausgaben vom laufenden Server posten:

lsblk
file -s /dev/sdb1
pvdisplay
ls /boot
mount

uhbi · August 2, 2017, 3:50pm

Hallo Herr Bunkus,

hier sind die Ausgaben:

root@sv1:~# lsblk
NAME              MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sdb                 8:16   1   931G  0 disk
ââsdb2              8:18   1     1K  0 part
ââsdb5              8:21   1 930,5G  0 part
â ââvg_ucs-swap_1 254:1    0  15,8G  0 lvm  [SWAP]
â ââvg_ucs-home   254:2    0 894,9G  0 lvm  /home
â ââvg_ucs-root   254:0    0  19,8G  0 lvm  /
ââsdb1              8:17   1   487M  0 part
sda                 8:0    0 931,5G  0 disk
ââsda1              8:1    0 931,5G  0 part /internalBackup


root@sv1:~# file -s /dev/sdb1
/dev/sdb1: LVM2 PV (Linux Logical Volume Manager), UUID: 5owCF5-Dkcm-0RyK-JxOI-CBRH-Do7O-2tzH52, size: 1000203091968


root@sv1:~# pvdisplay
  Incorrect metadata area header checksum on /dev/sdb1 at offset 4096
  --- Physical volume ---
  PV Name               /dev/sdb5
  VG Name               vg_ucs
  PV Size               930,51 GiB / not usable 4,00 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              238210
  Free PE               0
  Allocated PE          238210
  PV UUID               kbfJ1l-wMzS-m0uX-5eJQ-8qj5-S2Hs-vcwNd5

  "/dev/sdb1" is a new physical volume of "931,51 GiB"
  --- NEW Physical volume ---
  PV Name               /dev/sdb1
  VG Name
  PV Size               931,51 GiB
  Allocatable           NO
  PE Size               0
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               5owCF5-Dkcm-0RyK-JxOI-CBRH-Do7O-2tzH52


root@sv1:~# ls /boot
root@sv1:~#


root@sv1:~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1006117,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=1617136k,mode=755)
/dev/mapper/vg_ucs-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct,pipe_ino=678)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
/dev/sda1 on /internalBackup type fuseblk (rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
/dev/mapper/vg_ucs-home on /home type ext4 (rw,relatime,data=ordered)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
/dev/mapper/vg_ucs-root on /var/lib/docker/overlay type ext4 (rw,relatime,errors=remount-ro,data=ordered)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)

Moritz_Bunkus · August 3, 2017, 7:29am

Ihre Partition ergibt vorne und Hinten wenig Sinn, bzw. ich verstehe nicht, was dahinter steckt:

Es gibt keine einzige Partition, die für /boot in Frage kommt:
- sdb2 ist mit 1KB zu klein, bzw. das ist die erweiterte Partition, in der sich sdb5 befindet
- sdb5 ist Teil vom LVM (volume group vg_ucs)
- sda1 ist viel zu groß und auch für andere Zwecke gemountet
- sdb1 passt von der Größe her, ist aber ein LVM physical volume

sdb1 ist diejnige, die laut fstab mal /boot war, aber die Angaben, die das System momentan »sieht«, sind sehr widersprüchlich:

sdb1 ist laut Partitionstabelle 487 MB groß (das ist eine typische Größe für /boot)
sdb1 ist laut Partitionstabelle aber vom Typ »LVM physical volume«; für ein normales Linux-Dateisystem wäre der Typ eher »Linux«
file und der Logical Volume Manager stimmen darüber überein, das sdb1 ein physical volume mit Größe knapp 1 TB ist — was im krassen Widerspruch zur Partitionstabelle steht
Obwohl sdb1 ein physical volume ist, ist es nicht Bestandteil einer volume group.

Mir scheint, dass sdb1 früher mal ein normels Dateisystem enthielt, das auf /boot gemountet war. Irgendwie ist seitdem aber der Partitionstyp überschrieben worden, und es wurde darauf ein physical volume angelegt — mit falschen Größenangaben auch noch!

Anscheinend muss der Inhalt aber noch da sein, denn ansonsten könnte der Server ja gar nicht gebootet werden, da der Kernel und die initial ramdisk, die grub lädt, auf der Partition liegen, die /boot enthält.

Ich würde jetzt grob Folgendes machen:

Falls der Server virtualisiert ist: herunterfahren & einen Snapshot der Maschine erstellen. Falls nicht virtualisiert: Vollbackup anfertigen. Hintergrund: beim Herumspielen mit Partitionstabellen kann zu schnell zu viel kaputt gehen.
Sicherstellen, dass Sie 1. nicht aus Faulheit ausgelassen haben
Die Partitionstabelle von sdb bearbeiten und den Partitionstyp von sdb1 auf 83 = Linux stellen
Reboot
Schauen, ob pvdisplay sdb1 noch als physical volume erkennt (vermutlich ja)
Versuchen, die Partition manuell zu mounten (sofern sie nicht eh schon beim Booten automatisch gemountet wurde): mount /dev/sdb1 /boot. Klappt das, dann Inhalt von /boot begutachten.
Klappt das noch nicht, so als nächstes:
einen Volldump von sdb1 anlegen, z.B. dd if=/dev/sdb1 of=/root/dump-sdb1 bs=128K
dem LVM mitteilen, dass das wirklich kein physical volume ist: pvremove /dev/sdb1
erneut ein Reboot, anschließend dir Schritte 5. und 6. von oben
Wenn Sie /boot dann gemountet kriegen und der Inhalt OK ist, dann können Sie die /etc/fstab wieder anpassen und das nofail herausnehmen.

O_Bertgen · August 3, 2017, 12:50pm

Hallo Uwe,

war das vielleicht früher mal ein Multiboot-System,
bei dem zuerst Windows installiert war und dann anschliessend
UCS installiert worden ist ?

Vielleicht kam der UpDate-Prozess beim UCS damit nicht zurecht und
hat die alte Grub-Config falsch interpretiert.

Könnte vielleicht für Univention interessant sein.

und noch ein kleiner Tip:
Benutzt du Putty, um auf die Konsole zu kommen ?
Wenn du in der Putty-Startoberfläche links auf Window-Translation bei
Remote-Character-Set UTF-8 einstellst, kommt es nicht zu den
Darstellungsfehlern:

uhbi · August 3, 2017, 1:32pm

Hallo Herr Bunkus, Hallo Herr Bertgen,

@ Herr Bunkus
ihr Vorgehen hört sich recht aufwendig an. Der Rechner ist keine VM. Wie kann ich da am besten ein Vollbackup erstellen und gegeben falls wieder zurück spielen?

Ist es eventuell nicht einfacher die bisherigen Konfigurationen (Benutzer, Freigaben, PCs, …) und Daten zu sichern und das System neu aufzusetzen?

@Herr Bertgen
Danke für den Tipp mit dem Zeichensatz. Das werde ich vor dem nächsten Beitrag berücksichtigen.

Historie des Servers:
Der Rechner ist von Anfang nur als Univention Server installiert und betreiben worden. Vor dem Update habe ich noch die LVM home Partiton etwas verkleinert und anschließend die LVM root Partition vergrößert. Sie lief mit log-Dateien immer voll. Das hat alles funktioniert. Dann habe ich das Update durchgeführt.

Viele Grüße
Uwe

Moritz_Bunkus · August 3, 2017, 1:59pm

Huhu,

Klar ist das aufwändig. Sie haben schlicht ein komplexes Problem mit dem aktuellen Setup.

Backupmethoden gibt’s wie Sand am Meer. Eine relativ einfach umzusetzende ist, von einer Rescue-CD wie grml zu booten, die Partitionen mit Daten z.B. nach /mnt/server zu mounten, eine USB-Platte anzuschließen und nach z.B. /mnt/backup zu mounten, dann mit rsync -haxHAX --numeric-ids /mnt/server/ /mnt/backup/ zu sichern.

Was Sie nicht machen sollten: Sicherung mit tar, weil GNU tar weder ACLs noch erweiterte Attribute sichern kann.

Wenn Ihnen das alles zu viel oder zu gefährlich ist, wäre es evtl. an der Zeit, Geld in die Hand zu nehmen und einen brauchbaren Dienstleister damit zu beauftragen.

Naja, sichern können Sie da nur manuell, und neu aufsetzen heißt: Benutzer, Gruppen, Freigaben manuell anlegen, PCs alle erneut in Domäne joinen, Daten wieder raufkopieren (und auch dabei auf ACLs und extended attributes achten).

LG,
mosu

uhbi · August 4, 2017, 4:21pm

Hallo Herr Bunkus,

Wieviel Geld muss ich denn in die Hand nehmen für einen brauchbaren Dienstleister? Sie würden das doch machen?

VG
Uwe

Moritz_Bunkus · August 7, 2017, 6:08am

Ja, durchaus. Schreiben Sie mich doch mal an; dann können wir Details klären: m.bunkus@linet-services.de