Discussion:
mkfs.xfs :-( // Linux version 3.16.63-eisfair-64-VIRT
(zu alt für eine Antwort)
D. Oezbilen
2019-04-23 17:01:36 UTC
Permalink
Hallo @all,

so ganz einfache Sachen bringen unerwartet Probleme.

Diesmal ist es das:

mkfs.xfs

welches in der virt. Umgebung (kvm) das mit

gdisk o. fdisk

eine 8GB HD (unter kvm als IDE oder SCSI, kein virtio eingebunden)
formatiert
*___aber___ nicht mountet*.

#################################################

Apr 23 18:25:30 linuxsrv klogd: hdb:
Apr 23 18:25:44 linuxsrv klogd: hdb: hdb1
Apr 23 18:26:14 linuxsrv klogd: XFS (hdb1): Superblock has unknown
incompatible features (0x2) enabled.
Apr 23 18:26:14 linuxsrv klogd: Filesystem can not be safely mounted by
this kernel.
Apr 23 18:26:14 linuxsrv klogd: XFS (hdb1): SB validate failed with
error 22.

#################################################

Damit der Host aus der Schusslinie kommt (bisher Null Probleme mit nix
;-) gehabt, auch nicht mit mkfs.xfs, setze es bevorzugt fuer alle
Part./Platten ein, bei mir historisch bedingt), habe die virt. Maschine v.

gparted-live-0.25.0-3-amd64.iso

gebootet, dort eine XFS angelegt. Vor habe ich auch eine msdos mbr neu
angelegt.

S. da, jetzt wird diese XFS formatierte (mit SCSI, sym895 bei der
Installation des eis X64 ausgewaehlt, nicht virtio) HD (/dev/sdb1) *ohne
Probleme* eingebunden.

Apr 23 18:39:21 linuxsrv klogd: XFS (sdb1): Mounting V5 Filesystem
Apr 23 18:39:21 linuxsrv klogd: XFS (sdb1): Ending clean mount

(ja hier sdb, oben hdb, weil hin und her (ide(SCSi) gebootet,
Fehlermeldung ist ident.)

Damit ist das Problem _fuer_mich_ umschifft, und trotzdem ist es schal.

eis x64:
Linux version 3.16.63-eisfair-64-VIRT

Ist halt etwas nervig, wenn man mal zwischendurch (aus welchem Grund
auch immer) eine Part. mit XFS formatieren muss, man die virt. Einheit
wie o.a. booten, formatieren muss.

Ist das ein Feature (s. Fehlermeldung) oder ein Bug?

Gruss
Derya
Marcus Roeckrath
2019-04-23 17:38:42 UTC
Permalink
Hallo Derya,
Post by D. Oezbilen
so ganz einfache Sachen bringen unerwartet Probleme.
mkfs.xfs
Das mkfs.xfs aus dem eisfair-System oder dem Hostsystem?
Post by D. Oezbilen
welches in der virt. Umgebung (kvm) das mit
gdisk o. fdisk
eine 8GB HD (unter kvm als IDE oder SCSI, kein virtio eingebunden)
formatiert
*___aber___ nicht mountet*.
#################################################
Apr 23 18:25:44 linuxsrv klogd: hdb: hdb1
Apr 23 18:26:14 linuxsrv klogd: XFS (hdb1): Superblock has unknown
incompatible features (0x2) enabled.
Ich denke, dass es bei XFS wie bei anderen Dateisystem verschiedene Features
gibt, die von der Version des Dateisystems abhängen.

Ein System das nur ext2 kennt, wirdd ein volles ext3 (mit allen Features
formatiert) auch nicht einbinden können.
Post by D. Oezbilen
Apr 23 18:26:14 linuxsrv klogd: Filesystem can not be safely mounted by
this kernel.
Apr 23 18:26:14 linuxsrv klogd: XFS (hdb1): SB validate failed with
error 22.
Da wird also ein Feature beim Formatieren benutzt worden sein, was im
XFS-Modul unseres Kernels eben noch nicht existiert.
Post by D. Oezbilen
gparted-live-0.25.0-3-amd64.iso
gebootet, dort eine XFS angelegt. Vor habe ich auch eine msdos mbr neu
angelegt.
S. da, jetzt wird diese XFS formatierte (mit SCSI, sym895 bei der
Installation des eis X64 ausgewaehlt, nicht virtio) HD (/dev/sdb1) *ohne
Probleme* eingebunden.
Dann wird das gparted Formatierungsoptionen nutzen, die auch zu eisfair
passen.
Post by D. Oezbilen
Damit ist das Problem _fuer_mich_ umschifft, und trotzdem ist es schal.
Linux version 3.16.63-eisfair-64-VIRT
Ist halt etwas nervig, wenn man mal zwischendurch (aus welchem Grund
auch immer) eine Part. mit XFS formatieren muss, man die virt. Einheit
wie o.a. booten, formatieren muss.
Ist das ein Feature (s. Fehlermeldung) oder ein Bug?
Wenn mit einem mkfs.xfs des eis ein XFS nicht mountbar ist, dann wäre es ein
Bug, ansonsten war das mkfs.xfs zu neu für unseren Kernel.
--
Gruss Marcus
Marcus Roeckrath
2019-04-23 17:57:09 UTC
Permalink
Hallo Derya,
Post by D. Oezbilen
mkfs.xfs
Apr 23 18:26:14 linuxsrv klogd: XFS (hdb1): Superblock has unknown
incompatible features (0x2) enabled.
Dieses mkfs.xfs formatiert mit einem Superblock V5, was unser Kernel wohl
noch nicht beherrscht.

https://serverfault.com/questions/746377/want-to-understand-xfs-strangeness
https://docs.oracle.com/cd/E37670_01/E84716/html/ol6-rn-issues-xfs-superblock-compat.html

For eisfair darf also höchsten xfs superblock V4 benutzt werden!

Laut manpage könnte die Option

-m crc=0|1

das steuern, welche auch mkfs.xfs aus unserem xfsprogs-Paket beherrscht,
laos für unseren Kernel wohl

-m crc=0

lauten muss, was üblicherweise auch Default sein sollte.
--
Gruss Marcus
D. Oezbilen
2019-04-23 18:27:26 UTC
Permalink
Hallo Marcus,

Du warst schneller, ich habe auch diese Page gefunden, es funkt auch so.

mkfs.xfs -f -m crc=0,finobt=0 /dev/sdaX

So kann man formatieren.
-m crc=0 > lauten muss, was üblicherweise auch Default sein sollte.
So wird es aber nicht akzeptiert oder nicht richtig interpretiert.

nogo:

mkfs.xfs -f -m crc=0 /dev/sda4
mkfs.xfs -f -m crc=1,finobt=0 /dev/sdaX

D.h. crc=0 als default wird im System nicht gesehen.

funkt nur:

mkfs.xfs -f -m crc=0,finobt=0 /dev/sdaX

Gruss
Derya

PS: Im Umkehrschluss, kaum jemand setzt es ein? Sons waere es
aufgefallen, oder das Problem hat sich neulich mit einem Upgrade/Update
eingeschlichen.
XFS kann man auf Raid-HW sehr gut fein einstellen + LVM, best of, wenn
auch ext4 sehr aufgeholt hat.
D. Oezbilen
2019-04-23 18:30:01 UTC
Permalink
    mkfs.xfs -f -m crc=0 /dev/sda4
__Korrektur___

mkfs.xfs -f -m crc=0 /dev/sdaX

funkt.

Derya
Holger Bruenjes
2019-04-23 18:41:26 UTC
Permalink
Post by D. Oezbilen
    mkfs.xfs -f -m crc=0 /dev/sda4
__Korrektur___
mkfs.xfs -f -m crc=0 /dev/sdaX
funkt.
ja, sollte sein lt. man

finobt=value
....
By default, mkfs.xfs will create free inode btrees
for filesystems created with the (default) -m crc=1
option set. When the option -m crc=0 is used, the
free inode btree feature is not supported and is
disabled.

Holger
D. Oezbilen
2019-04-23 18:54:24 UTC
Permalink
Hallo Holger,

so wie ich das Problem verstand haengen die xfsprogs hinterher?
Nicht der Kernel.

Bisher in den vielen Jahren musste ich in (produktivem) Betrieb die
xfsprogs *nicht* einsetzen um ein xfs-Sysem ueberhaupt wieder im Zugriff
zu haben.

Wenn doch, hoffe ich, dass dieser Unterschied xfs vs kernel-Version
nicht die Show zum Stoppen bringt. Vllt. koennt ihr das mit einem
update/upgrade glattziehen?

Zur Not liesse sich in virt. Umgebung auch eine andere Dist. booten, die
damit klar kaeme, doch bei einer HW ist der Umfang der Arbeiten
groesser, wenn man nicht remote die Kiste kriegt.

Gruss
Derya
Holger Bruenjes
2019-04-23 19:08:08 UTC
Permalink
Hallo Derya
Post by D. Oezbilen
so wie ich das Problem verstand haengen die xfsprogs hinterher?
Nicht der Kernel.
eisfair hat die xfsprogs Version 4.19.0 auf Pack-Eis liegen, damit
sind wir nicht so schlecht am Start.


https://mirrors.edge.kernel.org/pub/linux/utils/fs/xfs/xfsprogs/

Holger
Marcus Roeckrath
2019-04-23 19:09:41 UTC
Permalink
Hallo Derya,
Post by D. Oezbilen
so wie ich das Problem verstand haengen die xfsprogs hinterher?
Nicht der Kernel.
IMHO genau andersherum.

Das xfsprogs-Paket (interne Programmversion 4.x) enthält die aktuellesten
Tools, die auch V5 Superblockoptionen setzen können, die unser Kernel aber
nicht beherrscht.

Möglicherweise ist mindestens ein kernel 4.9 notwendig.

Die älteren xfsprogs der version 3.x konnten crc=1 auch schonsetzen, aber
der Default war da noch crc=0.
--
Gruss Marcus
Marcus Roeckrath
2019-04-23 19:12:43 UTC
Permalink
Hallo Derya,
Post by D. Oezbilen
Wenn doch, hoffe ich, dass dieser Unterschied xfs vs kernel-Version
nicht die Show zum Stoppen bringt. Vllt. koennt ihr das mit einem
update/upgrade glattziehen?
Mir fällt dazu nur ein, mkfs.xfs nach mkfs.xfs.org umzubennen und mkfs.xfs
als Wrapper zu erstellen, der zwangsweise mkfs.xfs.org mit "-m crc=0"
aufruft, so dass mkfs.xfs besser zu unserem Kernel passt.
--
Gruss Marcus
Holger Bruenjes
2019-04-23 19:27:06 UTC
Permalink
Hallo Marcus
Post by Marcus Roeckrath
Mir fällt dazu nur ein, mkfs.xfs nach mkfs.xfs.org umzubennen und mkfs.xfs
als Wrapper zu erstellen, der zwangsweise mkfs.xfs.org mit "-m crc=0"
aufruft, so dass mkfs.xfs besser zu unserem Kernel passt.
joo,

Holger
Holger Bruenjes
2019-04-23 20:23:51 UTC
Permalink
Hallo
Post by Marcus Roeckrath
Mir fällt dazu nur ein, mkfs.xfs nach mkfs.xfs.org umzubennen und mkfs.xfs
als Wrapper zu erstellen, der zwangsweise mkfs.xfs.org mit "-m crc=0"
aufruft, so dass mkfs.xfs besser zu unserem Kernel passt.
joo,
Neues Paket mit xfsprogs-4.20.0 liegt auf Pack-Eis

mit wrapper Skript zum setzen des default '-m crc=0' fuer eisfair ;-)

Holger
Thomas Bork
2019-04-24 10:18:08 UTC
Permalink
Post by Holger Bruenjes
Neues Paket mit xfsprogs-4.20.0 liegt auf Pack-Eis
mit wrapper Skript zum setzen des default '-m crc=0' fuer eisfair ;-)
Ist mir trotzdem schleierhaft. Ab Kernel 3.16 ist v5 kein
experimentelles Feature mehr und so ist das auch in unserem Kernel:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/xfs?h=linux-3.16.y&id=53801fd97ae000793f51187b122b9475102199a8
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/xfs?h=linux-3.16.y&id=c99d609a16506602a7398eea7d12b13513f3d889
https://serverfault.com/questions/746377/want-to-understand-xfs-strangeness

Unsere Kernel-Konfiguration:

CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_XFS_RT=y
# CONFIG_XFS_WARN is not set
# CONFIG_XFS_DEBUG is not set

Die Konfigurationsmöglichkeiten:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/xfs/Kconfig?h=linux-3.16.y

Also in meinen Augen stimmt da etwas anderes bei Derya nicht...
--
der tom
[eisfair-team]
D. Oezbilen
2019-04-24 16:01:15 UTC
Permalink
Morgen Thomas,
Post by Thomas Bork
Also in meinen Augen stimmt da etwas anderes bei Derya nicht...
... :-)

Ich will hier nochmal expressis verbis darstellen, das diese Einheit am
Standard lebt, bleibt. Sprich ISO rein, Install unter kvm, dann pakete
nachziehen und immer die updates (stabile) nachziehen. Das war es.

Da ich *auch* nix in diesem Bereich eigens nachgezogen habe, wuesste ich
nicht wo anzusetzen, was an dieser x64 Einheit so anders sein soll.

Ich kann den alten Kernel booten und koennte auch eine alte Einheit

virteis.I.ohne_Update_ohne_Dev

v. 07.04. booten und versuchen dort eine Part. zu formatieren.
Melde mich spaeter dazu.

Derya
Marcus Roeckrath
2019-04-24 16:25:04 UTC
Permalink
Hallo Derya,
Post by D. Oezbilen
Post by Thomas Bork
Also in meinen Augen stimmt da etwas anderes bei Derya nicht...
... :-)
Ich will hier nochmal expressis verbis darstellen, das diese Einheit am
Standard lebt, bleibt. Sprich ISO rein, Install unter kvm, dann pakete
nachziehen und immer die updates (stabile) nachziehen. Das war es.
Da ich *auch* nix in diesem Bereich eigens nachgezogen habe, wuesste ich
nicht wo anzusetzen, was an dieser x64 Einheit so anders sein soll.
Ich kann den alten Kernel booten und koennte auch eine alte Einheit
virteis.I.ohne_Update_ohne_Dev
v. 07.04. booten und versuchen dort eine Part. zu formatieren.
Melde mich spaeter dazu.
Du hast auf dem eisfair-Server das Paket xfsprogs installiert und dann auf
dem eisfair-Server mkfs.xfs ausgeführt?
--
Gruss Marcus
D. Oezbilen
2019-04-24 17:24:21 UTC
Permalink
Hallo Marcus, Thomas,
Post by Marcus Roeckrath
Du hast auf dem eisfair-Server das Paket xfsprogs installiert und dann auf
dem eisfair-Server mkfs.xfs ausgeführt?
... ich formtiere nicht zum ersten Mal mit xfs. ;-)
xfsprogs heisst es ueberall.
Aber sicher habe ich das.

Die -1_Vorgaenger der Maschine an der wir wg. certs sassen hat schon
dieses Problem.

Ich habe diese

------------------------------
Linux eis 3.16.60-eisfair-64-VIRT #1 SMP Mon Oct 22 16:31:10 CEST 2018
x86_64 x86_64 x86_64 GNU/Linux
------------------------------

rueckgespielt, s. da, das sagt eisman.

------------------------------
eis # eisman stats
Last database update: 2019-04-05 01:35:37
Last (un)installation time: 2019-04-07 23:17:55

Total number of packages: 3241
- Stable packages: 3196
- Unstable packages: 45

Installed packages: 549
- Stable packages: 527
- Unstable packages: 22
------------------------------

Das ist also eine _Ursprungs_maschine, an der Nix, aber wahrlich nix
verdreht, rumconfiguriert, verstellt etc ist.

Um diese Zeit hatte ich angefangen den neuen eisx64 zum installieren. Da
hat der Apache nicht mal ein Cert. Sprich, nur_stupide_ setup/2/5 (suche
Paket X)/ install.
*nothing more.*

Und auch ein Kernel-Update hat nix gebracht, klar, weil die akt.
Maschine v. heute morgen dieses Verhalten auch aufweisst.

Die hat nicht mal irgendeinen spez. (eigenen) Benutzer:
------------------------------
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/bash
bin:x:2:2:bin:/bin:/bin/bash
eis:x:0:0:eisfair administrator:/home/eis:/bin/bash
halt:x:0:0:halt:/home/eis:/sbin/halt.sh
reboot:x:0:0:reboot:/home/eis:/sbin/reboot.sh
fcron:x:13:6:fcron:/dev/null:/bin/false
nobody:x:65534:65534:nobody:/dev/null:/bin/true
sshd:x:71:65:Privilege separation user sshd:/var/lib/empty:/bin/false
usr:x:2001:100:usr:/home/usr:/bin/bash
telegramd:x:2002:65534:Telegram-CLI user:/home/telegramd:/bin/false
exim:x:42:42:exim:/home/exim:/bin/false
squid:x:23:23:squid:/home/__dummyhome__:/bin/false
clamav:x:85:42:Clamav daemon:/usr/share/clamav:/bin/false
tftp:x:499:499:TFTP account:/srv/tftpboot:/bin/false
ftp:x:28:100:anonymous_ftp:/home/ftp:/bin/false
vftp:x:29:100:pureftp_virtual_users:/home/vftp:/bin/false
ntp:x:498:498:Network Time Protocol:/home/ntp:/bin/false
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
named:x:497:496:Nameserver daemon:/var/lib/named:/bin/false
ldap:x:2003:495:LDAP user:/home/ldap:/bin/false
memcached:x:496:494:Memcached daemon:/var/lib/memcached:/bin/false
uucp:x:495:10:UUCP_user:/var/spool/uucp:/bin/false
fax:x:494:10:FAX_daemon:/var/spool/hylafax:/bin/bash
wwwrun:x:493:65534:WWW daemon apache:/var/www/htdocs:/bin/sh
rpc:x:492:65534:user for rpcbind:/var/lib/empty:/sbin/nologin
statd:x:491:65534:NFS statd daemon:/var/lib/nfs:/sbin/nologin
------------------------------

cmdline sagt dies:
------------------------------
auto BOOT_IMAGE=eis ro root=803 raid=noautodetect console=tty0
console=ttyS0,115200
------------------------------
Ich habe auch einen Log des Bootvorgangs auf ttySx abgefangen.

Fast alle logs zeigen dieses Datum, 04.04.

------------------------------
Apr 4 23:47:32 eis syslogd 1.5.1: restart.
------------------------------
Apr 4 23:47:32 eis klogd: klogd 1.5.1, log source = /proc/kmsg started.
Apr 4 23:47:32 eis klogd: Inspecting /System.map-3.16.60-eisfair-64-VIRT
Apr 4 23:47:32 eis klogd: Loaded 47554 symbols from
/System.map-3.16.60-eisfair-64-VIRT.
Apr 4 23:47:32 eis klogd: Symbols match kernel version 3.16.60.
Apr 4 23:47:32 eis klogd: Loaded 3773 symbols from 44 modules.
------------------------------

_____Sprich_______ nur eine *stupide* installierte Einheit, die mit
diesem Verhalten herkommt, warum auch immer.

q.e.d. ;-)

Ich kann Dir/Euch die virt Einheit irgendwohin hochladen, mit der XML
aus dem Host. Passwort root setzte ich dann auf (dt., kleines) passwort. OK?

Fuer mich ist das nicht tragisch, es ist halt so, Holger hat es doch
schon glatt gezogen, passt. Legen wir uns wieder schlafen.

Danke Euch fuer die Muehe.
Derya
Marcus Roeckrath
2019-04-24 17:38:57 UTC
Permalink
Hallo Derya,
Post by D. Oezbilen
Post by Marcus Roeckrath
Du hast auf dem eisfair-Server das Paket xfsprogs installiert und dann
auf dem eisfair-Server mkfs.xfs ausgeführt?
... ich formtiere nicht zum ersten Mal mit xfs. ;-)
xfsprogs heisst es ueberall.
Aber sicher habe ich das.
Hast du aber nicht explizit geschrieben und es wäre also durchaus möglich,
dass du das Hostsystem benutzt hast.
Post by D. Oezbilen
Fuer mich ist das nicht tragisch, es ist halt so, Holger hat es doch
schon glatt gezogen, passt. Legen wir uns wieder schlafen.
Mir läßt sowas keine Ruhe, denn laut Thomas sollte das mit einem
3.16er-Kernel gehen; Holgers Test sagen aber auch was anderes.
--
Gruss Marcus
D. Oezbilen
2019-04-24 18:10:13 UTC
Permalink
Post by Marcus Roeckrath
Mir läßt sowas keine Ruhe, denn laut Thomas sollte das mit einem
3.16er-Kernel gehen; Holgers Test sagen aber auch was anderes.
Komm abhaken, ist eine virt. Maschine, ist schnell gesichert und auch
rueckgespielt.

Ausserdem hat Holger das Problem doch schon erschlagen. ;-)
Zudem, 1x formatiert, dann nie wieder? Vllt.

... etwas Schwund ist immer. ;-)

Danke Dir.
Derya
D. Oezbilen
2019-04-24 18:28:26 UTC
Permalink
Korrektur:
usr 2001 users 100 yes usr
... der existierte doch. Neu angelegt, ist aber off topic.

Derya
Marcus Roeckrath
2019-04-24 18:28:39 UTC
Permalink
Hallo Derya,
Post by D. Oezbilen
Post by Marcus Roeckrath
Mir läßt sowas keine Ruhe, denn laut Thomas sollte das mit einem
3.16er-Kernel gehen; Holgers Test sagen aber auch was anderes.
Komm abhaken, ist eine virt. Maschine, ist schnell gesichert und auch
rueckgespielt.
Ausserdem hat Holger das Problem doch schon erschlagen. ;-)
Zudem, 1x formatiert, dann nie wieder? Vllt.
Nur über einen Wrapper sichergestellt, dass ohne explizite
Formatierungsoptionen crc=0 gilt.
Post by D. Oezbilen
... etwas Schwund ist immer. ;-)
Damit geben wir uns nicht zufrieden, weil Schwund Datenverlust bedeuten
kann.
--
Gruss Marcus
D. Oezbilen
2019-04-24 18:48:22 UTC
Permalink
Post by Marcus Roeckrath
Nur über einen Wrapper sichergestellt, dass ohne explizite
Formatierungsoptionen crc=0 gilt.
yepp
Post by Marcus Roeckrath
Post by D. Oezbilen
... etwas Schwund ist immer. ;-)
Damit geben wir uns nicht zufrieden, weil Schwund Datenverlust bedeuten
kann.
Gehoert das nicht dazu?
Solche eiserne Regeln sind nicht alltagstauglich. ;-)

Ich weiss, was Du meinst, doch das ist ein minder, mini, kleines
Problem. Es gibt andere Baustellen, wo z.B. eine Maschine staendig
irgendwas hat, sowas ist doch dann absolut nicht mehr fuer den Alltag,
da nicht verlaesslich.

Derya

Marcus Roeckrath
2019-04-23 18:47:13 UTC
Permalink
Hallo Derya,
Post by D. Oezbilen
Post by D. Oezbilen
mkfs.xfs -f -m crc=0 /dev/sda4
__Korrektur___
mkfs.xfs -f -m crc=0 /dev/sdaX
funkt.
Ok, hatte mich nach Studium der manpage schon etwas verwundert, denn finobt
steht überhaupt nur zur Verfügung, wenn crc=1 gesetzt ist.

Nach Manpage müsste

crc=1,finobt=0

und

crc=1, finobt=1

möglich sein.
--
Gruss Marcus
Marcus Roeckrath
2019-04-23 18:45:32 UTC
Permalink
Hallo Derya,
Post by D. Oezbilen
-m crc=0 > lauten muss, was üblicherweise auch Default sein sollte.
So wird es aber nicht akzeptiert oder nicht richtig interpretiert.
D.h. crc=0 als default wird im System nicht gesehen.
Die haben in den aktuellen Versionen von mkfs.xfs den Default auf crc=1
gewechselt, also muss auf eis explizit "-m crc=0,finobt=0" gesetzt werden.
Post by D. Oezbilen
PS: Im Umkehrschluss, kaum jemand setzt es ein? Sons waere es
aufgefallen, oder das Problem hat sich neulich mit einem Upgrade/Update
eingeschlichen.
Ich halte nichts davon, die alten (möglicherweise bugbehafteten) Tools zu
nehmen.
--
Gruss Marcus
D. Oezbilen
2019-04-23 18:18:17 UTC
Permalink
Hallo @all,

die Loesung ist

-m crc=0,finobt=0
(mkfs.xfs -f -m crc=0,finobt=0 /dev/sdaX)

zu verwenden.

Hier

<https://serverfault.com/questions/746377/want-to-understand-xfs-strangeness>

ist es beschrieben. Die Versionen xfs vs. kernel stimmen nicht ueberein.
Na gut, ich denk in der Zukunft wird das Problem nicht mehr sein, wenn
die Versionen Kernel/xf wieder passen.

Legen wir uns wieder schlafen. ;-)

Gruss
Derya
Post by D. Oezbilen
so ganz einfache Sachen bringen unerwartet Probleme.
mkfs.xfs
welches in der virt. Umgebung (kvm) das mit
gdisk o. fdisk
eine 8GB HD (unter kvm als IDE oder SCSI, kein virtio eingebunden)
formatiert
*___aber___ nicht mountet*.
#################################################
Apr 23 18:25:44 linuxsrv klogd:  hdb: hdb1
Apr 23 18:26:14 linuxsrv klogd: XFS (hdb1): Superblock has unknown
incompatible features (0x2) enabled.
Apr 23 18:26:14 linuxsrv klogd: Filesystem can not be safely mounted by
this kernel.
Apr 23 18:26:14 linuxsrv klogd: XFS (hdb1): SB validate failed with
error 22.
#################################################
Damit der Host aus der Schusslinie kommt (bisher Null Probleme mit nix
;-) gehabt, auch nicht mit mkfs.xfs, setze es bevorzugt fuer alle
Part./Platten ein, bei mir historisch bedingt), habe die virt. Maschine v.
gparted-live-0.25.0-3-amd64.iso
gebootet, dort eine XFS angelegt. Vor habe ich auch eine msdos mbr neu
angelegt.
S. da, jetzt wird diese XFS formatierte (mit SCSI, sym895 bei der
Installation des eis X64 ausgewaehlt, nicht virtio) HD (/dev/sdb1) *ohne
Probleme* eingebunden.
Apr 23 18:39:21 linuxsrv klogd: XFS (sdb1): Mounting V5 Filesystem
Apr 23 18:39:21 linuxsrv klogd: XFS (sdb1): Ending clean mount
(ja hier sdb, oben hdb, weil hin und her (ide(SCSi) gebootet,
Fehlermeldung ist ident.)
Damit ist das Problem _fuer_mich_ umschifft, und trotzdem ist es schal.
Linux version 3.16.63-eisfair-64-VIRT
Ist halt etwas nervig, wenn man mal zwischendurch (aus welchem Grund
auch immer) eine Part. mit XFS formatieren muss, man die virt. Einheit
wie o.a. booten, formatieren muss.
Ist das ein Feature (s. Fehlermeldung) oder ein Bug?
Gruss
Derya
Marcus Roeckrath
2019-04-23 18:41:35 UTC
Permalink
Hallo Derya,
Post by D. Oezbilen
die Loesung ist
-m crc=0,finobt=0
(mkfs.xfs -f -m crc=0,finobt=0 /dev/sdaX)
zu verwenden.
Ja.
<https://serverfault.com/questions/746377/want-to-understand-xfs-strangeness>
Post by D. Oezbilen
ist es beschrieben. Die Versionen xfs vs. kernel stimmen nicht ueberein.
Na gut, ich denk in der Zukunft wird das Problem nicht mehr sein, wenn
die Versionen Kernel/xf wieder passen.
Kommt darauf an, ab welcher Kernellinie das geht und wann wir diese
Versionsgrenze erreichen.
Post by D. Oezbilen
Legen wir uns wieder schlafen. ;-)
Nein, jetzt läuft Game of Thrones. :-)
--
Gruss Marcus
Loading...