From owner-freebsd-arch@FreeBSD.ORG Wed Mar 23 23:22:09 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 46B42106566C; Wed, 23 Mar 2011 23:22:09 +0000 (UTC) Date: Wed, 23 Mar 2011 23:22:09 +0000 From: Alexander Best To: Andriy Gapon Message-ID: <20110323232209.GA15486@freebsd.org> References: <20110323200200.GA85810@freebsd.org> <201103232050.p2NKov4g017463@lurza.secnetix.de> <4D8A7976.5090103@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D8A7976.5090103@freebsd.org> Cc: Oliver Fromme , freebsd-arch@freebsd.org Subject: Re: kernel memory checks on boot vs. boot time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 23:22:09 -0000 On Thu Mar 24 11, Andriy Gapon wrote: > on 23/03/2011 22:50 Oliver Fromme said the following: > > Beware, I don't know if this is the *only* thing preventing > > boot2 from booting an amd64 kernel. There might be more. > > I haven't tried booting FreeBSD without the boot loader in > > a long time. Probably not in this century. > > Kind of hijacking the thread - while we are gradually moving from mbr+bsdlabel > to gpt and more, we are also moving from away from size-constrained boot2. > My vision is that boot2 and loader should fuse into something more powerful that > would reside in a boot partition, but with its config files on a "regular" > filesystem. +1. being able to control the whole boot process by /etc/boot.conf would be great. there are defenately too many files in /boot. new users have no clue what boot, boot0, boot1, boot2, cdboot, gptboot, etc. are all about. merging /boot/loader, /boot/gptboot and /boot/zfsgptboot would be really nice. building/installing all the mbr+bsdlabel boot files could be made dependable upon some variable (WITH_MBR_BOOT=), which could be disabled by default. also moving away from forth to something more modern might be thinkable. having support for a modern scripting language might make it easier to come up with a nice graphical bootloader e.g. there're probably more advantages. problem might be that the current gpart(8) manual recommends using 64k for the boot partition. that might not be enough, if ada0p1 should contain the functionality of all boot stages (including the loader), support for a modern scripting language and support for graphical menues (including a rudimentary vga/vesa driver for high res). cheers. alex > > -- > Andriy Gapon -- a13x