[Bug 1398163] patch to nwnvsetenv

[bugproxy]

Default Comment by Bridge

** Attachment added: "patch to nwnvsetenv"
   https://bugs.launchpad.net/bugs/1398163/+attachment/4640886/+files/nwnvsetenv.patch

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to powerpc-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1398163

Title:
  nvsetenv on PowerVM LPAR returns with an error

Status in powerpc-utils package in Ubuntu:
  Fix Released

Bug description:
  ---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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/powerpc-utils/+bug/1398163/+subscriptions