smxi
boot loader information option
A user asked me about adding grub detection, ie, to locate which partition or
disk grub was installed on, thinking I assume only of his single disk system
with a few partitions, but just to have this issue reported I'm creating this
issue here.
http://forum.siduction.org/index.php?topic=4390.0
Re grub detection, once you expand the use case to cover everything possible,
here's what is actually roughly required:
Detect all bootlloaders, grub, lilo, and whatever else is used on unix/linux.
handle uefi, which requires all permutations of that possible setup and data
sets.
locate root partition, check that partition for boot loader.
locate drive id, like /dev/sda, query that. Query all other drives located to
discover all other boot loader instances.
Since the main bootloader can be on another drive, and boot the partition
either using the partition boot, or a direct connection to the kernel image
thing from the primary grub/lilo whatever, the possibities are somewhat
staggering, and would require learning exactly how all types of uefi boot
implementations can be detected and handled, all types of boot loaders, all
partition and main boot sectors, etc. Scary stuff. My experience with inxi is
that once you expand the features to cover most possible scenarios, you're
talking about a minimum of 2 weeks of research and development, followed by at
least 2 more weeks of fringe case handling and issues. In other words, it would
be a major feature, not a trivial thing to do, so I'll wait for a patch for the
get_bootloader_data function, I'll handle the print bootloader stuff because
it's very picky and hard to understand.
Patch would need to include all possible scenarios, raid boot, uefi, all boot
loaders, multi disk systems, systems with multiple instances of bootloaders,
etc. I suggest filing an issue report on inxi wiki, it will stay up a long time
but might at some date be done if I feel the need to actually have that data,
just as the ram issue report stays until it gets done one day.
Note that as with ram/memory item, this currently would require root to run it,
which makes it a highly non desirable item, anything that can point to how to
get this type of data without root will escalate the feature consideration
radically, as will any crude patch. A patch merely should print lines of the
data, usually inxi internally creates pseudo multidimensional arrays, ie,
primary uses line breaks to separate array values, and secondary uses something
like csv formatting to hold each line's array data, so that's the desired
output more or less. Note that the attached shows things like NTFS too, so it
needs to handle all major OS bootloaders as well, windows, osx, etc.
I'm not likely to do this ever, but I'm posting an issue to record the idea.
Original issue reported on code.google.com by [email protected] on 5 Apr 2014 at 7:08
Attachments:
Original comment by [email protected] on 5 Apr 2014 at 7:11
- Added labels: Type-Enhancement
- Removed labels: Type-Defect
Original comment by [email protected] on 5 Apr 2014 at 7:14
- Added labels: Priority-Low
- Removed labels: Priority-Medium
[UPDATE] Because software tracking is a pain, this issue will not happen I believe unless someone provides a full patch for it, or unless inxi is refactored to another language, at which point maybe someone will feel like writing out that patch.
I don't thing this should be implemented .. ofc possible at least for BIOS installs but I'm not sure is worth the trouble..
In BIOS mode one need to use fdisk -l and match the disk with '*' , boot partition , then run dd on /dev/xxx mbr and grep for grub/lilio/.. strings but eheh that could go wrong and could possible be very slow AND need root/sudo.
Why not just display what the box boots, UEFI or BIOS ? this is very easy to find out these days ... if your system has : /sys/firmware/efi you boot UEFI if not you boot BIOS..
It does display bios/uefi/uefi legacy in -M, so that's handled (detecting uefi legacy is slightly different frojm uefi).
I tend to agree, this issue probably should not be done.