Dmitriy Matrosov <sgf....@gmail.com> writes: > On 09/15/12 18:23, lee wrote: >> >> Can't we have a boot manager which is independent of the installed OSs? >> Grub kinda does its own thing already, and if there was something like a >> standardised API through which OSs could tell the boot manager how they >> are to be booted, we would install the boot manager as the first thing >> and only once. Then we could install as many OSs (or at least Linux >> versions that comply with the standard) as we like, each of them telling >> the boot manager how to boot them. You wouldn't have the problem you >> have now anymore. > All of this can be implemented with grub (grub2 at least). And one of the > approaches, is to have (main) grub config, which loads OS-specific ones. The > main grub config should only know where to find OS-specific ones and should > _not_ be updated by update-grub from any OS. The os-specific ones, on the > other hand, should be updated by update-grub from corresponding OS. The > main config must be updated either manually, or by some other method (using > standardized API, as you said). Anyway, this is exactly what described in > article i mention earlier. And may be it's a bit complicated, but it works.
Yes, that's way too complicated. What I have in mind, as far as simplicity is concerned, is something more like what you do in the BIOS when you tell it from what disk to boot. It doesn't need to somehow be invented, installed and maintained by me because it's already there. The BIOS figures out which disks are available automatically and presents me with a list I can chose from. Just give me a CD I can boot from and optionally use to reserve a small partition on a disk to install this boot manager so that I don't need to keep the CD in the drive. This boot manager would present me with a list of OSs I can boot just like the BIOS presents me with a list of disks to boot from. That might be what they intended with grub. The result is something even more complicated than lilo, and I never figured out any of lilo or grub. I can only hope they work, and if I have to change disks or change partitioning in a way that requires changing grub, I have a major problem. Last time I checked, documentation for grub was like non-existent --- and I really don't want to mess around with it, I just want it to work and easy to use. I can't install or update grub when (after a change) I can't boot the OS which grub is supposed to boot. Messing around with it scares the hell out of me because for all I know I can be left with an unbootable system, so I don't do that. That's just great ... >> What if you install a tiny minimal Linux version only to get grub >> installed and exclusively use that version of grub for booting? The >> Debian installer and the package management would have to be fine >> without installing or updating grub, and you would have to boot into >> your minimal version to update grub from there. Is that possible? >> >> > Grub from this minimal linux should somehow figure out which OS root > corresponds to which kernel, or where to find /boot corresponding to some > OS. Default grub2 scripts can't do this (at the time, when i have checked). That seems to be exactly the problem the OP has. It's something the standardised API would cover by requiring OSs to give this kind of information to the boot manager ... What sense does it make that grub needs to figure out information like this? Why doesn't the OS just tell it? -- Debian testing amd64 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87627ej37f....@yun.yagibdah.de
