Re: [PATCH v2 1/6] ia64: Remove support
On Fri, May 12, 2023 at 12:09:14AM +0200, Ard Biesheuvel wrote: > Thanks, this could be helpful if we manage to find people that have > the bandwidth to keep working on this. Would you be willing to spend > time and development effort yourself on building and installing GRUB > from the upstream repository on this machine (which is a bit more > complicated than running kernels or user space programs)? Which distro > and version are you using btw? > > And just out of curiosity, why does this matter to you? Given that the > ia64 firmware, the hardware and the linux boot protocol have not > changed in a decade, wouldn't it make much more sense to stick with a > stable, current version of GRUB, assuming that these are machines that > need to be kept in working order? What kind of workloads are you > running on these machines? > > For ia64, there are no upsides to running newer GRUB code with changes > applied to the EFI layer, as these involve protocols and other > functionality that the ia64 firmware simply does not implement. In the > best case, it works exactly the same as it does today. In the worst > case, it bricks your box and someone has to go down and reinstall the > bootloader (or more) using some kind of rescue image. Future EFI work > will be focused on tightening memory permissions and implementing > other robustness and hardening improvements, and these changes might > tickle bugs in older firmware in ways we cannot anticipate at this > point. > > So what exactly would we be trying to achieve by keeping ia64 > supported in upstream GRUB? Is it really important enough to justify > asking contributors to spend time and effort on it rather than on > something else? I don't personally care about IA64 (I think the architecture was awful, right from when it was announced), but I don't understand some people's desire to delete code that is working. If the code works, why not leave it alone? Unless it gets in the way of doing some big API change that affects lots of different parts of the code, how does it add to anyone's effort? You don't have to compile test the code if it is only used on an architecture you don't work with. The people that do use that architecture can take care to make sure it still builds and fix it if needed. Now if the code ends up broken and no one actually cares to fix it, OK at that point you should probably remove it, but until it breaks or actually gets in the way (not just in theory), there really doesn't seem to be any reason to delete it. Removing it in fact is work, and if someone else still wants to work with it, you just made their effort even higher. The linux kernel I believe is considering dropping support for 486 recently because it was actually making it harder to maintain locking code. So in that case it is causing a maintenance problem and it seemed quite justified to consider removing it. I don't think they have actually done so yet, but at least they are considering it. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: 3rd gen Ipad to Boot Linux
On Wed, Jan 11, 2023 at 10:48:30AM -0800, Mr. Disorganized wrote: > I am just curious if GNU GRUB has the ability to boot onto an Apple device > like a 3rd gen Ipad to load Ubuntu or Kali. I just want to see if it is > possible. As far as I know, you need openiboot for those devices, assuming anything supports them at all. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 0/6] Dynamic allocation of memory regions and IBM vTPM v2
On Thu, Dec 01, 2022 at 03:47:30PM +0100, Daniel Kiper wrote: > What do you mean by "supported"? It is build tested and, AIUI, all "make > check" > tests pass. Though I am not sure anybody uses this kinda weird target. Well, > I think I knew but I forgot... :-) I thought OLPC used openfirware on i386. Are those things still around? -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to boot Windows when Bitlocker enabled with key sealed in TPM
On Thu, Feb 10, 2022 at 02:13:43PM -0700, Chris Murphy wrote: > If you boot windows once a day, it's changing what, 1-4 bytes, per > day? The entry for Windows is already in NVRAM, it doesn't need to be > written each time. You're only changing the BootNext value that points > to the Windows entry (and then the firmware removes it). Well the fact you are only rewriting nextboot with a few bytes is probably still a potential problem since from what I have seen, these simple SPI flash chips that seem to often be used tend not to have wear leveling. They don't expect a lot of writes. Ideally the UEFI NVRAM should be battery back ram, but that doesn't seem to be how a lot of systems actually implement it. If they expect you to install windows and run it, they don't need to support rewriting a lot. > This is not Secure Boot. It's measured boot. They're using the TPM to > measure the bootchain and make sure it hasn't been tampered with > before revealing the encryption key. If the user has written down the > recovery key, they can still boot from the BitLocker recovery window, > but that's an untenable default user experience following the > installation of a Linux distro. It's a 48 digit key. Oh right for bitlocker. Even more picky than secureboot. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to boot Windows when Bitlocker enabled with key sealed in TPM
On Thu, Feb 10, 2022 at 11:46:33AM -0700, Chris Murphy wrote: > On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen > wrote: > > > > On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote: > > > One idea I've heard floated is, having GRUB alter efivars such that > > > BootNext is changed to do a one time boot of Windows, instead of using > > > chainloader. If BIOS, use chainloader as now. If UEFI, set BootNext > > > efi variable? This has the benefit of working even on UEFI systems > > > which aren't BitLocker encrypted. > > > > > > Can GRUB modify efivars now? If not, what work would be needed to > > > enable GRUB to modify efivars? Alternatives? > > > > I am pretty sure I have read of cases where systems used such low quality > > flash for their UEFI variables that they broke after being written too > > many times. I think Ubuntu had a bug that caused it to rewrite some > > UEFI variable ever boot that initially spotted the problem or something > > like that. Cheap flash is often 1 writes or even less in some cases. > > > > But rewriting the variable each time you boot sounds like a "Don't do > > that" thing. > > Not every boot. Just when the user picks the Windows entry in the > menu. Anyway, the death of NVRAM is orthogonal to the issue, which is > that the current paradigm isn't working for newer systems. Eventually > it'll be the common case. So is the idea to just leave it broken, or > fix it? At a certain point it makes more sense to stop creating > Windows boot entries if they're not going to work. > > Also, systemd-boot is going to support BootNext. > https://github.com/systemd/systemd/pull/22043/commits/661615a0afacee3545cde0a48286c0fef983f8fe Well every time you boot windows counts as every boot. Perhaps not every boot of the system. Still seems like way too often at least. Secureboot combined with dual (or more) booting sure does seem like a huge mess. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to boot Windows when Bitlocker enabled with key sealed in TPM
On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote: > One idea I've heard floated is, having GRUB alter efivars such that > BootNext is changed to do a one time boot of Windows, instead of using > chainloader. If BIOS, use chainloader as now. If UEFI, set BootNext > efi variable? This has the benefit of working even on UEFI systems > which aren't BitLocker encrypted. > > Can GRUB modify efivars now? If not, what work would be needed to > enable GRUB to modify efivars? Alternatives? I am pretty sure I have read of cases where systems used such low quality flash for their UEFI variables that they broke after being written too many times. I think Ubuntu had a bug that caused it to rewrite some UEFI variable ever boot that initially spotted the problem or something like that. Cheap flash is often 1 writes or even less in some cases. But rewriting the variable each time you boot sounds like a "Don't do that" thing. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: About the code style requirement
On Wed, Sep 29, 2021 at 03:04:59PM +0800, Qu Wenruo via Grub-devel wrote: > Oh, didn't know there would be license problem. There often is. :) > Then it would be complex. > > Quite some code is directly copied from kernel without modification, those > should still be GPL-2.0 only. > > For code already cross-ported to U-boot, it's GPL-2.0+, I guess it would be > OK there. > > But from what I see in btrfs-progs, most of them is still GPL 2.0. > > I guess during the cross-port to U-boot, I have already broken the GPL 2.0 > requirement... > > Any advice on this problem? Does libbtrfsutils provide what you need? It appears to be LGPLv2.1+. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] i386-pc: build verifiers API as module
On Tue, Mar 23, 2021 at 05:33:12PM +0100, Daniel Kiper wrote: > How long are you going to support such systems? 1, 5 or 10 years? This > approach makes GRUB upstream as a hostage of small MBR gaps users. > Anyway, I think we have to make users aware that small MBR gaps are not > supported any longer. Otherwise we will be playing whack-a-mole game > which we will loose sooner or later. I was surprised to find a 63 sector gap on one of my systems recently when upgrading the root disk to a larger drive (by cloning the old disk and then resizing with gparted). I decided being that this was an SSD it was in my interest to change it to 1MB alignment while doing the resizing anyhow. I guess this install has been around for a while from before Debian changed to using 1MB alignment by default. So some such systems apparently are still around. Perhaps you need to actually have grub generate a warning when installed in a 63 sector gap for a while (where a while preferaby is more than one release cycle for common distributions, so hence more than 2 or 3 years) so that people get told there will be a problem with upgrades at some point and they should look into fixing their partitioning now. Ideally to make people know about it, put the warning on the boot screen, not just when doing grub install. Make people aware so they can start to look into what they need to do to change their system. Finding out after they can't boot is too late. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [SECURITY PATCH 116/117] templates: Disable the os-prober by default
On Wed, Mar 03, 2021 at 07:43:23PM +0100, John Paul Adrian Glaubitz wrote: > I'm not sure I'm able to follow the motivation to keep the naming scheme > as is. > > If I have an option called "DISABLE_FEATURE_X", then I would expect setting > it to "true" would mean that the feature is disabled not the other way around. And existing users have already set it to true to disable it, so true better mean disabled. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [SECURITY PATCH 116/117] templates: Disable the os-prober by default
On Wed, Mar 03, 2021 at 02:13:04PM +0100, Daniel Kiper wrote:
> On Tue, Mar 02, 2021 at 10:49:16PM +0100, Didier Spaier wrote:
> > Le 02/03/2021 à 19:02, Daniel Kiper a écrit :
> > > From: Alex Burmashev
> > > diff --git a/util/grub.d/30_os-prober.in b/util/grub.d/30_os-prober.in
> > > index 1b91c102f..80685b15f 100644
> > > --- a/util/grub.d/30_os-prober.in
> > > +++ b/util/grub.d/30_os-prober.in
> > > @@ -26,7 +26,8 @@ export TEXTDOMAINDIR="@localedir@"
> > > . "$pkgdatadir/grub-mkconfig_lib"
> > > -if [ "x${GRUB_DISABLE_OS_PROBER}" = "xtrue" ]; then
> > > +if [ "x${GRUB_DISABLE_OS_PROBER}" = "xfalse" ]; then
> > > + gettext_printf "os-prober will not be executed to detect other
> > > bootable partitions.\nSystems on them will not be added to the GRUB boot
> > > configuration.\nCheck GRUB_DISABLE_OS_PROBER documentation entry.\n"
> > > exit 0
> > > fi
> >
> > This is confusing: now to get boot entries from os-prober one have to
> > set:
> > GRUB_DISABLE_OS_PROBER=true
> > in /etc/default/grub.
> >
> > Either revert that, or (better, in my opinion) label the variable
> > GRUB_ENABLE_OS_PROBER and set it to false by default.
>
> When we worked on this patch we considered that. However, after some
> thinking we stated that renaming to GRUB_ENABLE_OS_PROBER will make
> more confusion. So, we decided to stick to existing name even if it
> is not the best one.
How does that make any sense?
You can disable it by default, but leave the meaning of true and false
and the name the same. Someone would then have to explicitly set
GRUB_DISABLE_OS_PROBER to false if they want to use it still. At least
then it makes some sense.
And what does the code do now if someone already has it set to true in
order to disable it, as is in all existing examples and documentation
about the option? Does it now actually get enabled which is the opposite
of what they wanted?
Something sure looks wrong with this.
--
Len Sorensen
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] password: Fix backspace in username prompt
On Mon, Mar 01, 2021 at 10:58:40AM +0300, Egor Ignatov wrote:
> From: Egor Ignatov
>
> Make backspace work in superuser login prompt.
>
> The problem was that bidi logical to visual ignored BN type,
> so you couldn't print control characters.
>
> Use grub_printf() 3 times, because a line wrap will cause
> the cursor to get stuck at the end of the terminal line.
>
> Resolves: #60114
> Signed-off-by: Egor Ignatov
> ---
> grub-core/normal/auth.c| 4 +++-
> grub-core/normal/charset.c | 1 +
> grub-core/term/gfxterm.c | 11 +--
> 3 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/grub-core/normal/auth.c b/grub-core/normal/auth.c
> index 6be678c0d..ffbf6d890 100644
> --- a/grub-core/normal/auth.c
> +++ b/grub-core/normal/auth.c
> @@ -177,7 +177,9 @@ grub_username_get (char buf[], unsigned buf_size)
> if (cur_len)
> {
> cur_len--;
> - grub_printf ("\b \b");
> + grub_printf ("\b");
> + grub_printf (" ");
> + grub_printf ("\b");
> }
> continue;
> }
Is this the part that the commit message refers to? I must admit I
am not quite sure why this change makes a difference, but if it does,
perhaps it is important (and non obvious) enough that the code should
actually have a comment explaining it, or someone might come by and
clean it up again later.
--
Len Sorensen
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Atomic writing to environment file
On Tue, Feb 16, 2021 at 08:44:43AM +0100, Claudius Heine wrote: > we were looking into using grub to implement an A/B system update mechanism > [1] and came to the point where we need to change the grub environment from > user space (grub-editenv) and from grub itself (save_env). > > We looked at the code [2] and [3], and it sort of looks like the environment > file is written directly in both cases. We suspect that this might cause the > environment file to become invalid/empty in a power-loss scenario. > > Other write schemes, like: `write file.tmp; mv file.tmp file` or using > hard-links (if the fs supports it) might provide a better protection against > a power-loss scenario. > > If this is an issue, then we would be willing to contribute some changes to > grub for this. > > kind regards, > Claudius Heine > > [1] > https://sbabic.github.io/swupdate/overview.html#double-copy-with-fall-back > [2] > https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/commands/loadenv.c#n380 > [3] https://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-editenv.c#n186 Of course the current method conviniently doesn't need to fully understand a filesystem, it just needs to update the existing block's contents. Of course on filesystems like zfs that has checksums, that would still need to be updated too somehow. I was under the impression grub really only implemented enough filesystem code to read the filesystems, not write them. I guess one method that could work in a simple way was to have two files and put a version number in each one, and update it each time you write to one after you updated the contents to make the updated file the newest. Of course I am not sure if any disk really has any problem with sector level updates being partially done or if they ever promise that you will always get complete sector updates. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How-to make grub play a sound when it asks a passphrase and/or in case of an issue.
On Wed, Feb 03, 2021 at 10:54:28PM -0800, Hanson Char wrote: > I don't know if Grub currently has any sound or accessibility support. How > about having a config option to send some ASCII bell characters "\x07" to > the terminal upon the events that you described? That would make a sound, > but far from being a "tune". Would such a simple solution be good enough? What terminal? Might work for serial consoles but I suspect most people are using VGA and grub has to implement that terminal itself and how to play sound becomes very architecture specific. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Why Lua support was removed
On Wed, Oct 14, 2020 at 04:33:31PM +0800, Tianjia Zhang wrote: > I want to use lua to do some logic on grub, which needs to be embedded in > the lua interpreter. I found that grub supports lua as early as 2009, and > only a few months later, the lua was removed. I checked the Changelog and > git log, the reason for removal was not found, I want to know why the > support for lua was removed. > > Judging from the current situation, if grub wants to support a scripting > language, lua is undoubtedly the most suitable and completely feasible. Is > it acceptable to support lua in grub now? If possible, I will consider doing > this. Looking at the grub source in Debian I see: grub-2.04/debian/grub-extras/lua/ It however appears disabled in the build of the package. I guess it stopped working at some point and was dropped if it was ever actually enabled. It is not mentioned in any way in the changelog making me think it was added at some point but never enabled. Was it ever actually part of grub, or was it just an external add-on you could use with it? -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] version: add a module to get GRUB version
On Wed, Apr 15, 2020 at 02:04:36PM +0200, Flavio Suligoi wrote: > Sometimes, writing a custom grub.cfg configuration file, > especially with embedded systems, it is indispensable > to know the version of the running GRUB. > This is essential for every automatic sw update procedure. You can't actually assume that the grub binary on the running system is the same version as the one currently booting the system. It probably tends to be if the distribution takes care to auto upgrade it when a new grub is installed, but it doesn't always happen. Of course in the case of a distribution, it's package management would already have that information. I am not saying adding this is a bad idea, I just don't believe it does anything useful. I just believe it is trying to solve a problem that doesn't actually exist. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 08/12] kern: Make grub_error() more verbose
On Fri, Mar 06, 2020 at 06:10:58PM +0100, Didier Spaier wrote: > My mistake, I should have written starting at 24 KiB as that is the > start address of the first usable LBA if I read correctly the UEFI > specification. Am I wrong? > > Thanks for the heads-up. I was wrong about 32KB, it is 32 sectors of 512 when that is the block size plus the MBR and header sectors, so 34 sectors at 512b, and yes with 4K blocks you hit 24k. Not sure if bigger sector sizes are likely to happen at some point. Maybe 32 or 64KB would be a safer starting point and being a power of 2, slightly more likely to hit a disk aligned block size. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 08/12] kern: Make grub_error() more verbose
On Fri, Mar 06, 2020 at 11:12:14AM -0600, Bruce Dubbs wrote: > Just a terminology issue here. Please don't call it a boot partition. It > conflicts with those who mount /boot as a separate partition. Please call > it a grub partition. Well the official name is "BIOS boot partition", so I can see why people tend to call it a boot partition. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 08/12] kern: Make grub_error() more verbose
On Fri, Mar 06, 2020 at 05:30:23PM +0100, Didier Spaier wrote: > That'd be just one less thing to care about for the Slint installer > in case of an 'automatic' installation, nothing major. > > Do you confirm that a Bios Boot partition starting at 1 KiB > and ending at 1 MiB won't overlap the GPT and is big enough? It would absolutely overlap GPT since GPT usually starts at 512 bytes and goes up to 32KB or so. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Can the grub2.02 improve the limit of initrd size in 64-bit system?
On Tue, Jul 30, 2019 at 10:50:23AM +0800, 电子科技大学-张旭霞 wrote: > Hi All, > > environment : X86-64 , kernel 3.16.0(64-bit support),grub2.02 > > I compile the grub2.02 by default. And the grub boots the linux kernel with > 32-bit boot protocol.(Documents/X86/boot.txt) > > I want to use the initrd as big as possible, but it is limited as follows. > > But when I make a image-initrd that size is 1.75G(no compression), the grub > can boot linux normal . > > It seems good for initrd size between 0x37fe-0x3fff.But the grub > seems it is against that. > > So I have some questions: > > 1、Why it is necessary to make sure that ADDR_MAX does not exceed 0x3fff ? > Has it a relationship about the 32-bit kernel? > > 2、Can I set addr_max=0x3fFF when (grub_le_to_cpu16 > (linux_params.version) >= 0x0203? > > include/grub/i386/linux.h > > #define GRUB_LINUX_INITRD_MAX_ADDRESS 0x37FF Interesting that on arm the address offset is allowed to be 32GB on 64bit arm. x86 does not appear to have any special handling for 64 bit yet. So 32 bit arm requires kernel + initrd less than 512MB, 64 bit arm requires kernel + inirrd less than 32GB. If I read the code correctly, booting x86 in efi mode the max initrd file allocation is 1GB (0x3fff). Seems the code is shared for 32 and 64 bit EFI and doesn't allow anything more on 64 bit than 32 bit. Of course no normal system would ever need more so no point implementing it. A 1GB ramdisk would be plenty to start a system that could then load more ramdisks if it really wanted to. Could any sensible use case exist for loading an initrd that large? -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2.02 can boot the linux kernel with 64-bit boot protocol
On Fri, Jul 26, 2019 at 08:09:11AM +, Sherry Zhang(BJ-RD) wrote: > Hi All, > I use the grub2.02 to boot the 64-bit kernel of Kernel 3.16.0. The grub2.02 > use the 32-bit boot protocol and the grub is also 32-bit. > But I see that grub can use the 64-bit boot protocol in the > Documents/x86/boot.txt. So I want to know how to realize it? I thought it only used 64 bit when running in EFI mode on 64 bit UEFI. Maybe I am mistaken. After all if grub is running in 32bit mode, it isn't going to be loading anything to memory above 4GB and hence has no need for 64 bit pointers. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub2 Reiser4 support
On Wed, Nov 28, 2018 at 04:31:07PM +0100, Sebastien wrote: > I couldn't find information easy to understand regarding Grub2 > Reiser4 support, hence my questions : > > Does Grub2 support booting off a Reiser4 partition ? > > If yes, starting which grub2 version ? > > If yes, what must be done to boot off a Reiser4 partition ? > > Thank you for your help. I have never heard of anyone working on such support. Reiserfs 3 I believe works, but not 4. Then again I don't think the linux kernel support ReiserFS 4 without manually patching it in. I don't even know why anyone would want to use it. I lost enough data due to reiserfs 3.x that I don't need to repeat that lesson. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/4] Accept Both ESC and F8 as user interrupt keys
On Wed, Mar 28, 2018 at 05:06:53PM +0200, Hans de Goede wrote: > Hmm, well people will still be able to use ESC to get the grub boot > menu, rather then the firmware boot-menu on those. > > The problem is that our current check for ESC only approach is problematic > because it conflicts with the enter firmware-setup key on almost all Bay > Trail, > Cherry Trail and Apollo Lake devices. You need to try hard to find a device > in one of those 3 categories which does not use ESC for this. Note I'm > aware some devices exist, but using ESC for this is really really common > among these devices. > > I'm open to other suggestions, but I think we really need to add another > key to avoid the pressing ESC at boot already has another meaning problem > and F8 seems like an ok choice. > > Either way thank you for the input on this. I don't disagree about having another key, I just disagree that F8 is a good choice. Looking at https://kb.wisc.edu/page.php?id=58779#here it appears no one uses F4 for anything. That would seem like a better choice than F8 at least. F6 also seems to be free but F4 seems nicer on desktop keyboards. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/4] Accept Both ESC and F8 as user interrupt keys
On Wed, Mar 28, 2018 at 04:50:26PM +0200, Hans de Goede wrote: > On most Bay Trail, Cherry Trail and Apollo Lake devices the ESC key is > the hotkey to enter the BIOS/EFI setup screen. > > This makes it hard for the user to show the grub-menu when it is hidden > and a short timeout is used, because pressing ESC too early leads to the > user entering the BIOS/EFI setup screen. > > F8 is (almost?) always free (on X86/PC platforms) as Windows uses this for > its boot menu, so also accept F8 as interrupt/show-menu key. As an added > advantage this is also more discoverable / easier for users coming from > Windows. I have seen F8 and F12 used as boot menu keys on many systems. I would not consider it usually free. Maybe it has become less common after windows started using it, but it isn't that unusual. ASUS seems to be a major user of F8 for boot menu. Not exactly an uncommon system board. Some Lenovo desktops also use F8 for the boot menu. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Maturity of GRUB on powerpc/ppc64?
On Wed, Oct 04, 2017 at 06:36:33PM +0200, John Paul Adrian Glaubitz wrote: > Are you sure? The parted manual seems to say otherwise: > > > http://www.hep.by/gnu/parted/set.html > > And I can fix the problem by manually running the parted command: > > set prep 1 on No I am not sure. I know there is a partition type for it though, and the debian installer for powerpc always created it properly on an IBM pseries for me so I never looked at the details. Looking at the parted source code, they are abusing flags to store things that are not flags. So it if sees partition type 0x41, it sets the "flag" prep. Setting the "flag" prep makes it set the partition type to 0x41. So yes, it is in fact a partition type, and it does not need any flags set by the looks of it. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Maturity of GRUB on powerpc/ppc64?
On Wed, Oct 04, 2017 at 03:25:20PM +0200, John Paul Adrian Glaubitz wrote: > On 10/04/2017 03:16 PM, Frank Scheiner wrote: > > Hey Adrian, you are really helpful! :-) > > So are all your tests. Your input is really appreciated, thank you! > > > I will check this out for the Power Macs and try to fix any issues on > > the way by directly adapting `/usr/bin/grub-installer`. > > Yep, that's the idea. I assume there are only minor changes necessary > to be made until everything works as intended. > > I still haven't managed to fully fix GRUB on POWER-based systems though > as I cannot get partman to flag the boot partition as PREP. And without > that flag, grub-installer is unable to find the target partition for > installing GRUB. It is not a flag, it is a partition type. PPC PReP Boot is partition type 0x41. Similar to how Linux is type 0x83 and Linux swap is type 0x82. I don't remember if it wants the boot flag set on it or not. > I have to dig into the partman source code more to be able to find > the problem. > > > But could take until the weekend to find the time. :-/ I'll keep you > > informed. > > No worries, take your time. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot
On Mon, Sep 25, 2017 at 03:15:15PM +, luigi burdo wrote: > I had in past issue with grub on opensuse, i have a G5 970MP. > > Adrian make a great present to us, making us have again debian working on BE . > > please do not made again it not usable on our hardware choosing grub. I have had issues with grub on opensuse running x86, so that doesn't really mean much. yaboot isn't being maintained, is a pain to build because it only works with an obsolete version of the ext fs library, which makes it incompatible with new ext* features. Much better to spend effort getting any bugs in grub fixed. A lot were fixed some 5 or 6 years ago when I wanted grub on an IBM p520 and worked with upstream to debug a lot of issues there over a few months. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot
On Sat, Sep 23, 2017 at 02:25:32PM +0200, Frank Scheiner wrote: > Do we have information about how it looks (e.g. is it Grub by default and > then, where is it installed?) for a POWER8 machine with Debian Stretch > (ppc64le) installed from an installer image? > > If also working for ppc64 and powerpc architecture machines that way it > could be straight-forward to use the same method (with respective > partitioning schemes for Apple and IBM machines) there, too. Well I think at this point it seems the only option is: powerpc/ppc64: On IBM use DOS partition table with a prep boot partition for grub. On Apple use Apple partition table (I don't know where grub is installed on those). ppc64el: On IBM use GPT and install grub there as is already the case. There does not appear to be any way to merge what Apple and IBM machines do. They are just not compatible that way. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot
On Fri, Sep 22, 2017 at 11:49:38AM +0200, John Paul Adrian Glaubitz wrote: > I was just wondering whether it makes sense for GRUB to use MS-DOS partition > on a Mac, thinking it may be better than Mac partition tables, I was > basically just thinking aloud. If it's not necessary for GRUB to work > properly, then we can stick with the current partition scheme, of course. Well it doesn't sound better, and would certainly be unfriendly do dual booting with MacOS. > FWIW, I made this change [1] to partman-partitioning now which will result > to debian-installer using the same disk labels on ppc64 for the various > sub-architectures as on powerpc. There are, of course, no 64-Bit OldWorld > Macs, Cell CPUs and so on, but I guess my change is more elegant than > duplicating > the case statement for ppc64 and removing all the unsupported > subarchitectures. I would have thought the firmware on the mac would insist on an apple partition table to boot. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot
On Thu, Sep 21, 2017 at 10:37:43PM +0200, John Paul Adrian Glaubitz wrote: > I have one POWER7 machine that has been provided to me by IBM for testing > purposes and to host one of our buildds. I have performed a test installation > of openSUSE Tumbleweed on it. > > Here's the partitioning scheme that is being used: > > (parted) p > Model: Virtio Block Device (virtblk) > Disk /dev/vda: 42.9GB > Sector size (logical/physical): 512B/512B > Partition Table: msdos > Disk Flags: > > Number Start End SizeType File system Flags > 1 1049kB 2097kB 1049kB primary boot, prep, type=41 > 2 2097kB 2163MB 2161MB primary linux-swap(v1) type=82 > 3 2163MB 18.9GB 16.7GB primary btrfs type=83 > 4 18.9GB 42.9GB 24.0GB primary xfs type=83 > > (parted) > > Interestingly, /boot is part of the btrfs filesystem: > > linux-mfl2:~ # mount | grep boot > /dev/vda3 on /boot/grub2/powerpc-ieee1275 type btrfs > (rw,relatime,space_cache,subvolid=261,subvol=/@/boot/grub2/powerpc-ieee1275) > linux-mfl2:~ # Well as long as grub can read that, then no problem. So as long as grub-install is including btrfs support in the grub image placed in the prep boot partition, then /boot can be on btrfs. That is almost certainly the case. > Ok, so I guess we can basically rule out GPT for the default label even > on POWER systems. I would therefore then vote for using MS-DOS partition > tables on POWER systems, i.e. what is already used now. For powerpc/ppc64 I would agree. For ppc64el GPT should be fine, and I believe someone said that is in fact what they have done since it is power8+ only. > So, MS-DOS partition tables will not work at all on a Mac, correct? Not as far as I know. And given the apple partition table is better anyhow, why would you want to? -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot
On Thu, Sep 21, 2017 at 06:26:10PM +0200, John Paul Adrian Glaubitz wrote: > Ok, good to know. What about GPT partition tables? On ppc64el, i.e. POWER8 > and newer, the default labels are all GPT. Any idea which is the earliest > POWER5+ machine which supports GPT or should we just assume MS-DOS > partition tabels for all POWER machines? I unfortunately never tried GPT on any IBM power machines and I no longer have access to them. I found this: http://download.boulder.ibm.com/ibmdl/pub/software/server/firmware/AH-Firmware-Hist.html So it claims that on power7 the firmware upgrade in 2013 added support for booting from a GPT disk. So to me that means a lot of power7 systems out there won't be able to (since not everyone has updated the firmware). It doesn't say what you have to create as a boot partition when using GPT though, so no idea how one would use it. It might support FAT32 filesystem and accessing the grub file the way UEFI systems do, and similar to what I think PowerMac machines do. I can't find anything to suggest any power6 or power5 system ever had an update to allow it. I would expect all power8 machines had GPT support from the start, and hence defaulting to that makes sense. > > The grub modules stay in whatever /boot is on, and the grub image > > generated contains enough of grub to read filesystems and is loaded > > by the firmware from the prep boot partition (it litterally reads that > > partition into ram as raw data, and executes it). > > Interesting. Do you know whether the mechanism is the same? My worries > are that users on older PowerPC hardware, especially Apple Macintosh > would have to go through extra lengths to get this working. On a powermac is is certainly different. You would have an apple partition table instead, along with whatever else a mac requires boot wise (which I don't know off hand). > It seems that openSUSE for ppc and ppc64 always seems to default to > GRUB. Makes sense, since it is a nice boot loader. > Could someone with both 32-bit and 64-bit Macs maybe perform test > installations of openSUSE on their machines? > > > http://download.opensuse.org/ports/ppc/tumbleweed/iso/ > > The latest release for 32-bit powerpc seems to be 11.1: > > > http://mirrors.vbi.vt.edu/linux/opensuse/discontinued/distribution/11.1/iso/ > > You can also test other distributions like Fedora, for example. Latest > version with ppc32 support seems to be 12: > > > https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/12/Fedora/ppc/iso/ > > The more test results we have, the better. If it turns out that GRUB will > even work properly on 32-bit PowerPC machines, I think it would be the > best option to make GRUB default for "powerpc" as well. > > Of course, we can still keep yaboot on the FTP archives. It will not > be a potential source of issues anymore, however. i386 offered lilo as an alternative to grub for quite a while in the installer. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot
On Thu, Sep 21, 2017 at 02:49:53PM +0200, Frank Scheiner wrote: > On 09/21/2017 02:21 PM, John Paul Adrian Glaubitz wrote: > > [...] > > What we need are people who are willing to extensively test d-i > > images with GRUB on powerpc and ppc64 and report back. > > I can offer to test with all sorts of Power Mac G4s and an Xserve G4 for > powerpc. I still need to buy a few CD-RWs though. :-) > > Also, I'm > > not yet sure whether I have understood how exactly GRUB is properly > > configured and used on powerpc and ppc64. > > (1) Mathieu's pointer to [1] (with Grub's expectations) came a little too > late for me and the howto I provided on [2]. > > (2) It looks like Rogério Brito on [3] wanted to make sure that his Grub > installation also works with what yaboot "dictated" during installation > (e.g. 800 KB HFS partition, etc.). > > I'm unsure what the best approach would be. Assuming that on updates to Grub > a new grub.img needs to be created, with approach (2) only a single file > needs to be copied to the HFS partition. With approach (1) I actually don't > know if the HFS partition will contain all the Grub modules in addition. But > approach (1) seems to be the "default" for Grub and most likely the shipped > tools also have the same expectations. > > [1]: https://bugs.debian.org/691207 > > [2]: https://lists.debian.org/debian-powerpc/2017/09/msg00034.html > > [3]: http://cynic.cc/blog/posts/running_grub2_on_powerpc_macs/ Well in the case of IBM power systems, you use a DOS MBR partition scheme and you create a Prep boot partition, which should be 1MB or so in size, and grub is installed there as a raw image. Has been working fine for a while as far as I have been able to tell. The grub modules stay in whatever /boot is on, and the grub image generated contains enough of grub to read filesystems and is loaded by the firmware from the prep boot partition (it litterally reads that partition into ram as raw data, and executes it). This is why the prep boot partition has to be large enough to hold whatever the grub image with required starting modules needs. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub-devel Digest, Vol 163, Issue 18
On Wed, Sep 20, 2017 at 04:59:58PM +, Oleksii Kurochko wrote: > After all there is only one interrupt controller, keyboard, PCI bus, > video card, etc (at least usually). > > Generally this is not problem because of each CPU has own APIC and we can > handle some interrupts in one OS and some in other OS. Still have to coordinate who owns what memory, firmware accesses (the firmware only expects one OS to be running at a time), etc. PCs were not designed to be hardware partitioned. This is clearly not a normal thing, not supported by generic OSs, and certainly not by generic boot loaders (and since the OSs need to agree on it, you might as well have one OS load the other in that case and not have the boot loader involved in the first place). -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Boot 2 Linux simultineously
On Wed, Sep 20, 2017 at 12:20:54PM +, Oleksii Kurochko wrote: > I want to boot on each processor ( 2 CPUs ) Linux kernel. > > By fast looking on it I did not see any SMP patches. > Is it some SMP support in the GRUB? You can only boot one OS on a machine unless you use virtualization. After all there is only one interrupt controller, keyboard, PCI bus, video card, etc (at least usually). grub boots one OS since that is all you can do on normal hardware. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: 8250 memory mapped UART
On Mon, Mar 27, 2017 at 11:29:48PM +0530, Gailu Singh wrote: > Can you please let me know how following three values are calculated in > your patch. I am trying to understand how do I change it for my board. > > port->board.base_baud = 400; > port->board.port_offset = 0x200; > port->board.base_offset = 0x1000; I would think this means: The configuration registers for the ports starts at the PCI base address of the device + 0x1000, and then each additional port is 0x200 above that (so port 2 would be at 0x1200 above the base address). A base_baud of 400 would normally mean the UART is fed from a 64MHz clock source. Pretty sure every uart I have used, the base_baud was 1/16th of the clock input (except some cases on the AM57xx where it uses 1/13th as far as I recall. It's a bit odd sometimes). Many PC boards in the past have used either 1.8432MHz or sometimes 14.7456 MHz, since that gives you perfect 115200 for the first one, and 921600 for the second one, as well as all integer divisions of those. After all with a base_baud of 400, a UART that only does integer divisions would give you 117647 when you ask for 115200, which is generally close enough. Of course some newer designs allow fractional divisions and can hence generate rather good results even with a non ideal input clock. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-probe for nested BSD partition on Linux
On Tue, Feb 28, 2017 at 09:50:27PM +0300, Andrei Borzenkov wrote: > 28.02.2017 21:31, Lennart Sorensen пишет: > > On Tue, Feb 28, 2017 at 08:13:53PM +0300, Andrei Borzenkov wrote: > >> Sorry? vda7 is 256M, how can you suddenly pretend it is 2G? > >> > >> 10:~ # fdisk -l /dev/vda > >> Disk /dev/vda: 5 GiB, 5368709120 bytes, 10485760 sectors > >> Units: sectors of 1 * 512 = 512 bytes > >> Sector size (logical/physical): 512 bytes / 512 bytes > >> I/O size (minimum/optimal): 512 bytes / 512 bytes > >> Disklabel type: dos > >> Disk identifier: 0x882b18da > >> > >> Device Boot Start End Sectors Size Id Type > >> /dev/vda1 2048 2099199 20971521G 83 Linux > >> /dev/vda2 2099200 6293503 41943042G a6 OpenBSD > >> /dev/vda3 6293504 10485759 41922562G 5 Extended > >> /dev/vda5 6295552 6819839 524288 256M 83 Linux > >> /dev/vda6 6821888 7346175 524288 256M 83 Linux > >> 10:~ # fdisk -l /dev/vda2 > >> Disk /dev/vda2: 2 GiB, 2147483648 bytes, 4194304 sectors > >> Geometry: 16 heads, 63 sectors/track, 10402 cylinders > >> Units: sectors of 1 * 512 = 512 bytes > >> Sector size (logical/physical): 512 bytes / 512 bytes > >> I/O size (minimum/optimal): 512 bytes / 512 bytes > >> Disklabel type: bsd > >> > >> Slice Start End Sectors Size Type Fsize Bsize Cpg > >> a 2099200 2623488 524289 256M boot 0 0 0 > >> b 2099200 2623488 524289 256M unused 0 0 0 > >> c 2099200 6293503 41943042G unused 0 0 0 > >> d 0 10485215 104852165G unused 0 0 0 > >> > >> Partition table entries are not in disk order. > > > > Well that does look mostly sane for an ancient BSD version. > > > > In case I was not clear. > > BSD partition a is represented in Linux as /dev/vda7. grub-probe -t > compatibility_hints -d /dev/vda7 returns hd0,msdos2 which is obviously > wrong, because it refers to 2GB area on disk while partition /dev/vda7 > is just 256M. I would expect either hd0,msdos2,openbsd1 or nothing > depending on whether such nested partition is supported. Oh now I see what you mean. Hmm, that is an interesting problem. It seems FFS and UFS reserve either 1 or 8KB at the start for bootblock, which I suppose would save the disklabel from being overwritten if using one of those filesystems. The documentation does seem to say to always leave a gap before the first slice/partition in all cases. > > Slice a is the rootfs for BSD > > > > Slice b should traditionally be swap, but appears to be unused here, > > and for some reason uses the same part of the disk as slice a, which > > does look odd. Maybe since the type is unknown, it doesn't matter. > > > > Slice c is the whole partition containing the slices (vda2) > > > > Slice d is the whole disk (vda), which apparently hasn't been used in > > BSD for a couple of decades now, if wikipedia can be trusted. > > > > So if linux only bothers to count the partition with a type that isn't > > unused, then it probably makes sense. That appears to be what the > > partition parsing code does. > > > > The start being the same as the start of vda2 does seem odd given it > > appears that you are supposed to leave space at the start (1 track > > recommended, or 64 sectors), and it appears the disklabel is at sector > > 1 (0 being the first), so it doesn't seem like having your filesystem > > start there would be safe unless the filesystem has reserved space at > > the start for such things. > > > > I just pressed 'b' in Linux fdisk and only change two partition sizes. I > have no idea how fdisk choses partition start. Could be a bug in fdisk. I think fdisk's default is probably wrong in this case. Certainly if you create a slice and then decide to mkfs.ext2 on it, your disklabel is gone if you don't make the start offset a bit higher. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-probe for nested BSD partition on Linux (was: [PATCH 1/1] add --partuuid to probe)
On Tue, Feb 28, 2017 at 08:13:53PM +0300, Andrei Borzenkov wrote: > Sorry? vda7 is 256M, how can you suddenly pretend it is 2G? > > 10:~ # fdisk -l /dev/vda > Disk /dev/vda: 5 GiB, 5368709120 bytes, 10485760 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: dos > Disk identifier: 0x882b18da > > Device Boot Start End Sectors Size Id Type > /dev/vda1 2048 2099199 20971521G 83 Linux > /dev/vda2 2099200 6293503 41943042G a6 OpenBSD > /dev/vda3 6293504 10485759 41922562G 5 Extended > /dev/vda5 6295552 6819839 524288 256M 83 Linux > /dev/vda6 6821888 7346175 524288 256M 83 Linux > 10:~ # fdisk -l /dev/vda2 > Disk /dev/vda2: 2 GiB, 2147483648 bytes, 4194304 sectors > Geometry: 16 heads, 63 sectors/track, 10402 cylinders > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: bsd > > Slice Start End Sectors Size Type Fsize Bsize Cpg > a 2099200 2623488 524289 256M boot 0 0 0 > b 2099200 2623488 524289 256M unused 0 0 0 > c 2099200 6293503 41943042G unused 0 0 0 > d 0 10485215 104852165G unused 0 0 0 > > Partition table entries are not in disk order. Well that does look mostly sane for an ancient BSD version. Slice a is the rootfs for BSD Slice b should traditionally be swap, but appears to be unused here, and for some reason uses the same part of the disk as slice a, which does look odd. Maybe since the type is unknown, it doesn't matter. Slice c is the whole partition containing the slices (vda2) Slice d is the whole disk (vda), which apparently hasn't been used in BSD for a couple of decades now, if wikipedia can be trusted. So if linux only bothers to count the partition with a type that isn't unused, then it probably makes sense. That appears to be what the partition parsing code does. The start being the same as the start of vda2 does seem odd given it appears that you are supposed to leave space at the start (1 track recommended, or 64 sectors), and it appears the disklabel is at sector 1 (0 being the first), so it doesn't seem like having your filesystem start there would be safe unless the filesystem has reserved space at the start for such things. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: explicit refresh?
On Wed, Feb 08, 2017 at 09:29:36AM +0100, Laszlo Ersek wrote: > Hi, > > this is a dumb question and it's not appropriate for a development > mailing list, but I couldn't find "grub-user" or "grub-users", so I'll > ask here anyway... > > My laptop is connected to my workstation via USB-serial (USB for the > laptop, serial for the workstation). Sometimes, by the time the laptop > comes up and starts "screen", for viewing the serial output from the > workstation, the workstation is already displaying the grub menu. > Occasionally in this case, I can't see anything at all, there's no grub > countdown, the cursor up/down keys do nothing (they certainly don't > refresh the screen), but if I blindly press Enter, then the selected > kernel entry is booted okay (and that kernel does produce serial output, > and takes the LUKS password from serial fine as well). > > So, Q1: what could cause the loss of serial output from grub when I > connect to it "too late"? > > Q2: when that happens, can I press something like C-r to force a full > serial / screen refresh? > > I know that USB-serial adaptors are generally wacky, but this is a > Prolific PL2303 adaptor which is (to my knowlede) usually considered > reliable. Plus, my laptop has no physical RS/232 port (shame on you, all > laptop vendors of today!), so this is the best I can do. Actually I would say PL2303 are usually considered quite unreliable. Doesn't help that there are lots of fakes on the market that are even worse. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Add fwconfig command
On Tue, Jan 24, 2017 at 07:18:13PM +0100, Thomas Schmitt wrote: > One should emphasize that the FSF when designing new license versions only > considers compatibility to older FSF licenses if they bear the "or later" > clause. > > E.g. it is not possible to combine GPL version 2 software with LGPL version 3 > software if the GPL does not offer the opportunity to get upgraded to GPL > version 3. That's because LGPL 3 forbids some patent evilness whereas GPL 2 > forbids to add forbiddances. > https://www.gnu.org/licenses/license-list.en.html#LGPLv3 > > According to Richard Stallman, the design flaw is not in LGPL 3 but in > issueing > GPL 2 without "or later" clause. (Company lawyers may well contradict.) Yes the nice GPL feature where you can't add anything to it, unless you are the FSF, then you can. Some people don't like handing future control to someone else like that. Most users of the GPL seem OK with it though. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: sgi O2 supported?
On Sat, Jan 07, 2017 at 09:11:54PM +0100, Waldemar Brodkorb wrote: > Grub is cross-compiled for platform arc. > Isn't arc the right choice? I thought ARC/ARCS is the prom > inside the SGI machine. > > http://cgit.openadk.org/cgi/cgit/openadk.git/tree/package/grub/Makefile Well mips-arc should be right, mipsel-arc would not be. I have not tried grub (or linux) on my SGI since it has an unsupported video board, so IRIX is all I get to play with on it. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: "Illegal Instruction" error in grub_script_comments
On Wed, Oct 19, 2016 at 11:32:08AM -0400, Matthew Whitehead wrote: > Lennart, > I think I found the problem. I don't know what kernel.img does, but I'm > guessing it is an essential part of grub2, loading after the 1st and 2nd > stage loaders? I disassembled the binary using 'objdump -D -b binary -m i386 > kernel.img' and found several cases both of rdtsc and cpuid. Both of these > instructions do not exist on first generation 80486 cpus. Here they are, and > I've attached the full disassembly output. > > 53a0: 85 c0 test %eax,%eax > 53a2: 74 6f je 0x5413 > 53a4: b8 01 00 00 00 mov$0x1,%eax > 53a9: 0f a2 cpuid > 53ab: 80 e2 10and$0x10,%dl > 53ae: 74 63 je 0x5413 > 53b0: 31 c0 xor%eax,%eax > 53b2: 0f a2 cpuid > 53b4: 0f 31 rdtsc > 53b6: a3 48 67 01 00 mov%eax,0x16748 > 53bb: 89 15 4c 67 01 00 mov%edx,0x1674c > 53c1: 31 c0 xor%eax,%eax > 53c3: 0f a2 cpuid > 53c5: 0f 31 rdtsc > 53c7: 89 c6 mov%eax,%esi > 53c9: b8 ff ff 00 00 mov$0x,%eax > 53ce: 89 d7 mov%edx,%edi > 53d0: e8 83 00 00 00 call 0x5458 > 53d5: 31 c0 xor%eax,%eax > 53d7: 0f a2 cpuid > 53d9: 0f 31 rdtsc > 53db: 89 45 e0mov%eax,-0x20(%ebp) > 53de: 8b 4d e0mov-0x20(%ebp),%ecx > ... > 5439: 31 c0 xor%eax,%eax > 543b: 0f a2 cpuid > 543d: 0f 31 rdtsc > 543f: 8b 0d 50 67 01 00 mov0x16750,%ecx > 5445: 6a 00 push $0x0 > 5447: e8 8f dc ff ff call 0x30db > > How can we adjust the makefiles to include -march=i486 or something similar? I don't think that's likely to make a difference. The cpuid and rdtsc instructions are supposed to be protected by a check for whether cpuid is a valid instruction, so it should never try to run them unless that isn't working. Would be interesting to see the failing test run under gdb in case it can point to what instruction is illegal and on what line. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: "Illegal Instruction" error in grub_script_comments
On Mon, Oct 17, 2016 at 02:34:16PM -0400, tedheadster wrote: > I am building the older grub2-1.98+20100804 under the similarly old Debian > 'squeeze' distribution. However, I bet the error persists with newer > version. This is because I am building it on a true Intel 80486 and I don't > thing the compiler is building for the correct architecture. Here is the > output: > > ./config.status --file=-:tests/grub_script_dollar.in | sed -e > 's,@pkglib_DATA@,efiemu32.o efiemu64.o moddep.lst command.lst fs.lst > partmap.lst parttool.lst handler.lst vi\ > deo.lst crypto.lst terminal.lst,g' > grub_script_dollar > chmod +x grub_script_dollar > > ./config.status --file=-:tests/grub_script_comments.in | sed -e > 's,@pkglib_DATA@,efiemu32.o efiemu64.o moddep.lst command.lst fs.lst > partmap.lst parttool.lst handler.lst \ > video.lst crypto.lst terminal.lst,g' > grub_script_comments > chmod +x grub_script_comments > > Illegal instruction > > ./grub_script_echo1: GRUB and BASH outputs did not match (see diff -u > /tmp/tmp.tP7l8uR3SD /tmp/tmp.wYCFOK2zor) > make[2]: *** [check] Error 1 > make[2]: Leaving directory `/root/grub2-1.98+20100804/build/grub-pc' > dh_auto_test: make -j1 check returned exit code 2 > make[1]: *** [build/stamps/build-grub-pc] Error 29 > make[1]: Leaving directory `/root/grub2-1.98+20100804' > make: *** [build] Error 2 > > Is there a file I can modify to pass in -march=i486 or something similar? Well I tried installing squeeze in a qemu VM emulating a 486. It worked fine there. But qemu is emulating a 486DX4, which supports CPUID. If your 486 is older if probably does not have the CPUID instruction. The place grub is blowing up appears to be the test suite which uses qemu-system-i386. So my suspicion is that it is actually qemu crashing, not grub, and that your best bet would be to just not run the test suite. The compile almost certainly worked fine. Simply uninstalling qemu whould make it not try to run the test based on the debian/rules file, although debian/control considers qemu a built dependancy. So you probably have to use -d with dpkg-builcpackage to make it ignore the missing dependancy. Or edit debian/rules and simply set the with_check variable to no. I can't find anything that says if qemu should run on an older 486, probably since those usually didn't have enough memory to make that worth the bother and they are too slow. Maybe no one had ever tried it before. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub2 please help
On Sun, Jul 24, 2016 at 07:38:53PM +0200, slavi...@seznam.cz wrote: > I am searching and finding info how chainloading whole ISO to using his > original bootloader. As well as Ubuntu ISO, Puppy ISO, Windows install ISO > and similarly. I spent much time and i did not successful and erudite man > from local Ubuntu forum wrote that is impossible. I am unbelieving :-) and > so ask to you as development team. If the software expects to read an ISO, then it expects to talk to some hardware optical drive. Tools like unetbootin makes things work by knowing how each image it supports works, and extracting required boot files and booting them differently than the ISO would (the ISO tends to use el torito boot), and relying on the thing being booted to work without an optical drive (many linux installers support ISO files on USB sticks after all). So since the OS being booted has native drivers for acciding the optical drive to read the ISO it is supposed to be booted from, unless you implement a virtualmachine/hypervisor that fully emulates the hardware of that optical drive, you are not going to make the OS believe there is an optical drive there. Of course at that point you are not installing on the native machine anymore, which probably defeats the purpose. chainloading works for OSs on a hard disk because everything involved expects to be run from a harddrive. There is nothing that has to be emulated. So really, the claim that it can't be done is correct. There exists a USB key you can buy which has a lot of smarts inside it which emulates a full USB optical drive using an ISO selected from the USB key. That works, because it looks exactly like a physical USB optical drive. As long as the OS supports USB, it would work. But pure software, it can't be done. Anything you do, will be bypassed by any real OS (so DOS you can probably get away with tricking with BIOS hooks),. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] [PATCH v3 02/10] xen: reduce number of global variables in xen loader
On Fri, Feb 19, 2016 at 05:59:27AM +0100, Juergen Gross wrote:
> On 18/02/16 18:00, Lennart Sorensen wrote:
> > On Thu, Feb 18, 2016 at 11:34:49AM +0100, Juergen Gross wrote:
> >> On 18/02/16 11:22, Daniel Kiper wrote:
> >>> On Wed, Feb 17, 2016 at 06:19:29PM +0100, Juergen Gross wrote:
> >>>> The loader for xen paravirtualized environment is using lots of global
> >>>> variables. Reduce the number by making them either local or by putting
> >>>> them into a single state structure.
> >>>>
> >>>> Signed-off-by: Juergen Gross
> >>>
> >>> Just two nitpicks but in general...
> >>>
> >>> Reviewed-by: Daniel Kiper
> >>>
> >>>> ---
> >>>> grub-core/loader/i386/xen.c | 259
> >>>> +++-
> >>>> 1 file changed, 138 insertions(+), 121 deletions(-)
> >>>>
> >>>> diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
> >>>> index ff7c553..d5fe168 100644
> >>>> --- a/grub-core/loader/i386/xen.c
> >>>> +++ b/grub-core/loader/i386/xen.c
> >>>> @@ -42,16 +42,20 @@
> >>>>
> >>>> GRUB_MOD_LICENSE ("GPLv3+");
> >>>>
> >>>> -static struct grub_relocator *relocator = NULL;
> >>>> -static grub_uint64_t max_addr;
> >>>> +struct xen_loader_state {
> >>>> + struct grub_relocator *relocator;
> >>>> + struct start_info next_start;
> >>>> + struct grub_xen_file_info xen_inf;
> >>>> + grub_uint64_t max_addr;
> >>>> + struct xen_multiboot_mod_list *module_info_page;
> >>>> + grub_uint64_t modules_target_start;
> >>>> + grub_size_t n_modules;
> >>>> + int loaded;
> >>>> +};
> >>>> +
> >>>> +static struct xen_loader_state xen_state;
> >>>> +
> >>>> static grub_dl_t my_mod;
> >>>> -static int loaded = 0;
> >>>> -static struct start_info next_start;
> >>>> -static void *kern_chunk_src;
> >>>> -static struct grub_xen_file_info xen_inf;
> >>>> -static struct xen_multiboot_mod_list *xen_module_info_page;
> >>>> -static grub_uint64_t modules_target_start;
> >>>> -static grub_size_t n_modules;
> >>>>
> >>>> #define PAGE_SIZE 4096
> >>>> #define MAX_MODULES (PAGE_SIZE / sizeof (struct xen_multiboot_mod_list))
> >>>> @@ -225,50 +229,55 @@ grub_xen_boot (void)
> >>>>if (grub_xen_n_allocated_shared_pages)
> >>>> return grub_error (GRUB_ERR_BUG, "active grants");
> >>>>
> >>>> - state.mfn_list = max_addr;
> >>>> - next_start.mfn_list = max_addr + xen_inf.virt_base;
> >>>> - next_start.first_p2m_pfn = max_addr >> PAGE_SHIFT;/* Is this
> >>>> right? */
> >>>> + state.mfn_list = xen_state.max_addr;
> >>>> + xen_state.next_start.mfn_list =
> >>>> +xen_state.max_addr + xen_state.xen_inf.virt_base;
> >>>> + xen_state.next_start.first_p2m_pfn = xen_state.max_addr >> PAGE_SHIFT;
> >>>>pgtsize = sizeof (grub_xen_mfn_t) *
> >>>> grub_xen_start_page_addr->nr_pages;
> >>>> - err = grub_relocator_alloc_chunk_addr (relocator, &ch, max_addr,
> >>>> pgtsize);
> >>>> - next_start.nr_p2m_frames = (pgtsize + PAGE_SIZE - 1) >> PAGE_SHIFT;
> >>>> + err = grub_relocator_alloc_chunk_addr (xen_state.relocator, &ch,
> >>>> + xen_state.max_addr, pgtsize);
> >>>> + xen_state.next_start.nr_p2m_frames = (pgtsize + PAGE_SIZE - 1) >>
> >>>> PAGE_SHIFT;
> >>>>if (err)
> >>>> return err;
> >>>>new_mfn_list = get_virtual_current_address (ch);
> >>>>grub_memcpy (new_mfn_list,
> >>>> (void *) grub_xen_start_page_addr->mfn_list, pgtsize);
> >>>> - max_addr = ALIGN_UP (max_addr + pgtsize, PAGE_SIZE);
> >>>> + xen_state.max_addr = ALIGN_UP (xen_state.max_addr + pgtsize,
> >>>> PAGE_SIZE);
> >>>>
> >>>> - err = grub_relocator_alloc_chunk_addr (relocator, &ch,
> >>>> - max_addr, sizeof (n
Re: [PATCH v3 02/10] xen: reduce number of global variables in xen loader
On Thu, Feb 18, 2016 at 11:34:49AM +0100, Juergen Gross wrote:
> On 18/02/16 11:22, Daniel Kiper wrote:
> > On Wed, Feb 17, 2016 at 06:19:29PM +0100, Juergen Gross wrote:
> >> The loader for xen paravirtualized environment is using lots of global
> >> variables. Reduce the number by making them either local or by putting
> >> them into a single state structure.
> >>
> >> Signed-off-by: Juergen Gross
> >
> > Just two nitpicks but in general...
> >
> > Reviewed-by: Daniel Kiper
> >
> >> ---
> >> grub-core/loader/i386/xen.c | 259
> >> +++-
> >> 1 file changed, 138 insertions(+), 121 deletions(-)
> >>
> >> diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
> >> index ff7c553..d5fe168 100644
> >> --- a/grub-core/loader/i386/xen.c
> >> +++ b/grub-core/loader/i386/xen.c
> >> @@ -42,16 +42,20 @@
> >>
> >> GRUB_MOD_LICENSE ("GPLv3+");
> >>
> >> -static struct grub_relocator *relocator = NULL;
> >> -static grub_uint64_t max_addr;
> >> +struct xen_loader_state {
> >> + struct grub_relocator *relocator;
> >> + struct start_info next_start;
> >> + struct grub_xen_file_info xen_inf;
> >> + grub_uint64_t max_addr;
> >> + struct xen_multiboot_mod_list *module_info_page;
> >> + grub_uint64_t modules_target_start;
> >> + grub_size_t n_modules;
> >> + int loaded;
> >> +};
> >> +
> >> +static struct xen_loader_state xen_state;
> >> +
> >> static grub_dl_t my_mod;
> >> -static int loaded = 0;
> >> -static struct start_info next_start;
> >> -static void *kern_chunk_src;
> >> -static struct grub_xen_file_info xen_inf;
> >> -static struct xen_multiboot_mod_list *xen_module_info_page;
> >> -static grub_uint64_t modules_target_start;
> >> -static grub_size_t n_modules;
> >>
> >> #define PAGE_SIZE 4096
> >> #define MAX_MODULES (PAGE_SIZE / sizeof (struct xen_multiboot_mod_list))
> >> @@ -225,50 +229,55 @@ grub_xen_boot (void)
> >>if (grub_xen_n_allocated_shared_pages)
> >> return grub_error (GRUB_ERR_BUG, "active grants");
> >>
> >> - state.mfn_list = max_addr;
> >> - next_start.mfn_list = max_addr + xen_inf.virt_base;
> >> - next_start.first_p2m_pfn = max_addr >> PAGE_SHIFT; /* Is this
> >> right? */
> >> + state.mfn_list = xen_state.max_addr;
> >> + xen_state.next_start.mfn_list =
> >> +xen_state.max_addr + xen_state.xen_inf.virt_base;
> >> + xen_state.next_start.first_p2m_pfn = xen_state.max_addr >> PAGE_SHIFT;
> >>pgtsize = sizeof (grub_xen_mfn_t) * grub_xen_start_page_addr->nr_pages;
> >> - err = grub_relocator_alloc_chunk_addr (relocator, &ch, max_addr,
> >> pgtsize);
> >> - next_start.nr_p2m_frames = (pgtsize + PAGE_SIZE - 1) >> PAGE_SHIFT;
> >> + err = grub_relocator_alloc_chunk_addr (xen_state.relocator, &ch,
> >> + xen_state.max_addr, pgtsize);
> >> + xen_state.next_start.nr_p2m_frames = (pgtsize + PAGE_SIZE - 1) >>
> >> PAGE_SHIFT;
> >>if (err)
> >> return err;
> >>new_mfn_list = get_virtual_current_address (ch);
> >>grub_memcpy (new_mfn_list,
> >> (void *) grub_xen_start_page_addr->mfn_list, pgtsize);
> >> - max_addr = ALIGN_UP (max_addr + pgtsize, PAGE_SIZE);
> >> + xen_state.max_addr = ALIGN_UP (xen_state.max_addr + pgtsize, PAGE_SIZE);
> >>
> >> - err = grub_relocator_alloc_chunk_addr (relocator, &ch,
> >> - max_addr, sizeof (next_start));
> >> + err = grub_relocator_alloc_chunk_addr (xen_state.relocator, &ch,
> >> + xen_state.max_addr,
> >> + sizeof (xen_state.next_start));
> >>if (err)
> >> return err;
> >> - state.start_info = max_addr + xen_inf.virt_base;
> >> + state.start_info = xen_state.max_addr + xen_state.xen_inf.virt_base;
> >>nst = get_virtual_current_address (ch);
> >> - max_addr = ALIGN_UP (max_addr + sizeof (next_start), PAGE_SIZE);
> >> + xen_state.max_addr =
> >> +ALIGN_UP (xen_state.max_addr + sizeof (xen_state.next_start),
> >> PAGE_SIZE);
> >>
> >> - next_start.nr_pages = grub_xen_start_page_addr->nr_pages;
> >> - grub_memcpy (next_start.magic, grub_xen_start_page_addr->magic,
> >> - sizeof (next_start.magic));
> >> - next_start.store_mfn = grub_xen_start_page_addr->store_mfn;
> >> - next_start.store_evtchn = grub_xen_start_page_addr->store_evtchn;
> >> - next_start.console.domU = grub_xen_start_page_addr->console.domU;
> >> - next_start.shared_info = grub_xen_start_page_addr->shared_info;
> >> + xen_state.next_start.nr_pages = grub_xen_start_page_addr->nr_pages;
> >> + grub_memcpy (xen_state.next_start.magic,
> >> grub_xen_start_page_addr->magic,
> >> + sizeof (xen_state.next_start.magic));
> >> + xen_state.next_start.store_mfn = grub_xen_start_page_addr->store_mfn;
> >> + xen_state.next_start.store_evtchn =
> >> grub_xen_start_page_addr->store_evtchn;
> >> + xen_state.next_start.console.domU =
> >> grub_xen_start_page_addr->console.domU;
> >> + xen_state.next_start.sh
Re: Mouse support for just the wheel and left button.
On Thu, Dec 17, 2015 at 01:34:10PM +, John Murphy wrote: > I'm able to scroll through entries on pages in my BIOS using the wheel > (Asus Maximus VII Formula). Not sure if that means anything. That probably doesn't mean anything. The firmware can choose to handle the mouse in any way it wants, but the interface actually provided to the boot loader through EFI is more limited. The UEFI spec mentions x, y and z axis for a pointing device and recommends using z-axis for scrolling, but I don't know if the mouse wheel would be used as a z-axis, or just button 4 and 5 (which uefi doesn't do, only left and right). -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Anonymous commit (empty Author and Committer)
On Sat, Oct 31, 2015 at 08:24:06AM +0300, Andrei Borzenkov wrote: > If we decide to fix this commit it is better done now, while it is the last > one. It is annoying but do you have suggestion how it can be done > differently? Well the only options are: 1) Leave it alone 2) Break the tree of anyone that already pulled. (Posting instructions on how to fix it would at least be nice then). Not sure how many people regularly pull the tree. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Anonymous commit (empty Author and Committer)
On Fri, Oct 30, 2015 at 09:19:19PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 30.10.2015 21:09, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > > On 30.10.2015 21:06, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > >> On 30.10.2015 15:26, Andrei Borzenkov wrote: > >>> See > >>> http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665ac > >>> > >>> > >>> I was not even aware that this is possible. Is there anything on server > >>> side that can prevent it? > >>> > >>> Would be good if commit were amended and force pushed to fix it. > >>> > >> It is a bug in SGit. I'll investigate how it happened > > I don't have non-fast-forward rights. Does someone from savannah-users > have them? Could he just delete this commit? If you do that, then anyone that already did a pull after it went in will have a broken tree. Rather annoying. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub-devel Digest, Vol 140, Issue 25
On Tue, Oct 20, 2015 at 06:42:07AM +0300, Andrei Borzenkov wrote: > Legacy BIOS is expected to do it as well. It provides the device number it booted from? Hmm, yeah I see it is stored in the DL register. > "BIOS" is often colloquially used for "firmware of my system". True, but it isn't, and being a mailing list for a bootloader where the difference is very important, it is not a good mistake to make. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub-devel Digest, Vol 140, Issue 25
On Mon, Oct 19, 2015 at 07:55:23PM +0300, Andrei Borzenkov wrote: > GRUB reads grub.cfg either from the device BIOS had booted from (sans > serious BIOS bugs) or from device where UUID of /boot/grub is found. At > least if this GRUB was installed by grub-install. So order of devices in > BIOS is irrelevant. > > I asked him to explain how GRUB was installed on both devices but he never > replied ... besides IIRC original question of about EFI, not BIOS. EFI would make a difference. I would very much expect EFI to tell the bootloader which device it was started from. After all EFI isn't BIOS, so if someone says BIOS I am going to assume that is what they mean. :) -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub-devel Digest, Vol 140, Issue 25
On Mon, Oct 19, 2015 at 09:05:47AM +, Stuart Weaver wrote: > Hi Manoel, > > Many thanks for your detailed answer and quick response! I've looked into > using this but I don't think it will stop the root problem of GRUB loading > the wrong grub.cfg file. Is there a way of using the 'search' command before > GRUB has loaded a grub.cfg and therefore use the same command to look for the > grub.cfg? > > To reiterate, > > 1. If both eMMC and USB are connected and from the BIOS I choose to boot into > the USB, I would expect the BIOS to load GRUB and GRUB to load the grub.cfg > on the USB... And that is exactly what happens. However... > > 2. If both eMMC and USB are connected and from the BIOS I choose to boot into > the eMMC I would expect the BIOS to load GRUB and GRUB to load the grub.cfg > on the eMMC... Unfortunately the BIOS loads GRUB on the eMMC (correct) but > GRUB loads the grub.cfg from the USB, not the eMMC. > > I would like to keep the two systems as separate as possible and let the BIOS > choose which system to boot. Is this possible? If the BIOS provides a list of disks to GRUB that has the USB as the first device and eMMC as the second, there isn't much grub can do about it. In my laptop I have two SATA devices, and the BIOS always provides them to GRUB in the order of the ports, even though I have it set to boot from the second one. It's a bit annoying, but at least it is consistent about it. Would be nice if yours put the fixed devices before the removable devices, but some systems are stupid. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: i386-pc target and no block lists
On Fri, Aug 14, 2015 at 08:22:28PM +0300, Andrei Borzenkov wrote: > > > On 14.08.2015 19:44, Lennart Sorensen wrote: > > > >Certainly Debian by default installs grub to the MBR (aka the disk), > >not to the partition. I would be surprised if any other distribution > >does it differently. > > > > openSUSE suggests partition by default. It makes sense for dual boot with > Windows as it allows easy switch between them (Windows gets rather upset > during updates installation when boot configuration changes). I have not had an issue with that in years. 10 years ago I would agree and I did use the partition back then, but I even managed to upgrade from windows 7 to windows 10 on my dual boot system and windows didn't even blink and left grub in charge much to my surprise. So if openSUSE suggest the partition, then they are very out of date and making a bad recomendation. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: i386-pc target and no block lists
On Fri, Aug 14, 2015 at 02:29:23PM +0200, Olaf Hering wrote: > Last night I finally got around to update my grub1 chainloader to grub2. > During install of the bootloader I ran into this issue: > > grub-install: warning: Embedding is not possible. GRUB can only be installed > in this setup by using blocklists. However, blocklists are UNRELIABLE and > their use is discouraged.. > > I think everyone just gets around this message by always passing > --do-it-anyway to grub2-install. At least the distro I'm using does > this. > > But since the system I just reinstalled is still fresh I wonder what > needs to be done to avoid the --do-it-anyway option? Right now I can not > imagine how the partition/filesystem layout has to look like. > > Olaf > > > esprimo:~ # parted -s /dev/disk/by-id/wwn-0x50014ee2590ff8f9 unit s print > odel: ATA WDC WD6400BEVT-2 (scsi) > Disk /dev/sda: 1250263728s > Sector size (logical/physical): 512B/512B > Partition Table: msdos > > Number Start End Size Type File system Flags > 1 2048s 4196351s 4194304s primary ext3boot, > type=83 > 2 4196352s6293503s 2097152s primary ext2 > type=83 > 3 6293504s23070719s16777216sprimary linux-swap(v1) > type=82 > 4 23070720s 1250263727s 1227193008s extended lba, > type=0f > 5 23072768s 53151s 88080384slogical ext4 > type=83 > 6 55200s 199235583s 88080384slogical fat32 > type=83 > 7 199237632s 287318015s 88080384slogical ext4 > type=83 > 8 287320064s 375400447s 88080384slogical ext3 > type=83 > 9 375402496s 463482879s 88080384slogical ext4 > type=83 > 10 463484928s 1250263727s 786778800s logical xfs > type=83 > > > esprimo:~ # /usr/lib64/grub2-chainloader/sbin/grub-install --verbose > /dev/disk/by-id/wwn-0x50014ee2590ff8f9-part1 So instead of installing grub to a partition, install it to the disk, which will place it after the partition table in the almost 2048 sectors before the first partition. Certainly Debian by default installs grub to the MBR (aka the disk), not to the partition. I would be surprised if any other distribution does it differently. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] configure.ac: support -fdiagnostics-color=always
On Mon, Apr 06, 2015 at 09:24:26PM +0300, Andrei Borzenkov wrote: > В Mon, 6 Apr 2015 19:33:30 +0200 > Michael Zimmermann пишет: > > > --- > > configure.ac | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/configure.ac b/configure.ac > > index 891c14f..1f8cb2c 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -1046,6 +1046,15 @@ if test "x$grub_cv_target_cc_qn" = xyes; then > >TARGET_CFLAGS="$TARGET_CFLAGS -Qn" > > fi > > > > +AC_CACHE_CHECK([whether option -fdiagnostics-color=always works], > > grub_cv_target_cc_fdiagnostics_color, [ > > + CFLAGS="$TARGET_CFLAGS -fdiagnostics-color=always -Werror" > > + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])], > > + [grub_cv_target_cc_fdiagnostics_color=yes], > > + [grub_cv_target_cc_fdiagnostics_color=no])]) > > +if test "x$grub_cv_target_cc_fdiagnostics_color" = xyes; then > > + TARGET_CFLAGS="$TARGET_CFLAGS -fdiagnostics-color=always" > > +fi > > + > > # > > # Compiler features. > > # > > I think it should be left to distribution/user. You can always run > > ./configure TARGET_CFLAGS="-Os -fdiagnostic-color=always" Yes please. Having your text build logs corrupted by colour codes is not helpful in any way. I didn't even know that awful option existed. Now if it had a =auto like ls and grep and such have where if the output is a terminal, it does colour, but otherwise it does not, well then at least it doesn't bother people logging the output. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
On Fri, Mar 27, 2015 at 02:19:44PM +, Jan Beulich wrote: > >>> On 27.03.15 at 15:09, wrote: > > On Fri, Mar 27, 2015 at 02:04:22PM +, Jan Beulich wrote: > >> >>> On 27.03.15 at 14:53, wrote: > >> > On 27/03/15 13:43, Jan Beulich wrote: > >> > On 27.03.15 at 14:32, wrote: > >> >>> On Fri, Feb 20, 2015 at 04:17:35PM +, Jan Beulich wrote: > >> >>> On 30.01.15 at 18:54, wrote: > >> > We need more fine grained knowledge about EFI environment and check > >> > for EFI platform and EFI loader separately to properly support > >> > multiboot2 protocol. > >> ... because of ... (i.e. I can't see from the description what the > >> separation is good for). Looking at the comments you placed > >> aside the variables doesn't help me either. > >> > >> > In general Xen loaded by this protocol uses > >> > memory mappings and loaded modules in simliar way to Xen loaded > >> > by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform > >> > and efi_loader. > >> And if I'm guessing things right, then introducing efi_loader but > >> leaving efi_enabled alone (only converting where needed) would > >> >>> efi_enabled is not fortunate name for new usage. Currently it means > >> >>> that Xen binary have or does not have EFI support build in. However, > >> >>> if we build in multiboot2 protocol into xen.gz then it means that > >> >>> it can ran on legacy BIOS or EFI platform. So, I think that we > >> >>> should rename efi_enabled to efi_platform because it will mean > >> >>> that Xen runs on EFI platform or not. > >> >> I disagree here. > >> >> > >> >>> efi_loader is used to differentiate between EFI native loader > >> >>> and multiboot2 protocol. > >> >> And I agree here. > >> > > >> > I suppose "built with efi support" is known because of CONFIG_EFI or > >> > not, and doesn't need a variable. > >> > > >> > However, "booted legacy" vs "booted EFI" does need distinguishing at > >> > runtime, as either is possible. > >> > >> Right, but that's what efi_enabled is supposed to express after > >> the change; there's no need to express "built with EFI support". > >> It just so happens that right now, without all these changes, > >> built-with-EFI-support == runs-on-EFI. > > > > Then how about 'efi_booted' as the variable name. > > Why should we rename a variable that's perfectly suitable for the > purposes we have? Even more so that we don't just want to > express that we were booted from EFI, but also that we're running > in a respective environment, including using tables coming from > EFI and using runtime services (unless specifically disabled). If > anything we could follow Linux and make efi_enabled a bit mask. OK, so it isn't just to tell that you booted from EFI. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
On Fri, Mar 27, 2015 at 02:04:22PM +, Jan Beulich wrote: > >>> On 27.03.15 at 14:53, wrote: > > On 27/03/15 13:43, Jan Beulich wrote: > > On 27.03.15 at 14:32, wrote: > >>> On Fri, Feb 20, 2015 at 04:17:35PM +, Jan Beulich wrote: > >>> On 30.01.15 at 18:54, wrote: > > We need more fine grained knowledge about EFI environment and check > > for EFI platform and EFI loader separately to properly support > > multiboot2 protocol. > ... because of ... (i.e. I can't see from the description what the > separation is good for). Looking at the comments you placed > aside the variables doesn't help me either. > > > In general Xen loaded by this protocol uses > > memory mappings and loaded modules in simliar way to Xen loaded > > by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform > > and efi_loader. > And if I'm guessing things right, then introducing efi_loader but > leaving efi_enabled alone (only converting where needed) would > >>> efi_enabled is not fortunate name for new usage. Currently it means > >>> that Xen binary have or does not have EFI support build in. However, > >>> if we build in multiboot2 protocol into xen.gz then it means that > >>> it can ran on legacy BIOS or EFI platform. So, I think that we > >>> should rename efi_enabled to efi_platform because it will mean > >>> that Xen runs on EFI platform or not. > >> I disagree here. > >> > >>> efi_loader is used to differentiate between EFI native loader > >>> and multiboot2 protocol. > >> And I agree here. > > > > I suppose "built with efi support" is known because of CONFIG_EFI or > > not, and doesn't need a variable. > > > > However, "booted legacy" vs "booted EFI" does need distinguishing at > > runtime, as either is possible. > > Right, but that's what efi_enabled is supposed to express after > the change; there's no need to express "built with EFI support". > It just so happens that right now, without all these changes, > built-with-EFI-support == runs-on-EFI. Then how about 'efi_booted' as the variable name. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/5] multiboot2: Fix information request tag size calculation
On Fri, Jan 30, 2015 at 01:52:09PM -0700, Ben Hildred wrote:
> Why do you want the size of a pointer instead of the size of the structure?
Isn't *request_tag the dereferenced pointer, and hence is the size of
the structure, where as before it was the size of a pointer?
--
Len Sorensen
> On Fri, Jan 30, 2015 at 10:59 AM, Daniel Kiper
> wrote:
>
> > Signed-off-by: Daniel Kiper
> > ---
> > grub-core/loader/multiboot_mbi2.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/grub-core/loader/multiboot_mbi2.c
> > b/grub-core/loader/multiboot_mbi2.c
> > index 6f74aee..d7c19bc 100644
> > --- a/grub-core/loader/multiboot_mbi2.c
> > +++ b/grub-core/loader/multiboot_mbi2.c
> > @@ -150,7 +150,7 @@ grub_multiboot_load (grub_file_t file, const char
> > *filename)
> > = (struct multiboot_header_tag_information_request *) tag;
> > if (request_tag->flags & MULTIBOOT_HEADER_TAG_OPTIONAL)
> > break;
> > - for (i = 0; i < (request_tag->size - sizeof (request_tag))
> > + for (i = 0; i < (request_tag->size - sizeof (*request_tag))
> > / sizeof (request_tag->requests[0]); i++)
> > switch (request_tag->requests[i])
> > {
> > --
> > 1.7.10.4
> >
> >
> > ___
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
>
>
>
> --
> --
> Ben Hildred
> Automation Support Services
> 303 815 6721
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: IDE compilation
On Tue, Nov 18, 2014 at 04:06:04PM +0100, Michael Heng wrote: > > > Hello, > > > > I want to know what a IDE do you all use? I just have download the grub > 2 project. Can you advise me how to setting up eclipse to import as a > project, how can I debug it? > > > > Kindly regards > > > > > > Michael > > HTML mail to mailing lists is rude. And personally I hate all IDEs. They are all awful and get in the way of getting work done. And debuging a boot loader is hard, and if you did want to use a debugger with it, would probably require a hardware debugger (using jtag or similar). Or you just add print statements to find out what the code is doing and where it is. Surprisingly effective. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Best practices for bisecting GRUB and cherry-picking?
On Thu, Nov 06, 2014 at 08:01:14AM +0100, Paul Menzel wrote: > Dear GRUB folks, > > > trying to a bisect a regression of AHCI on the ASRock E350M1 with > coreboot and GRUB as firmware, `ChangeLog` poses a problem when > resetting to an older commit and then cherry-picking certain commits to > fix other problems. The problem is that of course conflicts are shown. > > Do you know how to circumvent that to avoid manually resolving the > conflicts? Changelog entries should NEVER be part of the code commit since it forces your commits to only be able to applied in one order. And the git log should already be your changelog so the changelog serves no purpose other than to make life difficult for people. Same goes for version numbers in source files. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Has anyone integrate openSSL into GRUB?
On Sat, Aug 30, 2014 at 10:50:51PM -0700, Seth Goldberg wrote: > Licenses can always be modified with exceptions. I believe he was > mainly asking about from a technical perspective, though. Well given grub is a gnu project, I highly doubt any exception would be considered. So no, licenses can not always be modified (certainly the linux kernel license isn't going to change). Sometimes it is worth considering if the result would ever be useable, before even bothering to look at the technical bits. If there is a need for any ssl like stuff in grub I would imagine gnutls would be the obvious thing to look at instead. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Has anyone integrate openSSL into GRUB?
On Fri, Aug 29, 2014 at 03:55:43PM -0700, Mat Troi wrote: > Just wondering if anyone has tried to integrate openSSL into GRUB? That would be a license conflict disaster. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to exit from linux kernel and return to then grub?
On Sun, May 18, 2014 at 01:33:15PM +0800, Z C wrote: > If I boot into a linux kernel using a grub command like "linux /vmlinuz; > inirtd /initrd; boot", how do I shutdown linux itself (but do not power off > or reboot the computer hardware) and return back to the grub directly? > > What I meant is something equivalent to the "exit" command in most shells: > If you are within one shell and you enter another shell, then if you want > to quit the second shell and return back to the first shell, just simply > type exit. All env variables and commands you previous typed in the first > shell are completely intact. > > Suppose I am now in the grub shell, and then I boot into a tiny linux > kernel, say, a busybox shell, then what can I do to exit the second shell > (i.e. busybox shell) and return to the first shell (i.e. grub shell)? Of > course I can enter the grub shell again by simply rebooting the hardware, > but this is not what I want. Once linux boots, it does not preserve the boot loader in memory (whyever would it do that?) If you want to invent a way to load grub using kexec so you can switch back to grub fropm a running linux system, well have fun, but why bother? Where is the use? It is so hard to deal with what the state of all the hardware is without doing a reset. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Allow separate boot block and core.img location?
On Thu, Dec 19, 2013 at 05:28:16AM -0500, joe fresh wrote: > Isn't this as simple as: > > grub-install /dev/sda > dd if=/dev/sda of=/dev/sda1 bs=512 count=1 > followed by restoring DOS MBR... ? sda1 might not like having it's first sector overwritten. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to pick a kernel to boot ?
On Thu, Oct 24, 2013 at 04:46:19PM +0200, Lukáš Czerner wrote: > Hi, > > I have a simple question about grub2 which I can not find satisfying > answer to. > > What is a proper way to pick a kernel to boot from in case I have > multiple kernels installed ? Note that picking the right kernel from > the menu is not an option I do not always have access to the > console. > > With grub legacy, this was easy. Simply edit > > /boot/grub/menu.lst > > and pick the right number. All the information I need are in that > file. > > So what is a recommended way to do this with grub2 ? Same thing in /boot/grub/grub.cfg. There is default with a number. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub mishandles corrupt/missing primary GPT
On Wed, Oct 23, 2013 at 09:07:21PM -0600, Chris Murphy wrote: > While technically a violation of the UEFI spec, I think this can be worked > around by considering the disk GPT if the first entry in the MBR is type > 0xEE. I don't know of a hybrid MBR implementation where an entry other than > the first is 0xEE. Well everyone other than Microsoft seems to understand how useful support for hybrid setups can be and hence support them. > But if there is no 0xEE entry at all, this is identical to a formerly GPT > disk repartitioned as MBR by a utility that doesn't know anything about GPT, > and thus doesn't erase the stale GPT data - and therefore must be treated as > MBR. That is true. That does not mean there must ONLY be a 0xEE entry. > So perhaps this test is difficult because it's GPT on BIOS, with a limited > space BIOS boot partition. However, I think on UEFI computers this should > still work with one valid GPT, rather than not boot at all. There's a lot > more space for this there. Certainly if using the BIOS boot partition, there really isn't much of a space excuse anymore, unless you run into limitations on how much ram you can use in early boot. > Both primary and backup GPTs are preserved in this case since the primary is > in LBA 1 and 2, and only LBA 0 is overwritten with the new MBR. > > UEFI spec says if the MBR signature of 0xaa55 is intact, and there isn't an > 0xEE entry, and the partition entries are rational (physically on disk and > don't overlap), then the two GPTs are considered stale and the disk is MBR. > > The primary header contains the location of the backup GPT. If the header is > sufficiently corrupt, and the backup GPT can't be located, then that's the > same as an invalid backup GPT, and in that case fail. > > My point is we shouldn't fail when there is a valid locatable backup GPT. The > whole point of having a second GPT is obviated with the current behavior. Sometimes backups are designed in and never used. I don't recall ever seeing any indication Microsoft ever used the second copy of the FAT for anything other than filesystem repair tools. > I don't think we can work around this kind of hardware vendor sabotage. If it > looks like a valid GPT, but is actually stale, if it's used and contains > incorrect information, then boot fails. Better to try than not try at all. > > It's certainly uncommon. A Google search: corrupt "primary gpt" only turns up > 1900 results. But it is possible. > > And this isn't the only mishandling I'm finding, so it's not like GRUB is > unique. In fact just now by changing only a single byte in the primary GPT > table (I changed the E to an F in the BIOS boot partition type UUID), the > kernel suddenly has no idea what disklabel the disk is, and fails to mount > rootfs. So I need to track that down too, but it seems like it knows the > primary GPT table is corrupt, but then fails to use the backup GPT for some > reason. > > An argument against GRUB doing all of this work: maybe the bootloader should > be able to blindly trust the primary GPT table with no validity checks? And > instead rely on (presently non-existent) checks by the underlying OS to fixi > this problem? Something like an fsck_gpt, seeing as nothing else is in a good > position to both check and fix such GPTs other than a partition tool. Perhaps. Certainly simpler. I do wonder how Windows handles booting with a corrupt primary GPT. Would you happen to know? (A quick google search didn't find an answer to the question unfortunately). > The UEFI spec says "Software should ask a user for confirmation before > restoring the primary GPT" and yet it also requires the unspecified software > fix the primary GPT if corrupt. The spec actually uses the word "must". So > per usual, the spec has rather lofty demands. So it must fix it after asking the user for confirmation? -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] grub-install C rewrite
On Thu, Sep 26, 2013 at 08:49:52PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > This is interesting testcase which wasn't brought before. This would > potentially involve creating several core.img or forcing UUID when using > multiple devices. Again, pretty easy in C and hairy in bash due to list > handling. No, one core.img is fine. The boot disk is the boot disk in each case (so on x86 device 0x80). The same core.img gets inserted too all the devices, so that if it happens to be the boot disk, it works. Since the partition is raid1, the same UUID is everywhere. I do not expect booting from a raid5 device to be possible as the boot partition (althoug hperhaps grub is smart enough to read the kernel from an md raid5 device these days). > It's surely sth we can do. grub-install does only following that is > affecting system: > 1) mkdir -p > 2) copy files. We can write exact copy commands > 3) grub-mkimage. We can do the same. > 4) grub-setup. Ditto > 5) Create load.cfg. Ditto. > 6) calling external commands. > We can have 4 levels of verbosity: > 0) quiet, > 1) write to stderr the commands > 2) like 1 but show grub_util_info > 3) additionally show grub_dprintf > > It's also possible to have options --dry-run (doesn't really do the > changes, except, perhaps, "mkdir -p") and --gen-script which would > generate a list of commands which when executed would do exactly as if > grub-install was run. So you can do > grub-install --dry-run --gen-script=/tmp/myinstall ... > > /tmp/myinstall > This has additional advantage of see which commands are really executed > without having to understand the whole command flow. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] grub-install C rewrite
On Thu, Sep 26, 2013 at 03:59:03PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > What kind of changes was it? Could we make them into some (possibly > hidden) options? Well for quite a while the logic was assuming apple powerpc, and it needed rework to make it work on the IBM powerpc systems. To some extent I think grub-install as a script is a great source of info on what steps have to be taken to install grub, so you can do it manually if something isn't working. > windows is low priority and more of a bonus. The problems of handling > anything that looks like a list (e.g. list of devices where / resides on > in case of btrfs) and code becoming hairy to handle those cases is > bigger reason. Sure lists can be a hassle. I didn't check lately, but does grub-install understand a list of devices to install to yet? ie: grub-install /dev/sda /dev/sdb After all if I have software raid, both those devices contain /boot and are valid to boot from. And since on things like IBM powerpc, grub-install likes to update the firmware with the list of boot devices, they do all have to be specified at once or you end up with the wrong list (which so far I have worked around by manually fixing the firmware settings after updating grub, which doesn't happen very often lately). So calling grub-install for each device in turn (as I believe Debian does on x86 if you tell it multiple boot devices), does not actually give the correct result. Of course when grub-install is a script, it is easy to fiddle with it to make it handle such a case. So really my main objection is that it is much harder to debug and fix C code than it is to fix a script calling a bunch of external commands. At the very least a C version of grub-install must have an option to list every command it is attempting to execute externally. Certainly adding 'set -x' to grub-install has often been helpful. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] grub-install C rewrite
On Thu, Sep 26, 2013 at 03:08:54PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Hello, all. Recently I made some order in hostdisk.c and getroot.c > involving splitting in OS-specific parts. > In the same time I added WinAPI version of getroot/hostdisk allowing > grub-probe to work on windows natively > Also on-going is AROS-specific parts. > Windows and AROS are not friendly with bash. > The attempt to make both multiple files of same type work and handling > whitespaces/newlines/... in filenames would result in very ugly code > with loads of evals. > Current code may have subtle assumptions on behaviour of common tools > like sed and on locale (E.g. "[a-z]" doesn't cover u if locale is Estonian). > So to check viability I rewrote grub-install in C. This is mostly proof > of concept with loads of FIXMEs but I could boot i386-pc install made > with it. In many aspects (static variables, some tests, general > structure) it's reminiscent of sh version of grub-install it's based on. > Some functionality is likely to stay OS-specific, e.g. executing > compressors or determining firmware. > > I'd like to know the opinion of other people on possible switchover. If > switched then it'll have to be all grub-install, grub-mkrescue, > grub-mknetdir and grub-mkstandalone. > I'd like to hear from other people. Given the number of times I have had to edit grub-install in the past to get it to work right on a powerpc machine (I think it is now working OK), I would hate to have had that be C code. After all it really is mainly a wrapper around other grub tools. I think windows not having bash is a rather low priority to most people compared to actually be able to work with grub on the platforms where it is pretty much the only choice. So personally, based on my experience, I hate this idea. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: LUKS Encryption and Fingerprint readers?
On Fri, Aug 30, 2013 at 11:10:39AM +0200, j.witvl...@mindef.nl wrote: > -Original Message- > From: grub-devel-bounces+j.witvliet=mindef...@gnu.org > [mailto:grub-devel-bounces+j.witvliet=mindef...@gnu.org] On Behalf Of TJ > Sent: Thursday, August 29, 2013 10:20 PM > To: grub-devel@gnu.org > Subject: Re: LUKS Encryption and Fingerprint readers? > > On 29/08/13 20:13, Glenn Washburn wrote: > > On Thu, 15 Aug 2013 17:51:03 +0100 > > TJ wrote: > > > >> So I'd like to know what support for key-files and/or fingerprint > >> reading is/could be as input for LUKS unlocking? > >> > >> My other thought, to keep things simple, is to encrypt the entire > >> hard drive and install GRUB and the /boot/ files on the removable USB > >> key. More clunky but maybe easier to achieve. > > > > Based on this comment I assume you currently have an unencrypted boot > > area on the harddrive and using an initrd. > > I've been using a classical unencrypted boot-loader and kernel/initrd with > LUKS key-file protected file-systems on the servers and desktops. > > I've recently decided to standardise on a single model laptop, the Dell XPS > m1530, which includes a fingerprint reader. A primary reason for selecting > this model is its 3 mini-PCIe internal slots and > good range of external interfaces, coupled with 8GB RAM, VDPAU-supporting > Nvidia 8600M, 1920x1200 LCD, Blue-ray disc, proper MMC card reader, and > ExpressCard/54. The laptops are easy to strip down and > repair and parts are cheap and easy to come-by. > > The fingerprint reader is quite useful for trivial unlock and sudo > authorisation and that made me think maybe more use could be made of it. The > points about fingerprints being lifted from the keys to > unlock it hadn't occurred to me - that'd be silly so I'm now moving to > whole-disc encryption with the boot-loader, kernel, and initrd on a key-fob > USB. > > I'd still like GRUB to be able to read a key-file rather than a typed > pass-phrase, and have the key-file hidden on a (second) small (1GB) > randomised-data USB flash device (no file-system) so even the > operator can't be sure where to find the bytes that unlock it. > > If we can figure it out we'd like to be able to configure/unlock different > LVM volumes based on which LUKS slot is used to unlock, too, and log the LUKS > attempts from GRUB. > > Tall order I know, but the technology is there - we just have to join it up! > > -Original Message- > > Hi TJ, > > Are you very sure wanting this? > Some time ago i´ve been experimenting with fingerprints, and the result was > not encouraging... > From security point of view no that many problems (besides all well known > general issue´s with fingerprints). > I mean no false positive´s, but the huge amount of false-negatives: nine > times out of ten, I did not recognize correctly. Always glad I could still > use username & pwd. > As I was testing on IBM-Lenovo laptops, I think (hope) that those readers > were of decent quality... > > So unless the quality of the readers has improved drastically last five > years, you better think twice before embarking on such trip... They have improved. The one on my W530 which is about 9 months old works very well. Even swiping on a slight angle is no longer a problem. I would say it only fails to recognize a swipe 1 in 20 times. Given how well it worked I was wondering if perhaps it was just letting everything through, but using fingers I didn't register has never worked any time I have tried, so it does seem they really have gotten better. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 boot freedos kernel.sys
On Fri, Aug 30, 2013 at 10:05:12AM +0300, Beeblebrox wrote: > Len & Vladimir: > > I just sent a repeat of the first message by mistake - please disregard. > > >> You are trying to make it way too complicated. DOS doesn't like > complicated. > > I'm fine with that. I just went about it in that manner because I was not > very sure how to get this done and more or less fumbling around. > > >> I think the most practical thing to do would be to make a bootable USB > key and use that along with the USBASPI.SYS driver to get access to the > rest of the USB key after booting DOS. > > You of course mean by this that I would have to have a dedicated USB drive > just for this task - is that correct? I really don't want to have a USB > dedicated and limited to upgrading of BIOS. > > >>* You can always modify FreeDOS to* >* suit your needs > > * > *Just to confirm: What I am trying to get done is possible then? Not that I > want to make things complicated, I just want to be able to use a > grub2-bootlader USB to multi-boot various tools (including BIOS flash > utility from dos). > * > *Sadly, flashrom does not work on my hardware as yet. Does this give you any ideas: http://ubuntuforums.org/showthread.php?t=1545929 It uses a ramdisk as far as I can tell, rather than USB, but you can find USB drivers for DOS that you could add to give you access to a USB key. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 boot freedos kernel.sys
On Wed, Aug 28, 2013 at 07:21:42PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 28.08.2013 11:04, Beeblebrox wrote: > >chainloader --ebx=0x0180 (hd0,1)/boot/freedos/kernel.sys > The command to load freedos kernel is "freedos". It can load kernel from > any place accessible by GRUB. As to what FreeDOS kernel expects in order > to load the rest you have to consult FreeDOS documenttion or contact > their devs. > FreeDOS requirement may or may not be different from IBM-/MS-DOS > requirements as described by Lennart. You can always modify FreeDOS to > suit your needs: you have full source. That is a good point. :) -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 boot freedos kernel.sys
On Wed, Aug 28, 2013 at 12:04:31PM +0300, Beeblebrox wrote:
> I would like to know if the following is possible:
>
> * USB thumb drive has grub-1.98 on hd(0,1) gpt layout (boot-bios is hd0,2)
> * hd(0,1)/boot/freedos has files
> autoexec.bat, command.com, config.sys, kernel.sys, sys.com
> Un-tarred from freedos FDOEM.144 and copied into folder
> * Boot into USB drive's grub2 boot menu and try to boot freedos by:
> menuentry "DOS kernel" {
>root=UUID=8D40-EC8D
>chainloader --ebx=0x0180 (hd0,1)/boot/freedos/kernel.sys
>boot }
> gives err msg: "wrong signature". Probably expected, since files being
> booted are for a "virtual floppy", but I also tried it with the files from
> ke386f32 .zip as well.
>
> Q: Is what I'm trying to do possible?
> I don't want to boot into a ram-limited 1.44 or 2.88 virtual floppy. My
> purpose for this is to be able to make mobo BIOS-updates (place BIOS
> dosflash.exe + bios.rom files on USB drive, boot into grub2 -> chainload to
> dos, mount thumbdrive in dos to make files visible, run dosflash.exe)
>
> I asked this question on the freedos mail list, but they could not help
> much because of insufficient grub2 expertise. The feasibility of the
> concept is described here:
> http://www.novell.com/coolsolutions/feature/3612.html
> I would appreciate some help on how to get this done, or if someone has
> ideas on how to flash the BIOS using the grub2 menu, that would also work.
> Regards.
I don't see how that describes any such thing. It is perfectly known
how to boot linux kernel and a ramdisk of arbitrary size. linux was
designed to allow exactly that. DOS was NOT designed to have ramdisks
loaded along with the OS. DOS doesn't even have much of a clue about
devices without the BIOS doing all the work unless you add device drivers
to help it.
I think the most practical thing to do would be to make a bootable USB
key and use that along with the USBASPI.SYS driver to get access to the
rest of the USB key after booting DOS. That should work, and I see
no practical difference from what you were proposing in terms of what
it accomplishes. Sure you boot to a virtual floppy but then the virtual
floppy can load the USB driver and mount the rest of the USB drive as
a harddisk to access the BIOS file.
You are trying to make it way too complicated. DOS doesn't like
complicated.
Remember DOS needs access to config.sys and autoexec.bat using primitive
BIOS disk access calls. That is why the BIOS emulates a floppy drive
while booting from USB. DOS has no idea how to access a USB drive
normally. now if you could have the BIOS emulate a harddisk using the
USB key, DOS could boot from that too and use it directly I suspect, but
that would involve the BIOS booting the USB drive directly, not using
grub as far as I know, since the BIOS has to setup the disk emulation
so that the BIOS calls needed by DOS to access the disk are present.
I doubt grub can ask the BIOS to setup such emulation, and grub does
not stick around in memory after loading the OS to provide such access.
--
Len Sorensen
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [grub-devel] loongson-2f mini-pc (fuloong) elf image generation.
On Fri, Jul 12, 2013 at 06:25:58PM +0200, Aleš Nesrsta wrote: > Hi Vladimir, > > - what was the reason of the OHCI problem on Loongson? > (I don't see any details of solution below nor the patch... ?) I thought a lot of those systems use the AMD CS5536 south bridge, which should be perfectly normal OHCI/EHCI USB 2.0 with 4 ports. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Moving from Bazaar (bzr) to git
On Tue, Jun 25, 2013 at 04:57:25AM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > No flame-war messages please. You can voice your support pro or > contra based on convenience for you but please don't transform this > into flame war. I didn't intend to. I was only trying to say I find the interface for both hard to work with. I should have phrased it better. I know some people find git weird. I suppose it depends what you are used to. I sure am happy there exists translations between many of the systems so you can work with something you like locally. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Moving from Bazaar (bzr) to git
On Sat, Jun 22, 2013 at 04:52:04PM -0500, Bruce Dubbs wrote: > Personally, I prefer subversion, but I'm not a GRUB developer. The > choice of version control can be similar emacs/vi or Bourne Shell/C > Shell, so it really should be the choice of the primary developers. > > Using Google for 'git vs subversion' provides a lot of interesting > opinions. I find subversion almost as annoying as bazaar to deal with. It makes it very hard to find what you want to find. Like bazaar, the only way to tolerate subversion is to use a convertor to git format. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: horizontal boot menu
On Fri, May 31, 2013 at 12:32:56PM +0530, kiran ps wrote: > is there any way to make horizontal boot menu I remember someone working on it in the past with some patches suggested, but I don't think they were ever sufficiently done to get accepted. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Where is GRUB development?
On Mon, May 13, 2013 at 12:39:39PM -0600, Chris Murphy wrote: > Slightly different are the syntax changes between versions of GRUB 1.xx that > caused even grubby to puke. The difference in syntax between 0.97 and 2 are > monumental, unless you're a scripting nerd. If you're a regular user, the > whole linux boot loader experience is offensive. It's extraordinarily user > hostile. Certainly the syntax changed as new features were added. Grub 2 can boot a lot more OSs than grub 0.97 could. > Simple is pressing and holding an s key during boot to get single user mode. Nothing prevents the user space from choosing to implement that in init. In fact I have seen some systems have an 'interactive' startup by doing something like that. Single user is simply another mode of user space, and the kernel doesn't know or care about it and neither does the boot loader. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Where is GRUB development?
On Mon, May 13, 2013 at 11:43:50AM -0700, Bruce Korb wrote: > Well, my distro (openSuSE) generates a special entry for "rescue" > mode, too. But it rescues me into run level 5. "init 3" will, > indeed, drop me back to multi-user and "init 1" back to single user, > but without a reboot, various dinkleberries were an interference. (I > forget why -- perhaps a misperception. I'm not at home right now.) Well runlevels and their meanings are a user space issue. 1 is only single user by tradition, it doesn't have to be. Really not something a boot loader can know or care about. > I have learned that in the grub2 menu mode, you can press "e" and all > of a sudden you can edit the command line. It seems my request boils > down to some documentation. In the menu code so when I'm looking at > the menu, there should be something to indicate that I can press "e" > and edit the line to include a "1" at the end of the line. I know > that theoretically every operating system can have command line > operands that are completely different. In practicality, however, > they are 99.99% UNIX derivatives so pressing five keys to get to > single user mode ought not be a big issue: e1 > -- right? Not at home to try…. Hmm, I thought it was right on the screen that e was edit. I guess if you use a graphical menu it might not be there. And of course you ahve to hit control-x to boot your custom entry as far as I remember. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Where is GRUB development?
On Mon, May 13, 2013 at 10:09:41PM +0400, Andrey Borzenkov wrote: > Do you suggest to create extra menu entries for every possible > combination of kernel parameters? Yes. It's not grub's job to know everything about a linux kernel, or bsd kernel or whatever else you might want to pass. Runlevels is a user space thing too, and not even a kernel thing, so even more reason grub knows nothing about it. > Sometimes we may need to change or augment what is in the config during > boot as one off action. Without creating configuration file. Which you can still do. > Let's be fair. > > Editing grub2 menu entry is far more complicated than even editing plain > grub legacy menu entry. And most users have never seen even that - they > know gfxmenu that has input field for extra kernel parameters. So for > 99% of *users* booting into single user was a matter of pressing "1 > ENTER". Most of them are not even aware that menu entries can be edited > (because for them gfxmenu *was* grub). Not really. Editing in grub2 is not that different from grub 0.97 (although it is slightly different). I have never used gfxmenu, so no idea what it looks like. > For them doing anything in grub2 (even as much as forcing system into > single user) is shocking experience. I think you are the one that is being entirely unfair. Debian auto generates a grub.cfg just fine with a rescue option for each kernel detected which does single user mode. It does other options too if you ask it to. Pretty darn simple to use. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Where is GRUB development?
On Mon, May 13, 2013 at 09:24:34AM -0700, Bruce Korb wrote: > I've been Googling around to no particular avail. I have this > _really_ difficult problem. I need to boot into single user mode and > GRUB2 has made it so difficult that I am unable to accomplish that. I > am sure there are reasons for obscuring the obvious in this way, but > such reasons escape me. If anyone here is still doing GRUB2 > development, *please* consider an enhancement to the interface that > will make it obvious and easy to boot into run levels 1 and 3 as well > as 5. Thank you. That's a kernel command line issue, and something every distribution I have ever used took care of automatically by creating extra grub menu entries with the correct arguments. Nothing to do with grub other than grub happens to do what you tell it in the config. So grub has done nothing to make it difficult since it has never been a grub issue. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 3/7] Initial support for U-Boot platforms
On Wed, Apr 03, 2013 at 04:24:51PM +, Leif Lindholm wrote: > Because I am an overtly paranoid person. :) That's not paranoid. That's just inefficient. The length argument has to be based on the target size, NOT the length of the source. If you want to length of the source, that's what plain old strcpy does by definition. I just found some of those in some other code I was cleaning up and wasn't pleased with them there. Just because it says strncpy doesn't mean what you are doing is any safer than strcpy if you do it wrong. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [3/4] [PATCH] start angle (option of circular_progress) is measured in unusual quantities
On Fri, Mar 15, 2013 at 08:52:08PM +0400, Andrey Borzenkov wrote: > В Wed, 13 Mar 2013 14:52:13 +0400 > Vladimir Testov пишет: > > > In current state, start angle is measured in "parrots", where 1 "parrot" = > > 1 / > > 256 of full circle. > > > > With simple patch we can set start angle in degrees (which makes no > > difference > > for the program, but makes configuration to be more user-friendly) > > > > This has compatibility issue and probably cannot be done without > introducing theme file format version. > > What about adding new parameter name instead (although start_angle_angle > looks rather silly)? start_angle_degrees? Could have start_angle_radians too (although it would need floating point to be useful). Could even have start_angle_gradians -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: USB3 3TB HDD boot
On Fri, Mar 15, 2013 at 09:59:22AM -0600, Chris Murphy wrote: > How would it? > > These structures are still predicated on a 512 byte block. The MBR is always > 512 bytes, but on a 4096/4096 4Kn drive, LBA 0 is 4096 bytes. So if I don't > want to see 3584 bytes of useless garbage, I can't set the dd block size to > 4096, or I get extra information. Well if you want to get LBA 1 on a 4096 byte sector device, using dd bs=4096 skip=1 count=1 would get that sector and make it more obvious which sector you are getting (to me at least). So yeah you get extra stuff that way, but it is what is really there after all. If you only wanted 92 bytes you could have used a bs=128 as well and gotten even less junk. > If I want to see just the GPT header, which while only ~92 bytes, by spec it > gets its own sector, there's far less superfluous information using a bs of > 512 bytes than 4096 bytes. True, although the drive has to read 4096 bytes no matter how much you ask for. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: USB3 3TB HDD boot
On Thu, Mar 14, 2013 at 08:56:18PM -0600, Chris Murphy wrote: > Right, for a 4Kn drive, to read LBA 1 and get the GPT header I'd need: > > sudo dd if=/dev/disk3 skip=8 count=1 2>/dev/null | hexdump -C Wouldn't using 'bs=4096' make things simpler and more obvious? -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Best practice for new linux block driver device naming?
On Fri, Mar 08, 2013 at 05:05:33PM -0600, scame...@beardog.cce.hp.com wrote: > We are not expecting to be able to boot from the device in the first > iteration, > so it's not as if we would need support instantly (not that I imagine we could > get it instantly anyway), and it's not clear that it makes sense for such a > high > IOPS device to be used as a boot device in most imaginable use cases anyway, > but > OTOH, we would prefer not to rule out booting from it. > > So, that being said, are there any best practices for naming new block device > nodes? > Or is any scheme like /dev/sop[0-9a-z] about as good/bad as any other? > > And, is it a worthwhile idea to pursue adding some sort of shared device > namespace > for block devices to the kernel (maintaining backwards compatibility of > device node > names would of course be required) so that block devices could have some > shared > namespace as scsi devices do? > > Typically the block devices themselves don't care what the device nodes are > named, > only the userland apps do, though it falls to the block drivers to specify a > device > name via struct gendisk's ->disk_name member being set prior to calling > add_disk(). > > If there were some kernel interface the block driver could use to get a disk > name > assigned from a shared name space, something like > blk_get_new_disk_name(disk->disk_name); > that could hand out device names like b%s, so you'd get all the block devices > which use > this interface having device names like /dev/bda, /dev/bdb, /dev/bdc, > analogous to > /dev/sda, /dev/sdb, etc. -- the specifics here don't matter to me, the above > is just > an idea off the top of my head -- then, we teach grub about this new block > device > namespace *once*, and force all new block drivers to use it. Thereafter, > adding a > block driver to the kernel causes no more grub related pain to grub and distro > developers and users than adding a new scsi hba driver -- i.e. none. > > Would such a thing be worth pursuing? Or is there some good reason such a > thing > doesn't already exist? (Maybe this is more a question for lkml.) Oh it certainly sounds like a topic for lkml. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Best practice for new linux block driver device naming?
On Fri, Mar 08, 2013 at 04:34:28PM -0600, scame...@beardog.cce.hp.com wrote: > I get ~4x the IOPSs with a block driver vs. scsi driver due to contention > for locks in the scsi mid layer (in scsi_request_fn). It's the > difference between the device being worth manufacturing vs. not. Well that starts to qualify as a good reason I suppose. Of course it also makes you wonder if perhaps some work on optimizing that part of the scsi stack is oin order (I have no idea if that's even plausible). > See this thread: http://marc.info/?l=linux-scsi&m=135518042125008&w=2 > > Driver is similar to nvme (also a new block driver), but this one is > for SCSI over PCIe, basically highly parallelized access to very low > latency devices and trying to use the SCSI midlayer kills the IOPS. Some nifty hardware that's for sure. > There were reasons back then for doing that one as a block driver > which are no longer extant (hence the existence of the hpsa driver > which supplanted cciss for new smart array devices.) > > All other things being equal, I would also prefer a scsi driver. > Heck, it's called SCSI over PCIe -- I tried like hell to get it > to perform adequately as a SCSI driver but all other things are > not equal, not even close, the block driver was ~4x as fast. > > So we reluctantly go with a block driver, just like nvme did. Makes sense. Perhaps that does mean having to teach grub about it then. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Best practice for new linux block driver device naming?
On Fri, Mar 08, 2013 at 02:07:18PM -0600, scame...@beardog.cce.hp.com wrote:
> I'm just wondering if there are best pratices for new linux block
> drivers that are adding new devices nodes of which grub is currently
> not cognizant.
>
> E.g. when we added the HP Smart Array cciss driver to the kernel
> many years ago, it had device nodes like /dev/cciss/c*d*, and there's
> code in grub to handle this in util/getroot.c, in
> convert_system_partition_to_system_disk():
>
> /* If this is a CCISS disk. */
> if (strncmp ("cciss/c", p, sizeof ("cciss/c") - 1) == 0)
> {
> /* /dev/cciss/c[0-9]+d[0-9]+(p[0-9]+)? */
> p = strchr (p, 'p');
> if (p)
> {
> *is_part = 1;
> *p = '\0';
> }
>
> return path;
> }
>
> And there is similar code for other weird device names is in there
> as well.
>
> Ideally, I'm hoping there's a way to introduce new devices nodes
> with a new block driver which does not any require grub modifications.
> Looking over the code, it's not clear to me whether or not this is
> possible, and if it is, how to do it, what the constraints may be, etc.
>
> Currently I have a new driver which adds devices like /dev/sop0 with
> partitions like /dev/sop0p1, /dev/sop0p2, etc.
>
> If there is some better way to do this to enable grub to work with
> these devices, it is not yet too late for me to change it.
>
> Or on the other hand, if it turns out that it is not possible to add
> new block devices to linux and have grub support for those devices without
> also modifying grub, then I wonder if it might be worth looking into to
> adding some kind of shared device namespace for block devices to linux, so
> new block drivers could use that and have a common naming system for block
> devices,
> and grub could be modified to support this new common naming system,
> much as scsi hba device drivers share the /dev/sd* namespace for their
> attached
> disks, so it is easy to add new scsi hba drivers to linux and automatically
> have
> grub support for them. It would be nice if it were similarly easy to add new
> block device drivers to linux without also requiring modifications to grub.
> (It also occurs to me that this is such an obvious desire that if it is not
> already supported, perhaps there's a good reason why not, but if that's the
> case, I'm don't know what the reason might be.)
>
> Thoughts?
Well currently, SCSI, SATA, IDE, most well behaved raid controllers,
USB storage, and many others all show up simple as /dev/sd*. You better
have a really good reason to not do so if you make a new controller.
Certainly the IBM serveraid cards I have worked with just present sd*
devices (as well as some sg* devices for the controller and hotswap
backplane and such). I think the CCISS is a sample of a horrible design
as far as the device names in linux are concerned.
By creating a new type of block device you force everyone else to do work
to support it (or choose to ignore your device because no one cares).
By emulating a plain old scsi device interface, everything else just
works, and all the work is done by you in your device driver to pretend
to my just a scsi disk. If you want your device taken seriously,
I don't think you have a choice. Sysadmin's hate things that are
different for no good reason.
--
Len Sorensen
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: USB3 3TB HDD boot
On Mon, Mar 04, 2013 at 08:33:51PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Not necessarily. 3T drives often use msdos, just with 4K sectors which > increases the range of msdos to 16T. Hmm, I suppose that would work. I have never seen one that did that yet, but I don't have that many 3TB drives either. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: USB3 3TB HDD boot
On Mon, Mar 04, 2013 at 08:27:41PM +0400, Bob Lemar wrote: > Thank you for your replies. > > > Yes, it is definitely BIOS problems as it doesn't allow to boot from > external drive directly (via BIOS boot order settings). It doesn't > show this drive at boot menu even after soft reboot. So BIOS > doesn't provide access to GRUB like to any other drives or USB > flashes. > > And I suppose to think that it is not a bug, it is a feature. And > feature of external drive, not a BIOS. Vendors of spinning external > drive try to limit "uptime" of theirs HDD. External HDD could start as > soon as USB is powered but do not want to do it. It only starts when > OS tell it to start up (this commands are magic for me). > > Facts: > > - External drive is logically 4K (not a 512e thing). It is not a problem yet. > > - USB 3 is not a problem yet. The drive doesn't work with USB 2 just > the same way. So it is not "nativeness" BIOS-USB hub communication > problem. > > - BIOS behavior is correct (it power up USB); > > - external drive behavior is correct (it is powered but starts only on > demand and it is sleeping in many cases including PC start); > > - GRUB behavior is correct (it boots from drives that BIOS told him > about; only OS can detect this device as mass storage because it was > designed that way). > > - Ales, you were absolutely right with floppy for booting CD trick > example. While MB, HDD firmwares and bootloader have predictable and > correct behavior some users would like to have bootloader feature > (GRUB command) that wake up external HDDs and re-detect drives. > > Resolution: > > - Boot USB thumb and use kexec to boot external HDD. > I did: (1) clone linux to external drive; (2) correct fstab at > external; (3) boot into internal drive OS; (4) mount external HDD > which became visible; (5) kexec images and boot external drive. // I > am not sure that only external drive files were used at second boot -- > need to do clear experiment with minimal os at internal device or > thumb flash. kboot and petitboot are possible solve this problem. > > - It is good point to create feature request at BugTracker. I wish > GRUB has command to power up external USB HDD and do manual redetect. > But I don't know what is happening technically when OS do it. I guess > I should find out it to be more specific while filling bug. The fact it is 3TB would mean it uses GPT, not old style DOS partition table. Maybe the BIOS doesn't support booting from a GPT partitioned drive. If it had a hybrid partition table, then it might work assuming other things are not also causing problems. After all some bioses only list a drive as bootable if they see a partition marked bootable in a dos style partition table. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB and the risk of block list corruption in extX
On Fri, Feb 08, 2013 at 12:56:52PM -0600, Bruce Dubbs wrote: > You don't need an EFI system to give GRUB enough space. You just > need to partition the drive so the first partition starts at 1MB > instead of sector 63. I think using a GPT partition scheme is quite > preferred over the MSDOS scheme designed 30 years ago. That's true. Does grub-install check the partition table to see how much room there is before placing itself after the MBR? I haven't checked that since I tend to use GPT these days. > I will note that this causes problems for some systems, but I > haven't seen it since I don't do windows. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB and the risk of block list corruption in extX
On Fri, Feb 08, 2013 at 06:17:57PM +0100, Martin Wilck wrote: > In my case, the reason is a multiboot setup based on chainloading the > indiviual installed OS's bootloaders from a central, primary bootloader. > This is easily accomplished by installing the individual OS's > bootloaders in their respective "/" or "/boot" partitions. Linux > distributions have encouraged this kind of setup over several years - > "install boot loader in first sector of root/boot partition" used to be > a prominent option somewhere in the installation process (these > distributions were usually GRUB 0.9x based - GRUB 0.9x developers didn't > seem to have a big issue with stage1_5 being loaded via block lists). > > Recent GRUB2-based distributions like Fedora have removed this option, > and some users are dissatisfied with that. I would like to understand > what the actual risk is. So I'd appreciate examples for the "pretty > serious problems" you mention. grub 2 has a lot more features, is a lot bigger, and might not fit in your embedding area of some filesystems. Of course the block list breaks if the file in the filesystem is modified or moved without updating the block list, which used to break lilo all the time whenever one forgot to run the lilo command after making a change. Sure grub 0.9x was a bit less fragile than lilo, but block lists for files that could potentially be changed is fragile. Embedding enough of grub in the first track or a boot partition (as EFI systems support, as do a number of non x86 architectures) gives a much more reliable system since it can read anything else it needs using the filesystem and hence doesn't break if files are changed. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: SCO Unix
On Fri, Jan 25, 2013 at 03:06:32PM -0700, Chris Murphy wrote: > Fedora 15 and older, is GRUB 0.9x, and the grub.conf was manually produced > except for the Fedora entries (initially anaconda, and then after that for > kernel updates, grubby). > > Fedora 16 and newer, it's GRUB 2, and anaconda calls grub-mkconfig to produce > the initial grub.cfg, and uses grubby to add entries for kernel updates. > > So actually I don't understand the question because Fedora itself would not > ever have detected another OS. Either it's manually added to grub.conf in the > old days, or it's autodetected (or not autodetected) by os-prober via > grub-mkconfig on more recent Fedoras. I suspect your theory is even better than mine was. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: SCO Unix
On Fri, Jan 25, 2013 at 04:09:46PM +0100, GervanDijck wrote: > Why does FC18 not detect an installed SCO Unix OS , Windows gives no > problems. > > Can you inform me ? > > Everything with the bootloader goes fine till FC15. With FC16 ,17, > and 18 the problems start. Grub does what it is told in the config. If fedora doesn't put it in the config, then that's fedora's choice. I suspect given no one uses SCI unix anymore, fedora stopped probing for it, or at least stopped testing that it worked. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Multi-boot multiple Windows O/Ses and Linux
On Wed, Jan 16, 2013 at 08:19:37PM -0600, Randy Decker wrote: > With MS support for XP ending 8Apr2014 I am considering upgrading my software > configuration. I > currently multiboot Windows XP and Ubuntu 12.04.1 LTS (GNU/Linux > 3.2.0-35-generic i686) with GRUB > 1.99-21 ubuntu 3.7 updated automatically by ubuntu's update manager. At one > point my hardware > passed MS's test for windows 7 so I believe that is an option. > > I want to retain XP so I don't need to repurchase all the old software that > currently works fine > and because I have hardware that requires the game port interface that MS > chose not to support in > newer software. I thought XP dropped support for the old game port. It's been so long I don't even remember. > I am very happy with Ubuntu and find myself using it by preference when I > can. I'm not sure > where I placed my XP install disk after I mis-applied GRUB and overwrote the > MBR (back when I > think Ubuntu 9.04 was current). I would like to avoid that problem in the > future. Perhaps I > could dd the 440 or 512 bytes of the MBR for insurance just in case. > > My hardware is a generic PC with an AMD Duron and 2 GB of RAM. XP is on a > master IDE drive. A > SATA drive has three primary (MSDOS) partitions containing another XP > "drive", Ubuntu, and > linux-swap. Until recently these 3 partitions resided on the slave IDE > interface but gparted was > kind enough to move them all to a bigger newer SATA drive. The old drive is > now retired. > > I know grub is great at multiple O/Ses but windows is anti-social toward > other O/Ses. My > questions are: > 1 Can grub2 handle both XP and 7 in one configuration along with Linux? > 2 If so, can it still be compatible with Ubuntu's update manager? > 3 How would one approach the reconfiguration? > 4 Will 4 partitions be sufficient? > 5 Will GRUB want a partition? > 6 What would I need to be careful to avoid? > > I would expect to buy 7 to install on the SATA drive. I'm not sure how to > install 7 without > corrupting the MBR for XP. I didn't put the linux and linux-swap partitions > in an extended > partition on the SATA drive as they were on the IDE drive. I hadn't figured > out yet how to create the extended partition in gparted and I still had a > spare. I expect if I needed more than 4 partitions I > could copy the two linux partitions to a USB drive and back to an extended > partition. > > I have enjoyed reading your advice. Thanks for any illumination you can > provide. I copied the To: line, I hope I have it right. I ensured this is > plain Text. The general behaviour of windows is that it insists on booting from the first windows filesystem. Now certainly if you have XP installed and you then install windows 7 and pick a different partition to install to than XP is on, then it should create a windows boot menu with both XP and windows 7 on your C: partition. Installing windows will of course trash grub, so you will have to boot linux from some other method and reinstall grub to fix that afterwards. If you then install linux, then grub should be able to boot the windows boot menu. So you would end up with at boot: grub menu showing linux and windows If you select linux, then you get linux If you select windows, then you get the windows boot menu The windows boot menu would show XP and Windows 7 as options and whichever you choose you get. Now weather windows 7 will "upgrade" the filesystem so XP can't read it anymore, or mess up anything else, who knows. I have seen NT4 have issues after windows 2000 touched a filesystem in the past, so you never know. It might be possible to use partition hiding and other tricks with grub to make each windows totally unaware of the other and just have grub be the boot menu, but I have never played with that. You could certainly save a lot of partitions if your linux swap and root were logical partitions. That way they would combined only count as one primary partition. Grub does not want a partition, it just uses the space after the partition table in track 1 for embedding. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB for ARM based devices
On Fri, Oct 19, 2012 at 07:43:17PM +0100, Adam Hunston wrote: > Actually I had not thought of that, and I believe the firmware is expected > to be loaded by something like uboot... Well uboot is firmware (and a boot loader). But maybe uboot could load grub, although what is the point in that? (I can think of a few, but maybe you have better ones.) -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB for ARM based devices
On Fri, Oct 19, 2012 at 07:33:26PM +0100, Adam Hunston wrote: > Hello fellow developers, > > Am looking to compile a version of grub to work on ARM based devices, e.g. > the tablet world, is anybody interested in joining me on this, or have any > ideas for starting..? I am thinking probably looking at the legacy > bootloaders is probably a good start... > > Kind regards, Adam Does the arm device you have in mind have firmware seperate from the boot loader? For most devices (The Loongson MIPS devices being one of the few exceptions) grub expects the firmware to provide hardware initialization and device enumeration. uboot and redboot on the other hand tend to handle all the hardware initialization and device detection and are both the firmware and the boot loader in one. grub on some of those Loongson devices is also the firmware though. grub is mainly a boot loader only though. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: pxe failing on grub 2.00 for files larger than 50KiB
On Wed, Sep 26, 2012 at 08:30:45AM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > AFAIR it has an endianness bug in tftp code (which was mainly tested on > ppc). Please try bzr. Nifty. So endianess bugs can happen both ways. And here I thought us big endian users were always the ones having to deal with these things. :) -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 3/5] msdos-part: allow embedding in extended partition
On Thu, Sep 13, 2012 at 01:26:27PM +0800, Michael Chang wrote: > Yes. And thanks to the great grub2 would do the check for us. :) > > For openSUSE supported filesystem, they're all allowing embedding and > grub|grub2 works pretty well. > > I understand the drawbacks and pitfalls that having bootloaders > installed on a partition in use, it's fragile, file system dependent > and not work on lvm partiton. The question here is that these maybe > not enough to convince people to use mbr as default proposed location, > especially to deal with multiboot setup. I illustrate some of the > problems below: > > 1. Booting after bios is thus fully controlled by a distro loader and > you couldn't boot into other distro once that *main* disto failed. The > active partition no longer worked. Makes sense. > 2. You can't use chainload if you're not installed to a partition. > Grub2 has been done well to probe the foreign os config and knows how > to load the kernel and initrd directly, thus the chainload seems not > required. It's true but only if the foreign OS never changes his > config. There's a problem reported that foregin os not booting after > receiving kernel update. If using chainload then it would not have > problem because it's no depend to config change. I personally have never understood the desire for multiple linux installs on a machine, and hence have never had a reason to have more than one grub on the system. Any other OS for me has always been one windows install (and I don't have those very often either). I used to install grub to the partition because whenever you reinstalled windows it would overwrite the MBR and being able to change the active partition to get back to linux was handy. But since windows 95/98 aren't common anymore, the need to reinstall windows every 3 to 6 months to keep it working seems to have gone away, so now I just have grub in the MBR. But that's just how I do things. > So we are keeping the "boot from partition .." scenario although we > know grub2 not encourage to do this. The question here is that we hope > installing to extended partition could be supported, as unfortunately > that's one of the scenario. As far as I am aware, you can tell grub to force using the blockmap, but it does require passing the appropriate force argument to do it. > I agree with you that for gpt on legacy bios scheme, we should embed > bootloader to the boot partition. Given that generic(or standard) mbr > boot code is no longer to work on gpt (it always shows error, no > active partition ;), there's no good reason to embed bootloader on > partitions in use, assuming that the gpt introduces concept of boot > partition, and the old-day booting from msdos active partition no > longer worked or favored. gpt does have a specific partition type to use for bootloaders, and grub will use it automatically. It works great. Of course that again gives you back the problem of chainloading, since there can be only one such partition on a given system I suspect. I could be wrong, perhaps you could have multiple, but keeping track of which is which sounds complicated. > However syslinux which prefers living in a partition has provided > gptmbr, it maybe used to boot off a gpt partition. But IMHO for grub, > we should go for the bios boot partition (as it's name says GRAND > UNIFIED ..) and gptmbr might be optional for those still insist in > legacy way. I believe gptmbr is to allow a legacy bios system to load the mbr and execute code that will go do the right thing for a gpt disk (which a legacy bios doesn't understand of course). > > > > After all getting rid of the block mapping in grub2 has made it a lot > > less fragile, although you can still do it if you force it. > > Yes. Using block-list install is much more improved on 2.00. Thanks > for working on that. :) Well someone did. I mainly use grub, and report bugs when I find them (mostly on IBM powerpc since x86 generally just works). After much discovery of endianess bugs and other fun stuff grub2 actually works quite well on ibm powerpc machines now. The serial console display is a bit messed up for the menu still, although I haven't looked into why yet. Perhaps I should. I think they use ANSI rather than vt100 or something. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 3/5] msdos-part: allow embedding in extended partition
On Wed, Sep 12, 2012 at 03:25:43PM +0800, Michael Chang wrote: > Installing on extended partition is one of scenarios for SUSE and > openSUSE installation. If the /boot resides in a logical partition, > the installer would propose installing bootloader to extended > partition. For historic reasons, we prefer partition bootsector than > mbr, and use a generic mbr boot code to control the booting to active > partition. This is good or bad depends on what's the your view point, > but the point here is that for users who upgrade to grub2, we don't > want to break his current setup and still offer him the same options > he used to install grub. This is the major reason why we have to > install grub2 to extended partition. > > I could understand the patch is not good to be accepted , although it > works to solve our problem for now. However we'd like to feedback our > situation here and hope that grub2 could consider to support > installing to extended partition (I believe there must be more people > needs it) or point us a direction how to fix this problem cleanly. How much room is there in the filesystem for embedding the boot loader? It must depend on the filesystem in use too. What do you do when the disk is over 2TB in SUSE? You must be using GPT instead for that. Do you still try to embed the bootloader into the filesystem rather than use a GPT boot partition? After all getting rid of the block mapping in grub2 has made it a lot less fragile, although you can still do it if you force it. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub-devel Digest, Vol 103, Issue 1
On Sat, Sep 01, 2012 at 09:29:12AM -0700, ivo welch wrote: > as CD drives continue to to disappear from computers and as $5 USB drives > move towards >16GB range, it would make sense for OS makers to adopt some > standard that makes multiple ISO booting feasible and easy...even Windows. > grub probably does not have enough clout to convene this standard, even > though most PC boot OS varieties by count use it. > > last thought: vmware can hide the hardware. I wonder if a vmware like > strategy could hide just the CD drive. That's because vmware is a virtual machine that emulates hardware and then boots the OS in the emulation. So unless you want to write a hardware emulator and run all your OSs inside it, then I don't see it helping. And if you think Microsoft cares to help anyone put their OS on a USB key along with anything else, then you are mistaken. It is not in their financial interest to make it easy for users to try other things. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: chained grub2 derivative bootauto system
On Thu, Aug 30, 2012 at 02:20:22PM -0700, ivo welch wrote: > dear grub2 developers: > > I have wrestled often with the problems of setting up grub2 on new systems. > I know booting is a low-level science in itself, so I don't dare to > pretend that I know anything. but I wanted to put up a small starting > bounty of $500 for a grub2 derivative type of boot loader, to be made > available GPL, of course, in the main linux distributions (such as ubuntu) > if one knowledgeable developer finds this interesting. I consider most of it impossible. The bits that could be done are already possible in grub2 as far as I know. > from the user perspective, this booting system should work as follows: If you want to change the user perspective, go get a time machine and go get IBM/Microsoft/etc to design a much better boot interface than the PC has had since the begining. > if the user holds any key during the boot process, the new "B" loader (call > it bootauto.bin) would scan all available partitions for bootable systems > (such as Windows, linux, freebsd, etc.) and all root partitions for *.iso > files, and present the user with a list of what it found where, and put the > default selection line on the OS that was most recently booted. the user > should be able to select one of these, and then proceed booting from them. > the user presumably could also enter command line options at this stage, > choose a common option (such as "rescue", "single user", or "single user > read-only"), or possibly see all kernels, including older ones. > bootauto.bin obviously needs a whole lot more intelligence at boot time > than what grub2 has. You can't boot iso files in general. You can have special handlers for specific isos (such as debian or ubuntu or fedora install images) that knows which files to look for in the iso and which arguments to pass in order to get that installer to work with an iso rather than an actual cd/dvd. There is no way for the boot loader to make an iso on a disk look like a cd/dvd drive in such a way that whatever you boot can actually use it as a real cd/dvd. Once you leave the boot loader it is all up to the OS you boot to take care of things. At best you get a kernel, some ramdisk image, maybe a few modules and some arguments. The OS is then on its own. > if the user does not hold down a key, then bootauto.bin would boot whatever > it booted last, without delay. Great so now the boot loader has to store data somewhere. Boot loaders try to avoid writing. Writing is much harder (and more dangerous) than reading. Especially to filesystems. > the setup is similar to an OSX boot, where holding down an "ALT" key > presents all bootable OS's that are found. The Mac only handles the OSs it knows about, and it has pretty nice firmware to take care of it (including persistent storage in the firmware, rather than having to write to disk to remember things). Also according to what I read recently, Macs have only VERY recently started to allow booting from USB. > there would be no more grub configuration files, grub-install commands, > etc. bootauto.bin would do it all. bootauto.bin would presumably always > reside in a fixed spot, such as /bootauto.bin, and all that the boot sector > would have to do would be to find it and pass control to it. You can not fit code in a boot sector to find anything. The boot sector can only store enough to get something from a known location. You typically have 448 bytes total in the boot sector. This is why sensible system designs (IBM powerpc, EFI, etc) have a specific boot partition instead of a boot sector. That way you actually have enough space for a boot loader. The old PC BIOS based system is awful that way. The standard boot sector on a PC was simply a bit of code that would read from the partition marked 'bootable' on drive 0x80 (first hard disk) and look in the root directory for a specific filename to get the cluster chain to read. FAT file system is VERY simple to read, and by not supporting subdirectories it gets simpler yet. And it just barely fits in the boot sector. > from a user perspective, creating live USB flash sticks with multiple OS's, > or booting from another hard disk now becomes much simpler. end users only > need to connect the bootable device or connect USB stick with a couple of > ISOs on them, and it just works. > > the system-wide first-time installation of the bootloader would consist of > one command that copies the bootauto.bin file to a designated partition and > writes the bootsector. "bootauto-install /dev/sda /mnt/sda1" would install > the boot sector on /dev/sda that chain loads the B loader bootauto.bin on > mnt/sda1/bootauto.bin (whatever file system /mnt/sda1/ uses; could be ntfs, > ext4, etc). the only error should be that /mnt/sda1 cannot be written. no > mysterious chroots, no --binds, no uuid's, no grub configuration file > consultation. no problems if disks get rearranged on the next boot. sim
