[Bug 1398163] [NEW] nvsetenv on PowerVM LPAR returns with an error
Launchpad Bug Tracker
1398163 at bugs.launchpad.net
Mon Dec 1 21:16:04 UTC 2014
You have been subscribed to a public bug:
---Problem Description---
nvsetenv currently returns with an error immediately. This works on other distributions just fine.
# nvsetenv
No common Block found
Upon investigation into the source, there is a logic error in the
powerpc-utils code carried by Ubuntu:
diff -urpN powerpc-utils-1.2.18+r1.1.3/nwnvsetenv.c powerpc-utils-1.2.18+r1.1.3dev/nwnvsetenv.c
--- powerpc-utils-1.2.18+r1.1.3/nwnvsetenv.c 2014-11-21 12:52:55.000000000 -0500
+++ powerpc-utils-1.2.18+r1.1.3dev/nwnvsetenv.c 2014-11-21 13:08:00.624167652 -0500
@@ -65,7 +65,7 @@ int checkNewWorld(void)
fgets(buf, 255, cpuf);
fclose(cpuf);
- if (strncmp(buf, "AAPL", 4) != 0)
+ if (!strncmp(buf, "AAPL", 4))
result = 1;
}
Please backport this fix to 14.04 and 14.10.
---uname output---
Linux ltcbrazos2-lp03.austin.ibm.com 3.16.0-23-generic #31-Ubuntu SMP Tue Oct 21 17:55:08 UTC 2014 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = IBM,9119-MME
---Steps to Reproduce---
Run nvsetenv on a PowerVM LPAR. It will fail with an error, because it is trying to use "new world" powerpc code (Apple) on a IBM pseries hardware.
Userspace tool common name: nvsetenv
The userspace tool has the following bit modes: 64-bit
Userspace package: powerpc-utils
Hello. I tested this fix on an ubuntu lpar running on powervm and got
the following error.
Bad magic number 766f
Warning: checksum error (9a37) on nvram
string value in variable 17 is too long (8224 bytes)
I think the problem is actually an endian issue.
--- /root/pmac-utils/nwnvsetenv.c 2014-11-21 15:04:30.135728246 -0500
+++ /root/pmac-utils2/nwnvsetenv.c 2014-11-21 15:05:07.088088202 -0500
-85,7 +85,7 @@
while (read(nvfd, chrph, sizeof(chrp_header)) == sizeof(chrp_header))
{
- int size = chrph->len * 0x10 - sizeof(chrp_header);
+ int size = be16toh(chrph->len) * 0x10 - sizeof(chrp_header);
if (!strncmp(chrph->name, "common", 7))
{
*nvstart = start;
root at ltcbrazos1-lp05:~/pmac-utils2# ./nvsetenv
little-endian?=false
real-mode?=true
auto-boot?=true
diag-switch?=false
fcode-debug?=true
oem-banner?=false
oem-logo?=false
use-nvramrc?=false
ibm,fw-new-mem-def=true
ibm,fw-force-ior=false
ibm,fw-oflite-dbg=false
ibm,fw-prev-boot-vpd=
ibm,fw-override-cas=false
real-base=c00000
virt-base=ffffffff
virt-size=ffffffff
selftest-#megs=0
boot-file=
diag-file=diag
output-device=/vdevice/vty
input-device=/vdevice/vty
oem-banner=
oem-logo=
nvramrc=
boot-command=boot
reboot-command=
menu?=false
ibm,dasd-spin-interval=5
ibm,fw-show-true-pcie?=true
boot-device=/vdevice/v-scsi at 30000003/disk at 8100000000000000
diag-device=/vdevice/v-scsi at 30000003/disk at 8100000000000000 /vdevice/l-lan at 30000002:speed=auto,duplex=auto,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512
boot-last-label=setparams 'Red Hat Enterprise Linux Server 7.1 (Maipo), with Linux 3.10.0-195.el7.ppc64'
load_video
insmod gzio
insmod part_msdos
insmod xfs
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//vdevice/v-scsi at 30000003/disk at 8100000000000000,msdos2' --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 --hint='hd0,msdos2' 848ec64b-c059-47c1-b1c0-1a30191d316c
else
search --no-floppy --fs-uuid --set=root 848ec64b-c059-47c1-b1c0-1a30191d316c
fi
linux /vmlinuz-3.10.0-195.el7.ppc64 root=/dev/mapper/rhel_ltcbrazos1--lp05-root ro crashkernel=auto rd.lvm.lv=rhel_ltcbrazos1-lp05/root rd.lvm.lv=rhel_ltcbrazos1-lp05/swap LANG=en_US.UTF-8
initrd /initramfs-3.10.0-195.el7.ppc64.img
real-size=6000000
ibm,fw-find-tape-alias=false
ibm,fw-find-cdrom-alias=false
ibm,fw-tty-language=1
ibm,fw-keyboard=1
load-base=4000
screen-#columns=50
screen-#rows=18
ibm,fw-nbr-reboots=0
ibm,associativity-form=1
Ah excellent find, Tom!
Even with that, I think the diff I mentioned in the original bug might
also be a bugfix, but I am not sure. It definitely doesn't seem like
searching for AAPL should be checking against strncmp not returning 0,
but Canonical should weigh in here, I think.
** Affects: powerpc-utils (Ubuntu)
Importance: Undecided
Status: New
** Tags: architecture-ppc64le bot-comment bugnameltc-119137 severity-medium targetmilestone-inin1410
--
nvsetenv on PowerVM LPAR returns with an error
https://bugs.launchpad.net/bugs/1398163
You received this bug notification because you are a member of Ubuntu Foundations Bugs, which is subscribed to powerpc-utils in Ubuntu.
More information about the foundations-bugs
mailing list