grub-devel
[Top][All Lists]
Advanced

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

Re: Some suggestions for improvements in GRUB


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: Some suggestions for improvements in GRUB
Date: Mon, 23 Apr 2012 07:39:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 23.04.2012 07:23, Chris Murphy wrote:
> On Apr 22, 2012, at 12:49 PM, Karthik Krishna wrote:
>
>> Hi there,
>>
>> I am an engineering student from India. I have been using Linux Distros for 
>> some time. With its varied uses i have come to like GRUB very much. But i 
>> wish to say that there are certain things that are not user friendly and 
>> needs a bit of change.
>>
>> First of all, if a drive is deleted or edited using any partition manager, 
>> GRUB does not know anything about it. And so in the ensuing part of booting, 
>> it shows a boot error. i have been seeing this as my friends keep coming to 
>> me to "FIX" their boot. The problem lies in GRUB's steep learning curve in 
>> the  fixing department. when the grub error screen comes up, one has to come 
>> up with a plan to go to the internet and see the required grub error codes 
>> and relevant data to fix it. Thereby restoring grubs working.  But the thing 
>> is you need an another PC/laptop with a working internet to see the codes or 
>> relevant data. i have been doing this for some time. i see that people who 
>> wish to use Linux have a hard time using it fully, especially when it comes 
>> to its boot-loader.
>>
>> The onset of boot-loader problems really bogs down the motivation to move 
>> forward.
>>
>> So I wish to develop GRUB a bit so that it may be easy to use even in the 
>> case of error handling. I just dont know where to start. I know assembly, a 
>> bit of c and c++. I have heard of nasm and used gcc. So how do i develop it? 
>> I wanted to make a code that automatically detects partitions and checks it 
>> with a library of partitions to see if it has been changed or not. So that 
>> way the user is given the freedom of not doing anything rather letting GRUB 
>> doing the work for the user. i can develop the code using a simple 
>> algorithm. i want to make grub more smarter when it comes to handling errors 
>> and freeing the user.
>
> Brilliant. 
>
> I've been wondering if it's possible to get the existing grub-mkconfig script 
> and os-prober code, etc. wrapped into a GRUB module, and have it dynamically 
> create a grub.cfg at boot time. It would not need to write out a grub.cfg, 
> but use it as a "master" cfg, while incorporating any located grub.cfg 
> on-disk in a separate menu. That way, there's both. 
See os-prober.cfg
> But I agree, I know way way way way too much about GRUB to get reliable 
> booting. mkconfig is leap years beyond the asylum of having to hand write 
> menu.lst but even more automatic is better.
>
> For UEFI systems, I think GRUB2 is way too complicated, IMO. "All" that's 
> needed there is a way to make up for the fact so many UEFI implementations 
> have no interface to choose the bootloader for other OS's. And a prettier 
> menu, kinda like rEFIt (now rEFInd) or the way Apple does it, for basic mode 
> UI would be so much of a better experience. Fine, have an advanced menu to 
> get to for people who need a GRUB prompt, but I don't think most users need 
> to be interacting with GRUB as much as they have been historically.
The task of loading kernel into memory and launching it (avoiding
firmware bugs all the time) is almost the same on EFI and BIOS, you
can't just remove it and leave only menu.
The reason while such OS choosers are so "simple" is that they don't
handle real OS loading at all, that's all they are: OS-choosers. They
don't load kernels. An equivalent on BIOS would be mbldr, not GRUB
>
> Chris Murphy
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


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


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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