Re: Dell Media Direct button
Javier Martín wrote: 2008/8/20 Colin D Bennett [EMAIL PROTECTED]: On Wed, 20 Aug 2008 12:12:59 +0200 Robert Millan [EMAIL PROTECTED] wrote: On Wed, Aug 20, 2008 at 10:57:22AM +0200, Per Öberg wrote: Hi Some laptops, e.g., from Dell have a special button that they use to boot a special embedded OS for media only instead of the ordinary OS. For my Dell XPS1330M I can determine if the Media button was pressed by first writing 0xf9 to port 0x70 and then testing bit 0x08 of port 0x71. It would be really nice if such a test could be enabled in grub so that grub can go directly to a specific menu alternative without showing the gui if the media button was pressed. Is this interesting? I'd like to contribute but I don't know where to start. Sounds interesting, but this needs some thought on how to design it. I suppose what you want is change the 'default' variable. Perhaps increase it by 1? But then, where do you do this? grub_machine_init is too early as 'default' hasn't been set yet. Maybe we could have a global 'int default_offset' variable that is initialized in grub_machine_init and later on used by normal.mod? If I pressed the Media Direct button, I would also want to have a timeout of 0, since by pressing the Media Direct button instead of the power button, I've already indicated which entry I want to boot, and there is no need to show the menu -- unless, perhaps, we decided to show a different media menu... so hopefully giving all the power to the grub.cfg script would be enough to make all this possible. Regards, Colin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel Well, I own a XPS1330 myself (I'm writing from it now, as I'm taking a week at the beach in Benidorm ^^). This functionality could be implemented by a module that used the pre-menu hooks proposed by Bean: it would check the status before the menu is shown, then act on the result. However, all this assumes that pressing that key creates no additional side effect like the replacement of the MBR by the system firmware, booting another MBR written in flash memory or something like that: I thought the choice took place at the real MBR, but disassembling it revealed that it does not use the mentioned I/O ports interface, so most likely what the system firmware does is set the active flag in the MediaDirect partition. I'm ready to check any related patches on the actual hardware _once I'm back in Madrid_ because here I have no recovery tools. -Habbit ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel It works for me =) See how below... There might be different firmware versions out there and there's been a lot of fuss about early versions of MD screwing up you partition table. There has also been suggestions on how to disable it by overwriting your MBR (http://ubuntuforums.org/showthread.php?t=606345). There seems to be a number of different versions in the range of 1-3 and some uses a hidden HPA partion while some hides the partition by changing the partition id. The installation process and the possibility to upgrade between the different version indicates (not same as proof, i know) that the firmware does about the same for the different releases and that it is the MBR that is important since this is what you install to make it work. Dan Goodell has a website that describes his findings of how the Dell MBR works (http://www.goodells.net/dellrestore/hpa-issues.htm). On this website he indicates that these ports exists. I believe that his documentation is for MD v1-2 and I have v3.3. He has disassembled the MBR code and the procedure showed in the part he sent me showed out to work perfectly when using in my test setup. -- My setup: -- Comp: Dell XPS1330M, Media Direct version: 3.3 Delivered: 2008-07-14 Disk layout: - grub legacy on MBR, - 100Mb (/dev/sda1, Main grub partiton, config chainloads sda2, sda3 or sda5) - 100Mb (/dev/sda2, geexbox, with own grub and grub config files in /boot) - 30Gb, (/dev/sda3, Kubuntu with own grub and grub config files) - Extended partition ~250Gb linux (/dev/sda5, Not using yet but with test-boot-loader) ,~2Gb swap (/dev/sda6) N I have a small boot loader written from scratch, which is attached to the mail, that i dd to /dev/sda5 using dd if=boot.bin of=/dev/sda5 count=512 bs=1 If i press the MD button it will show a splash screen and then show grub main menu, same menu as with ordinary power button (but the graphics mode is different). I can then choose to chainload /dev/sda5 which changes the graphics mode and turns the screen
Re: Dell Media Direct button
Robert Millan wrote: On Wed, Aug 20, 2008 at 10:57:22AM +0200, Per Öberg wrote: Hi Some laptops, e.g., from Dell have a special button that they use to boot a special embedded OS for media only instead of the ordinary OS. For my Dell XPS1330M I can determine if the Media button was pressed by first writing 0xf9 to port 0x70 and then testing bit 0x08 of port 0x71. It would be really nice if such a test could be enabled in grub so that grub can go directly to a specific menu alternative without showing the gui if the media button was pressed. Is this interesting? I'd like to contribute but I don't know where to start. Sounds interesting, but this needs some thought on how to design it. I suppose what you want is change the 'default' variable. Perhaps increase it by 1? But then, where do you do this? grub_machine_init is too early as 'default' hasn't been set yet. Maybe we could have a global 'int default_offset' variable that is initialized in grub_machine_init and later on used by normal.mod? The sequence of writing to port 0x70 / reading from port 0x71 reflects reading from the computer's cmos nvram memory. bit 7 of 0x70 is reserved for disabling NMIs, so the actual information is stored in byte 0x79[8] in the cmos. To allow full flexibility, there should just be a module that allows reading / writing the cmos values (could also be useful for other things, such as reading a boot order set by the bios). Everything else makes more sense in scripting: - changing default - changing timeout - support for bit operations in the parser - etc... -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Dell Media Direct button
2008/8/21 Stefan Reinauer [EMAIL PROTECTED]: Robert Millan wrote: On Wed, Aug 20, 2008 at 10:57:22AM +0200, Per Öberg wrote: Hi Some laptops, e.g., from Dell have a special button that they use to boot a special embedded OS for media only instead of the ordinary OS. For my Dell XPS1330M I can determine if the Media button was pressed by first writing 0xf9 to port 0x70 and then testing bit 0x08 of port 0x71. It would be really nice if such a test could be enabled in grub so that grub can go directly to a specific menu alternative without showing the gui if the media button was pressed. Is this interesting? I'd like to contribute but I don't know where to start. Sounds interesting, but this needs some thought on how to design it. I suppose what you want is change the 'default' variable. Perhaps increase it by 1? But then, where do you do this? grub_machine_init is too early as 'default' hasn't been set yet. Maybe we could have a global 'int default_offset' variable that is initialized in grub_machine_init and later on used by normal.mod? The sequence of writing to port 0x70 / reading from port 0x71 reflects reading from the computer's cmos nvram memory. bit 7 of 0x70 is reserved for disabling NMIs, so the actual information is stored in byte 0x79[8] in the cmos. To allow full flexibility, there should just be a module that allows reading / writing the cmos values (could also be useful for other things, such as reading a boot order set by the bios). Everything else makes more sense in scripting: - changing default - changing timeout - support for bit operations in the parser - etc... -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel So what about a new nvram module in i386-pc that creates a variable $NVRAM hooked to routines getting/setting the live contents of the cmos memory? Then menu scripts can check its contents, among them the MediaDirect button. -Habbit ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI report w/ linux 2.6.26.2
Bean wrote: Hi, Please take a look at the wiki page and see if you can make graphic work by following the instructions: http://grub.enbug.org/TestingOnMacbook sorry I feel a little busy right now, and I'd have to figure out how to kick those agp modules out of the initrd too. By the way, why doesn't AGP work in EFI mode? (Does Linux currently not know how to initialize it without getting BIOS help? Or something else?) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] fix for a memleak in grub_ntfs_mount
On Wed, Aug 20, 2008 at 11:01:26PM +0200, Felix Zielcke wrote:
2008-08-20 Felix Zielcke [EMAIL PROTECTED]
* fs/ntfs.c (grub_ntfs_mount): Fix a memory leak.
Index: fs/ntfs.c
===
--- fs/ntfs.c (Revision 1822)
+++ fs/ntfs.c (Arbeitskopie)
@@ -850,6 +850,7 @@ fail:
{
free_file (data-mmft);
free_file (data-cmft);
+ grub_free (data);
}
return 0;
}
Looks fine to me.
--
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
Re: [PATCH] Generic 32-bit Linux loader (for coreboot)
Committed. -- 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
Re: Dell Media Direct button
On Thu, Aug 21, 2008 at 02:13:05PM +0200, Stefan Reinauer wrote: The sequence of writing to port 0x70 / reading from port 0x71 reflects reading from the computer's cmos nvram memory. bit 7 of 0x70 is reserved for disabling NMIs, so the actual information is stored in byte 0x79[8] in the cmos. To allow full flexibility, there should just be a module that allows reading / writing the cmos values (could also be useful for other things, such as reading a boot order set by the bios). Ah, good catch. For the record, we already have code that accesses cmos, in the date handling functions recently added by Bean. -- 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
[PATCH] Bug fix for EFI
Hi, This patch fix two bugs in the EFI port: 1, grub_longjmp (x86_64 EFI): Return 1 when val = 0. This behavior is consistent with grub_longjmp of i386 platform. 2, genfslist.sh and genpartmaplist.sh In EFI, the kernel is in a module kernel.mod. genfslist.sh scans the source for grub_fs_register, so kernel.mod would be included in fs.lst and partmap.lst, which cause serious problem when grub try to load extra file system modules. This patch simply ignore kernel.mod in genfslist.sh and genpartmaplist.sh. 2008-08-22 Bean [EMAIL PROTECTED] * normal/x86_64/setjmp.S (grub_longjmp): Return 1 when val = 0. * genfslist.sh: Ignore kernel.mod. * genpartmaplist.sh: Likewise. -- Bean diff --git a/genfslist.sh b/genfslist.sh index b54f0ff..ec48e86 100644 --- a/genfslist.sh +++ b/genfslist.sh @@ -15,6 +15,11 @@ module=$1 +# Ignore kernel.mod. +if test $module = kernel; then +exit +fi + # For now, this emits only a module name, if the module registers a filesystem. if grep -v ^# | grep '^ *grub_fs_register' /dev/null 21; then echo $module diff --git a/genpartmaplist.sh b/genpartmaplist.sh index ba65049..fceb0f8 100644 --- a/genpartmaplist.sh +++ b/genpartmaplist.sh @@ -15,6 +15,11 @@ module=$1 +# Ignore kernel.mod. +if test $module = kernel; then +exit +fi + # For now, this emits only a module name, if the module registers a partition map. if grep -v ^# | grep '^ *grub_partition_map_register' /dev/null 21; then echo $module diff --git a/normal/x86_64/setjmp.S b/normal/x86_64/setjmp.S index 4c8d4b3..621b09b 100644 --- a/normal/x86_64/setjmp.S +++ b/normal/x86_64/setjmp.S @@ -50,6 +50,11 @@ FUNCTION(grub_setjmp) */ FUNCTION(grub_longjmp) movl %esi, %eax + orl %eax, %eax + jnz 1f + incl %eax +1: + movq (%rdi), %rbx movq 8(%rdi), %rsp movq 16(%rdi), %rbp ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[Fwd: Bug#495949: grub-common: grub-probe segfaults]
The report is on http://bugs.debian.org/495949 There seems to be some LVM/RAID related memory corruption somewhere. On the report there's a backtrace, full backtrace and core file + grub-probe binary attached. This doestn't make any sense to me, so I hope some of you else has one. On Debian BTS we have a wishlist report for encrypted LVM but that person isn't saying at all that grub-probe segfaults http://bugs.debian.org/463107 Weitergeleitete Nachricht Von: Jean-Luc Coulon (f5ibh) [EMAIL PROTECTED] Antwort an: Jean-Luc Coulon (f5ibh) [EMAIL PROTECTED], [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: grub-devel@gnu.org Betreff: Bug#495949: grub-common: grub-probe segfaults Datum: Thu, 21 Aug 2008 19:44:49 +0200 Le 21.08.2008 19:31:04, Felix Zielcke a écrit : Am Donnerstag, den 21.08.2008, 19:12 +0200 schrieb Jean-Luc Coulon (f5ibh): So, attached the bt full output and the grub-probe binary (bzip2, warning, it is built for X86_64). That's what I'm using too I have now even compiled myself the 24-8 and used that grub-probe binary with your core file. I haven't thought that this would work. It's very weird, I really don't understand the backtrace. It looks like really severe memory corruption. Seems like it has something to do with your LVM or RAID so maybe output of: lvdisplay vgdisplay pvdisplay mdadm -Q --detail /dev/md0 mdadm -Q --detail /dev/md1 mdadm -Q --detail /dev/md2 Ok. Attached the output of each command. (/dev/md2 is encrypted with luks). helps. Remark, I subscribe grub-devel list but my message was rejeted :-o The list mail erver has unfortunately sometimes problems, I noticed this myself :( would be very nice of you if you send another mail to grub-devel after you made sure you get the `welcome to grub-devel' mail, else I just forward it but I think it's better to have the discussion with you :) And on grub-devel there's not only Robert and me but the others too. J-L ___ Pkg-grub-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-grub-devel --- Logical volume --- LV Name/dev/cryptvg0/opt_lv VG Namecryptvg0 LV UUIDopnuev-fu0Z-pW1K-8qMB-vZnY-KCPx-juG5zQ LV Write Accessread/write LV Status available # open 1 LV Size3.17 GB Current LE 812 Segments 3 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:5 --- Logical volume --- LV Name/dev/cryptvg0/local_lv VG Namecryptvg0 LV UUIDcWKbtN-KTTr-kTiv-wZUs-y5oE-svJ1-FNy6E0 LV Write Accessread/write LV Status available # open 1 LV Size3.88 GB Current LE 993 Segments 3 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:6 --- Logical volume --- LV Name/dev/cryptvg0/tmp_lv VG Namecryptvg0 LV UUIDjfBWUN-97E3-7430-QXv5-rzqe-CKFj-Fucqa6 LV Write Accessread/write LV Status available # open 1 LV Size6.00 GB Current LE 1536 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:7 --- Logical volume --- LV Name/dev/cryptvg0/photos_lv VG Namecryptvg0 LV UUIDsyYrHg-zvse-wRkr-9ae5-PoCG-0cl8-KNhyXY LV Write Accessread/write LV Status available # open 1 LV Size11.50 GB Current LE 2944 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:8 --- Logical volume --- LV Name/dev/cryptvg0/music_lv VG Namecryptvg0 LV UUID5C3fYQ-5Snq-dM2Q-L4nX-Obkb-ZI1B-2lTIDE LV Write Accessread/write LV Status available # open 1 LV Size3.15 GB Current LE 806 Segments 3 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:9 --- Logical volume --- LV Name/dev/cryptvg0/iso_lv VG Namecryptvg0 LV UUIDQIQ1r4-FqEL-at2b-qeZo-Fik0-939G-g4cJuh LV Write Accessread/write LV Status available # open 0 LV Size5.00 GB Current LE 1280 Segments 1 Allocation inherit Read ahead
[Wishlist] Better warning if grub.cfg not found
Hello, Doing some tests with Grub2 and qemu I've made a mistake that Grub (I think) could warn me better. The mistake is that I didn't have a grub.cfg file (well, I had but in the wrong place). The Grub2 feedback for a standard user it's just flickering (I think that Grub2 paints the menu) and after that shows the command line. I would expect a warning, before the command line or in the command line screen informing user that grub.cfg has not been found in the expected place. I'm doing the Grub2 imagine file using grub-mkrescue. Should already grub-mkrescue warn if grub.cfg is not there? (at least if using overlay option). I could take a look if grub-mkrescue should do it. -- Carles Pina i EstanyGPG id: 0x17756391 http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
