Zhu Yi wrote:
On Mon, 2009-12-14 at 11:24 +0800, Isaac Dupree wrote:
hmm
bootloader installation is often done by distro install-CDs.
Will the distro be smart enough to save these backups to the disk
somewhere sensible, rather than to the temporary in-memory
filesystem?
The backup files
On Mon, 2009-12-14 at 11:24 +0800, Isaac Dupree wrote:
> hmm
> bootloader installation is often done by distro install-CDs.
>
> Will the distro be smart enough to save these backups to the disk
> somewhere sensible, rather than to the temporary in-memory
> filesystem?
The backup files will
On Mon, 2009-12-14 at 10:58 +0800, Isaac Dupree wrote:
> maybe the boot sector is small enough that we could just keep
> separate
> additional backup files each time grub-setup/grub-install is used?
> e.g.
> backup-1
> backup-2
> backup-3
>
> or maybe using date/time instead of sequential numberi
richardvo...@gmail.com wrote:
An automatic backup is valuable both for savvy users who know how but
forgot, and for those who will find the backup and restore procedures
online only after their computer is bricked.
hmm
bootloader installation is often done by distro install-CDs.
Will the d
On Mon, 2009-12-14 at 10:59 +0800, kashyap garimella wrote:
> In conclusion, I believe this backup feature is useful and
> either
> implementation should do the work. If we can merge the good
> parts of
> them, we can get a better one. I just curious why the
>> In conclusion, I believe this backup feature is useful and either
>> implementation should do the work. If we can merge the good parts of
>> them, we can get a better one. I just curious why the thread is stuck
>> since September. Any blocking issues with it? Can we keep the topic
>> moving forw
On Mon, Dec 14, 2009 at 8:18 AM, Zhu Yi wrote:
> On Fri, 2009-12-11 at 17:39 +0800, Felix Zielcke wrote:
> >
> > Someone already made a patch for this inside grub-setup
> > See here and also for the discussion of it:
> > http://lists.gnu.org/archive/html/grub-devel/2009-09/msg00242.html
>
> Thank
Zhu Yi wrote:
3. The backup policy.
Garimella's patch backups every time before grub-setup overwrote the
boot sectors. There might be a problem when someone run
grub-setup/grub-install twice. So the backup image ends up with the
grub2 boot sectors. This makes the recovery for the "real" boot sec
On Fri, 2009-12-11 at 17:39 +0800, Felix Zielcke wrote:
>
> Someone already made a patch for this inside grub-setup
> See here and also for the discussion of it:
> http://lists.gnu.org/archive/html/grub-devel/2009-09/msg00242.html
Thanks. If I knew this patch, I won't try to write one my own. I d
On Sun, Dec 13, 2009 at 11:05:50PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> Robert Millan wrote:
> > Possible approach to solving mips / gfxterm kludge.
> >
> > Comments?
> >
> >
> It's already done cleanly when using some changes from gfxmenu branch
> (look at how it was solved in
* Michael Prokop wrote:
> as reported in #550337 update-grub might fail inside chroots.
> I'm providing detailed information about this issue in this mail as
> discussed on IRC in #grub.
[...]
> The problem is NOT the grub package itself (it installs and updates
> just fine). The problem exists
Bogdan wrote:
> Is it just me or does this whole thing on abandoning Multiboot 2 seem like a
> terrible idea? (That's a retorical question since I've already talked to
> several people in the OSDev community about it.) The only reason why people
> still use Multiboot is because it's the best we'
[Please Cc me on replies as I'm not subscribed to the ML but
read/write through gmane. Thanks]
Hi,
as reported in #550337 update-grub might fail inside chroots.
I'm providing detailed information about this issue in this mail as
discussed on IRC in #grub.
Situation
=
For example postin
Robert Millan wrote:
> Possible approach to solving mips / gfxterm kludge.
>
> Comments?
>
>
It's already done cleanly when using some changes from gfxmenu branch
(look at how it was solved in experimental)
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP
Possible approach to solving mips / gfxterm kludge.
Comments?
--
Robert Millan
=== modified file 'term/gfxterm.c'
--- term/gfxterm.c 2009-10-24 19:01:27 +
+++ term/gfxterm.c 2009-12-13 20:37:57 +
@@ -27,7 +27,7 @@
#include
#include
-#define DEFAULT_VIDEO_MODE "1024x600"
+#define D
Hi,
On Dec/12/2009, Carles Pina i Estany wrote:
> We should fix it. We have three options (maintaining the current
> behaviour for the user):
>
>
> a) simple_patch (just swapping that two lines)
After talking with Robert last night and for the time being I've
committed the simple one (r1933)
Is it just me or does this whole thing on abandoning Multiboot 2 seem like a
terrible idea? (That's a retorical question since I've already talked to
several people in the OSDev community about it.) The only reason why people
still use Multiboot is because it's the best we've got. It's not flexi
17 matches
Mail list logo
