Gordon Tetlow
2018-Jun-21 07:19 UTC
Recent security patch cause reboot loop on 11.1 RELEASE
On Wed, Jun 20, 2018 at 11:14 PM, Denis Polygalov <dpolyg at gmail.com> wrote:> What I did is following: > > # uname -a > FreeBSD my_host_name 11.1-RELEASE-p10 FreeBSD 11.1-RELEASE-p10 #0: Tue > May 8 05:21:56 UTC 2018 > root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > # freebsd-update fetch > Looking up update.FreeBSD.org mirrors... 3 mirrors found. > Fetching metadata signature for 11.1-RELEASE from update6.freebsd.org... done. > Fetching metadata index... done. > Inspecting system... done. > Preparing to download files... done. > > The following files will be updated as part of updating to 11.1-RELEASE-p11: > /boot/kernel/kernel > > Installing this update cause endless reboot loop. > > # cat /boot/loader.conf > kern.maxfiles="32768" > zfs_load="YES" > linux_load="YES" > linprocfs_load="YES" > linsysfs_load="YES" > > # dmesg |grep CPU > CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3400.19-MHz K8-class CPU) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > SMP: AP CPU #1 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #2 Launched! > cpu0: <ACPI CPU> on acpi0 > cpu1: <ACPI CPU> on acpi0 > cpu2: <ACPI CPU> on acpi0 > cpu3: <ACPI CPU> on acpi0 > acpi_perf0: <ACPI CPU Frequency Control> on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: CPU supports Enhanced Speedstep, but is not recognized. > est: CPU supports Enhanced Speedstep, but is not recognized. > > The machine is HP ProLiant ML350Sorry to hear you are having a problem. Just to confirm, this is running on hardware and not on a Xen hypervisor, correct? Assuming it's running directly on the hardware, can you see if setting: hw.lazy_fpu_switch=1 in /boot/loader.conf makes any difference? Is there any panic message? Thanks, Gordon
Denis Polygalov
2018-Jun-21 12:13 UTC
Recent security patch cause reboot loop on 11.1 RELEASE
Seems like I did not cc my reply to the mailing list. Doing it now because I found a hint which may lead to the cause of the reboot loop. Removing: linux_load="YES" linprocfs_load="YES" linsysfs_load="YES" prevent the reboot loop in multi-user mode but leave me without Linux emulation... Regards, Denis.> Hi Gordon, > > this is real hardware. I found the reason (see below). > Setting hw.lazy_fpu_switch=1 in /boot/loader.conf makes no difference. > No panic messages. > I can tell you when it happen. Here is the boot messages: > ... skipped ... > Timecounters tick every 1.000 msec > nvme cam probe device init > ugen2.1: <Intel EHCI root HUB> at usbus2 > ugen1.1: <Intel UHCI root HUB> at usbus1 > ugen0.1: <Intel UHCI root HUB> at usbus0 > uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2 > uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 > uhub2: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1 > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub0: 4 ports with 4 removable, self powered > > <---- here screen (local monitor) goes black and machine restarted. > > ada0 at ata2 bus 0 scbus8 target 0 lun 0 > ada0: <WDC WD2000FYYZ-01UL1B1 01.01K02> ATA8-ACS SATA 3.x device > ada0: Serial Number WD-WMC1P0D1KEHJ > ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) > ada0: 1907729MB (3907029168 512 byte sectors) > da0 at ciss0 bus 0 scbus0 target 0 lun 0 > da0: <HP RAID 5 OK> Fixed Direct Access SCSI device > da0: 135.168MB/s transfers > da0: Command Queueing enabled > da0: 858293MB (1757784604 512 byte sectors) > Trying to mount root from ufs:/dev/da0s1a [rw]... > > I noticed that I can boot the *patched* kernel in single user mode. > Removing these 3 lines from the /boot/loader.conf fixed rebooting loop problem: > > linux_load="YES" > linprocfs_load="YES" > linsysfs_load="YES" > > This machine is used as a test bench to test stuff > before deploying on a production server. > We need Linux emulation support on the production > server to run closed source software... > So... maybe this will help someone. > > Blaming evil penguins, > DenisOn 21/06/2018 4:19 PM, Gordon Tetlow wrote:> On Wed, Jun 20, 2018 at 11:14 PM, Denis Polygalov <dpolyg at gmail.com> wrote: >> What I did is following: >> >> # uname -a >> FreeBSD my_host_name 11.1-RELEASE-p10 FreeBSD 11.1-RELEASE-p10 #0: Tue >> May 8 05:21:56 UTC 2018 >> root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 >> >> # freebsd-update fetch >> Looking up update.FreeBSD.org mirrors... 3 mirrors found. >> Fetching metadata signature for 11.1-RELEASE from update6.freebsd.org... done. >> Fetching metadata index... done. >> Inspecting system... done. >> Preparing to download files... done. >> >> The following files will be updated as part of updating to 11.1-RELEASE-p11: >> /boot/kernel/kernel >> >> Installing this update cause endless reboot loop. >> >> # cat /boot/loader.conf >> kern.maxfiles="32768" >> zfs_load="YES" >> linux_load="YES" >> linprocfs_load="YES" >> linsysfs_load="YES" >> >> # dmesg |grep CPU >> CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3400.19-MHz K8-class CPU) >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> SMP: AP CPU #1 Launched! >> SMP: AP CPU #3 Launched! >> SMP: AP CPU #2 Launched! >> cpu0: <ACPI CPU> on acpi0 >> cpu1: <ACPI CPU> on acpi0 >> cpu2: <ACPI CPU> on acpi0 >> cpu3: <ACPI CPU> on acpi0 >> acpi_perf0: <ACPI CPU Frequency Control> on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: CPU supports Enhanced Speedstep, but is not recognized. >> >> The machine is HP ProLiant ML350 > > Sorry to hear you are having a problem. > > Just to confirm, this is running on hardware and not on a Xen > hypervisor, correct? > > Assuming it's running directly on the hardware, can you see if setting: > hw.lazy_fpu_switch=1 > in /boot/loader.conf makes any difference? > > Is there any panic message? > > Thanks, > Gordon >