[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grub-install revamp

From: Keshav P R
Subject: Re: grub-install revamp
Date: Mon, 27 Feb 2012 02:31:49 +0530

Status of mactel bless in grub2 v2.00 code freeze?

- Keshav

On 02/02/2012, Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> wrote:
> On 30.01.2012 03:37, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> 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.
> I've tried to write such a thing. I have  met some problems in practice:
> - I wanted also to integrate mactelbless in the same time. Unfortunately
> Apple uses the same pointer for both i386 and x86_64 efi. So hfs(+)
> partitions can hold only either 32-bit or 64-bit EFI binary. We could
> use "FAT Binary" to workaround this but not all macs support this.
> - If one of platform specific installs fail the script doesn't install
> other platforms.
> - When modifying nvram on EFI where to point it to? ESP or HFS? This is
> easy: HFS if it's a mac and ESP otherwise. Or just always ESP.
> - The same problem for ieee1275. While distinguishing between mac and
> non-mac is easy (check vendor string), I don't know how to distinguish
> the ones using PreP partition and the ones using a file on a FAT fs.
> I would appreciate any input both on these specific problems and the
> idea in general. Perhaps it's better to abandon it and have something
> easier like auto-detect firmware and use it as default and specify it
> manually if you need a different install.
> The attached patch is just a small illustration to discuss about. It
> doesn't work
>> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]