From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.33) id 1CAmfX-0006jy-FQ for mharc-grub-devel@gnu.org; Fri, 24 Sep 2004 05:47:11 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CAmfV-0006jh-Tz for grub-devel@gnu.org; Fri, 24 Sep 2004 05:47:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CAmfU-0006i8-Im for grub-devel@gnu.org; Fri, 24 Sep 2004 05:47:09 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CAmfU-0006i5-Gc for grub-devel@gnu.org; Fri, 24 Sep 2004 05:47:08 -0400 Received: from [212.227.126.171] (helo=moutng.kundenserver.de) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CAmZ5-0007kZ-Bm for grub-devel@gnu.org; Fri, 24 Sep 2004 05:40:31 -0400 Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CAmZ4-0002zf-00 for grub-devel@gnu.org; Fri, 24 Sep 2004 11:40:30 +0200 Received: from [80.138.149.67] (helo=intranator.net.local) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1CAmZ4-0006i0-00 for grub-devel@gnu.org; Fri, 24 Sep 2004 11:40:30 +0200 Received: from localhost (intranator.net.local [127.0.0.1]) by localhost (Postfix) with ESMTP id 8F4EE1BD for ; Fri, 24 Sep 2004 11:39:55 +0200 (CEST) Received: from equinox.net.local (equinox.net.local [172.16.1.70]) by intranator.net.local (Postfix) with ESMTP id BA980129 for ; Fri, 24 Sep 2004 11:39:54 +0200 (CEST) From: "Gerd v. Egidy" To: The development of GRUB 2 Date: Fri, 24 Sep 2004 11:40:28 +0200 User-Agent: KMail/1.6.1 References: <200409231749.01954.lists@egidy.de> <20040923193027.GA20500@artax.karlin.mff.cuni.cz> In-Reply-To: <20040923193027.GA20500@artax.karlin.mff.cuni.cz> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409241140.28297.lists@egidy.de> X-Virus-Scanned: by Intranator (www.intranator.com) with AMaViS and F-Secure AntiVirus X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e5d16684a8bae69e513e7196702f6940 Subject: Re: booting another system from running linux (kexec) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2004 09:47:10 -0000 On Thursday 23 September 2004 21:30, Tomas Ebenlendr wrote: > > Another way to solve this would be to add scripting, dhcp, rsync and > > writing to linux-fs/ntfs directly into grub. But I think that is a huge > > task and not flexible enough. > > That is what is grub2 supposed, It will have modules. Anyone can write > his own modules, and have grub2 installed from his distro. (If we will > not believe that, we will probably not choose to implement grub2, at > least in this way....). But grub2 is not stable (nor beta) yet. I don't > know if current state can be considered as alpha (probably yes). Ok, but I'll have to re-implement everything as grub module. Except if busybox would be included into grub by default... > Ad flexibility: you can always boot any system to do the hard work, and > then reboot the system from script. Grub then needs only to know that > hard work should be done. (This means no fs-write support, and you can > choose between compatibility with rsync, and other way of updating. If > your updates are stored centrally, you can use 'timestamps'. If > timestamp on your os is older than timpestamp obtained from server, the > hard work should be done.) > Scripting and dhcp are both issues that we want in grub2. Sounds this > reasonable to you? Requiring two boots everytime is not acceptable. But requiring a second boot after a remote update is ok. So the scheme would be: 1. boot into grub 2. grub script is running - network if detection - driver loading - dhcp - read timestamps from server (e.g. http) - compare timestamps with what is stored on local partition 3. if timestamps match: show regular grub boot menu 3. if timestamps differ: - boot into special small linux - update partitions via rsync - set new timestamps - reboot I'm just wondering if it is not a very ambitious goal to develop nic drivers for all cards supported under linux. And I think that is duplicating a lot of work. So wouldn't it be better concept to boot a _very stripped down_ version of linux, let the scripting and stuff be done by the already existing busybox framework and use kexec to do the real boot into the final os? This would turn big parts of grub into regular linux userspace code. I know that this is a very different approach than what you are currently doing. I do not want to offend anyone with my ideas or put the work you guys are doing in question. Maybe I'm missing some important part that prevents my scheme from being practical. Kind regards, Gerd