lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-Id: <201105250712.07085.jzb2@aexorsyst.com>
Date:	Wed, 25 May 2011 07:12:07 -0700
From:	"John Z. Bohach" <jzb2@...orsyst.com>
To:	linux-kernel@...r.kernel.org
Subject: NO S5 poweroff with nfsroot (works with same kernel and same rootfs on local storage)

Hello,

I'm running Linux version 2.6.36.1 on an LFS (linuxfromscratch)-based 
distro. and am trying to get the host (AMD-athlon) to physically remove 
power (S5) on a 'halt -n -d -f -p' command issued from runstate "init 
1" from an NFS rootfs (and yes the eth0 rootfs mount is still up in my 
run-level 1).

The results are the kernel code is entered, the "md" device is shutdown, 
and the following:

pci 0000:00:07.0: wake-up cabability enabled by ACPI
ACPI: Preparing to enter system sleep state S5
Disabling non-boot CPU's
SMP alternatives: switching to UP code

Then it hangs, though after a few minutes, I still get some NFS timeout 
messages, though I can't tell which mount, probably the rootfs?

'reboot -n -d -f' does reset the machine from the same state.

The reason I'm posting this here is because when I run the SAME kernel 
and the SAME rootfs from a local disk (/dev/sda1), the system does 
power-off successfully.  I have some custom tweaks to the rc-scripts to 
allow running identical rootfs over NFS and local disk, but I try to 
rule out any runtime differences by restricting my question to 
run-level 1.

Both BIOS and kernel support ACPI and I've fixed the rootfs to run in 
r/o mode, and made some other customizations to allow proper shutdown 
for nfsroot, but to rule out all non-interesting things, I run the 
halt -n -d -f -p command from run-level 1, and I've even run some 
manual commands to kill off every process and every mount that was 
still around.  Obviously I can't kill the root mount over NFS and eth0 
is still up.

Is this supported or is the root cause between the keyboard and the 
chair?

Thanks,
John Z. Bohach
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ