E1/E64 Patch für Eiskernel

[Thomas Zweifel]

Hallo Tom


Könntest Du folgenden Patch in den Eiskernel mitaufnehmen:

patchwork.kernel.org/patch/5684621/


Er lässt den kernel Logeintrag weg, dass keine Partitionstabelle auf dem
Device gefunden wurde.

LVM2 spammt sonst das logfile mit der unnützen Info zu.

Jun 12 23:56:32 eis64test klogd: md5: unknown partition table
Jun 12 23:56:32 eis64test klogd: md7: unknown partition table
Jun 12 23:56:32 eis64test klogd: md10: unknown partition table
Jun 12 23:56:37 eis64test klogd: md5: unknown partition table
Jun 12 23:56:37 eis64test klogd: md7: unknown partition table
Jun 12 23:56:37 eis64test klogd: md10: unknown partition table
Jun 12 23:56:42 eis64test klogd: md5: unknown partition table
Jun 12 23:56:42 eis64test klogd: md7: unknown partition table
Jun 12 23:56:42 eis64test klogd: md10: unknown partition table
Jun 12 23:56:52 eis64test klogd: md5: unknown partition table
Jun 12 23:56:52 eis64test klogd: md7: unknown partition table
Jun 12 23:56:52 eis64test klogd: md10: unknown partition table



Gruss Thomas

[Kay Martinen]

Post by Thomas Zweifel
patchwork.kernel.org/patch/5684621/
Er lässt den kernel Logeintrag weg, dass keine Partitionstabelle auf dem
Device gefunden wurde.
LVM2 spammt sonst das logfile mit der unnützen Info zu.
Jun 12 23:56:32 eis64test klogd:  md5: unknown partition table

Das ist natürlich unschön. Kommt so was nur beim Booten (vermute ich)
oder auch im Betrieb.

In dem Zusammenhang hätte ich auch einen; ebenso kosmetischen; Wunsch.

Bei jedem Booten erhalte ich
EXT3-fs (hdb2): error: couldn't mount because of unsupported optional
features (240)

und das für jedes (ext4) Filesystem das gemountet werden soll. Bei
meinem Fileserver sind es 4 Platten oder Partitionen.

Es hieß hier mal das liegt daran das der Kernel erst ext3 versucht
(obwohl ext4 gemountet werden soll!?) aber die Meldung finde ich nicht
nur nonsens (weil ja ext4 gemountet wird) sondern sie wird auch als
Fehler/Error gemeldet/gewertet. Dmesg zeigt sie in Rot.

Und es zerstört die Abfolge der Textmeldungen beim Start - so das
wirkliche Fehlermeldungen weniger gut auf fallen.


Kay

[Thomas Zweifel]

Post by Kay Martinen

Post by Thomas Zweifel
patchwork.kernel.org/patch/5684621/
Er lässt den kernel Logeintrag weg, dass keine Partitionstabelle auf dem
Device gefunden wurde.
LVM2 spammt sonst das logfile mit der unnützen Info zu.
Jun 12 23:56:32 eis64test klogd:  md5: unknown partition table

Das ist natürlich unschön. Kommt so was nur beim Booten (vermute ich)
oder auch im Betrieb.

Leider auch bei pvscan und anderen Kommandos, sehr exzessiv während
eines pvmove.

Post by Kay Martinen
In dem Zusammenhang hätte ich auch einen; ebenso kosmetischen; Wunsch.
Bei jedem Booten erhalte ich
EXT3-fs (hdb2): error: couldn't mount because of unsupported optional
features (240)
und das für jedes (ext4) Filesystem das gemountet werden soll. Bei
meinem Fileserver sind es 4 Platten oder Partitionen.
Es hieß hier mal das liegt daran das der Kernel erst ext3 versucht
(obwohl ext4 gemountet werden soll!?) aber die Meldung finde ich nicht
nur nonsens (weil ja ext4 gemountet wird) sondern sie wird auch als
Fehler/Error gemeldet/gewertet. Dmesg zeigt sie in Rot.
Und es zerstört die Abfolge der Textmeldungen beim Start - so das
wirkliche Fehlermeldungen weniger gut auf fallen.

Beim root FS lässt sich das wohl nicht vermeiden, die restlichen mounts
machen sich hier mit jeweils zwei Einträgen bemerkbar:

eis # dmesg | grep '\] EXT' | grep 'dm-0'
[ 34.615821] EXT4-fs (dm-0): mounted filesystem with journalled data
mode. Opts: errors=remount-ro,data=journal
[ 35.363423] EXT4-fs (dm-0): re-mounted. Opts:
errors=remount-ro,data=journal,acl,user_xattr



Gruss Thomas

[Marcus Roeckrath]

Hallo Kay,

Post by Kay Martinen
In dem Zusammenhang hätte ich auch einen; ebenso kosmetischen; Wunsch.
Bei jedem Booten erhalte ich
EXT3-fs (hdb2): error: couldn't mount because of unsupported optional
features (240)
und das für jedes (ext4) Filesystem das gemountet werden soll. Bei
meinem Fileserver sind es 4 Platten oder Partitionen.
Es hieß hier mal das liegt daran das der Kernel erst ext3 versucht
(obwohl ext4 gemountet werden soll!?) aber die Meldung finde ich nicht
nur nonsens (weil ja ext4 gemountet wird) sondern sie wird auch als
Fehler/Error gemeldet/gewertet. Dmesg zeigt sie in Rot.
Und es zerstört die Abfolge der Textmeldungen beim Start - so das
wirkliche Fehlermeldungen weniger gut auf fallen.

Ich wäre nicht dafür hier am Kernel rumzuschrauben/zu patchen, denn IMHO
läßt sich das nicht einfach durch Setzen einer Kernel-Konfigurationsoption
beeinflussen.

[Thomas Bork]

Post by Kay Martinen
Bei jedem Booten erhalte ich
EXT3-fs (hdb2): error: couldn't mount because of unsupported optional
features (240)

Das ist das normale Vorgehen des Kernels beim Mount der initramfs. Daran
werde ich nicht herumspielen...

[Kay Martinen]

Post by Thomas Bork

Post by Kay Martinen
Bei jedem Booten erhalte ich
EXT3-fs (hdb2): error: couldn't mount because of unsupported optional
features (240)

Das ist das normale Vorgehen des Kernels beim Mount der initramfs. Daran
werde ich nicht herumspielen...

Oh, ich werd alt. Ich hab beim Booten gemeint ich sähe diese Meldungen
auch für die anderen Disks. dmesg zeigt aber nur die obige an.

Na gut. Unschön aber wenn's nicht anders geht.

Ist mir bei anderen Linuxen (Debian) aber so nie auf gefallen. HABEN die
das evtl. gefixt oder ???

Kay

[Marcus Roeckrath]

Hallo Kay,

Post by Kay Martinen

Post by Thomas Bork

Post by Kay Martinen
Bei jedem Booten erhalte ich
EXT3-fs (hdb2): error: couldn't mount because of unsupported optional
features (240)

Das ist das normale Vorgehen des Kernels beim Mount der initramfs. Daran
werde ich nicht herumspielen...

Oh, ich werd alt. Ich hab beim Booten gemeint ich sähe diese Meldungen
auch für die anderen Disks. dmesg zeigt aber nur die obige an.
Na gut. Unschön aber wenn's nicht anders geht.
Ist mir bei anderen Linuxen (Debian) aber so nie auf gefallen. HABEN die
das evtl. gefixt oder ???

Was heißt gefixt? Das ist doch kein Bug, der eines Fixings bedarf sondern
nur ein Logging des Mountings des rootfs, was zumindest unser Kernel
"heuristisch" versucht und das dann dokumentiert.

In eine SuSE finde ich das auch nicht mehr, was einem neueren Kernel
geschuldet ist.

Wenn wir irgendwann mal auf einen 4er-Kernel umsteigen, kann das durchaus
also anders sein.

[Thomas Bork]

Post by Thomas Zweifel
patchwork.kernel.org/patch/5684621/
Er lässt den kernel Logeintrag weg, dass keine Partitionstabelle auf dem
Device gefunden wurde.
LVM2 spammt sonst das logfile mit der unnützen Info zu.

Schaue ich mit unverbindlich, also ohne Garantie auf Integration, an.

Da Du einer der wenigen bist, die lvm auf eisfair verwenden:

Startest Du von lvm-Volumes?
Ich beabsichtige in einer der nächsten Kernel-Versionen von

raid-extra-boot = /dev/sda,/dev/sdb

auf

raid-extra-boot = mbr

in lilo.conf umzustellen. Hintergrund ist eine kommende Konvertierung
von Devicenamen in der lilo.conf für boot (auf /dev/disk/by-id/...) und
für root auf "UUID=..."

Ich meine irgendwo gelesen zu haben, dass beim Start von lvm-Volumes

raid-extra-boot = mbr

tödlich ist, da lvm-Informationen überschrieben werden. Kannst Du das
mal testen?

[Thomas Zweifel]

Post by Thomas Bork

Post by Thomas Zweifel
patchwork.kernel.org/patch/5684621/
Er lässt den kernel Logeintrag weg, dass keine Partitionstabelle auf dem
Device gefunden wurde.
LVM2 spammt sonst das logfile mit der unnützen Info zu.

Schaue ich mit unverbindlich, also ohne Garantie auf Integration, an.

Danke.

Post by Thomas Bork
Startest Du von lvm-Volumes?

Nein, nur die Daten werden per lvm verwaltet.

Post by Thomas Bork
Ich beabsichtige in einer der nächsten Kernel-Versionen von
raid-extra-boot = /dev/sda,/dev/sdb
auf
raid-extra-boot = mbr
in lilo.conf umzustellen. Hintergrund ist eine kommende Konvertierung
von Devicenamen in der lilo.conf für boot (auf /dev/disk/by-id/...) und
für root auf "UUID=..."
Ich meine irgendwo gelesen zu haben, dass beim Start von lvm-Volumes
raid-extra-boot = mbr
tödlich ist, da lvm-Informationen überschrieben werden. Kannst Du das
mal testen?

Mache ich Gerne.



Gruss Thomas

[Thomas Zweifel]

Hallo Tom

Post by Thomas Bork
Ich beabsichtige in einer der nächsten Kernel-Versionen von
raid-extra-boot = /dev/sda,/dev/sdb
auf
raid-extra-boot = mbr
in lilo.conf umzustellen. Hintergrund ist eine kommende Konvertierung
von Devicenamen in der lilo.conf für boot (auf /dev/disk/by-id/...) und
für root auf "UUID=..."
Ich meine irgendwo gelesen zu haben, dass beim Start von lvm-Volumes
raid-extra-boot = mbr
tödlich ist, da lvm-Informationen überschrieben werden. Kannst Du das
mal testen?

Ich schätze, es gibt mit der eis Standardkonstellation (System auf md)
und Daten mit lvm keinerlei Probleme.


eis64test # cat /etc/lilo.conf
lba32
disk = /dev/sda
bios = 0x80
boot = /dev/md1
raid-extra-boot = mbr
read-only
prompt
....

eis64test # lilo
Warning: device-mapper (252) referenced in /proc/partitions,
but LILO is configured without DEVMAPPER option. Skipping device.
Warning: device-mapper (252) referenced in /proc/partitions,
but LILO is configured without DEVMAPPER option. Skipping device.
Warning: /dev/md1 is not on the first disk
Added eis *
Added oldeis
Added 3.16.60-VIRT
The boot record of /dev/md1 has been updated.
Warning: /dev/sdb is not on the first disk
The Master boot record of /dev/sdb has been updated.
Warning: /dev/hda is not on the first disk
The Master boot record of /dev/hda has been updated.
5 warnings were issued.


Selbst grobfahrlässiges herumgemurkse hat nichts beschädigt ;-)



Gruss Thomas

[Thomas Bork]

Selbst grobfahrlässiges herumgemurkse hat nichts beschädigt  ;-)

Ok, danke fürs testen.

[Thomas Bork]

Post by Thomas Bork

Post by Thomas Zweifel
patchwork.kernel.org/patch/5684621/
Er lässt den kernel Logeintrag weg, dass keine Partitionstabelle auf
dem Device gefunden wurde.
LVM2 spammt sonst das logfile mit der unnützen Info zu.

Schaue ich mit unverbindlich, also ohne Garantie auf Integration, an.

Ist in eiskernel 3.43.0 enthalten.