[opensuse-factory] Factory net install fails in UEFI mode on Dell T20
I want to install Tumbleweed on a Dell T20 w/ Xeon E3-1225v3, booting it from a USB stick and in splash=verbose mode. In legacy mode, after it starts looking for drivers it finds an Intel LynxPoint, activates the sata drivers, then proceeds to activate the network card, waits for DHCP and loads the rest of the stuff from the network. In UEFI mode (no matter if secure or non-secure) it loads some usb storage drivers, then tries the network card. At this point the screen goes blank completely with the cursor at the lowest line (not blinking) and it then reboots after some time (presumably because some watchdog kicks it). I've disabled the SATA-RAID functionality, the PXE network funcionality and tried with UEFI network stack on or off. Nothing changes. When I boot with nomodeset, at this point linuxrc goes off to tell me that the installation medium can't be found and wants me to input everything by hand. It does seem to configure the network card OK. Does anybody have an idea of what is going on there and how to fix it? I'd really like this machine to installed witth UEFI secure boot. It seems like I need to tell the kernel to pre-load some driver to see the USB stick I booted from, but which one? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Achim Gratz writes:
Does anybody have an idea of what is going on there and how to fix it? I'd really like this machine to installed with UEFI secure boot. It seems like I need to tell the kernel to pre-load some driver to see the USB stick I booted from, but which one?
The same thing happens if I boot from CD-ROM instead. The CD spins up just before the apparent crash, then the screen goes blank and the system reboots after about a minute or so. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Achim Gratz writes:
Achim Gratz writes:
Does anybody have an idea of what is going on there and how to fix it? I'd really like this machine to installed with UEFI secure boot. It seems like I need to tell the kernel to pre-load some driver to see the USB stick I booted from, but which one?
The same thing happens if I boot from CD-ROM instead. The CD spins up just before the apparent crash, then the screen goes blank and the system reboots after about a minute or so.
Playing around in linuxrc a bit more it seems that the system might crash in the initial loading of the ramdisk for the installation system. I am unable to start an installation from linuxrc because no matter what installation medium I tell it to use it comes back with "no repository found on medium" or something to that effect. I have successfully installed in legacy mode, but it didn't create a GPT and I can't boot from UEFI into that installation. If there's a way to create a GPT installation from a legacy-booted installer, please tell. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Sun, 16 Nov 2014 21:07:09 +0100
Achim Gratz
Achim Gratz writes:
Achim Gratz writes:
Does anybody have an idea of what is going on there and how to fix it? I'd really like this machine to installed with UEFI secure boot. It seems like I need to tell the kernel to pre-load some driver to see the USB stick I booted from, but which one?
The same thing happens if I boot from CD-ROM instead. The CD spins up just before the apparent crash, then the screen goes blank and the system reboots after about a minute or so.
Playing around in linuxrc a bit more it seems that the system might crash in the initial loading of the ramdisk for the installation system. I am unable to start an installation from linuxrc because no matter what installation medium I tell it to use it comes back with "no repository found on medium" or something to that effect.
I have successfully installed in legacy mode, but it didn't create a GPT and I can't boot from UEFI into that installation. If there's a way to create a GPT installation from a legacy-booted installer, please tell.
Create ESP partition (with correct GUID) and format it as FAT; mount it as /boot/efi run "grub2-install --target=x86_64-efi"; it will return an error that it could not update firmware settings. Verify that /boot/efi/EFI/opensuse/grubx64.efi is present; if not, manually copy /boot/grub2/x86_64-efi/core.img as this file Disable secure boot. On reboot you will need to manually select file to boot in your firmware menu (grubx64.efi on ESP). If this is not possible - find EFI shell; put it on USB stick as \EFI\BOOT\BOOTX64.EFI and try to boot from USB stick. If it is successful, you are in shell environment where you can manually load grub. If booting will be successful, you will need to go into yast and reconfigure bootloader. I advice first setting "no bootloader" and save. The select correct one. Changing bootloader on the fly never worked correctly in the past. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov writes:
Create ESP partition (with correct GUID) and format it as FAT; mount it as /boot/efi run "grub2-install --target=x86_64-efi"; it will return an error that it could not update firmware settings. Verify that /boot/efi/EFI/opensuse/grubx64.efi is present; if not, manually copy /boot/grub2/x86_64-efi/core.img as this file
Thanks for the answer, but... Way over my head, this would be my first UEFI install. The install system is empty, so I need to partition the disk. GPT is the order, how do I tell the non-UEFI booted installer to create a GPT? Then I need an EFI partition, how big should these by, BTW? The rest of the disk is something the installer should take care of, I hope.
Disable secure boot. On reboot you will need to manually select file to boot in your firmware menu (grubx64.efi on ESP). If this is not possible - find EFI shell; put it on USB stick as \EFI\BOOT\BOOTX64.EFI and try to boot from USB stick. If it is successful, you are in shell environment where you can manually load grub.
The BIOS seems good enough to find UEFI bootables.
If booting will be successful, you will need to go into yast and reconfigure bootloader. I advice first setting "no bootloader" and save. The select correct one. Changing bootloader on the fly never worked correctly in the past.
Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Mon, 17 Nov 2014 20:43:30 +0100
Achim Gratz
Andrei Borzenkov writes:
Create ESP partition (with correct GUID) and format it as FAT; mount it as /boot/efi run "grub2-install --target=x86_64-efi"; it will return an error that it could not update firmware settings. Verify that /boot/efi/EFI/opensuse/grubx64.efi is present; if not, manually copy /boot/grub2/x86_64-efi/core.img as this file
Thanks for the answer, but... Way over my head, this would be my first UEFI install. The install system is empty, so I need to partition the disk. GPT is the order, how do I tell the non-UEFI booted installer to create a GPT?
In expert yast partitioner select a disk, in lower right corner there is "Expert" menu (I think it is called this way) where you can chose to initialize partition table to MBR or GPT.
Then I need an EFI partition, how big should these by, BTW?
With grub2 it contains a couple of megabytes. so 100MB should be enough. elilo (and gummiboot) put kernels and initrds there so go figure.
The rest of the disk is something the installer should take care of, I hope.
Disable secure boot. On reboot you will need to manually select file to boot in your firmware menu (grubx64.efi on ESP). If this is not possible - find EFI shell; put it on USB stick as \EFI\BOOT\BOOTX64.EFI and try to boot from USB stick. If it is successful, you are in shell environment where you can manually load grub.
The BIOS seems good enough to find UEFI bootables.
If booting will be successful, you will need to go into yast and reconfigure bootloader. I advice first setting "no bootloader" and save. The select correct one. Changing bootloader on the fly never worked correctly in the past.
Regards, Achim.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Achim Gratz writes:
Does anybody have an idea of what is going on there and how to fix it? I'd really like this machine to installed witth UEFI secure boot. It seems like I need to tell the kernel to pre-load some driver to see the USB stick I booted from, but which one?
Some tries later I think what happens is that the e1000e driver somehow fails to get the network up, so the Net installer never finds an install source and gives up. At least I'm getting the same behaviour in a legacy boot if I blacklist the e1000e driver as I'm getting in the UEFI boot. I'll try if I can get over that impasse by using a DVD install. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Achim Gratz writes:
Some tries later I think what happens is that the e1000e driver somehow fails to get the network up, so the Net installer never finds an install source and gives up. At least I'm getting the same behaviour in a legacy boot if I blacklist the e1000e driver as I'm getting in the UEFI boot. I'll try if I can get over that impasse by using a DVD install.
That hunch proved to be correct, the UEFI install is progressing as I write this. Good thing I did buy an ODD for this machine! :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
No problem on 2 other x86_64 boxes with factory at the latest level via zypper dup with the same versions of libgcrypt and wicked. tindog:~ # systemctl status wickedd.service wickedd.service - wicked network management service daemon Loaded: loaded (/usr/lib/systemd/system/wickedd.service; enabled) Active: failed (Result: exit-code) since Mon 2014-11-17 21:02:43 GMT; 6min ago Process: 655 ExecStart=/usr/sbin/wickedd --systemd --foreground (code=exited, status=1/FAILURE) Main PID: 655 (code=exited, status=1/FAILURE) Nov 17 21:02:43 tindog wickedd[655]: libgcrypt version mismatch tindog:~ # ldd /usr/sbin/wickedd linux-vdso.so.1 (0x00007fff7d19a000) libwicked-0.so.6 => /usr/lib64/libwicked-0.so.6 (0x00007ff29b4f8000) libc.so.6 => /lib64/libc.so.6 (0x00007ff29b158000) libnl-route-3.so.200 => /usr/lib64/libnl-route-3.so.200 (0x00007ff29aef0000) libnl-3.so.200 => /usr/lib64/libnl-3.so.200 (0x00007ff29acd0000) libanl.so.1 => /lib64/libanl.so.1 (0x00007ff29aac8000) libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007ff29a880000) libgcrypt.so.20 => /usr/lib64/libgcrypt.so.20 (0x00007ff29a598000) libdl.so.2 => /lib64/libdl.so.2 (0x00007ff29a390000) /lib64/ld-linux-x86-64.so.2 (0x00007ff29b848000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff29a170000) libm.so.6 => /lib64/libm.so.6 (0x00007ff299e68000) libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007ff299c50000) tindog:~ # rpm -qf /usr/lib64/libgcrypt.so.20 libgcrypt20-1.6.1-11.2.x86_64 tindog:~ # strace -s 256 -f systemctl status wickedd ioctl(1, TIOCGWINSZ, {ws_row=48, ws_col=271, ws_xpixel=0, ws_ypixel=0}) = 0 write(1, "Nov 17 21:02:43 tindog wickedd[655]: \33[1;31mlibgcrypt version mismatch\33[0m\n", 75Nov 17 21:02:43 tindog wickedd[655]: libgcrypt version mismatch ) = 75 munmap(0x7fe838da0000, 8388608) = 0 munmap(0x7fe83ad40000, 4096) = 0 close(6) = 0 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++ tindog:~ # rpm -qa|grep wicked wicked-debugsource-0.6.12-8.2.x86_64 libwicked-0-6-0.6.12-8.2.x86_64 wicked-debuginfo-0.6.12-8.2.x86_64 wicked-service-0.6.12-8.2.x86_64 wicked-0.6.12-8.2.x86_64 Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Sid, I just performed an update and hit the same problem. Digging a bit, I see the network:wicked:master logs pointing to builds involving libgcrypt-1.6.2, yet both my systems still have 1.6.1. To confirm, I did a quick local RPM build of wicked on my system with ligbcrypt-1.6.1. This fixed this little hiccup. I suppose the updated libgcrypt has not yet been released? # zypper up libgcrypt20 Loading repository data... Reading installed packages... No update candidate for 'libgcrypt20-1.6.1-11.2.x86_64'. The highest available version is already installed. Resolving package dependencies... -Karol On Mon, Nov 17, 2014 at 09:39:21PM +0000, Sid Boyce wrote:
No problem on 2 other x86_64 boxes with factory at the latest level via zypper dup with the same versions of libgcrypt and wicked.
tindog:~ # systemctl status wickedd.service wickedd.service - wicked network management service daemon Loaded: loaded (/usr/lib/systemd/system/wickedd.service; enabled) Active: failed (Result: exit-code) since Mon 2014-11-17 21:02:43 GMT; 6min ago Process: 655 ExecStart=/usr/sbin/wickedd --systemd --foreground (code=exited, status=1/FAILURE) Main PID: 655 (code=exited, status=1/FAILURE)
Nov 17 21:02:43 tindog wickedd[655]: libgcrypt version mismatch
Sid, Since tumbleweed and factory repositories still contain libgcrypt-1.6.1, you might try grabbing 1.6.2 directly via: https://api.opensuse.org/build/openSUSE:Factory/snapshot/x86_64/libgcrypt/li... and if needed: https://api.opensuse.org/build/openSUSE:Factory/snapshot/x86_64/libgcrypt/li... After manual upgrade with these 2 packages, wickedd comes up fine. Hope this helps, Karol
On 17/11/14 23:56, Karol Mroz wrote:
Sid,
Since tumbleweed and factory repositories still contain libgcrypt-1.6.1, you might try grabbing 1.6.2 directly via:
https://api.opensuse.org/build/openSUSE:Factory/snapshot/x86_64/libgcrypt/li...
and if needed:
https://api.opensuse.org/build/openSUSE:Factory/snapshot/x86_64/libgcrypt/li...
After manual upgrade with these 2 packages, wickedd comes up fine.
Hope this helps, Karol Thanks Karol, Both now installed. # ps fax|grep wickedd 22619 pts/13 S+ 0:00 | \_ grep --color=auto wickedd 22603 ? SLs 0:00 /usr/lib/wicked/bin/wickedd-dhcp6 --systemd --foreground 22604 ? SLs 0:00 /usr/lib/wicked/bin/wickedd-auto4 --systemd --foreground 22605 ? SLs 0:00 /usr/lib/wicked/bin/wickedd-dhcp4 --systemd --foreground 22607 ? SLs 0:00 /usr/sbin/wickedd --systemd --foreground 22609 ? SLs 0:00 /usr/sbin/wickedd-nanny --systemd --foreground Regards Sid.
-- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 17/11/14 a las 18:39, Sid Boyce escribió:
tindog:~ # strace -s 256 -f systemctl status wickedd ioctl(1, TIOCGWINSZ, {ws_row=48, ws_col=271, ws_xpixel=0, ws_ypixel=0}) = 0 write(1, "Nov 17 21:02:43 tindog wickedd[655]: \33[1;31mlibgcrypt version mismatch\33[0m\n", 75Nov 17 21:02:43 tindog wickedd[655]: libgcrypt version mismatch ) = 75 munmap(0x7fe838da0000, 8388608) = 0 munmap(0x7fe83ad40000, 4096) = 0 close(6) = 0 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++
This is in any case a bug.. why in hell is doing that ? it should either rely on the shared library symbol versioning being correct or require exactly the libgcrypt version used for build in the spec file.. attached there is a patch to avoid this issue in the future...
Hi Cristian, On Sat, Nov 22, 2014 at 09:45:39PM -0300, Cristian Rodríguez wrote:
El 17/11/14 a las 18:39, Sid Boyce escribió:
tindog:~ # strace -s 256 -f systemctl status wickedd ioctl(1, TIOCGWINSZ, {ws_row=48, ws_col=271, ws_xpixel=0, ws_ypixel=0}) = 0 write(1, "Nov 17 21:02:43 tindog wickedd[655]: \33[1;31mlibgcrypt version mismatch\33[0m\n", 75Nov 17 21:02:43 tindog wickedd[655]: libgcrypt version mismatch ) = 75 munmap(0x7fe838da0000, 8388608) = 0 munmap(0x7fe83ad40000, 4096) = 0 close(6) = 0 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++
This is in any case a bug.. why in hell is doing that ? it should either rely on the shared library symbol versioning being correct or require exactly the libgcrypt version used for build in the spec file.. attached there is a patch to avoid this issue in the future...
Thanks for the patch. We have the following in the pipeline to address this: https://github.com/openSUSE/wicked/pull/464 As it stands now, libgcrypt20-1.6.2 has been released as an update so the versioning should align without the need for any manual touch-ups. Regards, Karol
participants (5)
-
Achim Gratz -
Andrei Borzenkov -
Cristian Rodríguez -
Karol Mroz -
Sid Boyce