From owner-freebsd-current@freebsd.org Tue Jun 16 15:35:22 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 90BBC33EBBA for ; Tue, 16 Jun 2020 15:35:22 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49mXMY57vBz4B0L for ; Tue, 16 Jun 2020 15:35:21 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 05GFZJxH081326; Tue, 16 Jun 2020 08:35:19 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 05GFZJFn081325; Tue, 16 Jun 2020 08:35:19 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202006161535.05GFZJFn081325@gndrsh.dnsmgr.net> Subject: Re: CTF: UEFI HTTP boot support In-Reply-To: To: Miguel C Date: Tue, 16 Jun 2020 08:35:19 -0700 (PDT) CC: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 49mXMY57vBz4B0L X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [1.47 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.11)[-0.111]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.02)[0.020]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.66)[0.663]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 15:35:22 -0000 > I've been trying out FreeBSD with raspberry Pi4 (4GB) and wanted to see > what the state of HTTP BOOT is in FreeBSD, so I bumped into this! > > 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. > > And on the other hand is there any doc on how to set up dhcp/http specific > to FreeBSD similar to https://en.opensuse.org/UEFI_HTTPBoot_Server_Setup? Since Linux uses this idea of a kernel payload and an initrd payload to boot with it is much easier to get these 2 things over the network and then have a workable system. FreeBSD does not have the initrd payload and that complicates things, you need a functionaly filesystem avaliable at the end of kernel initilization. > > I looked into https://www.freebsd.org/doc/handbook/network-diskless.html > but that doesn't seem to be up to date (or at least it focuses only on PXE > and TFTP). Yes, old but workable. I have a more advanced system that supports NFS booting using NFS support in PXE. The only thing done via tftp is to upgrade the PXE running on the client to one that speaks NFS, then the kernel is loaded via NFS and the root file system is later provided via NFS. The use of NFS provides very fast boots, and I do not need a web server to do it :-). > For clarification my ultimate goal is to use a few pi4's as "thin clients", > so eventually I will have to setup an image of the system with the needed > software (freerdp) but for starters I just wanted to check if pointing > directly to a img/iso would work and that does not seem to be the case. I would strongly suggest use of NFS instead of trying to provide an ISO image, as you no longer need to store the ISO in memory on the client box, and with a pi4 your already memory contrained. > Thanks. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Rod Grimes rgrimes@freebsd.org