Re: CTF: UEFI HTTP boot support
Rodney W. Grimes wrote: > > The "fake cd drive" is in the kernel, loader just copies the iso into > > memory like any other module, and by the time that's done you just > > reboot into the newly installed system, which again uses > > > > vfs.root.mountfrom="cd9660:/dev/md0.uzip" > ^^^ > > Argh, the cd9660 confused me, I think your doing a > "root on mfs/md"? loader.conf says rootfs_load="yes" rootfs_name="contents.izo" rootfs_type="md_image" vfs.root.mountfrom="cd9660:/dev/md0.uzip" contents.izo is uzip'd contents.iso which file(1) describes as ISO 9660 CD-ROM filesystem data '' That's for normal boot, for the loader 'install' command it expects an uncompressed iso for rootfs. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: does a ZFS change in head require additional work?
On 6/16/20 9:39 PM, Rick Macklem wrote: Hi, r362158 changed the arguments for zfs_checkexp() in head. There were no other changes, since the arguments are simply passed on to vfs_stdcheckexp(). Is there something else that needs to be done, such as sending this patch upstream? rick Yes please do upstream this! The FreeBSD snapshot for head used by the CI bot was broken this week (in libc) so your change to the KPI has managed to fly under the radar. We'll need this merged upstream before I update the FreeBSD ports for OpenZFS. Thanks for the reminder! -Ryan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Building modules gives error: "invalid output constraint '=@cce' in asm"
Hi,
Has anyone faced a similar issue?
I had a 12.0-RELEASE kernel earlier. I cloned the master branch and built
world, built kernel and installed kernel with a different kernel name
(INSTKERNNAME) and rebooted the machine and see it booting to 13.0-CURRENT
as expected. Then, I am trying to compile the driver modules and hit the
compilation error. I haven't done "install world" as I don't want the base
12.0 to be disturbed.
When I compared the /usr/include/machine/atomic.h and the atomic.h from the
OBJ directory, I see the below highlighted change. Looks like, building
module is trying to use the headers in OBJ directory as expected, but
hitting the compilation issue.
*12.0 base installation atomic.h*
static __inline int \
atomic_fcmpset_##TYPE(volatile u_##TYPE *dst, u_##TYPE *expect, u_##TYPE
src) \
{ \
u_char res; \
\
__asm __volatile( \
" " MPLOCKED "" \
" cmpxchg %3,%1 ; " \
" sete%0 ;" \
"# atomic_fcmpset_" #TYPE " " \
*: "=q" (res), /* 0 */ \ *
"+m" (*dst), /* 1 */ \
"+a" (*expect)/* 2 */ \
: "r" (src) /* 3 */ \
: "memory", "cc"); \
return (res); \
}
*13.0- CURRENT atomic.h in OBJ dir*
static __inline int \
atomic_fcmpset_##TYPE(volatile u_##TYPE *dst, u_##TYPE *expect, u_##TYPE
src) \
{ \
u_char res; \
\
__asm __volatile( \
" " MPLOCKED "" \
"# atomic_fcmpset_" #TYPE " " \
*: "=@cce" (res),/* 0 */ \*
"+m" (*dst), /* 1 */ \
"+a" (*expect)/* 2 */ \
: "r" (src) /* 3 */ \
: "memory", "cc"); \
return (res); \
}
Any clue would be really helpful?
Thanks,
Rajesh
On Tue, Jun 16, 2020 at 12:29 PM Rajesh Kumar wrote:
> Hi,
>
> I am trying to build my module with freebsd current branch. But I am
> facing compilation issue with header files as below. I have built and
> installed the freebsd current branch and booted to that kernel before
> building my module. So, not sure what is going wrong.
>
>
>
>
>
>
> *In file included from
> /root//freebsd_current/sys/sys/systm.h:44:./machine/atomic.h:230:1: error:
> invalid output constraint '=@cce' in
> asmATOMIC_CMPSET(char);^./machine/atomic.h:205:4: note: expanded from macro
> 'ATOMIC_CMPSET': "=@cce" (res),/* 0 */ \*
>
> Am I missing something?
>
> Thanks,
> Rajesh.
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
does a ZFS change in head require additional work?
Hi, r362158 changed the arguments for zfs_checkexp() in head. There were no other changes, since the arguments are simply passed on to vfs_stdcheckexp(). Is there something else that needs to be done, such as sending this patch upstream? rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: UEFI HTTP boot support
On Tue, Jun 16, 2020 at 10:37 PM Miguel C wrote: > > > On Tue, Jun 16, 2020 at 10:35 PM Miguel C wrote: > >> >> On Tue, Jun 16, 2020 at 7:25 PM Rebecca Cran wrote: >> >>> On 6/16/20 5:17 AM, Miguel C wrote: >>> >>> > 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? >>> >>> Unfortunately HTTP boot only works as far as the kernel: UEFI fetches >>> loader.efi, the loader fetches and runs the kernel over HTTP -- and then >>> you need to use NFS to mount the filesystem (or have a local root >>> filesystem). >>> >>> >> Thanks for the reply , I can work with that for a live system still >> better than tftp, http+nfs should be that hard. >> >> >>> UEFI also has RamDisk support, but I don't think that's for remote >>> ISO/disk files, just local files. >>> >>> As for the ISO it does seem to work for remote ISO files, the bhyve con >> presentantion suggests the same and I was able to boot the ubuntu arm64 >> install iso using the direct link as a HTTP BOOT entry,. >> >> �>Start HTTP Boot over IPv4 >>> Station IP address is 172.16.50.62 >>> >>> URI: http:/?172.16.50.106/uarm64.iso >>> File Size: 916357120 Bytes >>> Downloading...26% >>> >> >> But we also don't seem to have iso images for the raspberry pi, so it >> might not work there, this does sugget just a link to the .efi file would >> work: https://github.com/jljusten/tianocore/wiki/HTTP-Boot but I tired >> that with no succes >> > > Actually that was bad interpertation on my side for a ramdisk to be used > it needs o be iso/img format. > > >> In any case from what you're saying... for a live system I need http + >> nfs for rootfs. >> >> But I'm still clueless how to set that up for FreeBSD, the guide >> mentioned here is linux centric, what need to live on the http server side? >> >> Update so I was trying the ubuntu boot again and noticed it required a few tries (literary choose that boot entry ... fail... try again... 3 times and it worked ) Could be a bug in rpi4-uefi.dev though but it proves it works. I then tried openbsd miniroot img (just case its smaller honestly :D ) and it also booted the img file, but not FreeBSD (using 12.1 ) I noticed the openbsd image includes startup.nsh inside ef/boot/ alongside bootaa64.efi, unsure if that's what FreeBSD would need. >>> -- >>> Rebecca Cran >>> >>> >>> ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: UEFI HTTP boot support
On Tue, Jun 16, 2020 at 10:35 PM Miguel C wrote: > > On Tue, Jun 16, 2020 at 7:25 PM Rebecca Cran wrote: > >> On 6/16/20 5:17 AM, Miguel C wrote: >> >> > 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? >> >> Unfortunately HTTP boot only works as far as the kernel: UEFI fetches >> loader.efi, the loader fetches and runs the kernel over HTTP -- and then >> you need to use NFS to mount the filesystem (or have a local root >> filesystem). >> >> > Thanks for the reply , I can work with that for a live system still better > than tftp, http+nfs should be that hard. > > >> UEFI also has RamDisk support, but I don't think that's for remote >> ISO/disk files, just local files. >> >> As for the ISO it does seem to work for remote ISO files, the bhyve con > presentantion suggests the same and I was able to boot the ubuntu arm64 > install iso using the direct link as a HTTP BOOT entry,. > > �>Start HTTP Boot over IPv4 >> Station IP address is 172.16.50.62 >> >> URI: http:/?172.16.50.106/uarm64.iso >> File Size: 916357120 Bytes >> Downloading...26% >> > > But we also don't seem to have iso images for the raspberry pi, so it > might not work there, this does sugget just a link to the .efi file would > work: https://github.com/jljusten/tianocore/wiki/HTTP-Boot but I tired > that with no succes > Actually that was bad interpertation on my side for a ramdisk to be used it needs o be iso/img format. > In any case from what you're saying... for a live system I need http + nfs > for rootfs. > > But I'm still clueless how to set that up for FreeBSD, the guide mentioned > here is linux centric, what need to live on the http server side? > > >> -- >> Rebecca Cran >> >> >> ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: UEFI HTTP boot support
On Tue, Jun 16, 2020 at 7:25 PM Rebecca Cran wrote: > On 6/16/20 5:17 AM, Miguel C wrote: > > > 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? > > Unfortunately HTTP boot only works as far as the kernel: UEFI fetches > loader.efi, the loader fetches and runs the kernel over HTTP -- and then > you need to use NFS to mount the filesystem (or have a local root > filesystem). > > Thanks for the reply , I can work with that for a live system still better than tftp, http+nfs should be that hard. > UEFI also has RamDisk support, but I don't think that's for remote > ISO/disk files, just local files. > > As for the ISO it does seem to work for remote ISO files, the bhyve con presentantion suggests the same and I was able to boot the ubuntu arm64 install iso using the direct link as a HTTP BOOT entry,. �>Start HTTP Boot over IPv4 > Station IP address is 172.16.50.62 > > URI: http:/?172.16.50.106/uarm64.iso > File Size: 916357120 Bytes > Downloading...26% > But we also don't seem to have iso images for the raspberry pi, so it might not work there, this does sugget just a link to the .efi file would work: https://github.com/jljusten/tianocore/wiki/HTTP-Boot but I tired that with no succes In any case from what you're saying... for a live system I need http + nfs for rootfs. But I'm still clueless how to set that up for FreeBSD, the guide mentioned here is linux centric, what need to live on the http server side? > -- > Rebecca Cran > > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: UEFI HTTP boot support
Rodney W. Grimes wrote: > > 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 We don't use PXE much except in a bringup lab, and then I think we use NFS for rootfs. Normally if iso is comming from network it is to do an install eg loader is doing 'install tftp://host/install.tar' The "fake cd drive" is in the kernel, loader just copies the iso into memory like any other module, and by the time that's done you just reboot into the newly installed system, which again uses vfs.root.mountfrom="cd9660:/dev/md0.uzip" but in that case the rootfs is an iso image on local disk. The rootfs iso is minimal - enough to fsck and mount real media and initialize Verified Exec. It improves our chances of being able to recover from severe disk corruption after cleaning lady pulls the cord, to vaccuum ;-) --sjg ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: UEFI HTTP boot support
Rodney W. Grimes 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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: UEFI HTTP boot support
On 6/16/20 5:17 AM, Miguel C wrote: 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? Unfortunately HTTP boot only works as far as the kernel: UEFI fetches loader.efi, the loader fetches and runs the kernel over HTTP -- and then you need to use NFS to mount the filesystem (or have a local root filesystem). UEFI also has RamDisk support, but I don't think that's for remote ISO/disk files, just local files. -- Rebecca Cran ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: UEFI HTTP boot support
> Rodney W. Grimes wrote: > > > 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 > > We don't use PXE much except in a bringup lab, and then I think we use > NFS for rootfs. Probably much like what I do once my kernel is loaded. > Normally if iso is comming from network it is to do an install > eg loader is doing 'install tftp://host/install.tar' > > The "fake cd drive" is in the kernel, loader just copies the iso into > memory like any other module, and by the time that's done you just > reboot into the newly installed system, which again uses > > vfs.root.mountfrom="cd9660:/dev/md0.uzip" ^^^ Argh, the cd9660 confused me, I think your doing a "root on mfs/md"? > but in that case the rootfs is an iso image on local disk. > > The rootfs iso is minimal - enough to fsck and mount real media > and initialize Verified Exec. > It improves our chances of being able to recover from severe disk > corruption after cleaning lady pulls the cord, to vaccuum ;-) > > --sjg > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: UEFI HTTP boot support
> On Tue, Jun 16, 2020, 17:53 Miguel C wrote: > > > On Tue, Jun 16, 2020 at 4:35 PM Rodney W. Grimes < > > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > > 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 for the tips, but I was really looking for HTTP BOOT info no NFS, > > that's why I replied to this thread. > > > > I might look into that at some point if HTTP BOOT is not an option of > > course, but this thread is about a Call for Testers for UEFI HTTP BOOT, not > > NFS and I would like to help test, the pi4 project just conveniently > > touches on the same use case (an it also does have support for http boot > > using https://rpi4-uefi.dev/) so I'm curious if I can test that way. > > > > Other than the iso I can ofc attempt the dhcp+dns+webserver setup but for > > that I would need a bit more guidance as the linked URL here is linux > > centric, hence why some docs would help. > > > > > > > > Am I just misremembering or can't you get freebsd to load an mfsroot-image, > which can act as rw fs ? Yes, but that is *not* an .iso as was asked above. > I seem to remember pc-bsd DVDs using this say 7 years ago. Yes. > > You would of course have to modify/build your own iso image with the > mfsroot-image on it. Perhaps, if you can get the mfsroot image into memory by the loader while you still have access to the bios code. > Best regards > Andreas -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: UEFI HTTP boot support
I don't think it needs the cdrom driver does it? UEF accepts a iso (since 2.5) has a http boot URI and that is mounted as a ramdisk via the http boot driver itself (I think, this is all a bit new to me too :) Most of the info I found on it is from tiano core: https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot) I did just find the presentation/demo of this working with the FreeBSD amd64 iso that I bumped into before: https://bhyvecon.org/bhyveconOttawa2019-DScott.pdf ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: UEFI HTTP boot support
On Tue, Jun 16, 2020, 17:53 Miguel C wrote: > On Tue, Jun 16, 2020 at 4:35 PM Rodney W. Grimes < > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > 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 for the tips, but I was really looking for HTTP BOOT info no NFS, > that's why I replied to this thread. > > I might look into that at some point if HTTP BOOT is not an option of > course, but this thread is about a Call for Testers for UEFI HTTP BOOT, not > NFS and I would like to help test, the pi4 project just conveniently > touches on the same use case (an it also does have support for http boot > using https://rpi4-uefi.dev/) so I'm curious if I can test that way. > > Other than the iso I can ofc attempt the dhcp+dns+webserver setup but for > that I would need a bit more guidance as the linked URL here is linux > centric, hence why some docs would help. > > > Am I just misremembering or can't you get freebsd to load an mfsroot-image, which can act as rw fs ? I seem to remember pc-bsd DVDs using this say 7 years ago. You would of course have to modify/build your own iso image with the mfsroot-image on it. Best regards Andreas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: UEFI HTTP boot support
> Rodney W. Grimes 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 rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: UEFI HTTP boot support
On Tue, Jun 16, 2020 at 4:35 PM Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> wrote: > > 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 for the tips, but I was really looking for HTTP BOOT info no NFS, that's why I replied to this thread. I might look into that at some point if HTTP BOOT is not an option of course, but this thread is about a Call for Testers for UEFI HTTP BOOT, not NFS and I would like to help test, the pi4 project just conveniently touches on the same use case (an it also does have support for http boot using https://rpi4-uefi.dev/) so I'm curious if I can test that way. Other than the iso I can ofc attempt the dhcp+dns+webserver setup but for that I would need a bit more guidance as the linked URL here is linux centric, hence why some docs would help. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: UEFI HTTP boot support
> 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-unsubscr...@freebsd.org" -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic on mlx5en.
Thanks. On 2020-06-16 12:47, Hans Petter Selasky wrote: On 2020-06-16 13:36, Santiago Martinez wrote: While here, do you know if there is any ongoing effort to add NETMAP support to mlx? Not for FreeBSD. You might want to look at RoCE and infiniband support for userspace. It should support raw ethernet queues aswell. --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic on mlx5en.
On 2020-06-16 13:36, Santiago Martinez wrote: While here, do you know if there is any ongoing effort to add NETMAP support to mlx? Not for FreeBSD. You might want to look at RoCE and infiniband support for userspace. It should support raw ethernet queues aswell. --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic on mlx5en.
Hi Hans Petter, I did sync to r362201 and it works great! no more panics. FreeBSD lenovo01 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362201: Tue Jun 16 08:31:05 BST 2020 smartinez@lenovo01:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 hw.mlx5.auto_fw_update: 0 hw.mlx5.fw_reset_enable: 1 dev.mlx5_core.3.hw.fw_version: 14.26.1040 dev.mlx5_core.2.hw.fw_version: 14.26.1040 dev.mlx5_core.1.hw.fw_version: 14.26.1040 dev.mlx5_core.0.hw.fw_version: 14.26.1040 While here, do you know if there is any ongoing effort to add NETMAP support to mlx? Thanks a lot for your help. Santiago On 2020-06-15 15:39, Santiago Martinez wrote: Ok , will sync now/compile and let you know. Santi On 2020-06-15 15:05, Hans Petter Selasky wrote: On 2020-06-15 15:49, Santiago Martinez wrote: Hi Hans Petter, At the moment I'm running r362037 but can reinstall, patch/rebuild as needed as is just a lab machine. This revision is not good. There are two things you can try: 1) Try a kernel newer than r362139. 2) Copy sys/sys/tree.h from 12-stable and put it into the 13-current tree at the same location and re-build the kernel. --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: UEFI HTTP boot support
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? 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? 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). 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. Thanks. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Building modules gives error: "invalid output constraint '=@cce' in asm"
On Tue, Jun 16, 2020 at 12:29:14PM +0530, Rajesh Kumar wrote: > Hi, > > I am trying to build my module with freebsd current branch. But I am > facing compilation issue with header files as below. I have built and > installed the freebsd current branch and booted to that kernel before > building my module. So, not sure what is going wrong. > > *In file included from > /root//freebsd_current/sys/sys/systm.h:44:./machine/atomic.h:230:1: error: > invalid output constraint '=@cce' in > asmATOMIC_CMPSET(char);^./machine/atomic.h:205:4: note: expanded from macro > 'ATOMIC_CMPSET': "=@cce" (res),/* 0 */ \* > > Am I missing something? Your compiler is too old. You must either build on current, use buildworld/buildkernel method. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Building modules gives error: "invalid output constraint '=@cce' in asm"
Hi, I am trying to build my module with freebsd current branch. But I am facing compilation issue with header files as below. I have built and installed the freebsd current branch and booted to that kernel before building my module. So, not sure what is going wrong. *In file included from /root//freebsd_current/sys/sys/systm.h:44:./machine/atomic.h:230:1: error: invalid output constraint '=@cce' in asmATOMIC_CMPSET(char);^./machine/atomic.h:205:4: note: expanded from macro 'ATOMIC_CMPSET': "=@cce" (res),/* 0 */ \* Am I missing something? Thanks, Rajesh. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
