10000 unable to boot from USB devices due to bus enumeration delays · Issue #165 · gokrazy/gokrazy · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

unable to boot from USB devices due to bus enumeration delays #165

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
1 of 5 tasks
jshield opened this issue Jan 28, 2023 · 5 comments
Closed
1 of 5 tasks

unable to boot from USB devices due to bus enumeration delays #165

jshield opened this issue Jan 28, 2023 · 5 comments

Comments

@jshield
Copy link
jshield commented Jan 28, 2023

Platform

I’m using:

  • gokrazy/rpi3b
  • gokrazy/rpi3b+
  • gokrazy/rpi4b
  • gokrazy/apu2c4
  • gokrazy/x86-64

Observed behavior

when booting from a USB device, root device isn't always available until USB bus enumeration is completed, leading to being unable to mount the rootfs and panics

Expected behavior

ideally be able to specify a rootdelay value to permit the USB bus enumeration to complete before attempting to mount rootfs.

I had a quick look at the source and can't see an obvious way to provide additional kernel cmdline args, is it currently possible today?

@stapelberg
Copy link
Contributor

I had a quick look at the source and can't see an obvious way to provide additional kernel cmdline args, is it currently possible today?

Clone https://github.com/gokrazy/kernel locally and add a replace directive to the corresponding go.mod file in your ~/gokrazy/instancename/builddir/github.com/gokrazy/kernel/go.mod. Then, modify https://github.com/gokrazy/kernel/blob/main/cmdline.txt accordingly.

@stapelberg
Copy link
Contributor

BTW, this general process of working with modules and the replace directive is also documented at https://gokrazy.org/development/modules/.

Let me know if you run into issues — I have previously successfully added rootdelay= when it was needed (for a USB memory stick).

@jshield
Copy link
Author
jshield commented Jan 28, 2023

thanks for the advice, for context I'm currently bootstrapping one of these using the rtr7 kernel:
https://www.servethehome.com/new-fanless-4x-2-5gbe-intel-n5105-i226-v-firewall-tested/
eventually I'll move it to the internal NVMe drive but for prototyping I'm using a USB drive, due to a lack of a SD slot.

I've tried the rtr7-recover tool but it didn't seem to succeed transferring the UEFI bootloader, the device supports UEFI HTTP Boot, so if you are planning a refresh of rtr7-recover, supporting that would negate the need for tftp/pxe for devices that support it.

@stapelberg
Copy link
Contributor

I've tried the rtr7-recover tool but it didn't seem to succeed transferring the UEFI bootloader, the device supports UEFI HTTP Boot, so if you are planning a refresh of rtr7-recover, supporting that would negate the need for tftp/pxe for devices that support it.

I have installed my https://michael.stapelberg.ch/posts/2021-07-10-linux-25gbit-internet-router-pc-build/ using UEFI network boot with rtr7-recover.

Have you tried connecting both devices to a switch instead of connecting them with a direct cable? I found that this can make the difference with some devices…

If you know what exactly needs fixing or improvements in rtr7-recover, please let me know

@jshield
Copy link
Author
jshield commented Jan 28, 2023

the local fork of the kernel worked so I can now do OTA updates using gok.

as far as I know with UEFI HTTP Booting it should be a matter of handling an additional class identifier and sending it an http url pointing to the EFI payload.

https://en.opensuse.org/UEFI_HTTPBoot_Server_Setup

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
0