mirror of
https://github.com/netbootxyz/netboot.xyz.git
synced 2026-04-25 07:05:56 +03:00
[GH-ISSUE #1043] Pass manually configured ipxe static ip to ubuntu installer #277
Labels
No labels
Hacktoberfest
Hacktoberfest
bootloader
bsd
bug
confirmed
documentation
duplicate
enhancement
enhancement
enhancement
eol
experimental-merged
freebsd
help wanted
invalid
investigate
ipxe
linux
live-os
memdisk
menu
no-issue-activity
no-issue-activity
pull-request
released
todo
upstream
windows
windows
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/netboot.xyz#277
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Keno on GitHub (Oct 27, 2021).
Original GitHub issue: https://github.com/netbootxyz/netboot.xyz/issues/1043
I do not have dhcp set up, so I entered the ipxe menu to manually set an ip.
This allowed it to successfully chain boot.netboot.xyz. However, the ip I had
manually set in ipxe is not being passed down to the ubuntu installer. The installer
does then offer to perform an interactive netmount, but unfortunately, that
is currently broken on Ubuntu 20.04.3 (see #995). I was hoping it might be possible
to pass down the static ip configured in ipxe to the ubuntu installer.
Since netboot.xyz does not the correct image location for the ubuntu installer
iso, this would also work around the broken upstream.
@antonym commented on GitHub (Oct 27, 2021):
I've been meaning to make the Ubuntu/Debian more static friendly, there's just a few variations of setting up the ip addressing. You can probably modify the kernel options via the Utility menu if you need to try one of these ip= options:
Ubuntu:
(http://manpages.ubuntu.com/manpages/bionic/man7/casper.7.html)
Debian:
ip=[DEVICE]:[CLIENT_IP]:[NETMASK]:[GATEWAY_IP]:[NAMESERVER] [,[DEVICE]:[CLIENT_IP]:[NETMASK]:[GATEWAY_IP]:[NAMESERVER]]Let you specify the name(s) and the options of the interface(s) that should be configured at boot time. Do not specify this if you want to use dhcp (default). It will be changed in a future release to mimic official kernel boot param specification (e.g. ip=10.0.0.1::10.0.0.254:255.255.255.0::eth0,:::::eth1:dhcp).
(https://manpages.debian.org/testing/live-boot-doc/live-boot.7.en.html#ip)
Kernel Standard that live-boot is referring to:
(https://kernel.googlesource.com/pub/scm/linux/kernel/git/ak/linux-mce-2.6/+/v2.6.12/Documentation/nfsroot.txt#80)
@divinity76 commented on GitHub (Nov 24, 2021):
fwiw im seeing the same issue for booting gparted ( #1055)
@divinity76 commented on GitHub (Nov 25, 2021):
same problem for Debian 11 Live system
@github-actions[bot] commented on GitHub (Dec 26, 2021):
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@divinity76 commented on GitHub (Dec 26, 2021):
no don't close it, it's still a real, annoying, unfixed issue
(but it only affects a small number of users, because most already have dhcp)
@antonym commented on GitHub (Dec 26, 2021):
Still valid, just need to find some time to work it and figure out a good incantation for ip=
@antonym commented on GitHub (Dec 31, 2021):
I think part of the issue too is that on Red Hat based distros, you can pass BOOTIF which will set the networking on the MAC specified. This can be set in iPXE to reflect the PXE interface that was booted and therefore has the network connection.
This lets you avoid having to predictively set the device interface which can vary wildly for users. I think that the existing live-boot/casper code does not have this functionality. I'm wondering if the device is left off, if then live-boot will attempt to scan all present networking devices to find one that works.
Again, just need to find some time to test in the lab or parse the live-boot code, if anyone has tested or knows, please feel free to update here.
@github-actions[bot] commented on GitHub (Mar 15, 2022):
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@panicmarvin commented on GitHub (Apr 22, 2022):
After 22.04, wait for Ubuntu Casper to prompt interactive static IP configuration, and I have successfully installed ISO.
Just need to wait for a while.
@github-actions[bot] commented on GitHub (May 23, 2022):
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@divinity76 commented on GitHub (Jun 16, 2022):
yeah, this is still a problem on Ubuntu 20.04+18.04, but it's no longer a problem on Ubuntu 22.04 installer (:
.... unfortunately the 22.04 installer doesn't actually work for me, it crashes on "IO errors on /dev/loop2" - only me?
@divinity76 commented on GitHub (Jun 16, 2022):
Update: turns out, the 22.04 installer will CRASH with 1GB ram, HANG on 2GB ram, and install fine on 3GB ram
@nicexe commented on GitHub (Sep 1, 2022):
The iso for ubuntu server itself is 2GB so your actual usable ram would be 2GB less than what the system has.
@antonym commented on GitHub (Sep 2, 2022):
Previously the installer kernels didn't take up much memory, and could just stream down the installer files and packages but because Ubuntu decided to change how that functionality works, it takes more memory as the install ISO has to be pulled into memory after the network boot kernels have loaded.