All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: grub-install revamp
Date: Mon, 30 Jan 2012 03:37:29 +0100	[thread overview]
Message-ID: <4F260269.10201@gmail.com> (raw)

Hello, all. It was a Robert's idea of having grub-install to install all 
available (as in: the ones which were make install'ed) ports in a single 
grub-install w/o having to keep and run one grub-install per port.
This has an advantage of making the disk bootable in various ways 
including ability to move it from one computer to another.
The first problem is the files collision. To resolve this the 
modification will be to load modules from 
$prefix/$cpu-$platform/$modname.mod. Also 2 new script constants will be 
defined:  $cpu and $platform.
The problem then is that different firmwares require different kind of 
arrangements in order to be bootable.
i386-pc requires 55AA signature, some code in MBR and embedding zone. A 
dummy msdos active partition is required on some systems.
*-efi require files on ESP and some nvram entries
i386-qemu, i386-coreboot, i386-qemu_mips and loongsoon-firmware are 
firmware ports and we don't use grub-install for those but 
grub-mkstandalone.
i386-multiboot just has to be readable by whatever is a coreboot payload.
mipsel-loongson has to be on ext2 msdos partition.
sparc64 requires SUN partition map and the code in sector 1
Powerpc (Apple) requires a file on HFS and nvram modification
PowerPC (IBM) uses PreP partition
ARC uses a special entry in the dvh partition table
I have no idea what i386-ieee1275 requires but I guess it's a fat 
partition with special file + nvram modification.

So I propose following strategy: grub-install does the following 
platform-specific installations:
- if /boot/efi is on fat, copy grub to 
/boot/efi/efi/$boot_id/grub[ia32|x64|ia64].efi (replace $boot_id and 
grub with boot if --removable is specified) and update nvram if no 
--removable is specified and currently running EFI version matches the 
installed one.
- if /boot/mac is on HFS or HFS+, create there a structure recognized by 
both PPC and Intel macs and update nvram if architecture matches
- If /boot/ext2 is on ext*, put mipsel-loongson and i386-multiboot there.
- If /boot/olpc is on fat, install i386-ieee1275 there and update nvram 
if architecture matches.
- For every argument that is an msdos or gpt disk, install i386-pc 
bootsector.
- For every argument that is a sun disk, install sun bootsector.
- For every argument that is a dvh disk, install mips-arc.
- For every argument that is a prep partition install powerpc-ieee1275

While the copying to partitions is harmless and updating nvram is done 
only if architecture and platform matches, the disk operations may be 
harmful. While none of the current 4 configuration usually come in 
contradictory combinations, it's possible to purposedly create a disk of 
multiple types and it will confuse this logic. Also if we throw e.g. 
hppa into the mix which requires just a signature on bytes 0-1 and some 
info in 0xf4-0xff then we can't know if msdos disk is for BIOS or hppa 
install. So we need a way to specify them more precisely. PreP and ARC 
came in only after 1.99 so we can make them accept only the new way 
whatever it will be. In case of old way we can easily distinguish 
sparc64-ieee1275 and i386-pc with e.g. uname -i. I propose either of:
--device-bios=/dev/xyz --device-sun=/dev/xyz --device-arc=/dev/xyz 
--device-prep=/dev/xyz
Or: bios:/dev/xyz sun:/dev/xyz arc:/dev/xyz prep:/dev/xyz

Also it may happen that installation of some port is undesirable. So we 
need options
--install-only=...
--exclude=...
Any further ideas?

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



             reply	other threads:[~2012-01-30  2:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30  2:37 Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2012-02-01 20:15 ` grub-install revamp Vladimir 'φ-coder/phcoder' Serbinenko
2012-02-26 21:01   ` Keshav P R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F260269.10201@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.