Moin Debianisten,

für das Backup benutze ich einen ML350 G5, der allnächtlich per
ACPI-Wakup anläuft, mit rsync die Daten von ein paar Quellen einsammelt
und dann wieder runter fährt. Das läuft seit langer Zeit einwandfrei.

Nach dem Bullseye-Upgrade startet der Server nicht mehr zuverlässig,
egal ob per ACPI, WOL oder Druck auf die Power-Taste. In etwa 20 Prozent
der Fälle bleibt er irgendwo beim Start der initrd stehen - ohne das
rootfs gemounted zu haben. Somit kann ich beim nächsten gelungenen Start
keine Logeinträge vom gescheiterten Startversuch sehen.

"Gelöst" habe ich die Situation durch ein Kernel-Downgrade von 5.10 auf
4.19.

Ich würde mittels Bugreport gerne einen Beitrag zum Debugging leisten, letztlich auch im eigenen Interesse. Leider kann ich aber außer der
recht lapidaren Situationsbeschreibung keinerlei Material liefern - auch
auf der Konsole steht nichts Hilfreiches.
Wie kriege ich vom (gescheiterten) Bootvorgang mehr Daten heraus?

Dank und Grüße,


Boris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Moin Boris ,

Am 21.09.21 um 09:03 schrieb Boris:

Moin Debianisten,

für das Backup benutze ich einen ML350 G5, der allnächtlich per
ACPI-Wakup anläuft, mit rsync die Daten von ein paar Quellen einsammelt
und dann wieder runter fährt. Das läuft seit langer Zeit einwandfrei.

Nach dem Bullseye-Upgrade startet der Server nicht mehr zuverlässig,
egal ob per ACPI, WOL oder Druck auf die Power-Taste. In etwa 20 Prozent
der Fälle bleibt er irgendwo beim Start der initrd stehen - ohne das
rootfs gemounted zu haben. Somit kann ich beim nächsten gelungenen Start keine Logeinträge vom gescheiterten Startversuch sehen.

"Gelöst" habe ich die Situation durch ein Kernel-Downgrade von 5.10 auf 4.19.

Ich würde mittels Bugreport gerne einen Beitrag zum Debugging leisten, letztlich auch im eigenen Interesse. Leider kann ich aber außer der
recht lapidaren Situationsbeschreibung keinerlei Material liefern - auch
auf der Konsole steht nichts Hilfreiches.
Wie kriege ich vom (gescheiterten) Bootvorgang mehr Daten heraus?

klasse Maschine, auch wenn sie schon ein paar Tage alt ist. :-)

Aus eigenen leidvollen Erfahrungen mit debian und Derivaten auf manchen HP-Maschinen (vor allem Laptops) möchte ich eine weitere Idee
beisteuern: Hast du das letzte BIOS (von 2015) drauf? Nur so eine Idee.

hth, LG
Christoph

--
Bitte keine Mails von USA-Providern wie AOL, me.com/icloud (Apple),
gmail (Google), hotmail/outlook.com (Microsoft) oder yahoo.
Solche Mails werden ohne Rückmeldung gelöscht.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Moin Christoph,

Am 21.09.21 um 11:22 schrieb Christoph Schmees:

Moin Boris ,

Am 21.09.21 um 09:03 schrieb Boris:

Moin Debianisten,

für das Backup benutze ich einen ML350 G5, der allnächtlich per
ACPI-Wakup anläuft, mit rsync die Daten von ein paar Quellen einsammelt
und dann wieder runter fährt. Das läuft seit langer Zeit einwandfrei.

Nach dem Bullseye-Upgrade startet der Server nicht mehr zuverlässig,
egal ob per ACPI, WOL oder Druck auf die Power-Taste. In etwa 20 Prozent
der Fälle bleibt er irgendwo beim Start der initrd stehen - ohne das
rootfs gemounted zu haben. Somit kann ich beim nächsten gelungenen Start
keine Logeinträge vom gescheiterten Startversuch sehen.

"Gelöst" habe ich die Situation durch ein Kernel-Downgrade von 5.10 auf
4.19.

Ich würde mittels Bugreport gerne einen Beitrag zum Debugging leisten,
letztlich auch im eigenen Interesse. Leider kann ich aber außer der
recht lapidaren Situationsbeschreibung keinerlei Material liefern - auch
auf der Konsole steht nichts Hilfreiches.
Wie kriege ich vom (gescheiterten) Bootvorgang mehr Daten heraus?

klasse Maschine, auch wenn sie schon ein paar Tage alt ist. :-)

Aus eigenen leidvollen Erfahrungen mit debian und Derivaten auf manchen HP-Maschinen (vor allem Laptops) möchte ich eine weitere Idee
beisteuern: Hast du das letzte BIOS (von 2015) drauf? Nur so eine Idee.

Danke für Deine Gedanken!

Ja, um das BIOS hab' ich mich schon bemüht, eher wegen anderer Sachen
(ACPI: SPCR: Unexpected SPCR Access Width. Defaulting to byte size,
BIOS has corrupted hw-PMU ressources, pcc_cpufreq_init: Too many CPUs,
dynamic performance scaling disabled. Try to enable another scaling
driver through BIOS and complain to the system vendor).
Das BIOS
DMI: HP ProLiant ML350 G6, BIOS D22 08/16/2015
sowie das Abschalten des "Processor Power and Utilization Monitoring"
hat aber gegen dieses ganze Gequängel nicht geholfen.

Nichtsdestotrotz läuft der Rechner mit dem älteren Kern klaglos stabil, wohingegen - wie beschrieben - der Kernel 5.10 keine Freude bereitet.

Grüße,


Boris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 21.09.21 um 15:25 schrieb Boris:

Moin Christoph,

Am 21.09.21 um 11:22 schrieb Christoph Schmees:

Moin Boris ,

Am 21.09.21 um 09:03 schrieb Boris:

Nach dem Bullseye-Upgrade startet der Server nicht mehr zuverlässig,
egal ob per ACPI, WOL oder Druck auf die Power-Taste. In etwa 20
Prozent
der Fälle bleibt er irgendwo beim Start der initrd stehen - ohne das
rootfs gemounted zu haben. Somit kann ich beim nächsten gelungenen
Start
keine Logeinträge vom gescheiterten Startversuch sehen.

"Gelöst" habe ich die Situation durch ein Kernel-Downgrade von 5.10 auf >>> 4.19.

Ich würde mittels Bugreport gerne einen Beitrag zum Debugging leisten,
letztlich auch im eigenen Interesse. Leider kann ich aber außer der
recht lapidaren Situationsbeschreibung keinerlei Material liefern -
auch
auf der Konsole steht nichts Hilfreiches.
Wie kriege ich vom (gescheiterten) Bootvorgang mehr Daten heraus?

klasse Maschine, auch wenn sie schon ein paar Tage alt ist. :-)

Aus eigenen leidvollen Erfahrungen mit debian und Derivaten auf manchen
HP-Maschinen (vor allem Laptops) möchte ich eine weitere Idee
beisteuern: Hast du das letzte BIOS (von 2015) drauf? Nur so eine Idee.

Danke für Deine Gedanken!

Ja, um das BIOS hab' ich mich schon bemüht, eher wegen anderer Sachen
(ACPI: SPCR: Unexpected SPCR Access Width. Defaulting to byte size,
BIOS has corrupted hw-PMU ressources, pcc_cpufreq_init: Too many CPUs, dynamic performance scaling disabled. Try to enable another scaling
driver through BIOS and complain to the system vendor).

Ich weiß jetzt nicht ob da immer noch das Management des Server so läuft
wie auf den Compaq ProLiant, bei meinen ProLiant musste ich den kernel
mit der Option Go Bios neu erstellen.


Gruß

Dirk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Moin Dirk,

Am 21.09.21 um 18:47 schrieb Dirk Paul Finkeldey:

Am 21.09.21 um 15:25 schrieb Boris:

Moin Christoph,

Am 21.09.21 um 11:22 schrieb Christoph Schmees:

Moin Boris ,

Am 21.09.21 um 09:03 schrieb Boris:

Nach dem Bullseye-Upgrade startet der Server nicht mehr zuverlässig,
egal ob per ACPI, WOL oder Druck auf die Power-Taste. In etwa 20
Prozent
der Fälle bleibt er irgendwo beim Start der initrd stehen - ohne das
rootfs gemounted zu haben. Somit kann ich beim nächsten gelungenen
Start
keine Logeinträge vom gescheiterten Startversuch sehen.

"Gelöst" habe ich die Situation durch ein Kernel-Downgrade von 5.10 auf >>>> 4.19.

Ich würde mittels Bugreport gerne einen Beitrag zum Debugging leisten, >>>> letztlich auch im eigenen Interesse. Leider kann ich aber außer der
recht lapidaren Situationsbeschreibung keinerlei Material liefern -
auch
auf der Konsole steht nichts Hilfreiches.
Wie kriege ich vom (gescheiterten) Bootvorgang mehr Daten heraus?

klasse Maschine, auch wenn sie schon ein paar Tage alt ist. :-)

Aus eigenen leidvollen Erfahrungen mit debian und Derivaten auf manchen
HP-Maschinen (vor allem Laptops) möchte ich eine weitere Idee
beisteuern: Hast du das letzte BIOS (von 2015) drauf? Nur so eine Idee.

Danke für Deine Gedanken!

Ja, um das BIOS hab' ich mich schon bemüht, eher wegen anderer Sachen
(ACPI: SPCR: Unexpected SPCR Access Width. Defaulting to byte size,
BIOS has corrupted hw-PMU ressources, pcc_cpufreq_init: Too many CPUs,
dynamic performance scaling disabled. Try to enable another scaling
driver through BIOS and complain to the system vendor).

Ich weiß jetzt nicht ob da immer noch das Management des Server so läuft wie auf den Compaq ProLiant, bei meinen ProLiant musste ich den kernel
mit der Option Go Bios neu erstellen.

mmmhh, das Zeitalter 'Compaq' riecht ja nun wirklich schon ein bisschen
nach Museum.....
Eine Kernel Option "Go Bios" kann ich weder in 4.19 noch in 5.10 finden.

Grüße,


Boris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Moin,

On 21 September 2021 09:03:44 CEST, Boris <boris@cation.de> wrote:

Moin Debianisten,

Ich würde mittels Bugreport gerne einen Beitrag zum Debugging leisten, >letztlich auch im eigenen Interesse. Leider kann ich aber außer der
recht lapidaren Situationsbeschreibung keinerlei Material liefern - auch
auf der Konsole steht nichts Hilfreiches.
Wie kriege ich vom (gescheiterten) Bootvorgang mehr Daten heraus?

Schau Dir mal netconsole an, damit schickst Du Lognachrichten des einen Rechners über das Netzwerk an einen anderen Rechner.

Dank und Grüße,

Boris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --C7OXXNXD9TDPzlqRhOvVCzbEJ7Nr5cqUO
Content-Type: multipart/mixed;
boundary="------------455235759775FF32F5C6AD33"
Content-Language: de-DE-frami

This is a multi-part message in MIME format. --------------455235759775FF32F5C6AD33
Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable

Am 23.09.21 um 21:13 schrieb Boris:

Moin Dirk,

Am 21.09.21 um 18:47 schrieb Dirk Paul Finkeldey:

Am 21.09.21 um 15:25 schrieb Boris:

Moin Christoph,

Am 21.09.21 um 11:22 schrieb Christoph Schmees:

Moin Boris ,

Am 21.09.21 um 09:03 schrieb Boris:

Nach dem Bullseye-Upgrade startet der Server nicht mehr zuverlässig, >>>>> egal ob per ACPI, WOL oder Druck auf die Power-Taste. In etwa 20
Prozent
der Fälle bleibt er irgendwo beim Start der initrd stehen - ohne das >>>>> rootfs gemounted zu haben. Somit kann ich beim nächsten gelungenen >>>>> Start
keine Logeinträge vom gescheiterten Startversuch sehen.

"Gelöst" habe ich die Situation durch ein Kernel-Downgrade von
5.10 auf
4.19.

Ich würde mittels Bugreport gerne einen Beitrag zum Debugging
leisten,
letztlich auch im eigenen Interesse. Leider kann ich aber außer der >>>>> recht lapidaren Situationsbeschreibung keinerlei Material liefern
- auch
auf der Konsole steht nichts Hilfreiches.
Wie kriege ich vom (gescheiterten) Bootvorgang mehr Daten heraus?

klasse Maschine, auch wenn sie schon ein paar Tage alt ist. :-)

Aus eigenen leidvollen Erfahrungen mit debian und Derivaten auf
manchen
HP-Maschinen (vor allem Laptops) möchte ich eine weitere Idee
beisteuern: Hast du das letzte BIOS (von 2015) drauf? Nur so eine
Idee.

Danke für Deine Gedanken!

Ja, um das BIOS hab' ich mich schon bemüht, eher wegen anderer
Sachen (ACPI: SPCR: Unexpected SPCR Access Width. Defaulting to byte
size,
BIOS has corrupted hw-PMU ressources, pcc_cpufreq_init: Too many
CPUs, dynamic performance scaling disabled. Try to enable another
scaling driver through BIOS and complain to the system vendor).

Ich weiß jetzt nicht ob da immer noch das Management des Server so
läuft wie auf den Compaq ProLiant, bei meinen ProLiant musste ich den
kernel mit der Option Go Bios neu erstellen.

mmmhh, das Zeitalter 'Compaq' riecht ja nun wirklich schon ein
bisschen nach Museum.....
Eine Kernel Option "Go Bios" kann ich weder in 4.19 noch in 5.10 finden.

config-4.19.0-0.bpo.17-rt-686-pae


# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y

Grüße,

Boris

Gruß Dirk

--------------455235759775FF32F5C6AD33
Content-Type: application/pgp-keys;
name="OpenPGP_0xCA85AD4EC5EB3AEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Description: OpenPGP public key
Content-Disposition: attachment;
filename="OpenPGP_0xCA85AD4EC5EB3AEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEYUyh4hYJKwYBBAHaRw8BAQdA9RURRsFRjDSb0MafA7JM1rW11Tl5FFfn5bxpo59MDovNL0Rp cmsgUGF1bCBGaW5rZWxkZXkgPGRpcmsuZmlua2VsZGV5QGV3ZXRlbC5uZXQ+wosEExYIADMWIQRH 06WI+/Avb6u/I7vKha1Oxes66gUCYUyh4gIbAwULCQgHAgYVCAkKCwIFFgIDAQAACgkQyoWtTsXr OuoR0AD+MnTiZEOQ8cXOg7F/t/02YdLUYd8xMP5CQvwbEss0GzkA/i9sycLUdXEc8ABvDAtj3xpl jCuagHx2Zk6lCIg+csIMzjgEYUyh4xIKKwYBBAGXVQEFAQEHQFEmJT8suAbHOgcgmg+81O96wRoJ zxb4eOAeYb6ldaMSAwEIB8J4BBgWCAAgFiEER9OliPvwL2+rvyO7yoWtTsXrOuoFAmFMoeMCGwwA CgkQyoWtTsXrOupGeQEA6V/xjF2JdCcrRZs1d3fIxPUUNVldizbQrUozhAWap3kA/jXXyOHpbMWb PIIoVwB0Y/9u+27XSiK7rmYRFRGJHvoL
=l36+
-----END PGP PUBLIC KEY BLOCK-----

--------------455235759775FF32F5C6AD33--

--C7OXXNXD9TDPzlqRhOvVCzbEJ7Nr5cqUO--

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQRH06WI+/Avb6u/I7vKha1Oxes66gUCYVMOWQUDAAAAAAAKCRDKha1Oxes66l6h AP9RmgkRi7luDoIO9Xj8ubAEdbkBwpZBa/w8zRxqkKEtZQD/Z0O78ngYVSdHCBns0XqymGxiiB7L gZ4Q51cZcUyAFQo=
=KUvT
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 21.09.21 um 09:03 schrieb Boris:

Nach dem Bullseye-Upgrade startet der Server nicht mehr zuverlässig, egal ob per ACPI, WOL oder Druck auf die Power-Taste. In etwa 20 Prozent der Fälle bleibt er irgendwo beim Start der initrd stehen - ohne das rootfs gemounted zu haben. Somit kann

ich beim nächsten gelungenen Start keine Logeinträge vom gescheiterten Startversuch sehen.
Hallo,

ich hatte so ein Verhalten mal vor langer Zeit nachdem ich ein debian Upgrade durchgeführt hatte
und auf systemd umgestellt wurde. Wenn ich mich recht entsinne gab es keine Probleme wenn ich
den alten init-Modus gebootet habe. Was dabei raus gekommen war, das während des bootens der systemd
durch das parallele starten sich ab und an mal was aufgehängt hatte und daher dann das / nicht
gemountet wurde, weil Er immer auf was wartete. Irgendwann hatte sich das von selber erledigt.

Ich weiss nicht mehr woran es gelegen hatte aber erinnere mich das es damals was mit dem random-
Generator war, wenn der zu wenig entropie geliefert hatte. Aber ob es jetzt das war oder ich hier
was verwechsle kann ich nicht mehr sagen.

Vielleicht ist es ja wieder so was ähnliches. Irgendwie hörst sich das für mich so an, als würden
ggf. Module manchmal in der falschen Reihenfolge geladen werden, oder mal das eine und mal ein
anderes Modul für die gleiche HW oder ... und dann fällt mir noch ein meine PCI-Devices bekommen
nach dem reboot manchmal andere PCI-Adressen als nach einem powerswitch, was bei XEN ziemlich
lästig ist und ich daher den Server jedes mal beim runter fahren auch kurz ausschalten muss.

MfG,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Moin Robert,

Am 24.09.21 um 06:24 schrieb Robert Pommrich:

Moin,

On 21 September 2021 09:03:44 CEST, Boris <boris@cation.de> wrote:

Moin Debianisten,

Ich würde mittels Bugreport gerne einen Beitrag zum Debugging leisten,
letztlich auch im eigenen Interesse. Leider kann ich aber außer der
recht lapidaren Situationsbeschreibung keinerlei Material liefern - auch
auf der Konsole steht nichts Hilfreiches.
Wie kriege ich vom (gescheiterten) Bootvorgang mehr Daten heraus?

Schau Dir mal netconsole an, damit schickst Du Lognachrichten des einen Rechners über das Netzwerk an einen anderen Rechner.

mmhh, das muss ich dann aber erst in initrd einbauen. Und es liefert mir vermutlich auch nicht mehr als das, was ich auf dem Monitor sehen kann.....

Grüße,

Boris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Moin Dirk,

späte Antwort, aber ich bin noch dran!

Am 28.09.21 um 14:45 schrieb Dirk Paul Finkeldey:

Am 23.09.21 um 21:13 schrieb Boris:

Moin Dirk,

Am 21.09.21 um 18:47 schrieb Dirk Paul Finkeldey:

Am 21.09.21 um 15:25 schrieb Boris:

Moin Christoph,

Am 21.09.21 um 11:22 schrieb Christoph Schmees:

Moin Boris ,

Am 21.09.21 um 09:03 schrieb Boris:

Nach dem Bullseye-Upgrade startet der Server nicht mehr zuverlässig, >>>>>> egal ob per ACPI, WOL oder Druck auf die Power-Taste. In etwa 20
Prozent
der Fälle bleibt er irgendwo beim Start der initrd stehen - ohne das >>>>>> rootfs gemounted zu haben. Somit kann ich beim nächsten gelungenen >>>>>> Start
keine Logeinträge vom gescheiterten Startversuch sehen.

"Gelöst" habe ich die Situation durch ein Kernel-Downgrade von
5.10 auf
4.19.

Ich würde mittels Bugreport gerne einen Beitrag zum Debugging
leisten,
letztlich auch im eigenen Interesse. Leider kann ich aber außer der >>>>>> recht lapidaren Situationsbeschreibung keinerlei Material liefern
- auch
auf der Konsole steht nichts Hilfreiches.
Wie kriege ich vom (gescheiterten) Bootvorgang mehr Daten heraus?

klasse Maschine, auch wenn sie schon ein paar Tage alt ist. :-)

Aus eigenen leidvollen Erfahrungen mit debian und Derivaten auf
manchen
HP-Maschinen (vor allem Laptops) möchte ich eine weitere Idee
beisteuern: Hast du das letzte BIOS (von 2015) drauf? Nur so eine
Idee.

Danke für Deine Gedanken!

Ja, um das BIOS hab' ich mich schon bemüht, eher wegen anderer
Sachen (ACPI: SPCR: Unexpected SPCR Access Width. Defaulting to byte
size,
BIOS has corrupted hw-PMU ressources, pcc_cpufreq_init: Too many
CPUs, dynamic performance scaling disabled. Try to enable another
scaling driver through BIOS and complain to the system vendor).

Ich weiß jetzt nicht ob da immer noch das Management des Server so
läuft wie auf den Compaq ProLiant, bei meinen ProLiant musste ich den
kernel mit der Option Go Bios neu erstellen.

mmmhh, das Zeitalter 'Compaq' riecht ja nun wirklich schon ein
bisschen nach Museum.....
Eine Kernel Option "Go Bios" kann ich weder in 4.19 noch in 5.10 finden.

config-4.19.0-0.bpo.17-rt-686-pae

# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y

Dank für's Zeigen!
Ich benutze auf allen System amd64 Kernel. Vielleicht liegt es daran,
dass es die Option CONFIG_PCI_GOBIOS weder in der Kernelversion 4.19.x
noch 5.10.x zu geben scheint.

Grüße,

Boris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)