Robert Millan wrote:
Then again, on BIOS we only use UUIDs when the situation is desperate, like on
a cross-disk install. If you're concerned about security and/or reliability,
don't do cross-disk installs.
that's good
This line of thinking is what is commonly used to justify draconian measu
On Sun, Aug 03, 2008 at 02:08:33PM +0200, Robert Millan wrote:
>
> This line of thinking is what is commonly used to justify draconian measures
> (i.e. Treacherous Computing) but it doesn't make any sense. If your security
> policy is such that you don't trust users with physical access, try any
On Sun, Aug 03, 2008 at 07:09:51AM -0400, Isaac Dupree wrote:
>
> Is using UUIDs alone resilient
> against this situation:
> An attacker finds out the
> UUIDs on your hard-disk. S/he
> makes a USB drive or CD (that
> preferably looks innocuous
> when plugged into a running
> system), but ha
Robert Millan wrote:
Perhaps we are over-engineering a bit here. In the long run, maybe it makes
more sense to always use UUIDs and drop the make_install_device() complexity.
I'm also concerned that UUID may not be unique. For instance, a disk
was cloned, and a filesystem of the clone was mo
On Sun, Jul 27, 2008 at 08:27:53PM +0200, Robert Millan wrote:
>
> Aside from the discussion about removing / refurbishing make_install_device(),
> is everybody ok with what this patch does?
>
> If I don't hear any objections I'll commit it soon.
Committed.
--
Robert Millan
The DRM opt-in f
Committed.
On Sun, Jul 27, 2008 at 10:36:35PM +0200, Robert Millan wrote:
> On Sun, Jul 27, 2008 at 10:13:19PM +0200, Robert Millan wrote:
> >
> > So I'm submitting a patch that implements --prefix, without having
> > grub-install
> > use it. This is useful already (for manual installs), and I
On Sun, Jul 27, 2008 at 10:13:19PM +0200, Robert Millan wrote:
>
> So I'm submitting a patch that implements --prefix, without having
> grub-install
> use it. This is useful already (for manual installs), and I'd like to use
> that
> --prefix option for Coreboot later too.
Here's a combined pa
On Sun, Jul 27, 2008 at 09:28:58PM +0200, Robert Millan wrote:
> On Sun, Jul 27, 2008 at 08:37:37PM +0200, Robert Millan wrote:
> > I'm not satisfied with the current user interface of that script, but I
> > couldn't think of any better way to do it back then. If you can improve
> > it that'd be m
Aside from the discussion about removing / refurbishing make_install_device(),
is everybody ok with what this patch does?
If I don't hear any objections I'll commit it soon.
On Sat, Jul 26, 2008 at 12:10:50AM +0200, Robert Millan wrote:
> 2008-07-26 Robert Millan <[EMAIL PROTECTED]>
>
>
On Sun, Jul 27, 2008 at 12:29:43PM -0400, Pavel Roskin wrote:
> On Sun, 2008-07-27 at 14:19 +0200, Robert Millan wrote:
>
> > > We could also use UUID for single-drive installs and fallback to the
> > > partition prefix only if UUID is unsupported or the user requests not to
> > > use UUID. Then
On Sun, Jul 27, 2008 at 08:37:37PM +0200, Robert Millan wrote:
> I'm not satisfied with the current user interface of that script, but I
> couldn't think of any better way to do it back then. If you can improve
> it that'd be much welcome.
>
> Btw, I'm currently working on adding --prefix / uuid
On Sun, 2008-07-27 at 14:19 +0200, Robert Millan wrote:
> > We could also use UUID for single-drive installs and fallback to the
> > partition prefix only if UUID is unsupported or the user requests not to
> > use UUID. Then it won't be a big deal if we hardcode the drive.
>
> Based on the rest
On Fri, Jul 25, 2008 at 09:08:52PM -0400, Pavel Roskin wrote:
>
> As for single drive installs, we could also encode the prefix in the
> text form, like "(hd0,5)/boot/grub" and obsolete the numerical partition
> data. That would make make_install_device() unnecessary.
On single drive installs we
On Sat, 2008-07-26 at 00:10 +0200, Robert Millan wrote:
> See attached patch. I'm afraid it doesn't make kernel smaller as promised;
> I expected to get rid of make_install_device() in kernel, but later noticed
> that this is still needed for non-cross installs.
I like your patch. We should try
On Fri, Jul 25, 2008 at 05:47:00PM -0400, Pavel Roskin wrote:
> On Fri, 2008-07-25 at 23:08 +0200, Robert Millan wrote:
> > On Thu, Jul 24, 2008 at 12:49:05PM -0400, Pavel Roskin wrote:
> > >
> > > As I said, GRUB uses its internal ID instead of BIOS ID. We need to fix
> > > it.
> >
> > Why not
On Fri, 2008-07-25 at 23:08 +0200, Robert Millan wrote:
> On Thu, Jul 24, 2008 at 12:49:05PM -0400, Pavel Roskin wrote:
> >
> > As I said, GRUB uses its internal ID instead of BIOS ID. We need to fix
> > it.
>
> Why not just remove that logic and use UUIDs instead? It would also simplify
> the
On Thu, Jul 24, 2008 at 12:49:05PM -0400, Pavel Roskin wrote:
>
> As I said, GRUB uses its internal ID instead of BIOS ID. We need to fix
> it.
Why not just remove that logic and use UUIDs instead? It would also simplify
the code both in grub-setup and in kernel, maybe even make it smaller.
--
On Thu, 2008-07-24 at 13:00 +0200, Felix Zielcke wrote:
> Sorry for my third mail, I really should think more before writing :(
> sdb needs to be in device.map else grub-install luckly complains about it.
grub-install always complains about device.map. Even if it does a
single-drive install and
From: "Felix Zielcke" <[EMAIL PROTECTED]>
Maybe this Debian bug ? :)
For the reporter fd0 wasn't in device.map
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467501
Sorry for my third mail, I really should think more before writing :(
sdb needs to be in device.map else grub-install luc
From: "Felix Zielcke" <[EMAIL PROTECTED]>
...
Now did the same with my other disk and it worked.
I forgot I did first the mistake grub-install /dev/sdb
which I never did before.
I'll try if I can reproduce this somehow.
the VM hasn't a floppy assigned, and I've disabled floppy disk and controlle
From: "Felix Zielcke" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2008 4:01 PM
To: "The development of GRUB 2"
Subject: Re: Issue with boot != root and chainloading
From: "Pavel Roskin" <[EMAIL PROTECTED]>
I've seen that fd1 somewhere, but I don
On Tue, 2008-07-22 at 16:01 +0200, Felix Zielcke wrote:
> From: "Pavel Roskin" <[EMAIL PROTECTED]>
>
>
> > I've seen that fd1 somewhere, but I don't remember where. I guess
> > GRUB just defaults to that value if it cannot figure out the real
> > device number of the root device.
> >
>
> M
On Tue, Jul 22, 2008 at 09:50:21AM -0400, Pavel Roskin wrote:
Quoting Andy Kittner <[EMAIL PROTECTED]>:
Everything went smooth, however after rebooting I get dropped in rescue
mode with this message: "unknown device fd1,5"
Please check your /boot/grub/device.map. You may need to remove it
From: "Pavel Roskin" <[EMAIL PROTECTED]>
I've seen that fd1 somewhere, but I don't remember where. I guess
GRUB just defaults to that value if it cannot figure out the real
device number of the root device.
Maybe this Debian bug ? :)
For the reporter fd0 wasn't in device.map
http://bug
Quoting Andy Kittner <[EMAIL PROTECTED]>:
Everything went smooth, however after rebooting I get dropped in rescue
mode with this message: "unknown device fd1,5"
Please check your /boot/grub/device.map. You may need to remove it
and let grub-install regenerate it. It would be great if you p
Hi all,
First of all I hope I've come to the right place with my little bug
(from what I've read this list seems to be preferred to the tracker?).
Anyway here it goes: I have two hard drives in my notebook, and tried
installing grub (svn r1724) with it's root on the second one (/dev/sdb5
to
26 matches
Mail list logo
