Re: [PATCH] Correct spelling of *scheduled*
In the same line of the comment, miscellaneous is also spelled incorrectly. On Mon, May 25, 2015 at 3:13 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Date: Sun, 24 May 2015 23:27:46 +0200 Run the command below $ git grep -l schedulded | xargs sed -i 's/schedulded/scheduled/g' and revert the change in `ChangeLog-2015`. --- gentpl.py | 2 +- grub-core/disk/ahci.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/gentpl.py b/gentpl.py index f177883..b0ef79f 100644 --- a/gentpl.py +++ b/gentpl.py @@ -82,7 +82,7 @@ GROUPS[softdiv] = GROUPS[arm] + [ia64_efi] GROUPS[no_softdiv] = GRUB_PLATFORMS[:] for i in GROUPS[softdiv]: GROUPS[no_softdiv].remove(i) -# Miscelaneous groups schedulded to disappear in future +# Miscelaneous groups scheduled to disappear in future GROUPS[i386_coreboot_multiboot_qemu] = [i386_coreboot, i386_multiboot, i386_qemu] GROUPS[nopc] = GRUB_PLATFORMS[:]; GROUPS[nopc].remove(i386_pc) diff --git a/grub-core/disk/ahci.c b/grub-core/disk/ahci.c index 7f75724..4e8619c 100644 --- a/grub-core/disk/ahci.c +++ b/grub-core/disk/ahci.c @@ -1002,7 +1002,7 @@ grub_ahci_readwrite_real (struct grub_ahci_device *dev, if (parms-write) grub_memcpy ((char *) grub_dma_get_virt (bufc), parms-buffer, parms-size); - grub_dprintf (ahci, AHCI command schedulded\n); + grub_dprintf (ahci, AHCI command scheduled\n); grub_dprintf (ahci, AHCI tfd = %x\n, dev-hba-ports[dev-port].task_file_data); grub_dprintf (ahci, AHCI inten = %x\n, -- 2.1.4 ___ 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: [PATCH] Removing nested functions, part one of lots
On Tue, Jan 1, 2013 at 4:37 PM, Andrey Borzenkov arvidj...@gmail.comwrote: В Tue, 1 Jan 2013 14:42:04 + Colin Watson cjwat...@ubuntu.com пишет: * If a hook requires more than one local variable from its parent function, declare struct name-of-parent_ctx with the necessary variables, and convert both the hook and the parent to access the variables in question via that structure. Personally I find ctx part a bit confusing. It is not really execution context in usual sense, it is just collection of random variables. I would rather go with struct name-of-parent_data here. It's acting as a closure. That might be a more exact name. ___ 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: Secure Boot. Why don't you take the wind out of their sails?
On Tue, Jul 10, 2012 at 12:04 AM, Chris Murphy li...@colorremedies.com wrote: On Jul 9, 2012, at 7:23 PM, richardvo...@gmail.com wrote: All systems ship with verification disabled, and all the major motherboard manufacturers have indicated that secure boot will always stay an opt-in mechanism. This is mystifying because it directly contradicts the Microsoft Windows hardware certification requirements, which require that to get the made for Windows 8 certification, the hardware must be UEFI, must implement Secure Boot, must have it enabled by default (except servers), and must have a Microsoft key included. It also requires a user chooseable option to disable Secure Boot on x86, but not ARM. Maybe I'm missing something, but when I read this, it doesn't say the hardware must have Secure Boot enabled by default. Rather, it must be enabled by the OEM as part of the Windows preinstallation process, so that it's enabled when it reaches the end user. System builders are still going to purchase UEFI Secure Boot-capable motherboards with Secure Boot disabled-by-default, and they will just work if you want to install Linux. End-users who bought pre-installed Windows will have to change the configuration option in system setup, which for someone planning to install a new OS from scratch is not a major hurdle. It will be a minor road bump for people using live-CD style media (including USB), but won't be a showstopper if the user actually has permission from the computer owner to boot the alternate media. What likely is that it will prevent unauthorized (by the owner) rebooting public computers using alternate media, but that's not exactly a valid scenario to begin with. ARM is a red herring, IMO. Pretty much all ARM processors include some sort of code security module that blocks external access to the bootloader without the correct reprogramming key. This is pretty standard for embedded systems, and has been for decades. Most embedded systems aren't designed to boot from removable media. Most tablets don't give the end user root privilege. That's a shame, and something we should work to fix, but going around telling everyone that the world will end if Microsoft gets Secure Boot onto media devices is just dishonest. Those devices have been locked down already, and the world didn't end. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Secure Boot. Why don't you take the wind out of their sails?
I'll decloak to offer my response, but please remember that I'm not one of the developers so my opinion is of limited value. By the same token, I've been recognized by Microsoft for community contributions, but I do not work for them and do not speak for them. First, putting things in simple language is very positive and necessary. However, your short easy-to-understand summary is incorrect. The bootloader password doesn't protect against malware, and it offers only a little protection against anybody taking over your computer. In fact, if some malware rewrote the grub configuration file, it could be quite annoying to recover. Also, the bootloader password solves a very different problem from the secure boot initiative. The grub password check doesn't verify integrity of system files. Finally, the secure boot initiative isn't a threat to open source operating systems. The computer administrator has to install a signed OS and then enable signature verification in the firmware. All systems ship with verification disabled, and all the major motherboard manufacturers have indicated that secure boot will always stay an opt-in mechanism. And even then, the firmware setup utility can be used to once again disable verification, so it isn't even a hindrance to resale of used equipment, as long as the sale is authorized and the configuration is changed. It might create some barrier to use of stolen equipment, but even then it is likely that clearing the NVRAM by removing the backup battery will gain access. Full-disk encryption is still the best safeguard in case physical security is compromised. So definitely, this sort of thing needs to be summarized and then explained in detail using plain English that can be understood by those who aren't so technically astute. But lets not sacrifice accuracy in the desire to use simpler words. Ben Voigt On Mon, Jul 9, 2012 at 5:38 PM, Graham Cunnington geecee...@yahoo.co.uk wrote: Subject: Secure Boot. Why don't you take the wind out of their sails? (1) Now is the time to move quickly. The development needs to be short and clear so that even a beginner can use it immediately. (2) The Problem: Microsoft and allied companies have an idea to force a Microsoft (Verisign) key on to hardware manufacturers which may be an attempt once again to bring in anti-competitive practices and may decrease the uptake of Linux systems. The Secure boot key proposed could in fact limit consumer choice and drag Grub2 into a fight none of its making. (3) The Problem of Verbosity: Grub2 already has the solution to protect Grub and therefore the kernels that Grub boots, but that solution is currently unavailable because Grub developers have no idea how to KISS. Keep It Simple Silly. Long-winded geeky sentences have no place in Grub. in some environments, such as kiosks, it may be appropriate to lock down the boot loader to require authentication before performing certain operations. The ‘password’ (see Section 14.3.33 [password], page 62) and ‘password_pbkdf2’ (see Section 14.3.34 [password pbkdf2], page 62) commands can be used to define users, each of which has an associated password. ‘password’ sets the password in plain text, requiring ‘grub.cfg’ to be secure; ‘password_pbkdf2’ sets the password hashed using the Password- Based Key Derivation Function (RFC 2898), requiring the use of grub-mkpasswd-pbkdf2 (see Chapter 30 [Invoking grub-mkpasswd-pbkdf2], page 101) to generate password hashes. In order to enable authentication support, the ‘superusers’ environment variable must be set to a list of usernames, separated by any of spaces, commas, semicolons, pipes, or ampersands. Superusers are permitted to use the GRUB command line, edit menu entries, and execute any menu entry. If ‘superusers’ is set, then use of the command line is automatically restricted to superusers. The above is incomprehensible to most users who are not developers. Why not just say: You can password-protect Grub. This will secure it against malware and anybody taking over your computer. (4) The Solution: (a) Insert into the standard Grub Menu a link which says: Set a password on Grub, which when clicked allows the user to do so. (b) If this has already been done, then on switching on the computer, the password dialog box should pop up prior to the boot Menu. (c) If this is done then we already have Secure Boot and the administrators of companies and home computers will have protected their computers and the Microsoft initiative becomes unnecessary, at least for Secure Boot (Secure Bios is another matter and another battle). (d) do it quickly, keep it simple, keep it smart then tell the world what you have done. Computer journalists will love you for it. Remember, it has to be easy to understand even to people new to computers can quickly set a password on their boot. (5) Who am I? A pemsioner with no background in computing,
Re: Secure Boot. Why don't you take the wind out of their sails?
However, your short easy-to-understand summary is incorrect. The bootloader password doesn't protect against malware, and it offers only a little protection against anybody taking over your computer. In fact, if some malware rewrote the grub configuration file, it could be quite annoying to recover. No, you're incorrect. The password is stored IN the grub configuration file. So if that person can rewrite the grub configuration file it can rewrite the password too (or fully disable it or ...). Thus that protection becomes fully INEFFECTIVE. Even if the password were stored in a separate file that file could be changed just as well. You just made my point ;) Malware can change the bootloader password, since it's simply stored in a file, making you jump through quite a number of hoops before being able to use your computer again. [snip] Finally, the secure boot initiative isn't a threat to open source operating systems. The computer administrator has to install a signed OS and then enable signature verification in the firmware. All systems ship with verification disabled, and all the major motherboard manufacturers have indicated that secure boot will always stay an opt-in mechanism. And even then, the firmware setup utility can be used to once again disable verification, so it isn't even a hindrance to resale of used equipment, as long as the sale is authorized and the configuration is changed. It might create some barrier to use of stolen equipment, but even then it is likely that clearing the NVRAM by removing the backup battery will gain access. Nobody's saying that the basic technology which is not exactly new either is a threat. But the implementation SecureBoot is. You're misinformed. While on x86 systems there's a switch required to disable SecureBoot that same switch is NOT ALLOWED for ARM systems (https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/restricted-boot-comic-contest-defend-user-freedom-on-tablets-and-smartphones). Please get your facts straight. Apart from that even if there is a switch the question remains how easily accessible it is going to be? How obvious the need to use it is going to be? You're the guy asking for stuff to be simple so that point should be clear to you. Uh no, I'm not that guy. I was calling out that guy on his claim that a bootloader password protects against malware, while trying to be very clear that it isn't the idea of a simple explanation I object to, but the fact that accuracy was sacrificed. I was in a meeting between reading the OP and the time my response went out, I didn't see the other replies. Full-disk encryption is still the best safeguard in case physical security is compromised. There's still some code loaded and executed before opening the volume. That code is responsible for initially decrypting the volume and loading something else from within it. Now I say decrypt so that means that code needs to get credentials from somewhere and if that code were malicious it would be given the credentials (as it would appear no different to the user) and could use them for anything. No way getting around verification of the code unless you have a firmware that supports booting from that volume directly but then again the firmware needs to be verified by some means too. Imagine you're giving a party and want some sort of entry control. As long as you don't verify somebody (code) to be trusted to execute the entry control by checking everybody's invite (credentials), there's no way to have it invites-only. If you're lacking credentials it won't work and if the doorman are untrusted they could not be checking the invites/credentials properly. You can't get rid of either one of them completely. Where did I say otherwise? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Timeout broken with serial port
On Mon, Sep 5, 2011 at 3:51 PM, Aleš Nesrsta star...@volny.cz wrote: Hi, I think it is not GRUB related problem, more probably there is some HW problem on Your serial port. Try to check idle voltage on RxD pin of serial port (best with oscilloscope... :-) ). Or You can have some unwanted leakage between pins of connector or wires in cable (check resistance between wires of cable) etc. Normal serial port should NEVER do anything if there is nothing connected to it. According to RS232 (V24) specification there should be voltage in range from -12V to -3V on RxD pin in idle state (in simplest case there is some internal pull-up resistor connected from RxD to -Vcc directly inside UART or something else...). In this normal case nothing is received by serial port and nothing will be interpreted as keypress in GRUB, i.e. GRUB will boot normally. In Your case, probably something causes some noise on RxD pin or there is bad voltage level on RxD pin (e.g. = +3V or near to 0V etc.) when nothing is connected - so serial port interprets it as receiving some character(s). An idle transmitter should be in the range -3V...-12V. But here there is no transmitter. I would not be at all surprised if some hardware implements cable detect using a weak pull to 0V. Still, data shouldn't be reported by the receiver unless the voltage is in the valid range, and the input should not be left floating either. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Automatic module license checking
When does this check run? Seems ridiculous to do this on every boot cycle, a bootloader should execute as quickly as possible, not try to solve the world's legal problems. Just my $0.02 2011/4/11 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com: Hello, all. Due to recent case of non-compliance with GPL in a project using GRUB2 codebase and according to new GNU guidelines I've implemented an automatic module license checking. This checks doesn't change in nothing the distributor obligation: any GRUB2 module is covered by GPLv3(+) (and optionally dual-licensed under another license). However, this change makes this compliance requirement explicit by requiring author to put a GRUB_MOD_LICENSE macro. Also note that everybody is allowed to remove the said check but doing so doesn't free from legal GPL obligation. When implementing this check I've added a bunch of GRUB_MOD_LICENSE and GRUB_MOD_DUAL_LICENSE, I'll be grateful if everyone who sees a problem (e.g. non-correspondance between license header and macro) would report it to me and I'll fix it as soon as time permits. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
I've wondered occasionally whether it would be worth it to include something like GRUB_STATIC in upstream grub-mkconfig; if set, this would cause grub-mkconfig to do nothing, perhaps printing a message. This would mean you wouldn't have to figure out how to disable distribution facilities that run grub-mkconfig for you; you could just set GRUB_STATIC=1 and write your own grub.cfg if you wanted. Vladimir, do you think you'd take such a change for 1.99? Based on other messages in this thread, this likely wouldn't be very effective. Boot from a LiveCD? It won't have GRUB_STATIC set. IMO, a better option would be to control this from the config file itself (and obviously it's already too late from one perspective, there already exist distro releases with tools that won't respect it). I would lean toward a solution wherein the tools refuse to modify a config that contains any of config_protected 1 config_protected yes config_protected true (and prints an appropriate message so a user who is trying to run a boot fix-it tool is informed how to disable the protection, better have a specific exit code as well so that wrapper tools which don't show tool stdout/stderr to the user can detect this condition and display their own message, possibly localized) Then the tools can generate a config that starts with # this file is auto-generated, allow re-generation (manual edits will be lost) config_protected false Any user who opens the config in an editor should understand that a change needs to be made to switch off auto-generation, they can most likely infer the syntax they want or go read the documentation. Ben ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Improve documentation of BIOS installation
-@strong{Caution:} Be very careful which partition you select! When GRUB
-finds a BIOS Boot Partition during installation, it will automatically
-overwrite part of it. Make sure that the partition does not contain any
-other data.
+@xref{BIOS installation}, for details on where the core image can be
+installed on PC systems.
I would suggest NOT moving warnings into links introduced as for
details. Something should be kept here, like:
( ! ) Caution: If your system has a BIOS Boot Partition, GRUB
automatic installation will overwrite it and data could be lost. Be
sure to read @xref{BIOS installation/GPT}.
And then that section needs to also contain a simple test which users
can do to discover that they have no BIOS Boot Partition to worry
about.
Please also check whether it's more correct to say that GRUB will
automatically overwrite during installation, or GRUB will overwrite
during automatic installation.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Out of Memory Error
On Mon, Mar 28, 2011 at 2:56 PM, Gus Zernial gus_zern...@yahoo.com wrote: I've posted my problem to this list before without getting a solution - also to grub-help and Ubuntu forum(s), no answer - I'm stumped and would really appreciate help. I have Kubuntu 10.10, a custom 2.6.37.1 kernel, and GRUB2. I was on v1.98 when the problem started, I'm now on 1.99~rc1 which I downloaded and compiled, the upgrade didn't help. My system has three disks - / is on an SSD, and /home is on the other Which SSD? This sounds rather like the infamous OCZ time warp. Are other changes made to the SSD lost, or only the boot sector? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Out of Memory Error
On 03/29/2011 05:48 PM, richardvo...@gmail.com wrote: Which SSD? This sounds rather like the infamous OCZ time warp. Are other changes made to the SSD lost, or only the boot sector? On Tue, Mar 29, 2011 at 7:50 PM, Phillip Susi ps...@cfl.rr.com wrote: What OCZ time warp? I have an OCZ SSD and don't have any trouble with it. Hadn't noticed anything about this on their forums either. I don't have any trouble with mine either, but it seems to plague certain systems. It was discussed extensively during the most recent firmware release cycle, which is how I learned about it. http://www.ocztechnologyforum.com/forum/search.php?securitytoken=guestdo=processquery=%22time%20warp%22 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Documentation bug?
I have just downloaded a tarball of grub-1.99~rc1, and a ‘find’ command on the untarred tree did not return any positives either. What tarball have you downloaded? Source code, probably. stage2_eltorito is machine code that has to be compiled for the particular architecture. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Guidance on conflicts between GNU GRUB and proprietary software
On Fri, Sep 24, 2010 at 9:09 AM, Richard Stallman wrote: It appears that, rather than the operating system itself being at fault, a number of Windows applications take over a sector in the boot track and store bits and pieces of data there. I am surprised applications can do that. Isn't that a security hole in Windows? Is it a security hole if the linux superuser can write to /dev/sda ? If you block this level of access, how's fdisk (or any number of other partition managers) supposed to do its job? How's one supposed to install grub in the first place, if access to those blocks is forbidden by every OS? We are talking about the owner of the machine, and software they choose to run. An OS that prevented the owner from having full control over his own machine would be something to complain about, letting the owner write to his boot track is not. If we think there's a real security hole here, like unprivileged applications able to overwrite grub code, I'll go advocate with Microsoft to have it fixed. Until then I just agree that it's a tragedy that applications which aren't bootloaders or partition managers mess around in this area, but it shouldn't be up to the OS to decide which applications run by the superuser are specially privileged to manage partitions, and which aren't. Yours truly, R Benjamin Voigt Microsoft Visual C++ MVP and Windows private beta tester P.S. Does anyone know if the Linux versions of those same proprietary license managers abuse the boot track like their Windows behavior? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Detect other software using embedding area
On Sun, Sep 5, 2010 at 10:14 AM, C. P. Ghost cpgh...@cordula.ws wrote: On Tue, Aug 31, 2010 at 2:54 PM, Thomas Schmitt scdbac...@gmx.net wrote: Maybe one should use external boot media of which GRUB can claim complete ownership. I.e. an USB stick or a CD which hosts GRUB and a custom configuration. This way, GRUB would have no shares in the embattled area at all. This way, GRUB would be unusable on rack-mounted servers in data centers. You can't add a USB stick or CD there, if all you have is remote serial console access... On servers hopefully you are setting up a special partition for grub to use. The embedding area sounds like it is trying to solve a problem with dual-boot systems where the first OS is already installed and cannot be moved. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Optimise memset on i386
[snip] + unsigned long patternl = 0; + grub_size_t i; + + for (i = 0; i sizeof (unsigned long); i++) + patternl |= ((unsigned long) pattern8) (8 * i); + might I suggest: unsigned long patternl = pattern8; patternl |= patternl 8; patternl |= patternl 16; patternl |= patternl 32; patternl |= patternl 64; O(lg N) instead of O(N), no loop, no branches, and the compiler should be smart enough to optimize away the last two lines on systems with narrower long. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Optimise memset on i386
On Fri, Jul 23, 2010 at 12:34 PM, Christian Franke christian.fra...@t-online.de wrote: richardvoigt wrote: might I suggest: unsigned long patternl = pattern8; patternl |= patternl 8; patternl |= patternl 16; patternl |= patternl 32; patternl |= patternl 64; O(lg N) instead of O(N), no loop, no branches, and the compiler should be smart enough to optimize away the last two lines on systems with narrower long. The latter is unfortunately not the case. At least gcc 4.5.0 prints a warning but still produces code. Ok then, a compile-time conditional should fix that. unsigned long patternl = pattern8; if (8 sizeof patternl) patternl |= patternl 8; if (16 sizeof patternl) patternl |= patternl 16; if (32 sizeof patternl) patternl |= patternl 32; if (64 sizeof patternl) patternl |= patternl 64; I'm pretty confident in gcc's ability to optimize this version. I hope. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Optimise memset on i386
On Fri, Jul 23, 2010 at 2:48 PM, richardvo...@gmail.com richardvo...@gmail.com wrote: On Fri, Jul 23, 2010 at 12:34 PM, Christian Franke christian.fra...@t-online.de wrote: richardvoigt wrote: might I suggest: unsigned long patternl = pattern8; patternl |= patternl 8; patternl |= patternl 16; patternl |= patternl 32; patternl |= patternl 64; O(lg N) instead of O(N), no loop, no branches, and the compiler should be smart enough to optimize away the last two lines on systems with narrower long. The latter is unfortunately not the case. At least gcc 4.5.0 prints a warning but still produces code. Ok then, a compile-time conditional should fix that. Thanks to Seth for pointing out my obvious bug. unsigned long patternl = pattern8; if (1 sizeof patternl) patternl |= patternl 8; if (2 sizeof patternl) patternl |= patternl 16; if (4 sizeof patternl) patternl |= patternl 32; if (8 sizeof patternl) patternl |= patternl 64; I'm pretty confident in gcc's ability to optimize this version. I hope. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug in multiboot_mbi2.c
What, you want to control color channels independently? Aren't monochromatic amber displays good enough any more? :) On Mon, Jun 21, 2010 at 9:22 PM, Seth Goldberg seth.goldb...@oracle.com wrote: The code that constructs the framebuffer info has a nasty bug where the field position and mask size for red are set to the GREEN values: tag-common.framebuffer_type = MULTIBOOT_FRAMEBUFFER_TYPE_RGB; tag-common.framebuffer_type = MULTIBOOT_FRAMEBUFFER_TYPE_RGB; -- tag-framebuffer_red_field_position = mode_info.green_field_pos; -- tag-framebuffer_red_mask_size = mode_info.green_mask_size; tag-framebuffer_green_field_position = mode_info.green_field_pos; tag-framebuffer_green_mask_size = mode_info.green_mask_size; tag-framebuffer_blue_field_position = mode_info.blue_field_pos; tag-framebuffer_blue_mask_size = mode_info.blue_mask_size; --S ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Patch] Simple USB hub support
On Sun, Jun 20, 2010 at 4:21 AM, Aleš Nesrsta star...@volny.cz wrote: Hi, included patch should make USB hubs operational. It works in the same simple way as whole GRUB2 USB support, i.e. USB hub and device must be connected to computer BEFORE uhci/ohci module is loaded. Note (mainly for Vladimir): Via hub are normally working also devices which I reported to be not functional on UHCI. So, from my point of view it looks like there is surely some problem in powering of UHCI root hubs on my computer. But I still don't know why only some devices are sensitive to this problem (all of them are not big consumers of power). When connected via USB-HS hub, even low-speed and full-speed devices enumerate under the EHCI, not UHCI. So it's not surprising that the behavior changes and the devices start working. Can you verify the speed of the devices in question, and that the hub is USB 2.0 high-speed? Best regards Ales ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Which partitioning schemes should be supported by GRUB?
I can think of an alternative. We do still need grub_install_dos_part and grub_install_bsd_part for the multiboot trampoline, which is in assembly, so it's difficult to abandon them altogether. However, there's no reason we need to use them in make_install_device. How about we invent a way to encode most of the information in string form in grub_prefix, while leaving a placeholder for make_install_device to fill in the disk? There are 64 bytes available for grub_prefix, which should be plenty. For example, how about the following (with \0 standing for ASCII NUL): (\0,msdos1,bsd1)/boot/grub It's then just a matter of spotting the (\0, sequence and replacing the \0 with the drive name. I think this can probably be done using less code than the first option above, and all told it feels a bit less hacky to me. Instead of doing string replacement, why not just define a disk-relative partition format? Also, the '\0' seems unnecessary. Is having (, meaningful in some way already? What do people prefer? -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: escape strings in grub.cfg
On Sun, Apr 11, 2010 at 7:09 PM, Colin Watson cjwat...@ubuntu.com wrote:
On Sat, Apr 10, 2010 at 10:10:15PM +0100, Carles Pina i Estany wrote:
Last weekend, the Asturian team found a bug in Grub. Thanks for the
debugging. The string that appears in grub.cfg for Loading the initram
in Asturian is Cargando'l discu RAM inicial So grub.cfg looks
like:
echo Cargando'l discu RAM inicial...
This is syntactically invalid because the character '.
Easy work around: generate the line like:
echo Cargando'l discu RAM inicial...
New problem: in some language, this string could have a double quote
inside.
New solution: escape the double quotes strings when they are used in
gettext and always use these strings with double quotes.
See the attached patch.
I'm not convinced of the patch, does anybody has a cleaner idea/patch?
This doesn't cover everything - you've just moved the goalposts a bit.
Here's the relevant bit of the lexer:
SQUOTE{
\' {
yy_pop_state (yyscanner);
ARG (GRUB_SCRIPT_ARG_TYPE_SQSTR);
}
[^\']+ { COPY (yytext, yyleng); }
}
DQUOTE{
\ {
yy_pop_state (yyscanner);
ARG (GRUB_SCRIPT_ARG_TYPE_DQSTR);
}
\$ {
yy_push_state (VAR, yyscanner);
ARG (GRUB_SCRIPT_ARG_TYPE_DQSTR);
}
{ COPY (\\, 1); }
\\\ { COPY (\, 1); }
\\\n { /* ignore */ }
[^\$\\\n]+ { COPY (yytext, yyleng); }
(.|\n) { COPY (yytext, yyleng); }
}
In other words, only ' is special (as a terminator) when reading a
single-quoted string, and the sequences $ \\ \ \n are special inside
a double-quoted string. (Incidentally, I think there's another bug
here; if $ is special, \$ should be special as well.)
Given this, wouldn't you be better off using single-quotes instead?
You'd then end up with:
echo 'Cargando'\''l discu RAM inicial...'
... where the construction used to escape ' is close quotes, literal ',
reopen quotes. (Tested in grub-emu.)
+gettext_escape_double_quotes ()
+{
+ echo -n $(gettext $@) | sed 's/\/\\\/'
+}
This is underquoted, and in any case the 'echo -n' is redundant since
gettext itself already writes to standard output and $() substitution
strips trailing newlines. $@ requires special treatment, and that sed
s/// command needs /g. With my suggestion, I'd recommend:
gettext_quoted () {
gettext $@ | sed s/'/'''/g
}
I haven't tried it myself, but you just said the newline is stripped
by $() and then took out the $(), seems like the newline would be
present again.
... and then make sure it's enclosed in '' rather than wherever it's
used (or modify the sed to put single-quotes at the start and end, if
that works out neater).
--
Colin Watson [cjwat...@ubuntu.com]
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Multiboot2 Suggestions
8) Any RAM that is not immediately usable by the OS should not be reported as usable RAM in the memory map. An example of this is the ACPI reclaimable area (which is RAM that isn't usable until the OS has finished using the ACPI tables). RAM used to store the multi-boot information, RAM used to store the kernel and RAM used to store any modules should be treated in the same way. I suggest using area type 0xFFFE = RAM used for multi-boot information and area type 0xFFFD = RAM used for kernel/modules. This makes it much easier to write a kernel's early initialisation code, because it can use RAM without worrying about trashing data that is needed by the kernel/OS later. kernel should know itself what it asked bootloader to do. MBI now is a single chunk. Further than that there are only elf section tag and module tags which refer to external memory. I think it should be easily trackable now. Unfortunately a lot of OSs are written by C programmers who do the absolute minimum to setup paging in a small piece of startup code written in assembly, before jumping to their main(). This means they allocate RAM for page tables, etc before they've parsed or checked anything; usually by searching the memory map for the first usable area and using the first pages of that area. Unfortunately I'm often the person that needs to explain to them that usable doesn't mean usable; and that their code only works by accident (and their initialisation code could overwrite things needed by the OS later if it's booted by a different multi-boot compliant boot loader; including future versions of GRUB and not excluding non-GRUB boot loaders); and that the only memory they can safely use before determining what is usable and what isn't is the space in their .bss, which usually happens to be linked to a virtual address (e.g. above 0xC) and not the address it's actually loaded at.The other alternative is for the initialisation code to copy everything from the usable areas into their .bss so that they can assume that usable means usable (but there's no maximum size for the multi-boot information and no way to know how big big enough is, and this won't work if there's any extra modules). Basically, regardless of how the OS handles the problem, the small piece of startup code written in assembly ends up being an ugly mess. If multi-boot guaranteed that usable actually did mean usable then the problem goes away. Alternatively you could rename it, so that type 1 = potentially usable maybe so that beginners realise they're screwed before they write their dodgy code... ;-) This does sound like there ought to be different codes for usable - unused vs usable - valid. I think the original objection may have been to enumerating all the different kinds of usable - valid regions which could snowball into a very large number of IDs. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Help regarding booting application processor
Ok, I will think in this direction. I just wanted to verify whether the code in the trampoline.S is correct or not. Well, I'm not qualified to review your trampoline, I read x86 assembler but I'm not familiar with the details of the boot sequence. I think you're in the right place to find someone who is, though. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Help regarding booting application processor
On Wed, Feb 24, 2010 at 12:57 AM, Swapnil Pimpale swapnil.p...@gmail.com wrote: Hi all, I am a final year engineering student and I am doing my project in GRUB-1.97~beta4 and Linux Kernel 2.6.24.7. I am working on Intel Core 2 Duo architecture. I want to boot a separate kernel on the second core. As of now, I have brought up the halted AP from the GRUB by sending IPIs in the INIT-SIPI-SIPI sequence. I have also allocated a 4KB page below 1MB and asked the AP to jump to that address. I am trying to put the BSP in while(1) loop and I want the AP to switch from real to protected mode and then jump to start of kernel. But whenever I do a jump to 1MB the system reboots. Remember that the RAM physical address space is shared between both processors. You'll need to tell Linux not to touch the second core and not to touch the memory used by your second OS. I think you can accomplish both of these goals using the right kernel command line. Then you'll have to divide up other hardware, like PCI devices, so that only one OS accesses any given device. For example, the second OS won't be able to use a hard disk connected to a SATA controller visible to the first one. Especially the second kernel needs to be written not to address the PCI bus controller(s), including enumeration of bus devices. If you can't partition the hardware like this then you'll need a hypervisor, which uses protected mode to intercept and virtualize attempted hardware access from the other OS. I am using the following code as the trampoline code for the AP. Can someone please let me know what is wrong in the following code. Probably you've stomped on a shared resource being used by the first processor. Even if you run an infinite while loop on the first core, it can still execute interrupt service routines installed by grub (or by the second kernel, if not careful about interrupt-processor masks) which would access grub global data structures. If you overwrite anything you may end up with a protection fault or invalid instruction exception, both of which would probably vector back to BIOS startup code. Awaiting your reply, Thanks, Swapnil Pimpale - trampoline.S - /* Tell GAS to generate 16-bit instructions so that this code works in real mode. */ #include grub/symbol.h #include grub/i386/pc/memory.h .align 4096 .code16 FUNCTION(TRAMPOLINE_CODE) initial: mov %cs, %ax mov %ax, %ds cli lidtl idtdesc - initial lgdtl gdtdesc - initial mov $0x9e00, %bx // 9e00 is the cs shl $4, %ebx movl $(gdt - initial + 8), %eax movl %ebx, %eax mov $0x10, %bx xor %ecx, %ecx mov $0xb800, %cx // address of video RAM in %cx shl $4, %ecx mov $0x0744, %dx // for printing D xor %eax, %eax pushw %ax mov $0x08, %ax pushw %ax xor %eax, %eax mov $0x9e00, %ax shl $4, %eax add protcseg - initial, %eax pushl %eax xor %eax, %eax movl %cr0, %eax // turn on the PE bit orl $0x1, %eax movl %eax, %cr0 jmp l1 l1: mov %bx, %ds mov %dx, (%ecx) // Print D add $2, %ecx add $1, %dx ADDR32 ljmpl $0x8,$((protcseg - initial) + (0x9e00 4)) .align 256 .code32 protcseg: l3: mov %dx, (%ecx) movw %bx, %es movw %bx, %fs movw %bx, %gs movw %bx, %ss l4: // The following is the code used by /loader/i386/linux.c for entering Linux mov $0x8c000, %esi xor %ebx, %ebx mov $0x8c000, %eax jmp *0x214(%eax) // System reboots here l5: jmp l5 .p2align 2 gdt: .word 0, 0 .byte 0, 0, 0, 0 .word 0x, 0 .byte 0, 0x9A, 0xCF, 0 .word 0x, 0 .byte 0, 0x92, 0xCF, 0 .word 0x, 0 .byte 0, 0x9E, 0, 0 .word 0x, 0 .byte 0, 0x92, 0, 0 gdtdesc: .word 0x27 .long gdt idtdesc: .word 0 .long 0 FUNCTION(TRAMPOLINE_END) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Licensing Re: Lead-up message 'Welcome to GRUB!' ...
On Mon, Feb 22, 2010 at 4:31 PM, Isaac Dupree m...@isaac.cedarswampstudios.org wrote: On 02/21/10 15:38, richardvo...@gmail.com wrote: On Sun, Feb 21, 2010 at 4:00 AM, Robo Lrobo.om...@gmail.com wrote: Hi all, Firstly I would like to thank everyone for the reply and Your time. I would like to clarify the issue. First I need to hide the very first Welcom message because I need to hide GRUB for other users of MS Windows on my PC. I need it only for myself. I'm not entirely certain, but: (1) I think GRUB is licensed under GPLv3 or higher only yes (2) GPLv3 covers what were considered to be loopholes in GPLv2 (firmware enforced signature, software-as-a-service) therefore well, GPLv3 is not identical to GPLv2, but I don't think the differences are important to this issue. (3) Your use of GRUB (copying it into the boot record) requires you to provide your users with notice of their GPL rights to your version of GRUB. No, I think it probably does not. Firstly, because Robo L may not be conveying the program (see definition in GPLv3), and if not, cannot possibly be violating GPLv3. You're right, the loophole I mentioned in #2 was plugged in AGPL in a way that only covers over-the-network use and thus probably not Robo's scenario. http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLRequireSourcePostedPublic Secondly, even if installing it to the hard disk of a computer that is shared between you and other people (or other corporations) is conveying, GPLv3 Section 5 says, d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so. I didn't check whether mainstream GRUB interaction displays Appropriate Legal Notices. (Welcome to GRUB! is most certainly NOT an Appropriate Legal Notice.) If it doesn't, you're free. If it does, I think you still I never meant to suggest that removing the message was forbidden, just that if there is a requirement to offer source code to the users then it's pointless to hide the message. do not need to display Appropriate Legal Notices until interactive user interfaces have been activated; say, by typing in the secret code that activates them. In section 0. Definitions, An interactive user interface Anything that accepts a secret code and responds to it is an interactive user interface. displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that [says it's GPLed, etc.]. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion. I don't see interactive user interfaces defined anywhere in the GPL or mentioned in GPL-FAQ, so I am hardly sure whether a secret password-entry system that only interacts by secretly reading a password (and then brings up the real interactive interface) would count as an interactive interface in its own right that must tell the user about itself even when they don't know the password... The Affero-GPL is written with further language about interaction, but as I guess that the normal GPL wouldn't make a GPL'd SSH server program have to break the SSH protocol in order to fulfill Legal Notices, there must be some limits on what is considered interaction... I doubt the GPL was written with surreptitious installation of software on other people's computers in mind... well, maybe it was It definitely covers putting a copy on someone else's computer. But Robo said he's installing it on his own computer. And GPLv3 doesn't seem to put restrictions on that like AGPLv3 does. So one can hardly say that another user on my PC not venture a guess that there is a GRUB if you are required to tell them that GRUB is there and offer them the source code. Richard: redirection is not good idea for me, becouse II need classical console. I wrote a module with hidden password (secret process - no response on console - silent) If match then redirect to boot linux. The nature of the process is that another user on my PC not venture a guess that there is a GRUB and secound linux OS! Security through obscurity is never a good idea and especially not when you have to give away the source code. You have to give the source code when requested, or distribute it on-disk along with the binary... neither of which compromise security here. It's I doubt that putting a copy on a hidden partition satisfies the GPL. Here, let me sell you some GPL software on a DVD, oh yeah there's an advertisement video on a second track and the source code is embedded via stenography. not a secret algorithm; it's a secret that GRUB is there at all. (GPLv3 section 5.d , if obeyed strictly, might break this secret -- but that is all). The secret password to activate GRUB may be in the source code, or possibly the algorithm
Re: Lead-up message 'Welcome to GRUB!' inverted text printed lowlevel via BIOS ?!?
On Sun, Feb 21, 2010 at 4:00 AM, Robo L robo.om...@gmail.com wrote: Hi all, Firstly I would like to thank everyone for the reply and Your time. I would like to clarify the issue. First I need to hide the very first Welcom message because I need to hide GRUB for other users of MS Windows on my PC. I need it only for myself. I'm not entirely certain, but: (1) I think GRUB is licensed under GPLv3 or higher only (2) GPLv3 covers what were considered to be loopholes in GPLv2 (firmware enforced signature, software-as-a-service) therefore (3) Your use of GRUB (copying it into the boot record) requires you to provide your users with notice of their GPL rights to your version of GRUB. So one can hardly say that another user on my PC not venture a guess that there is a GRUB if you are required to tell them that GRUB is there and offer them the source code. Richard: redirection is not good idea for me, becouse II need classical console. I wrote a module with hidden password (secret process - no response on console - silent) If match then redirect to boot linux. The nature of the process is that another user on my PC not venture a guess that there is a GRUB and secound linux OS! Security through obscurity is never a good idea and especially not when you have to give away the source code. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Lead-up message 'Welcome to GRUB!' inverted text printed lowlevel via BIOS ?!?
2010/2/20 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com: Robo L wrote: I mean, that Grub print via lowlevel printig (int 0x10) with proprietary string data. It's true that most BIOSes are proprietary and we're against non-free firmware. Unfortunately, however, most motherboards around aren't supported by any free firmware so we have to cope with what we have. We How is any of this relevant to the OP's question? I think it is, somewhat, but you haven't made the connection. Also, the OP doesn't appear to be looking for a better way to print the welcome message, or to understand why the welcome message is printing via int 0x10, but actually to remove the welcome message. About the only legitimate case I can think of is if the BIOS is redirecting output to a serial port and the presence of a welcome message confuses an automated system on the other end of the serial link that isn't expecting it. encourage you to use motherboards with free firmware. I'm aware of 3 categories of such: 1) Coreboot has made a great job in freeing x86-based mobos. You can consult their list here: http://www.coreboot.org/Supported_Motherboards 2) Touchbook by always innovating http://alwaysinnovating.com/home/index.htm claims to use U-Boot and supply the complete sources. I haven't checked this claim however 3) Yeeloong by Lemote http://www.lemote.com/english/yeeloong.html. It uses PMON, soon GRUB will work as firmware on it too (big parts are done) On BIOS grub uses its interrupts by default because this interface usually supports the hardware user has and on coreimg stage it allows to shave off few bytes. However we move to using our own drivers since firmware interface is often buggy and/or incomplete. Please can You tell me what is a reason? How is a solution? Is it a correct by the licence? GRUB doesn't link with BIOS Many thanks Robo -- - E=mc2 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Lead-up message 'Welcome to GRUB!' inverted text printed lowlevel via BIOS ?!?
On Thu, Feb 18, 2010 at 4:24 AM, Robo L robo.om...@gmail.com wrote: Hi All I have a problem with remove the message Welcome to GRUB! in text Mode. In source 1.96 I remove Welcome text message, when call function grub_printf(). In gfx mod is all OK, but If I not initialize gfx mode grub steel show Welcome to GRUB! inverted (black on white) I mean, that Grub print via lowlevel printig (int 0x10) with proprietary string data. Please can You tell me what is a reason? How is a solution? Is it a correct by the licence? The license does not allow you to install or run GRUB on a computer without telling the user, if that's what you're after. The license lets you remove the welcome message, but you still MUST inform the user of their GPL rights to the copy of GRUB you've given them (and if you are using a copy of GRUB modified to remove the welcome message, then you are responsible for meeting the GPL source code copy requirements yourself, and can't simply direct users to an official download page). Many thanks Robo -- - E=mc2 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: avoid possible overflow?
2010/2/16 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com: Carles Pina i Estany wrote: Hello, The common pattern when doing a search by bisection is something like: + current = min + (max - min) / 2; Instead of the first natural idea: - current = (max + min) / 2; To avoid overflows. In gettext/gettext.c it's used in the incorrect way. It's not a big problem since would happen only with .mo files with lot of strings, like number that int represents in that architecture divided by 2 (aprox aprox.). See the attached file for a patch if we want to patch. You forgot to make the same change before the loop. But actually it doesn't matter because overflow in this statement: internal_position = offsettranslation + position * 8; is reached well before the overflow in bisecting. Anyway this mattersonly for 4GiB files and unless we put videos in .po I don't see how this limit would be reached. So I prefer readability and would reject this patch. There's a very readable way to express the better code that's immune to the overflow: int const range = max - min; /* or unsigned int, if min and max are declared that way */ current = min + range / 2; Else I would at least add a comment that we simplified because we consider that will not happen. Thanks, ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH][UPDATED] support for xz compression format
On Tue, Feb 16, 2010 at 12:58 PM, Szymon Janc szy...@janc.net.pl wrote:
Dnia wtorek 16 luty 2010 o 14:44:45 Vladimir 'φ-coder/phcoder' Serbinenko
napisał(a):
+ #define VLI_MAX_DIGITS 9
Are you sure it's 9? It gives only 63 and not 64 bits
It is a limitation of xz format.
+ if (! test_header(file) || ! test_footer(file))
+ {
Seeking to the end of file is very expensive on pxe. Can it be skipped?
xz stores uncompressed data size at the end of file, without it file size
can't
be set.
gzio has same issue, it reads last 4 bytes of file to determine uncompressed
data size.
Then maybe use of a more sensible format should be strongly
encouraged. For sequentially accessed devices like tape, it may be
expensive to return to the header to add the size. For flash memory,
it may require an overwrite (and flash memory has fast random access,
this is pretty much the only case to prefer a footer). And formats
which support pipelining of course can't rewind to update a header.
But in general the archive will be read many times for each time it is
created, so it's best to put the size in the place which is best for
the decompressor.
Since gzip format allows decompression in pipeline mode, it's a
virtual certainty that nothing from the footer is required for
processing.
And of course this is true of the xz format as well. I quote from the
documentation:
Streamable: It is always possible to create and decompress .xz files
in a pipe; no seeking is required.
http://tukaani.org/xz/format.html
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Framebuffer rotation patch
On Tue, Feb 16, 2010 at 3:05 PM, Michal Suchanek hramr...@centrum.cz wrote:
2010/2/16 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com:
Michal Suchanek wrote:
With typeof macro this can be made type-neutral avoiding potential
mistakes.
+static inline long
+grub_min (long x, long y)
+{
+ if (x y)
+ return y;
+ else
+ return x;
+}
+
I don't see how typeof would be used. As I understand the docs it can
only set types relative to something what is already defined (and in
some cases actually dereference/call it) and there is nothing defined
at the point these functions are declared to copy the type from.
#include stdio.h
#define swap(a,b) {typeof (a) mytemp ## __LINE__; mytemp ## __LINE__ =
b; b = a; a = mytemp ## __LINE__; }
Unlike inlines this pollutes the local namespace with unexpected
identifiers.. Perhaps the temporary variable should be at least
prefixed with an underscore or something.
The braces introduce a block and the variable goes out of scope, in
fact there's no need for __LINE__ because of this.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH][UPDATED] support for xz compression format
On Tue, Feb 16, 2010 at 3:28 PM, Seth Goldberg seth.goldb...@sun.com wrote:
y
Quoting richardvo...@gmail.com, who wrote the following on Tue, 16 Feb 2010:
On Tue, Feb 16, 2010 at 12:58 PM, Szymon Janc szy...@janc.net.pl wrote:
Dnia wtorek 16 luty 2010 o 14:44:45 Vladimir 'φ-coder/phcoder' Serbinenko
napisał(a):
+ #define VLI_MAX_DIGITS 9
Are you sure it's 9? It gives only 63 and not 64 bits
It is a limitation of xz format.
+ if (! test_header(file) || ! test_footer(file))
+ {
Seeking to the end of file is very expensive on pxe. Can it be skipped?
xz stores uncompressed data size at the end of file, without it file size
can't
be set.
gzio has same issue, it reads last 4 bytes of file to determine
uncompressed
data size.
Then maybe use of a more sensible format should be strongly
encouraged. For sequentially accessed devices like tape, it may be
expensive to return to the header to add the size. For flash memory,
it may require an overwrite (and flash memory has fast random access,
this is pretty much the only case to prefer a footer). And formats
which support pipelining of course can't rewind to update a header.
But in general the archive will be read many times for each time it is
created, so it's best to put the size in the place which is best for
the decompressor.
Since gzip format allows decompression in pipeline mode, it's a
virtual certainty that nothing from the footer is required for
processing.
I know I've said this before, but it bears repeating: Don't forget about
network booting! This is precisely the problem for which we came up with a
different solution for loading large compressed archives via tftp when PXE
booting. The assumption, of course, is that you can size a buffer maximally
(with some sane maximum) then shrink it once the archive has been
decompressed. That's what we do and it's served us will with Legacy GRUB
for years now.
In the case of .xz, there appear to be block headers, where the
uncompressed size is stored up front. So as long as separate blocks
can go into independent memory allocations, there'd be no need to
oversize the buffer.
--S
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Setting of PE bit reboots the system
On Sat, Jan 30, 2010 at 12:26 PM, Swapnil Pimpale swapnil.p...@gmail.com wrote: Hi all, I am working on GRUB 2 on Intel Core 2 Duo architecture. As a part of my academic project, I need to bring up the second core. When the second core comes up, I need to switch from real mode to protected mode. For this, I am trying to set the PE bit of cr0 register. But, whenever I set the PE bit the system reboots. Is there any solution on this problem? What do you expect to accomplish on the second core? Are you trying to boot a different OS on each core? Every general purpose OS expects to be activated on the first core with no other cores running and to have possession of all RAM. You'll either need a specialty kernel (for all active OSes) or a virtualization layer. Does the reboot happen immediately when you set the PE bit, or does that cause something to fail later (maybe in the OS startup code)? Thanks, Swapnil Pimpale. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Changes in GRUB help
On Mon, Jan 25, 2010 at 7:22 AM, KESHAV P.R. skodab...@gmail.com wrote: Date: Mon, 25 Jan 2010 09:08:45 +0100 From: Robert Millan r...@aybabtu.com Subject: Re: Changes in GRUB help To: The development of GNU GRUB grub-devel@gnu.org Message-ID: 20100125080845.gi13...@thorin Content-Type: text/plain; charset=us-ascii On Sun, Jan 24, 2010 at 11:15:11PM +0530, KESHAV P.R. wrote: * Add support for Fedora's initramfs (semi-patch attached) - name like initramfs-2.6.31.9-174.fc12.x86_64.img . Your patch looks like it ought to work; have you tested it? Please document grub-extras in grub.enbug.org website. You can do that if you like; it's a wiki. -- Robert Millan Yes, the patch definitely works. It is part of Fedora's GRUB2 src-rpm package. But I changed the 10_linux.in file manually before compiling grub2. The strange thing is that even without any initrd line in the menuentry, the Fedora system boots successfully (my guess is that the Fedora's kernel searches for its compatible initramfs file without relying on grub or grub2). Linux initramfs is inside the kernel binary, not a separate file, and so needs no extra support from the bootloader. As for documenting grub-extras, I don't know how to use a wiki . Also please change the behavior of the help command as soon as possible. Thank you. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Changes in GRUB help
On Mon, Jan 25, 2010 at 3:22 PM, Colin Watson cjwat...@ubuntu.com wrote: On Mon, Jan 25, 2010 at 03:12:51PM -0600, richardvo...@gmail.com wrote: On Mon, Jan 25, 2010 at 7:22 AM, KESHAV P.R. skodab...@gmail.com wrote: Yes, the patch definitely works. It is part of Fedora's GRUB2 src-rpm package. But I changed the 10_linux.in file manually before compiling grub2. The strange thing is that even without any initrd line in the menuentry, the Fedora system boots successfully (my guess is that the Fedora's kernel searches for its compatible initramfs file without relying on grub or grub2). Linux initramfs is inside the kernel binary, not a separate file, and so needs no extra support from the bootloader. Linux *can* behave this way if you want it to, but most distributions do not set it up like that. This mode is usually only used by self-built kernels, and it's not universal even there since sometimes it's more convenient to be able to change the initramfs separately. Linux 2.6 MUST have an initramfs. You can either embed one inside the kernel or let the kernel create one dynamically with hardcoded content. I suspect you're thinking of initrd, which is optional. After creating or copying the initramfs from within the kernel image (thus establishing a ramfs mount point), the kernel will decode and copy the content of any initrd selected by the bootloader to the mounted ramfs. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [multiboot] command-line format
Also, I firmly believe that we shouldn't be satisfied with flawed solutions just because they're part of our legacy baggage. We can do better than this because Free Software is more flexible and more powerful. For example, NetBSD can distribute its own version of GRUB and patch it, and coordinate an interface change between GRUB and its kernel, etc. I think a bootloader with universal in its name should be doing everything possible to avoid this. If I want to multiboot between Linux, NetBSD, OpenSolaris, and OpenBSD, do I load my MBR with the BSD fork of GRUB, the Linux fork of GRUB, or the Solaris fork of GRUB? This really is a non-solution. I think that defaulting the first parameter to the value used by what, 90% of kernels, but providing a way to override it (I like the variable idea) will be the least surprising for users. The path is filesystem-relative anyway, so GRUB isn't required to know how the kernel names its devices, nor do changes to grub device addressing change the parameter passed. But the current behavior requiring the user to explicitly specify the 0th parameter certainly works, and if the format is to be changed then during the switch from GRUB Legacy to GRUB2 is the ideal time to do it. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multiboot ammendment: non-VBE video
On Sun, Jan 3, 2010 at 10:35 AM, Isaac Dupree
m...@isaac.cedarswampstudios.org wrote:
Robert Millan wrote:
In this case color_info is defined as following:
I'd appreciate if a native English speaker confirms this, but I believe
this should say as follows (same for the other instances of this
construct).
as follows reads naturally to me, as a native speaker (also checked:
online dictionaries mention the phrase as follows without saying it's
specific to my area -- northeast U.S. -- so I think it's right to use)
+1 for as follows
+...@samp{framebuffer_palette_addr} contains address of array of
@samp{framebuffer_palette_num_colors} following structures:
There seems to be some word missing here.
the following structures?
as follows would also work well if structures isn't an important word to
keep?
wait, it's like saying array of 3 following structures, each of the same
type. hmm. @samp{framebuffer_palette_num_colors} structures as follows?
How about this?
XYZZY contains _the_ address of _an_ array of N structures which follow
-Isaac
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.info
2009/12/31 Bruce O. Benson bben...@gmail.com: 2009/12/31 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com Bruce O. Benson wrote: 2009/12/30 Bruce Dubbs bruce.du...@gmail.com mailto:bruce.du...@gmail.com Bruce O. Benson wrote: All contributors can safely, legally add/merge/move stuff there if desired, delete anything/everything I wrote, add attributions I could not find, etc. It's not how it works. For the documentation to be accepted to GNU project contributors have to sign legal papers. Now I'm going to comment on value of manual: Installation via Package Management is distribution-specific so it's inappropriate for upstream manual Building / Installation from Source is a part of INSTALL and we already have this Utilities - description of tools is inappropriate. User doesn't care if it's ELF or text file but how to use them. Pre-Boot - is wrong. MBR doesn't point anywhere it's executable code. grub-rescue part is wrong too Lua shell is part of grub-extras, not grub itself. In whole the manual is vague, contains inappropriate or inexact information. If we merge any part of this manual into bzr we would need to proofread every patch This is the typical problem of contributing complaints vs. code. In Vladimir's defense, he contributes lots of code. Thanks for trying to do the documentation which he hasn't. All of the above information ought to be findable from the grub online manual. Things which aren't part of grub core, such as distro-specific packaging, are probably well-served by a link to the package documentation at that distro's site; a link is better than pretending the greater ecosystem doesn't exist, while avoiding making the grub project responsible to documenting scripts and package managers beyond their control. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
On Mon, Dec 28, 2009 at 9:21 PM, Zhu Yi yi@intel.com wrote: On Tue, 2009-12-29 at 06:04 +0800, Isaac Dupree wrote: Option 1~3 requires the recover has the knowledge of the backup file format somehow, but a simple dd is enough for option 4. What do you think? If the partitioning had been changed in the mean time, 4 would overwrite it with the older values. Similar problem for a weird setup with partitions in between (I dunno, might be possible with GPT or other weirdness). Good point. I think option 2 or 3 is soundest. Option 2 would have three separate files of information, (right?), and there must be a pretty straightforwards `dd` option to skip to the correct start position. Option 3 would omit the start position file... but that file is really cheap, maybe we'd better keep things simple for restorers and stick with three separate files.(Or, we could do something weird like putting start-position somewhere in the filename of the backup.) This requires the restorer to understand the role of each of the 3 (or 2) files and use `dd' twice with correct options. So an important thing is, we need to document this somewhere. And I think the best place is to document it in the grub-install script. Because this will enable the not-so-advanced user to recover her boot sectors easily as well. If we decide so, we go back to option 1 (my original implementation). Because the backup file format is not important any more as it is totally transparent to the restorers. Am I right? Another option would be to start the backup file with #!/bin/sh ... Thanks, -yi ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub is the bootloader used on Win7?
On Fri, Dec 25, 2009 at 3:21 PM, Felix Zielcke fziel...@z-51.de wrote: Am Freitag, den 25.12.2009, 19:15 -0200 schrieb Renato S.Yamane: Hi, I´m a GNU/Linux user, but I have a computer with Windows too (fresh install, with NO Linux installed) Recently, my RAID5 failed, sometimes I get a corrupetd system and I see Windows loading GRUB! Anyone now if Windows7 is using Grub as default bootloader (because I don´t believe that Grub is installed on my BIOS)? - This is the first message error: http://img31.imageshack.us/img31/7215/img0227s.jpg - When I press Enter I see this: http://img10.imageshack.us/img10/5285/img0225jm.jpg - And this is the commands available: http://img85.imageshack.us/img85/7056/img0229w.jpg Best regards and Merry Christimas! Renato S. Yamane Official Windows 7 from Microsoft unmodified, i.e. not some preinstalled OEM Version does clearly not use GRUB4DOS nor plain GRUB Legacy nor GRUB 2. They still use bootmgr which they introduced with Vista, which is basically though the old ntldr from NT4/2000/XP just a bit modified. SLIC is part of the mechanism Windows (many versions) uses to volume license to OEMs and enable OEM recovery disks which only work on a particular brand or model of computer. The SLIC is supposed to be included in the system BIOS by the OEM... but software pirates sometimes patch the SLIC into the BIOS or use a hotpatch program to load it before booting into Windows (Windows can't tell whether the SLIC came legit from an OEM BIOS or from a user hack). It looks like this system is running an illegal copy of Windows, or at the very least improperly activated. Since Windows 7 was released only in October, there should still be time to get a refund from the company who sold you the fake copy of Windows, the Microsoft Anti-piracy hotline would probably be helpful in forcing the company to provide you with a legitimate copy. http://www.microsoft.com/piracy/reporting.mspx ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
In conclusion, I believe this backup feature is useful and either implementation should do the work. If we can merge the good parts of them, we can get a better one. I just curious why the thread is stuck since September. Any blocking issues with it? Can we keep the topic moving forward? Your comments are highly welcome. The reason is very simple. If you are good user, you should have already backed up your copy on your own. And this feature is not necessary. That opinion was voiced, then countered and I think even the author of that opinion eventually retracted it. An automatic backup is valuable both for savvy users who know how but forgot, and for those who will find the backup and restore procedures online only after their computer is bricked. -Garimella Kashyap ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: gettext: commands/hdparm.c
On Sun, Dec 6, 2009 at 12:25 PM, Carles Pina i Estany car...@pina.cat wrote: Hello, commands/hdparm.c has some grub_printf's: grub_printf (Model: \%.40s\\n, le16_to_char (tmp, idw[27], 40)); grub_printf (Firmware: \%.8s\\n, le16_to_char (tmp, idw[23], 8)); grub_printf (Serial: \%.20s\\n, le16_to_char (tmp, idw[10], 20)); To have a proper alignment it needs to code something (dynamic tab). I could change it to: grub_printf (_(Model:\t\%.40s\\n), le16_to_char (tmp, idw[27], 40)); grub_printf (_(Firmware:\t\%.8s\\n), le16_to_char (tmp, idw[23], 8)); grub_printf (_(Serial:\t\%.20s\\n), le16_to_char (tmp, idw[10], 20)); Or just don't translate Model/Firmware/Serial (leave like it's now) Or do the dynamic coding that maybe it's not needed... Thoughts? How about using the string width specifier to control padding? grub_printf (%20s \%.40s\\n, _(Model:), le16_to_char (tmp, idw[27], 40)); -- Carles Pina i Estany http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: USB device not seen by grub
On Fri, Dec 4, 2009 at 3:36 PM, Robert Millan r...@aybabtu.com wrote: On Thu, Dec 03, 2009 at 06:27:07PM -0600, richardvo...@gmail.com wrote: 2009/12/3 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com: Chris Jones wrote: I am trying to have grub boot off a partition on a USB stick. You can't chainload to disk invisible by BIOS. But you can load supported OSes from it. What would be necessary to enable chainload to such devices? Install an IRQ 19 handler? Yeah, something like that. In essence, GRUB acting as a BIOS. Sounds awful, but hey we already have efiemu. As Vladimir says, the legacy grub map command must already be installing such a hook (although it proxies implementation to the existing BIOS after changing the drive number, rather than calling a grub storage driver). Invoke the extension ROM of the host adapter so that it hooks IRQ 19? There's usually no such ROM. Except for adapters that come in discrete PCI cards. And even then, I doubt it's always present. There are actually quite a lot of devices like this. Most notebooks have broken BIOS that won't load the extension ROM from a PCMCIA slot, if grub could do so it would enable booting from a wide variety of PCMCIA/CardBus/ExpressCard-to-SCSI/SATA/USB adapters. Here's one example that I happen to own, and got frustrated with system BIOS not allowing boot from expansion card: http://www.newegg.com/Product/Product.aspx?Item=N82E16820161325cm_re=SolidGO-_-20-161-325-_-Product I'm fairly sure there is an extension BIOS because some people report being able to boot from it, however most laptops cannot. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: USB device not seen by grub
2009/12/4 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com: Robert Millan wrote: On Thu, Dec 03, 2009 at 06:27:07PM -0600, richardvo...@gmail.com wrote: 2009/12/3 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com: Chris Jones wrote: I am trying to have grub boot off a partition on a USB stick. You can't chainload to disk invisible by BIOS. But you can load supported OSes from it. What would be necessary to enable chainload to such devices? Install an IRQ 19 handler? Yeah, something like that. In essence, GRUB acting as a BIOS. Sounds awful, but hey we already have efiemu. It's by far not the same thing. EfiEmu emulates only RuntimeServices. EFI has two types of functions: BootServices and RuntimeServices. BootServices are only available when boot loader is running and are terminated on kernel launch. RuntimeServices are always available but have very small number of functions. And actually GRUB acts only as a loader to efiemu??.o and real functions are contained in efiemu??.o which is quite small For BIOS disks emulations we would need much more functions but we could adopt a similar approach. E.g: bioshook usbbios.o parameters chainloader (usb0,1)+1 usbbiso.o may of course be compiled from GRUB files but has to be standalone. There are few tricky parts associated with this process but basically it would be an overblown drivemap. But I don't see any real reason to make even small fraction of required effort since GRUB2 is able to load many free OS directly and so can load them of an BIOS-invisible disks without any problems. Some free OS are still out of GRUB family like Minix is but I would gladly accept a port of it (which is orders of magnitude easier to do) As of proprietary OS I think we need to support them only to the etent of what they are able to do themselves. Documentation on such OS are often scarce and anything we do may completely break with new version. SCSI adapter vendors manage to implement IRQ 19 in a way that provides universal OS support, I don't see how this would be different. And all of this only to make good to someone who would like to see every free software die? Not all supporters of free software share that philosophy, quite a few of us like to be able to tell people that proprietary software you use, well, it works better with free software. And sometimes free software is enriched by playing well with closed-source. For example, more people would dual-boot if there was a grub-tools package for Windows and Mac OS that added Reboot to linux to the start menu (by changing the default boot selection in the grub config). If grub-win existed which could install grub from inside Windows, we'd have even more users of both grub and free OSes to dual-boot with. And a Windows driver that jumped directly to grub code at an appropriate point during shutdown (i.e. after flushing disk write caches, which is probably when anti-virus drivers unload) thereby avoiding the BIOS POST delays and making dual-booting even faster and less painless would equate to even more users. I happen to have a licence for VMWare workstation 6.x which emulates a USB host controller (IIRC devices include emulated mouse as well as real devices attached to the host, including mass storage), but doesn't support booting from it. This annoyed me at one point when I was trying to prepare a bootable USB stick and couldn't test it. So I'm willing to give this a shot. Which Linux distribution do most of you use for grub development (I value the fact that commands to install the correct version of bzr, which I've not used before, were recently posted to the list). That was for Debian Lenny, but would I get started faster with another version? NB: I'm most experienced with gentoo, which is definitely NOT a quick start. Ben Voigt ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: USB device not seen by grub
2009/12/3 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com: Chris Jones wrote: I am trying to have grub boot off a partition on a USB stick. You can't chainload to disk invisible by BIOS. But you can load supported OSes from it. What would be necessary to enable chainload to such devices? Install an IRQ 19 handler? Invoke the extension ROM of the host adapter so that it hooks IRQ 19? Hook some other system calls? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Faster glyph lookup by BMP index
Is this table stored in the file or built during font load? 128KiB in memory is no issue at all on modern systems, 128KiB in a file is somewhat more troublesome since it won't fit in a boot sector, is a big chunk of a rescue diskette, and the I/O cost is noticeable. These glyphs are stored in sorted order in the file, correct? May I suggest that only every Nth index be stored in the file header (where N = 16 for example) and the intermediate ones discovered at runtime, in those subranges containing a character actually used (and the indexes and character data for those glyphs are then cached in memory)? This also means block reads from the file (block length is easily calculated as the difference of two adjacent indices) instead of extraction of individual characters, most languages tend to have good locality so this should also be a win. Or is the entire font file cached in memory anyway? 2009/11/29 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com: Hello. Basic Multilingual Plane is range of Unicode characters in 0-65535 and it contains most of the characters needed by most of the languages of the world. By keeping an array with pointers to such characters at the cost of 128KiB per font we can almost instantenously lookup characters which are likely to be used in grub. Available in experimental -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub-devel Digest, Vol 69, Issue 19
On Tue, Nov 10, 2009 at 4:06 AM, Pedro A ARANDA paag...@hotmail.com wrote:
Hi all,
just my .2 euto-cents:
With this function, you always assume that strlen(s1) = strlen(s2),
right?
int
grub_auth_strcmp (const char *s1, const char *s2)
{
int n;
volatile int ret = 0;
for (n = grub_strlen (s1); n = 0; n--)
{
if (*s1 != *s2)
ret |= 1;
else
ret |= 0;
s1++; s2++;
}
return ret;
}
because if not, you'd have to
if (*s1 == 0 || *s2 == 0)
break;
in the loop and the return would be something like
return *s1 == 0 *s2 == 0 ret == 1;
And then you can continue simplifying to
while (1) {
if (*s1 != *s2) break;
if (*s1 == 0) break;
if (*s2 == 0) break;
s1++; s2++;
}
return *s1 == 0 *s2 == 0;
Again, just my .2 euro-cents or less
That's a good efficient strcmp, but the execution time leaks all kinds
of information about the secret. Specifically, when there's a front
subset match, the function will run longer. That allows a brute force
attacker to break the password in linear time with the password length
instead of exponential time. auth_strcmp is specifically trying to
avoid any data-dependent branching.
Cheers,/PA
Windows Live: Keep your friends up to date with what you do online.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Tue, Nov 10, 2009 at 8:25 AM, Duboucher Thomas tho...@duboucher.eu wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bean a écrit :
Hi,
Oh, I just come up with a better way to do this:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
char r1 = 0;
char r2 = 0;
char *p;
int i, c;
p = r1;
c = 0;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
*p | = (*s1 ^ *s2);
if ((int) *s1 == c)
{
p = r2;
c = 0x100;
}
}
return (r1 != 0);
}
The condition (int) *s1 == c would be true exactly once.
Well, it seems I lost something somewhere. I don't understand the need
of doing it exactly sizeof (grub_password_t) times, except from having a
perfectly symetric function. IMHO, stopping the comparison when the
input buffer is done reading, or when the maximum size of a passphrase
is reached does not leak any information to the attacker. So I would
stick to
typedef char grub_password_t[1024];
int
auth_strcmp (const grub_password_t input, grub_password_t key)
{
int retval, it;
for (it = retval = 0; it PASSPHRASE_MAXSIZE; it++, input++, key++)
After changing the parameter type, those postincrements won't do what
you expect.
{
retval |= (*input != *key);
if (*input == '\0')
break;
}
return !retval;
}
Also, take care that it requires to check how the function is
optimized; sometimes you have surprises ... ;)
Thomas.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkr5d90ACgkQBV7eXqefhqio+QCfba54+l45DiQNyI3IzfnwgvVe
tbUAnRTPI+yYSZoVZLfM9fze7c7cvRQN
=EjYS
-END PGP SIGNATURE-
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Mon, Nov 9, 2009 at 4:46 PM, Duboucher Thomas tho...@duboucher.eu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Millan a écrit : On Mon, Nov 09, 2009 at 10:43:48PM +0100, Duboucher Thomas wrote: Well, the only way to solve that problem would be IMHO to add a limit to the size of s2, and use this maximum size as an end condition for the 'for' statement. Any better idea? :) We have a maximum line read size anyway. If we do this, we might as well make that limit global so that the macro can be shared with this routine. Sounds good to me. :) Any ideas for renaming s1 and s2? correct_key and attempted_key But there seems to still be potential for overflow on one of the strings. Are both strings in fixed-equal-length buffers? That should be clearly documented. Thomas. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr4m8EACgkQBV7eXqefhqj9SgCgjHomnoIkzzu5WuTCZQVcB/8t cwcAn1EkevCL3PXGlIuhLzFPlER9fXD3 =okR/ -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
Hello,
I'd be concerned about (s1 != s2). Depending on how efficiently this
compiles, could not branch prediction make this faster for match vs. not
match, etc?. I'd be worried about all the ways (and future ways) compilers
might help us and introduce time differences.
I was avoiding suggesting new conditionals for that reason, but didn't
see the one already there. Good find.
I'd feel most comfortable with the time delay, but why not stick to complete
artithmetic?
I agree. But I think you've inverted the return value (strcmp returns
0 on perfect match).
int i;
int acc = 0;
for(i=0;iMAX_LEN;i++,s1++,s2++)
{
acc |= (*s1 ^ *s2);
if (*s1 == 0)
break;
}
return (acc == 0);
Also, these strcmp functions don't properly return or . Just = / !=.
However, my context being so new is quite limited.
Darron
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-1.97
On Wed, Oct 28, 2009 at 11:02 AM, Bruce Dubbs bruce.du...@gmail.com wrote: Michal Suchanek wrote: 2009/10/28 Bruce Dubbs bruce.du...@gmail.com: I'd also like to make a comment. It may be useful if you split up the build into subdirectories by component. When I extracted the tarball, there were 57 files/directories in the top of the build tree. After configure it was 64. So far so good. However, after make it was over 2400 files, many with very long file names. This makes it almost impossible to navigate form the command line, even on a very big screen. If you split it up, you could also shorten the filenames. I would think that would be an advantage to encourage programmers to read the code and contribute to the project. I guess it's meant to be used like this: tar -jxvf grub-version.tar.bz2 cd grub-version mkdir build cd build ../configure./configure --prefix=/usr \ --sysconfdir=/etc \ --disable-largefile \ --disable-grub-emu \ --disable-grub-emu-usb \ --disable-grub-fstest \ --disable-efiemu --prefix=/some_prefix --options make make install Yes, that is exactly what we are doing. Right now the configure line is Not exactly, and the difference is important.Michal suggested running ../configure with a double-dot meaning parent directory. Your line has only a single dot, meaning current directory. As a result your files are all mixed together instead of separated as intended. ./configure --prefix=/usr \ --sysconfdir=/etc \ --disable-largefile \ --disable-grub-emu \ --disable-grub-emu-usb \ --disable-grub-fstest \ --disable-efiemu ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Macbook, Efi, Display mode
I have an idea what might be wrong in my gentoo kernel. I hope I find the time for a little bit of testing, tomorrow. Did you compile it yourself (emerge gentoo-sources/vanilla-sources/hardened-sources then make menuconfig then make bzImage) or did you use genkernel? greetings, Stefan ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Macbook, Efi, Display mode
On Sat, Oct 24, 2009 at 7:38 PM, Stefan Bienert bien...@zbh.uni-hamburg.de wrote: richardvo...@gmail.com wrote: I have an idea what might be wrong in my gentoo kernel. I hope I find the time for a little bit of testing, tomorrow. Did you compile it yourself (emerge gentoo-sources/vanilla-sources/hardened-sources then make menuconfig then make bzImage) or did you use genkernel? I just used gentoo-ources without any patching by myself. Then you should be able to add EFI display support quite easily during the make menuconfig step greetings, Stefan ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [2637] 2009-10-16 Colin Watson cjwat...@ubuntu.com
On Sat, Oct 17, 2009 at 6:40 AM, Vladimir 'phcoder' Serbinenko phco...@gmail.com wrote: Robert Millan wrote: On Fri, Oct 16, 2009 at 03:38:44PM +, Colin Watson wrote: Revision: 2637 http://svn.sv.gnu.org/viewvc/?view=revroot=grubrevision=2637 Author: cjwatson Date: 2009-10-16 15:38:42 + (Fri, 16 Oct 2009) Log Message: --- 2009-10-16 Colin Watson cjwat...@ubuntu.com * configure.ac (TARGET_CFLAGS): Add -mno-mmx -mno-sse -mno-sse2 -mno-3dnow on x86 architectures. Some toolchains enable these features by default, but they rely on registers that aren't enabled in GRUB. Thanks to Vladimir Serbinenko for the suggestion. Would it be preferable to enable those registers instead? They are disabled for following simple reason: imagine an OS which isn't aware of those registers. Then if user simultaneously launches two applications which use those registers then they won't be preserved accross context switches leading to bugs. I don't know if there is a way to disable these registers again after enabling them. I don't think grub2 will benefit a lot because of I think this cannot be accurate because virtual machines would be badly broken (registers enabled by the host, guest without awareness is exactly the situation you describe). mmx/sse/sse2/3dnow because we don't use floating point arithmetics. If I remember correctly sse has some commands for operations on parallel operations on integers but the only place I see where benefit could be considerable is decompression and decryption. If it's proven that For example, memcpy is much faster using those extended instruction sets. Maybe that's not an important use case for grub2 either. decompressing/decrypting with SSE makes it considerably faster then enabling SSE would be a good thing. Anyhow for now we can just disable MMX/SSE/SSE2/3dnow and when someone implements handling those registers he can enable them again On FreeBSD kernel itself is compiled without MMX, SSE, SSE2 and 3dnow to avoid to have to handle them on kernel threads switches. -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Refuse to install on XFS destroying its superblock
On Sat, Oct 17, 2009 at 7:09 AM, Vladimir 'phcoder' Serbinenko phco...@gmail.com wrote: Robert Millan wrote: On Sat, Oct 17, 2009 at 01:43:37PM +0200, Vladimir 'phcoder' Serbinenko wrote: Robert Millan wrote: On Sat, Oct 17, 2009 at 12:18:05AM +0200, Vladimir 'phcoder' Serbinenko wrote: 2009-10-16 Vladimir Serbinenko phco...@gmail.com + * util/i386/pc/grub-setup.c (setup): Refuse to overwrite XFS superblock. + (options): New option --destroy-xfs. + (main): Handle --destroy-xfs. I gave this some more thought, and I think this could be less ad-hoc. We're treating XFS as if it were a weird, unique thing just because it isn't biased towards DOS-style boot like most filesystems are. Instead, I've done something more generic, using our standard filesystem probing engine which should be more reliable than a single memcmp. The danger is that fs_probe may reject filesystem as valid just because it's newer than expected. What do you mean with reject filesystem as valid? Sorry for being unclear. I just meant that if some XFS structures are updated then our xfs driver won't recognise it as xfs Then instead of blacklisting xfs, why not whitelist filesystems which are known to have usable blocks for embedding (doesn't the number of blocks vary with filesystem anyway?) and an override parameter (--into-unrecognized-fs). -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Handling multiple cores by GRUB
On Thu, Oct 15, 2009 at 11:44 AM, James Courtier-Dutton james.dut...@gmail.com wrote: 2009/10/14 Robert Millan r...@aybabtu.com: But I don't think this would be desireable except in very specific situations, and I'm not sure which ones. Perhaps loading a compressed file would be an example (so that uncompression and disk poll can be done in parallel). Not specifically related, but why is grub reading a file from a USB stick so slow when compared with say reading the HD. I mean slow, it is about 20 times slower here. What model USB stick? Consumer-grade NAND flash controllers really are 10-15x slower than a recent SATA hard disk. (7MB/s vs 110MB/s on read). Only the expensive SSD, which access many NAND flash chips in parallel, can meet or exceed hard disk speeds. And USB 2.0 High Speed maxes out at about 1/3 of hard disk speed, Firewire 800 or USB 3.0 Ultra or eSATA would overcome that. But most likely you are just using slow flash memory with a cheap controller. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
I am suggesting an interface that allows style commands like
style {
(class==button).(text==OK) { style }
(class==dialog).nothing here.(class=button) { style }
(class==buttonbar) { direction = right_to_left }
(class==button) {
border_top = button_top
border_left = button_left
...
}
}
I don't like this. It's a unit testing nightmare. Matter of fact, so
is auto-layout. I don't want my bootloader to be a web browser. I
want it to be reliable and load fast.
At the very least, please keep the actual boot sequencing (the stuff
equivalent to menu.lst of grub-0.97) separate and let the GUI stuff
incorporate them by reference. Then provide a hotkey (e.g. hold 'R'
during boot) to skip all GUI (and I mean skip everything configurable,
not just text vs graphics) and provide a simple selection with no
nesting, no icons, no borders, no fonts, no colors, no multiple lists,
just everything in one big scrollable list, with access to the command
line.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
On Fri, Oct 9, 2009 at 12:09 PM, Michal Suchanek hramr...@centrum.cz wrote:
2009/10/9 richardvo...@gmail.com richardvo...@gmail.com:
I am suggesting an interface that allows style commands like
style {
(class==button).(text==OK) { style }
(class==dialog).nothing here.(class=button) { style }
(class==buttonbar) { direction = right_to_left }
(class==button) {
border_top = button_top
border_left = button_left
...
}
}
I don't like this. It's a unit testing nightmare. Matter of fact, so
is auto-layout. I don't want my bootloader to be a web browser. I
want it to be reliable and load fast.
At the very least, please keep the actual boot sequencing (the stuff
equivalent to menu.lst of grub-0.97) separate and let the GUI stuff
incorporate them by reference. Then provide a hotkey (e.g. hold 'R'
during boot) to skip all GUI (and I mean skip everything configurable,
not just text vs graphics) and provide a simple selection with no
nesting, no icons, no borders, no fonts, no colors, no multiple lists,
just everything in one big scrollable list, with access to the command
line.
The thing is that people *demand* that things are configurable, and
for grub legacy poorly written (possibly because grub-legacy was hard
to extend) patches for that were created which were not incorporated
into the mainline grub-legacy.
So the choice here is to support configurable menu (and try to strip
features as much as possible to keep the complexity reasonable while
still maintain reasonable flexibility) or accept that several ad-hoc
graphics menu implementations will eventually emerge on the net.
Or you can stop trying to solve all the world's problems (and getting
an equivalent number of bugs), and design something that lends itself
to extension.
You've already got modules. I think that if you provide the following
few functions, people will make mutually compatible extensions that
could then be merged into the main tree as desired:
Some data structure for holding the boot sequence commands, like grub
legacy's menu.lst but without the look-and-feel stuff.
Enumeration of available boot sequences (and possibly bootable media
not listed in the user's configuration).
A function for executing a particular boot sequence by id-string.
A function for printing text in text-mode.
A class for holding a screen-buffer. (readable attributes such as
width and height)
A function for presenting the screen-buffer, and returning after a key
is pressed or timeout (or possibly if bootable media is inserted).
A function for filling a rectangular subregion with a specific color.
A function for drawing a box (flags for which sides to draw, color of
sides, and single-or-double line, and raster-combining op such as XOR
to help with highlighting selected items).
A function for drawing a bitmap.
A function for drawing a string (specify color).
A function for obtaining the user's stored GUI configuration (content
is specific to the extension).
And a global setting that specifies which GUI extension is to be loaded.
You can provide a couple prebuilt extensions such as simple scrolling
text list selectable with arrow keys ala grub-legacy (no GUI
configuration) and a fancier one more like rEFIt with one horizontal
list of kernel icons above and a set of tools below (GUI configuration
is the set of items to place in the toolbar, all others go in the
kernel list). These are small enough in scope to get right and cover
completely with tests.
Yes, fancier menus will emerge out on the net. Yes, they'll be
incompatible and have some duplication of effort in terms of
auto-layout. But every one of the auto-layout routines will be far
simpler, because it doesn't have to let the user choose how to divide
space, etc. Each only has to accommodate more items in the
already-defined layout. Plus, users can always fallback to a good
version and recovery from a messed-up GUI configuration will be made
easier.
And, you can work on an extension which is the infinitely-flexible
pseudo-CSS pseudo-HTML autolayout engine you're already started on.
But I'm suspicious that it'll never be finished because the scope is
so large.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
Hi, I think you've overlooked a detail about grub's menu layout. The smallest elements, text and image, both have fixed size, The largest element, the screen, also have fixed size, therefore, we need to adjust the middle layers to fit both ends, it's not as simple as it seems. There are two method to calculate the size of window. It can be calculate using children widget, with auto layout, or parent widget, with x,y,width,height coordinate, as the smallest and largest element are fixed, we need to switch from children determined size to parent determined size at some point during the walk of ui tree. For operation system, the switch is at the window boundary. Consider web browser. Inside the browser, elements are placed with layout manager, no coordinate is needed, but the browser itself is placed on the screen using x,y,width,height coordinate by the OS. For some OS like chrome, it seems to incorporate the concept of using the whole screen as browser. The menu system support both method, it's just a matter of how you define the border, that's, when to switch from x,y,width,height positioning to layout manager positioning. Therefore, it needs to have two set of margin properties: inner_*, outer_* : calculate from children to parent I think that margin and padding are the standard names for this spacing measurements (distance from content to border) and (distance from border to bounding box), respectively. Also in some systems padding of adjacent elements can overlap. attach_* : calculate from parent to children -- Bean gitgrub home: http://github.com/grub/grub/ my fork page: http://github.com/bean123/grub/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
Perhaps the naming of margin_* property is a little misleading, perhaps I can rename them distance_* to remind it they're used as fixed distance to borders of parent. That's undoubtedly the problem. For example, Motif uses the term attach to achieve fixed distance from the edge of the parent (or from a sibling component). See e.g. http://www.cs.cf.ac.uk/Dave/X_lecture/node8.html ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
- the border settings offer many options but I miss the option for - setting the text border explicitly to single/double border without using an image I think image is most flexible, who want ascii border in graphic mode ? BTW, border in graphic mode doesn't necessary be full character size, so text may not draw properly anyway. About the single/double border, it's more suitable to config them using styles other that property. Can't one obtain an N pixel solid border by using a parent panel with background = border color, and client panel just a few pixels smaller using the margin-positioning directives? This should give a border without needing a new set of commands, nor image files. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Create environment block safely
You might also need to check for the alternate name, in case the operation failed after writing the new content and unlinking the old file, but before renaming the new file. There is no old file here, or if there is then the user has already explicitly indicated that they don't care about it. There is no unlink call in my code (and wouldn't be even if this weren't a create operation; no need to bother when you're renaming over the top anyway). I guess I didn't look closely enough at the rename docs: The rename() system call causes the link named old to be renamed as new. If new exists, it is first removed. Both old and new must be of the same type (that is, both must be either directories or non-directories) and must reside on the same file system. The rename() system call guarantees that an instance of new will always exist, even if the system should crash in the middle of the operation. So my unease was unfounded. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for howmany option in grub2
On Fri, Oct 2, 2009 at 3:53 PM, Robert Millan r...@aybabtu.com wrote: On Sun, Sep 27, 2009 at 08:04:51PM +0200, j...@hkfree.org wrote: Hello, I am using Debian GNU/Linux as my primary system. As a loader I am using GRUB. Actually I have upgraded to GRUB2. I don't know, if it was feature of original (legacy) GRUB or it was functionality provided by debian scripts (update-grub), for generating menu.lst. There was feature - howmany. This option specifies number of kernels, that user wants to have in boot menu. Script, that modifies menu.lst, use this variable. I like this feature, because I have usually more kernels, but I want to see only last two versions in GRUB menu. I have created patch, that add support for this to /etc/grub.d/10_linux. I have created this patch against version shipped with Debian (1.97~beta3-1) - I don't know if there are some Debian specific modifications. Also there should be variable GRUB_HOW_MANY propagated from /etc/default/grub (my patch don't do this). Kernel and it's rescue variant is counted as one kernel. I have already reported this bug to Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548600 Does anyone else think we want an option for this? It seems like feature creep. IMO this is the responsibility of the distro. The distro's package manager is presumably what adds and removes kernels, there's no way that the grub scripts should be expected to know when past kernels have been removed. With more manual-install oriented distros like gentoo, trying to have grub maintain the kernel list like this would be insane, since the local admin determines the naming convention. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Create environment block safely
On Wed, Sep 30, 2009 at 5:54 PM, Colin Watson cjwat...@ubuntu.com wrote: If grub-editenv create is interrupted, it's theoretically possible for it to create an incomplete block that future grub-editenv calls won't recognise. It would be better for it to atomically create either a complete block or nothing. Any objections? Be aware that this may lose security settings. Write-in-place is also different wrt hard links, but it would be pretty odd for that file to have additional hard links. You might also need to check for the alternate name, in case the operation failed after writing the new content and unlinking the old file, but before renaming the new file. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: -Werror and --disable-werror
On Sat, Sep 19, 2009 at 9:12 AM, Vladimir 'phcoder' Serbinenko phco...@gmail.com wrote: Robert Millan wrote: Hi, -Werror is not in effect. This will help ensuring that all new code is checked to be warning-free before commit (incidentally, I found a newly introduced bug thanks to this just minutes before enabling it). If you mean this change: + /* Any value different than `p.offset' will satisfy the check during + first loop. */ + lastaddr = !p.offset; + Then there was no bug here. if (labeln lastaddr == p.offset) return grub_error (GRUB_ERR_BAD_PART_TABLE, loop detected); labeln++; if ((labeln (labeln - 1)) == 0) This is a check for being an integral power of 2 (or 0), i.e. having a single bit set. Was that the intent? It's probably worth an explanatory comment for the sake of those who aren't familiar with the test. lastaddr = p.offset; labeln is 0 during first loop run and then lastaddr is set. I explicitly omitted initing variables to have smaller loop detector I suspect initializing lastaddr, which takes place outside the loop, is less expensive than testing labeln on every iteration. Since -Werror may be a problem in some situations, I've added a --disable-werror switch, which does the obvious thing. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Save boot record before writing to the dest_drive
On Sat, Sep 19, 2009 at 5:09 PM, Colin Watson cjwat...@ubuntu.com wrote: On Sat, Sep 19, 2009 at 11:10:49PM +0200, Robert Millan wrote: I'm sorry, but I really see very limited usefulness in this. It's only potentially useful to expert users, but those should know how to backup sectors in their disk already. Of course, like many restore facilities, it's only useful if you remembered or realised that you needed to do the backup before the data was overwritten ... As a user of grub, I think that automatically making a backup is nice, as long as: (1) I can specify not to make the backup (2) It doesn't overwrite any existing file unless I explicitly specify the filename It would be nice to have a straightforward answer to the sort of bug report that goes argh, I installed Debian/Ubuntu and it ate the special magic boot loader I carefully installed there five years ago, I must admin. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
On Sun, Sep 20, 2009 at 3:31 AM, Michal Suchanek hramr...@centrum.cz wrote: 2009/9/19 richardvo...@gmail.com richardvo...@gmail.com: On Sat, Sep 19, 2009 at 1:45 PM, Michal Suchanek hramr...@centrum.cz wrote: Hello why does the menu system have a glyph drawing function? Is the one in font.c not suitable? Why are there two methods for returning text width and height, one in gfx_region in pixels, the other in text_region in characters? Does size in characters make any sense? There might be proportional fonts or at least fonts of different size in the future. Pixels and proportional fonts are meaningless to a serial console. So is element placement. I know of multiple systems that support multiple columns, status bar, menu bar, popup dialogs, etc in text mode over a serial connection. If those things are considered out of scope for a bootloader, I'd tend to agree. But people seem to be defining rich interfaces for grub and to do so requires the ability to measure sizes in characters. Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] save_env variable_name=value
On Fri, Sep 11, 2009 at 4:43 PM, Pavel Roskin pro...@gnu.org wrote: On Thu, 2009-09-03 at 17:08 +0200, Robert Millan wrote: Pavel, please comment on this when you can. It seems to me that doing it in grub-mkconfig would require less ad-hoc code in loadenv.mod and make it more efficient. I don't see how grub-mkconfig could compensate for a missing feature in save_env. Perhaps I'm missing the context here. AFAICT, it's grub.cfg that has to work around using two commands instead of one. Therefore grub-mkconfig has to generate a longer grub.cfg (not sure how this makes grub-mkconfig uglier), but that's an incomplete assessment. There's also a different burden placed on user-edited configs and usage of the grub console, correct? I don't think that the suggestion was meant to save a few bytes in grub-mkconfig. I think it was suggesting a nicer interface for users working in the console. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
possible? load extension ROMs when BIOS doesn't (e.g. laptops)
I searched and couldn't find anything like this in the archives, apologies if this has already been discussed or is far off-topic. Many notebook computers can't boot from PCI-express expansion cards (example ExpressCard SATA controllers) for the simple reason that, although the card contains an extension BIOS with boot support, the main BIOS didn't invoke it. Would it be possible for a bootloader on an internal (recognized by main BIOS) disk to call these missed extension ROMs so that the attached disk becomes available for boot? The only thing hurdle I'm aware of, (as an experienced programmer of microcontrollers and user-mode x86, but never x86 boot/kernel code) would be if the main BIOS has not performed Plug-n-Play configuration of these cards so the BIOS isn't even mapped into memory yet. I'm pretty sure that PCI and PCI-express cards would have been configured, and PCMCIA cards wouldn't, and I don't know whether ExpressCard would be waiting for some form of card services. Does this sound like something that can/should be solved in the bootloader? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
