Felix Zielcke wrote on 20080902:
> I think it would be good if the output from compiling wouldn't be that
> verbose.
* shameless plug mode on *
Maybe my hmake wrapper for gnu make does what you want : A make and
cc/c++ output (color)filter written in perl. Especially useful if your
warning level
Am Mittwoch, den 03.09.2008, 01:38 +0200 schrieb Javier Martín:
> But ata and reiserfs
> are quite the bloaters... The reiserfs case is particularly strange: in
> the linux kernel, the reiserfs module is 50% bigger than ext3.ko; while
> in GRUB, reiserfs.mod (without journaling) is twice the size o
On Wed, Sep 3, 2008 at 12:56 PM, y.volta <[EMAIL PROTECTED]> wrote:
> For the Grub2 internal script engine, yes, it is little. but need more work
> to be improved. About the size, i think, Lua can be a replacement if this
> lua.mod is available at runtime. at the same time, why not load gziped mod
On Wed, Sep 3, 2008 at 2:59 PM, Felix Zielcke <[EMAIL PROTECTED]> wrote:
> There exists even a thing called `GNU automake' which converts
> Makefile.am files to Makefile.in
> I never used it though, so I don't really know if it would be easier
> with it then in that ruby stuff currently used.
>
> I
Javier Martín wrote:
> El mié, 03-09-2008 a las 02:08 +0200, phcoder escribió:
>> Hello, again.
>> Javier Martín wrote:
>>> We have 63 sectors = 32256 bytes (sectors range from 0 to 63 and the
>>> first is used by the MBR).
>>>
>> I've just rechecked on my system. My first partition begins at secto
Hello all. In old good time of grub-legacy one could obtain the help
about "root" command with
> help root
Now "root" is a variable and so "help root " gives no information. I
suggest that it should be possible to add custom strings to help command
in normal mode. Something like
grub_register_help
Hello, all.
For some FS sometimes additional functions are needed. It could be some
type of control (e.g. in ZFS manage zpools) or preparation for OS
booting (e.g. in FAT put IO.SYS and MSDOS.SYS at the begining of the
root directory). While theese functions are quite specific to FS
sometimes are i
Hello, all.
Now when core image can be booted by multiple sources perhaps it would
be a good idea to recieve some boot arguments in case boot method (e.g.
multiboot) supports it. Probably the best way is to recieve pairs
which can be easily imported to environment. Another
possibility of improving
On Wed, Sep 03, 2008 at 04:25:12PM +0800, Bean wrote:
> On Wed, Sep 3, 2008 at 12:56 PM, y.volta <[EMAIL PROTECTED]> wrote:
> > For the Grub2 internal script engine, yes, it is little. but need more work
> > to be improved. About the size, i think, Lua can be a replacement if this
> > lua.mod is av
On Wed, Sep 03, 2008 at 11:42:44AM +0200, phcoder wrote:
> Hello, all.
> For some FS sometimes additional functions are needed. It could be some
> type of control (e.g. in ZFS manage zpools) or preparation for OS
> booting (e.g. in FAT put IO.SYS and MSDOS.SYS at the begining of the
> root director
Hi,
What is the conclusion of this thread? is this idea still explored?
Robert Millan wrote:
The first concern that comes to mind is how would GRUB coexist with the
payload area which precisely starts at 0x10. But I expect we'd face
many unexpected issues.
Does this mean, GRUB needs
Am Mittwoch, den 03.09.2008, 16:37 +0800 schrieb Bean:
> However, I don't like that it uses ruby to generate makefiles. Ruby is
> not a standard component, so there is a chance that user don't install
> it. I guess perl would be better.
I had somehow already the impression that this ruby based bu
On Wednesday 03 September 2008, Javier Martín wrote:
> El mié, 03-09-2008 a las 02:08 +0200, phcoder escribió:
> > Hello, again.
> >
> > Javier Martín wrote:
> > > We have 63 sectors = 32256 bytes (sectors range from 0 to 63 and the
> > > first is used by the MBR).
> >
> > I've just rechecked on my
On Wed, Sep 03, 2008 at 11:50:33AM +0200, phcoder wrote:
> Hello, all.
> Now when core image can be booted by multiple sources perhaps it would
> be a good idea to recieve some boot arguments in case boot method (e.g.
> multiboot) supports it. Probably the best way is to recieve pairs
> which can
Hi again,
El mié, 03-09-2008 a las 11:10 +0200, phcoder escribió:
> >> I'll have a look at it but not sure to find anything since I'm not
> >> familiar with either ata or reiserfs internal structure.
> > I was not suggesting that it was you or me who did it; it was a general
> > "call" for GRUB de
Robert Millan wrote:
> On Wed, Sep 03, 2008 at 11:42:44AM +0200, phcoder wrote:
>> Hello, all.
>> For some FS sometimes additional functions are needed. It could be some
>> type of control (e.g. in ZFS manage zpools) or preparation for OS
>> booting (e.g. in FAT put IO.SYS and MSDOS.SYS at the begi
Robert Millan wrote:
> On Wed, Sep 03, 2008 at 11:50:33AM +0200, phcoder wrote:
>> Hello, all.
>> Now when core image can be booted by multiple sources perhaps it would
>> be a good idea to recieve some boot arguments in case boot method (e.g.
>> multiboot) supports it. Probably the best way is to
Attached patch is generated via `autoupdate --force' from autoconf 2.61
a svn-diff after ./autogen.sh doestn't show anything more, because
the ./configure script in SVN is already generated with autoconf 2.61.
autoconf 2.61 is dated 17.11.2006 on ftp.gnu.org
Debian etch + lenny have autoconf 2.61
Am Mittwoch, den 03.09.2008, 15:27 +0200 schrieb Felix Zielcke:
> Yes I really want to get rid of old stuff and if you even only need to
> call `autoupdate --force' ;)
>
Oh and config.guess and config.sub have
timestamp='2007-07-22'
whereas the versions from automake 1.9 and 1.10 have
timestamp=
Robert Millan wrote:
> On Wed, Sep 03, 2008 at 04:25:12PM +0800, Bean wrote:
>> On Wed, Sep 3, 2008 at 12:56 PM, y.volta <[EMAIL PROTECTED]> wrote:
>>> For the Grub2 internal script engine, yes, it is little. but need more work
>>> to be improved. About the size, i think, Lua can be a replacement i
phcoder wrote:
> I was thinking about the scenario when ide drives are trusted but not
> USB or removable devices. Cryptographic checksums wouldn't bring much
> because if attacker can modify harddrive he can also modify GRUB to skip
> checksum check.
Then you password protect it :) Once that is
Hi,
How about following (may not be syntaxically correct):
In kernel:
/* Variable holding pointer to preboot hook function. */
preboot_hook:
.long 0
...
/* Check if there is preboot hook installed. */
movlpreboot_hook, %eax
testl %eax, %eax
jne
Vesa Jääskeläinen wrote:
> phcoder wrote:
>> I was thinking about the scenario when ide drives are trusted but not
>> USB or removable devices. Cryptographic checksums wouldn't bring much
>> because if attacker can modify harddrive he can also modify GRUB to skip
>> checksum check.
>
> Then you p
El mié, 03-09-2008 a las 20:07 +0300, Vesa Jääskeläinen escribió:
> Hi,
>
> How about following (may not be syntaxically correct):
>
> In kernel:
>
> /* Variable holding pointer to preboot hook function. */
> preboot_hook:
> .long 0
>
> ...
> /* Check if there is preboot hook ins
Am Mittwoch, den 03.09.2008, 19:23 +0200 schrieb Javier Martín:
> * I doubt: is the current DL system in GRUB able to hand dependencies
> directly? In other words, is our "insmod" more like modprobe or Linux
> insmod? This affects the handling of "insmod drivemap" or "insmod
> sendkey" if preboot.
Hello. In this case we can transfer the whole functionality located in
kern/loader.c to a dedicated module boot.mod. This module will also
register "boot" command. In this way the encapsulation won't be broken
and kernel will become even smaller.
Vladimir 'phcoder' Serbinenko
Vesa Jääskeläinen wrot
phcoder wrote:
> But consider a scenario when attacker can't overwrite the existing
> harddrive but can plug new one. Then the attacker can prepare a
> harddrive having a partition with the same UUID as our boot partition.
> Then he plugs it and depnding on factors like order of interfaces,
> devic
phcoder wrote:
> Hello. In this case we can transfer the whole functionality located in
> kern/loader.c to a dedicated module boot.mod. This module will also
> register "boot" command. In this way the encapsulation won't be broken
> and kernel will become even smaller.
Remember that realmode code
Hello. I was looking at the grub code and seen that if a disk has
multiple partition tables (e.g. macintel with bootcamp) then only first
one will be detected. In some cases it can lead to unreachable
partitions if for some reason partition is present only in one table.
Does anyone has an idea how
Vesa Jääskeläinen wrote:
> phcoder wrote:
>> Hello. In this case we can transfer the whole functionality located in
>> kern/loader.c to a dedicated module boot.mod. This module will also
>> register "boot" command. In this way the encapsulation won't be broken
>> and kernel will become even smaller
Vesa Jääskeläinen wrote:
> That is a valid point.
>
> Would you prefer to use hardware path to device or what you had in mind
> then? Because this is something that we can left for expert people. Most
> common problem is that user plugs in new drive to system and
> bios/hardware order gets changed
phcoder wrote:
> Vesa Jääskeläinen wrote:
>> That is a valid point.
>>
>> Would you prefer to use hardware path to device or what you had in mind
>> then? Because this is something that we can left for expert people. Most
>> common problem is that user plugs in new drive to system and
>> bios/hardw
Vesa Jääskeläinen wrote:
> phcoder wrote:
>> Yes it is, but in my opinion price is too high (shame ubuntu uses this
>> solution). It's somewhat similar to some solutions found in windows when
>> for user convenience they open a big gate for the hackers (e.g. all
>> users by default are administra
Hans,
could you please address Marco's issues and send a new patch so the
topic is brought up again?
Am Freitag, den 29.08.2008, 18:08 +0200 schrieb Marco Gerards:
>
> > diff -uwr grub-1.96_svn20080813-org/ChangeLog
> > grub-1.96_svn20080813-new/ChangeLog
> > --- grub-1.96_svn20080813-org/Chang
On Wed, 2008-09-03 at 15:27 +0200, Felix Zielcke wrote:
> Attached patch is generated via `autoupdate --force' from autoconf 2.61
> a svn-diff after ./autogen.sh doestn't show anything more, because
> the ./configure script in SVN is already generated with autoconf 2.61.
>
> autoconf 2.61 is dated
On Wed, 2008-09-03 at 16:51 +0200, Felix Zielcke wrote:
> Am Mittwoch, den 03.09.2008, 15:27 +0200 schrieb Felix Zielcke:
> > Yes I really want to get rid of old stuff and if you even only need to
> > call `autoupdate --force' ;)
> >
>
> Oh and config.guess and config.sub have
> timestamp='2007-0
36 matches
Mail list logo
