On 09/29/2010 00:11, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Let me try to explain more clearly what I have in mind. In the GPT
case, we have a dedicated partition ID for bootloader software. This
makes things simpler. If we had such a dedicated partition ID in the
MSDOS case, then a lot
On 09/28/2010 11:46 PM, Grégoire Sutre wrote:
> Regarding the question of whether such an MSDOS partition type exists,
> I did not look very hard, but 45h comes to mind. This type is used by
> the Boot-US boot manager. It is reported as such by NetBSD fdisk. It
> is not listed in the known types
On 09/28/2010 09:05 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Using an embedding partition on msdos as an optional alternative (not as
replacement) to MBR gap is a clear possibility, good idea and was
proposed before but details are very unclear. Like:
- How to create such partition
- How
On 09/28/2010 11:15 PM, Lennart Sorensen wrote:
> On Tue, Sep 28, 2010 at 10:58:31PM +0200, Vladimir 'φ-coder/phcoder'
> Serbinenko wrote:
>
>> On 09/28/2010 10:07 PM, Lennart Sorensen wrote:
>>
>>> On Tue, Sep 28, 2010 at 09:43:25PM +0200, Vladimir 'φ-coder/phcoder'
>>> Serbinenko wrote:
On Tue, Sep 28, 2010 at 10:58:31PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 09/28/2010 10:07 PM, Lennart Sorensen wrote:
> > On Tue, Sep 28, 2010 at 09:43:25PM +0200, Vladimir 'φ-coder/phcoder'
> > Serbinenko wrote:
> >
> >> GPT has new types.
> >>
> > GPT has an msdos par
On 09/28/2010 10:07 PM, Lennart Sorensen wrote:
> On Tue, Sep 28, 2010 at 09:43:25PM +0200, Vladimir 'φ-coder/phcoder'
> Serbinenko wrote:
>
>> GPT has new types.
>>
> GPT has an msdos partition type for itself for use in hybrid setups.
> I know GPT partition tables have new types, but GPT
On Tue, Sep 28, 2010 at 09:43:25PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> GPT has new types.
GPT has an msdos partition type for itself for use in hybrid setups.
I know GPT partition tables have new types, but GPT itself has a type
reserved in the old dos partition table.
> in msd
On 09/28/2010 09:15 PM, Lennart Sorensen wrote:
> On Tue, Sep 28, 2010 at 09:05:21PM +0200, Vladimir 'φ-coder/phcoder'
> Serbinenko wrote:
>
>> Using an embedding partition on msdos as an optional alternative (not as
>> replacement) to MBR gap is a clear possibility, good idea and was
>> propos
On 9/28/2010 3:05 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Using an embedding partition on msdos as an optional alternative (not as
> replacement) to MBR gap is a clear possibility, good idea and was
> proposed before but details are very unclear. Like:
> - How to create such partition
T
On Tue, Sep 28, 2010 at 09:05:21PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> Using an embedding partition on msdos as an optional alternative (not as
> replacement) to MBR gap is a clear possibility, good idea and was
> proposed before but details are very unclear. Like:
> - How to cre
On 09/28/2010 10:04 AM, Colin Watson wrote:
> On Mon, Sep 27, 2010 at 09:55:17PM -0700, Bogdan wrote:
>
>> Another potential solution that I have not seen proposed - GRUB could create
>> its
>> own partition in order to reserve space.
>>
> We do this - well, we expect that the user or the
On 09/28/2010 10:04 AM, Colin Watson wrote:
> On Mon, Sep 27, 2010 at 09:55:17PM -0700, Bogdan wrote:
>
>> Another potential solution that I have not seen proposed - GRUB could create
>> its
>> own partition in order to reserve space.
>>
> We do this - well, we expect that the user or the
On 9/28/2010 12:18 PM, Colin Watson wrote:
> This is not true. GRUB has an ata module which can be built into
> core.img if necessary to read data from parts of the disk the BIOS can't
> read. It's not really solid enough to use by default, but people do
> occasionally report success with it.
Bu
On Tue, Sep 28, 2010 at 11:40:13AM -0400, Phillip Susi wrote:
> On 9/28/2010 4:04 AM, Colin Watson wrote:
> > * The BIOS can often only read from relatively near the start of the
> > disk, and core.img must be readable by the BIOS. If some other
> > operating system is already installed
On 9/28/2010 4:04 AM, Colin Watson wrote:
> * The BIOS can often only read from relatively near the start of the
> disk, and core.img must be readable by the BIOS. If some other
> operating system is already installed - the common dual-boot case,
> and the case where this problem is
> On Tue, Sep 28, 2010 at 02:10:20AM -0700, Bogdan wrote:
> > Only one of the 4 primary partitions can be active. So, turn whatever is
> > not
> > needed into an extended partition. What tools with this screw over? Or, are
>we
>
> > talking about OSes that don't support extended partitions he
On Mon, Sep 27, 2010 at 11:44:10PM -0500, richardvo...@gmail.com wrote:
> Is it a security hole if the linux superuser can write to /dev/sda ? If you
> block this level of access, how's fdisk (or any number of other partition
> managers) supposed to do its job? How's one supposed to install grub
On Tue, Sep 28, 2010 at 02:10:20AM -0700, Bogdan wrote:
> Only one of the 4 primary partitions can be active. So, turn whatever is not
> needed into an extended partition. What tools with this screw over? Or, are
> we
> talking about OSes that don't support extended partitions here?
That would
On Tue, Sep 28, 2010 at 03:40:34AM -0700, Bogdan wrote:
> > Moving partitions in an OS installer as a prerequisite for actually
> > working properly (which is a large part of what I care about given my
> > work on Debian and Ubuntu) is far too unsafe, especially if the size of
> > the partition exc
> EDD is still INT 13h, last I checked - just function 42h rather than 2h.
> We use that. Nevertheless, we still get occasional reports of problems
> due to BIOS limitations.
That's why I used the term "conventional INT 13h interface."
> Moving partitions in an OS installer as a prerequisite fo
On Tue, Sep 28, 2010 at 02:51:01AM -0700, Bogdan wrote:
> > On Tue, Sep 28, 2010 at 02:10:20AM -0700, Bogdan wrote:
> > Yes, which is the only thing that will fit into the boot sector which
> > needs to read everything else.
>
> I disagree. You have more than enough space for both EDD and conventi
> On Tue, Sep 28, 2010 at 02:10:20AM -0700, Bogdan wrote:
> > > * The BIOS can often only read from relatively near the start of the
> > >disk, and core.img must be readable by the BIOS. If some other
> > >operating system is already installed - the common dual-boot case,
> > >and th
On Tue, Sep 28, 2010 at 02:10:20AM -0700, Bogdan wrote:
> > * The BIOS can often only read from relatively near the start of the
> >disk, and core.img must be readable by the BIOS. If some other
> >operating system is already installed - the common dual-boot case,
> >and the case wher
> * The BIOS can often only read from relatively near the start of the
>disk, and core.img must be readable by the BIOS. If some other
>operating system is already installed - the common dual-boot case,
>and the case where this problem is overwhelmingly most likely to
>matter - i
On 09/24/2010 04:09 PM, Richard Stallman wrote:
> > It appears that, rather than the operating system itself being at fault,
> > a number of Windows applications take over a sector in the boot track
> > and store bits and pieces of data there.
>
> I am surprised applications can do that
On Mon, Sep 27, 2010 at 09:55:17PM -0700, Bogdan wrote:
> Another potential solution that I have not seen proposed - GRUB could create
> its
> own partition in order to reserve space.
We do this - well, we expect that the user or the OS installer does this
- on GPT, as it's obviously the right a
Another potential solution that I have not seen proposed - GRUB could create
its
own partition in order to reserve space.
> P.S. Does anyone know if the Linux versions of those same proprietary license
> managers abuse the boot track like their Windows behavior?
That's a good point although I
On Fri, Sep 24, 2010 at 9:09 AM, Richard Stallman wrote:
>> It appears that, rather than the operating system itself being at
> fault,
>> a number of Windows applications take over a sector in the boot track
>> and store bits and pieces of data there.
>
> I am surprised applications ca
> It appears that, rather than the operating system itself being at fault,
> a number of Windows applications take over a sector in the boot track
> and store bits and pieces of data there.
I am surprised applications can do that. Isn't that a security hole
in Windows?
As for the dec
Hi,
Just thought I'd throw my 2 cents in..
Any software (except the software that "owns" the MBR) that uses any
sectors that are in the first track with the MBR and outside of any
partition (e.g. before the first partition) is broken. Not only will
this broken software (potentially) conflict with
On Thu, Sep 23, 2010 at 11:19:24PM +0100, Colin Watson wrote:
> Hi Richard,
>
> We've had some (amicable!) disagreements in the GRUB development team
> regarding a question of how far we should go out of our way to avoid
> conflicts with certain types of mainly proprietary software, and
> Vladimir
Hi Richard,
We've had some (amicable!) disagreements in the GRUB development team
regarding a question of how far we should go out of our way to avoid
conflicts with certain types of mainly proprietary software, and
Vladimir Serbinenko, our current maintainer, suggested that I ask you
for guidance
32 matches
Mail list logo
