From owner-freebsd-hackers@freebsd.org Wed Mar 14 13:11:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8208F5106F for ; Wed, 14 Mar 2018 13:11:57 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 247D37FF2F for ; Wed, 14 Mar 2018 13:11:57 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-wm0-x233.google.com with SMTP id i194so3934925wmg.1 for ; Wed, 14 Mar 2018 06:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AuMtdrS6TTQTSWfbfixNUSNI/kJ+wAIZlEfwRunvBeo=; b=evmgA0uqqA9EQUa6svME8oUVjYQGz6Ubny/3THXRlyrVlqeIqkEDb5Q3QuED0Aedob jwWeJTITu21p9TBcQNqhSfiw+uH8zSbo+P5Ovst/CLXbWIbQx/l6dxe6X7BdgExNsyRq fuo7iNLc9dZH9CgPFOiEIW4PHZ6phcjJBCyAMNtubm0FuCHTg1W1RVI2to6s5JSbBDgP LYNGncKEHDsuFYIys5zF/1v8lRPRnYd9xxf3oLYA3vTvWA59bQ7FhNH8umU9irSrM9Mk KLQEyYa8HU/pwKgIzEv3D5PRiuCFWho2BG/zgNgZUpDZSZl/g1KuhLdcuL2h/DzvKH+h mH6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AuMtdrS6TTQTSWfbfixNUSNI/kJ+wAIZlEfwRunvBeo=; b=sRIekeU7JGlSwEYKTTBe3xMZiVz9/OxD/bljl5lU0PiF5wxW4T4AsoTj7wy9AqiZoP wBrt8Zue4jzfQUZ7vN/5LM46TqBfReSFbadGFmkrYPZ50tVZAnHJJXRTKhxkdxd50TuE Q7VMRJlee4WlKl8Q3Skr/8/K4Yl7A6t0TJHQzEi7q/OROydVQMBTFJxMVwN/KuYSnhJm lKE8Dfzh5CGenBnqOqvo3bFPeXaQdFDbHMdobqNeU1eQ6w7+a5H7seb/o2KkkJv+Pi+W 7pobzNgqtBuzeOXVLIckwCan4nJukkL8XEounkKspEuSSfmqEV2og3Qygb7SnfagKKtd yxbA== X-Gm-Message-State: AElRT7FXjKP7Z6OLwlh6so17CrA6euZ1lyTQDstZJfyOn4pCrd9gL34A e4s+lY0y6Wy4EWENEB0EZWd4t25ogtc2hFolmDfDtA== X-Google-Smtp-Source: AG47ELvcjiCbYkSty2zxMGvRnIpGViHw1gY+XZUIRzg6k9NpO0yBW0NhVT8NwZhfiZdIhivEnichewrb/SNThnTvSvc= X-Received: by 10.80.136.85 with SMTP id c21mr4882325edc.259.1521033115988; Wed, 14 Mar 2018 06:11:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.140.35 with HTTP; Wed, 14 Mar 2018 06:11:55 -0700 (PDT) X-Originating-IP: [174.202.11.120] In-Reply-To: References: <201803140353.w2E3rHN1086319@pdx.rh.CN85.dnsmgr.net> From: Mark Saad Date: Wed, 14 Mar 2018 09:11:55 -0400 Message-ID: Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD To: Warner Losh Cc: "Rodney W. Grimes" , Kristoffer Eriksson , "freebsd-hackers@freebsd.org" , Theron Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 13:11:57 -0000 Warner I'll see if I can get this working , later today. From what I remember with NetBSD changes back in 2004 they wanted to get Xen working booting from Grub with out chain loading. If memory serves me that's what led them into getting the kernel to boot via the multiboot protocol . Solaris/Illumos can also do the same . I use iPXE at work to network boot an Illumos derivative with a kernel, boot archive and some variables to govern console bits and what not. In a weird sort of coincidence Illumos imported FreeBSD's loader to try and dump Grub so maybe everything is there already ? Lets see what I can get working today. >> > >> > Warner >> > >> >> > >> I am going down the rabbit hole to see how it works . >> > > >> > > If you have any questions I am happy to share my working tooling. >> > > >> > >> > I think you are both missing my point. I can boot FreeBSD with ipxe >> > loading mfsbsd style setups like this >> > >> > :freebsd >> > initrd ${base-root}/freebsd/mfsroot.gz >> > chain ${base-root}/other/memdisk harddisk raw >> >> Nope, not what I am doing. >> >> > I want to be able to boot and run it like I would Linux or ESXi with >> > the ability to directly load an kernel and a mfsroot/initrd and pass >> > kernel loader arguments >> > >> > :centos674 >> > set centos674_args edd=off ramdisk_size=50000 nomodeset >> > ks=${centos-root}/CentOS6.7_x64/ks/supermicro-4drives.ks >> > ksdevice=${net0/mac} verbose ip=dhcp >> > root-path=${centos-root}/CentOS6.7_x64/OS/ net.ifnames=0 biosdevname=0 >> > nousb >> > echo ${centos674_args} >> > kernel ${base-root}/centos/CentOS6.7_x64/isolinux/vmlinuz >> > ${centos674_args} >> > initrd ${base-root}/centos/CentOS6.7_x64/isolinux/initrd.img >> >> :freebsd6411 >> set root-path 192.168.48.38:/B/FreeBSD/11.0/amd64 >> iseq ${platform} efi && chain >> nfs://192.168.48.38/B/FreeBSD/11.0/amd64/boot/loader.efi || chain >> nfs://192.168.48.38/B/FreeBSD/11.0/amd64/boot/pxeboot >> boot || goto failed >> goto start >> >> I agree it would be nice to get the "variable=value" stuff working. >> I do know the above does infact pass that root-path to the kernel, >> and without that mountroot fails, so some of this is working > > > right, loader.efi and/or pxebooot is what sets the root path (and other > variables). What others are asking for is some kind way to do just load the > kernel + a bundle of variables with some kind of 'mini /boot/loader' (in our > terms) that can turn the bundle into the metadata the kernel needs to do > it's job. We have an extra layer of with loader.efi/pxeboot and linux > doesn't... > > Warner -- mark saad | nonesuch@longcount.org