Date: Tue, 16 Jun 2020 09:09:39 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: "Simon J. Gerraty" <sjg@juniper.net> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Miguel C <miguelmclara@gmail.com>, freebsd-current@freebsd.org Subject: Re: CTF: UEFI HTTP boot support Message-ID: <202006161609.05GG9dRs081460@gndrsh.dnsmgr.net> In-Reply-To: <5957.1592322514@kaos.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Rodney W. Grimes <freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > I'm curious if it should be possible to point to a img/iso directly (I > > > tried to use the img.xz unpacked it and make it available on a local web > > > server and that didn't seem to work for me) but maybe thats cause those > > > images miss something, so arm64 aside does that work for amd64? I.E. using > > > the bootonly.iso? > > > > One problem you run into in attemtping this is even if you get an > > image downloaded and started that image is being provided by some > > memory device driver that emulates some type of iso device. > > FreeBSD does not have a driver for that device so once the kernel > > gets to the point of mounting its root file system it falls on > > its face with a mountroot failure. > > Are you refering to something like: > > vfs.root.mountfrom="cd9660:/dev/md0.uzip" > > we boot that way all the time. What provides the cd9660 driver to FreeBSD? When you load the .iso over a network card, aka PXE/HTTP, the code that does that usually creates a ram disk and a "fake cd drive" that stops working as soon as you stop running the PXE code, which means the device does not show up while the kernel is probing. FreeBSD simply does not support bios devices in this manner, unless something has changed I am totally unaware of. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202006161609.05GG9dRs081460>