Cloning from #947142.
Ok, with TC2, we'll need the output of the efibootmgr command and the associated dmesg. I don't have access to Beaker.
Noticed this from before the fatal error, but note that the packages are found. ================================================================================ + python /tmp/anamon --recipe-id 909746 --xmlrpc-url http://lab-02.rhts.================================================================================ Progress Exception yum.Errors.RepoError: RepoError() in <bound method YumSqlitePackageSack.__del__ of <yum.sqlitesack.YumSqlitePackageSack object at 0x7fd2e9d65bd0>> ignored Exception yum.Errors.RepoError: RepoError() in <bound method YumSqlitePackageSack.__del__ of <yum.sqlitesack.YumSqlitePackageSack object at 0x7fd2e9d65c90>> ignored Exception yum.Errors.RepoError: RepoError() in <bound method YumSqlitePackageSack.__del__ of <yum.sqlitesack.YumSqlitePackageSack object at 0x2279bd0>> ignored Exception yum.Errors.RepoError: RepoError() in <bound method YumSqlitePackageSack.__del__ of <yum.sqlitesack.YumSqlitePackageSack object at 0x227c390>> ignored Exception yum.Errors.RepoError: RepoError() in <bound method YumSqlitePackageSack.__del__ of <yum.sqlitesack.YumSqlitePackageSack object at 0x2279ad0>> ignored Exception yum.Errors.RepoError: RepoError() in <bound method YumSqlitePackageSack.__del__ of <yum.sqlitesack.YumSqlitePackageSack object at 0x22791d0>> ignored Exception yum.Errors.RepoError: RepoError() in <bound method YumSqlitePackageSack.__del__ of <yum.sqlitesack.YumSqlitePackageSack object at 0x2323f50>> ignored Exception yum.Errors.RepoError: RepoError() in <bound method YumSqlitePackageSack.__del__ of <yum.sqlitesack.YumSqlitePackageSack object at 0x2279550>> ignored Setting up the installation environment . Creating disklabel on /dev/sdb . Creating lvmpv on /dev/sdb1 . Creating disklabel on /dev/sda . Creating efi on /dev/sda1 . Creating xfs on /dev/sda2 . Creating lvmpv on /dev/sda3 . Creating swap on /dev/mapper/rhel_sgi--uv2--01-swap . Creating xfs on /dev/mapper/rhel_sgi--uv2--01-home . Creating xfs on /dev/mapper/rhel_sgi--uv2--01-root . Starting package installation process Preparing transaction from installation source Installing libgcc (1/581) Installing setup (2/581) Installing filesystem (3/581) Installing hwdata (4/581)
We got further (Russ hit the same error with F19). 1650 def add_efi_boot_target(self): 1651 if self.stage1_device.type == "partition": 1652 boot_disk = self.stage1_device.disk 1653 boot_part_num = self.stage1_device.partedPartition.number 1654 elif self.stage1_device.type == "mdarray": 1655 # FIXME: I'm just guessing here. This probably needs the full 1656 # treatment, ie: multiple targets for each member. 1657 boot_disk = self.stage1_device.parents[0].disk 1658 boot_part_num = self.stage1_device.parents[0].partedPartition.number 1659 boot_part_num = str(boot_part_num) 1660 1661 rc = self.efibootmgr("-c", "-w", "-L", productName, 1662 "-d", boot_disk.path, "-p", boot_part_num, 1663 "-l", 1664 self.efi_dir_as_efifs_dir + "\\shim.efi", 1665 root=ROOT_PATH) 1666 if rc: 1667 -> raise BootLoaderError("failed to set new efi boot target") 1668 (Pdb) 1656 # treatment, ie: multiple targets for each member. 1657 p boot_disk boot_disk = self.stage1_device.parents[0].disk DiskDevice instance (0x7fd2e948c550) -- name = sda status = True kids = 3 id = 0 parents = [] uuid = None size = 152627.835938 format = existing gpt disklabel major = 8 minor = 0 exists = True protected = False sysfs path = /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda partedDevice = parted.Device instance -- model: ATA INTEL SSDSA1NW16 path: /dev/sda type: 1 sectorSize: 512 physicalSectorSize: 512 length: 312581808 openCount: 0 readOnly: False externalMode: False dirty: False bootDirty: False host: 1 did: 0 busy: True hardwareGeometry: (19457, 255, 63) biosGeometry: (19457, 255, 63) PedDevice: <_ped.Device object at 0x7fd2ef340dd0> target size = 0 path = /dev/sda format args = [] originalFormat = disklabel removable = False partedDevice = <parted.device.Device object at 0x7fd2f60bdcd0> (Pdb) p boot_part_num '1' (Pdb) p boot_disk.path '/dev/sda' (Pdb) p productName 'Red Hat Enterprise Linux' (Pdb) p self.efi_dir_as_efifs_dir '\\EFI\\redhat' (Pdb) p ROOT_PATH '/mnt/sysimage'
On my system self.efi_dir_as_efifs_dir is "\\EFI\\fedora" but the actual path is "efi\BOOT" (on the install iso). There also is no shim.efi. --------------------------------------------------------- fs4:\> ls Directory of: fs4:\ 06/07/13 11:41a <DIR> 2,048 EFI 0 File(s) 0 bytes 1 Dir(s) fs4:\> cd EFI fs4:\EFI> ls Directory of: fs4:\EFI 06/07/13 11:41a <DIR> 2,048 . 06/07/13 11:41a <DIR> 0 .. 06/07/13 11:41a <DIR> 2,048 BOOT 0 File(s) 0 bytes 3 Dir(s) fs4:\EFI> cd BOOT fs4:\EFI\BOOT> ls Directory of: fs4:\EFI\BOOT 06/07/13 11:41a <DIR> 2,048 . 06/07/13 11:41a <DIR> 2,048 .. 06/07/13 11:41a <DIR> 2,048 fonts 06/07/13 11:41a 1,189,220 MokManager.efi 06/07/13 11:41a 1,370,230 BOOTX64.efi 06/07/13 11:41a 1,359 grub.cfg 06/07/13 11:41a 856,054 grubx64.efi 4 File(s) 3,416,863 bytes 3 Dir(s)
Matthew, I need to run but will work on this tomorrow. The beaker JobID is https://beaker.engineering.redhat.com/jobs/432764 I was hoping to see the efibootmgr output in the anaconda log but no such luck. Suggestions? George
You'll need to run the efibootmgr command by hand from a shell. I no longer have access to Beaker, so can't look at the logged output.
How does one get from the debugger to a shell? Is there any way to ssh, ftp (etc) to the install kernel?
Hi Matthew, I am still chasing this. What I noticed is that on the uv2000 system I got the following: [root@sgi-uv2-01 RPMS]# efibootmgr BootCurrent: 0003 BootOrder: 0003,0003,0000,0001,0002 Boot0000* EFI Network Boot0001* EFI Internal Shell Boot0002* EFI Network 1 Boot0003* Red Hat Enterprise Linux Note the duplicate in the BootOrder. Do you know offhand if there is a way to turn on anaconda debugging from the kickstart metadata in beaker? George
(In reply to George Beshers from comment #5) > I need to run but will work on this tomorrow. > The beaker JobID is https://beaker.engineering.redhat.com/jobs/432764 Hi, I see from the log you were using a RHEL7 kernel without the new UEFI anti-bricking patch. Is there any log of F19 TC2 installation?
Hi, So just tested the Fedora19-Development from beaker. Is 3.9.4-300.fc19.x86_64 recent enough? Installing efibootmgr (553/566) self.add_efi_boot_target() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1691, in write self.install() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2338, in writeBootLoader storage.bootloader.write() File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 166, in doInstall writeBootLoader(storage, payload, instClass, ksdata) File "/usr/lib64/python2.7/threading.py", line 764, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run threading.Thread.run(self, *args, **kwargs) BootLoaderError: failed to set new efi boot target What do you want to do now? 1) Report Bug 2) Debug 3) Quit Please make your choice from above: An unknown error has occured, look at the /tmp/anaconda-tb* file(s) for more details =============================================================================== Trying to allocate 1231 pages for VMLINUZ [Linux-EFI, setup=0x10ce, size=0x4ce446] [Initrd, addr=0x66233000, size=0x1f19610] [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.9.4-300.fc19.x86_64 (mockbuild@bkernel02) (gcc version 4.8.0 20130412 (Red Hat 4.8.0-2) (GCC) ) #1 SMP Fri May 24 22:17:06 UTC 2013 [ 0.000000] Command line: console=ttyS0,115200n8 earlyprintk=ttyS0,115200n8 ks=http://beaker.engineering.redhat.com/kickstart/337809 ksdevice=08:00:69:16:8C:FE netboot_method=efigrub [ 0.000000] e820: BIOS-provided physical RAM map: There was one failure during boot. [ OK ] Started Create static device nodes in /dev. Starting udev Kernel Device Manager... [FAILED] Failed to start Device-Mapper Multipath Device Controller. See 'systemctl status multipathd.service' for details. [ OK ] Started udev Kernel Device Manager. But its the most recent version of Anaconda [ OK ] Started udev Wait for Complete Device Initialization. Starting Activation of DM RAID sets... Starting installer, one moment... anaconda 19.30.3-1 for Fedora 19 (pre-release) started. 09:36:45 Running pre-installation scripts + wget -O - http://lab-02.rhts.eng.bos.redhat.com:8000/install_start/913525 --2013-06-13 09:36:45-- http://lab-02.rhts.eng.bos.redhat.com:8000/install_start/913525 Resolving lab-02.rhts.eng.bos.redhat.com (lab-02.rhts.eng.bos.redhat.com)... 10.16.64.13 Connecting to lab-02.rhts.eng.bos.redhat.com (lab-02.rhts.eng.bos.redhat.com)|10.16.64.13|:8000... connected. HTTP request sent, awaiting response... 200 OK Length: 4 [text/plain] Saving to: 'STDOUT' True 0K 100% 882K=0s 2013-06-13 09:36:45 (882 KB/s) - written to stdout [4/4] 09:36:46 Not asking for VNC because of an automated install 09:36:46 Not asking for VNC because text mode was explicitly asked for in kickstartos.redhat.com/beaker/anamon Starting automated install...p://lab-02.rhts.eng.bos.redhat.com/beaker/anamon Generating updated storage configurationrage-log 5:program-log Resolving lab-02.rhts.eng.bos.reChecking storage configuration...hat.com)... 10.16.64.13 ================================================================================s.eng.bos.redhat.com (lab-02.================================================================================ Installation HTTP request sent, awaiting response... 200 OK Length: 8 1) [x] Installation source 2) [x] Timezone settings (http://download.eng.bos.redhat (America/New_York timezone) .com/devel/candidate-trees/fedo 4) [x] Create user ra/development/19/x86_64/os/) (No user will be created) 3) [x] Install Destination 6) [x] Software selection (Automatic partitioning selecte (GNOME Desktop) d) 2013-06-13 09:36:45 (67.0 MB/s) - '/tmp/anamon' saved [8766/8766] 5) [x] Set root password (Password was set by kickstart. + python /tmp/anamon --recipe-i )--xmlrpc-url http://lab-02.rhts.eng.bos.redhat.com:8000/RPC2 ================================================================================ ================================================================================ Progress Exception yum.Errors.RepoError: RepoError() in <bound method YumSqlitePackageSack.__del__ of <yum.sqlitesack.YumSqlitePackageSack object at 0x7fd311b374d0>> ignored Exception yum.Errors.RepoError: RepoError() in <bound method YumSqlitePackageSack.__del__ of <yum.sqlitesack.YumSqlitePackageSack object at 0x7fd311b37250>> ignored Exception yum.Errors.RepoError: RepoError() in <bound method YumSqlitePackageSack.__del__ of <yum.sqlitesack.YumSqlitePackageSack object at 0x7fd311b37f90>> ignored Setting up the installation environment . Creating disklabel on /dev/sdb . Creating lvmpv on /dev/sdb1 . Creating disklabel on /dev/sda . Creating efi on /dev/sda1 . Creating ext4 on /dev/sda2 . Creating lvmpv on /dev/sda3 . Creating swap on /dev/mapper/fedora_sgi--uv2--01-swap . Creating ext4 on /dev/mapper/fedora_sgi--uv2--01-home . Creating ext4 on /dev/mapper/fedora_sgi--uv2--01-root . Starting package installation process Preparing transaction from installation source Installing libgcc (1/566)
No, it needs to be 3.9.4-301 or later.
FC19-TC4 is able to install on UV2000 hardware. It did not hit the problem observed in TC2. It looks like it properly set the EFI variables. [root@uvpsw4 fedora]# uname -a Linux uvpsw4.americas.sgi.com 3.9.5-301.fc19.x86_64 #1 SMP Tue Jun 11 19:39:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux I'll try it again, and on different hardware, but this problem may have been fixed.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.12.6-200.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug has been in a needinfo state for more than 1 month and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 19, please feel free to reopen the bug and provide the additional information requested.