Re: Bug in arg.c
On 05.01.2012 04:02, Seth Goldberg wrote: --- a/grub-core/lib/arg.cWed Jan 04 17:38:56 2012 -0800 +++ b/grub-core/lib/arg.cWed Jan 04 18:59:08 2012 -0800 @@ -351,7 +351,7 @@ opt = find_long (cmd-options, arg + 2, arglen); if (!option argv[curarg + 1] argv[curarg + 1][0] != '-' - opt-type != ARG_TYPE_NONE) + opt opt-type != ARG_TYPE_NONE) option = argv[++curarg]; if (!opt (cmd-cmd-flags GRUB_COMMAND_ACCEPT_DASH)) Committed, thanks -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: ZFS Crypto key hand off to kernel
On 10.01.2012 13:23, Darren J Moffat wrote: I've been testing the ZFS Crypto support in GRUB2 with Solaris 11 and found it works great - many thanks! The 'zfskey' command works very nicely, however the key is only available to grub and isn't handed off to the kernel that GRUB2 starts up. I'm considering an extension to the multiboot2 spec to provide a mechanism to hand off the key from GRUB2 to the running kernel. I would like for this not to be specific to the ZFS crypto support but to be usable for LUKS and other systems that allow for an encrypted root/boot where both GRUB2 and the kernel need the same key. Is this something that would be of interest for GRUB2 ? If so I'll look at developing the spec update and a patch for GRUB2 to support it for the zfs crypto support. That would be most welcome. The main issues are: 1) What to consider a key? IMHO it should be the master key, and not password or session key. 2) How to match keys to actual devices? I think it should be UUID for LUKS and POOLUUID+FSNAME for ZFS, or perhaps just POOLUUD. 3) GRUB may have some keys without knowing which pool/fs it's used for. They should be marked as such. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: ZFS Crypto key hand off to kernel
On 13.01.2012 15:27, Darren J Moffat wrote: On 01/13/12 14:17, Vladimir 'φ-coder/phcoder' Serbinenko wrote: Is this something that would be of interest for GRUB2 ? If so I'll look at developing the spec update and a patch for GRUB2 to support it for the zfs crypto support. That would be most welcome. The main issues are: 1) What to consider a key? IMHO it should be the master key, and not password or session key. Agreed, it is really helpful that GRUB2 has already done the PKCS#5 PBE transform in the case of a ZFS encrypted dataset. So there is no need to give the passphrase to the kernel when you can give the real key. Also it wouldn't actually be useful in the case of ZFS encryption for GRUB2 to hand off the list of actual data encryption keys all we need is the key encryption key (aka master key, aka wrapping key). 2) How to match keys to actual devices? I think it should be UUID for LUKS and POOLUUID+FSNAME for ZFS, or perhaps just POOLUUD. I need to brush up on LUKS it has been a while since I looked at it but that sounds correct to me. For ZFS I think it might be enough to give the dataset name but I like the idea of passing the POOL GUID as well. If I had both I would certainly use them. 3) GRUB may have some keys without knowing which pool/fs it's used for. They should be marked as such. I must be missing something here, how could that happen in the ZFS case? Or do you mean in general ? I mean exactly the ZFS case. zfskey only stores the password and files in a special place and on an attempt to read encrypted data, the real key is decoded. IF no such attempt has been made, they key won't be decoded and GRUB won't know what it's for. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Retiring grub-mkdevicemap
Hello, all. With the lazy scanning and hints patches grub-mkdevicemap was completely excluded from the grub-install, it's not used anymore by any other GRUB tool. Does anyone have a reason to keep it around at all? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Multiboot video mode request on EFI-gop
On 16.01.2012 16:22, Thomas Nilsen wrote: Hi, I think i might have explained myself incorrect. What i mean is: 1. Grub2 runs very well on BIOS (U)EFI bios. Nice graphics as requested in gfxmode etc. 2. Grub2 loads multiboot kernel and gives it its requested videomode (from the videomode request part of multibootheader) 3. Grub2 does NOT load multiboot kernel and gives it its requested videomode. It seems to give it its mode, but the info is not right in the multiboot parameters.. So the kernel cannot tell what mode it is, where its LFB is and bpp etc. Conclusion: So what i think is happening (not happening) is that when using GOP and not VBE (for bios) then the updating of the multibootparams are not handled correctly.. It might be my mistake, but i cannot seem to get it working.. (might be my code that is not right..) Did you notice that the structure for the generic video is different and pointed in another place than VBE one? regards Thomas 2012/1/16 Phillip Susi ps...@ubuntu.com mailto:ps...@ubuntu.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/16/2012 5:24 AM, Thomas Nilsen wrote: Im thinking since its the efi-gop driver/module that handles video mode on EFI boot this could probably be used when booting the same way that vbe module does the change before executing the kernel. That's exactly what it is for. Make sure you have that module loaded. Im interrested in contributing on fixing this if someone with some information can point me where to start off if someone knows whats missing, or maby what is going wrong. I will start doing some research aswell, but help is very much appreciated. If the GOP module is loaded and you are not satisfied with the video modes it provides, then AFAIK, you will need to either try a different motherboard ( that has a different EFI GOP implementation ) or get the specs for your video card and write your own EFI GOP driver. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPFDmDAAoJEJrBOlT6nu751w0IAK22Sr9ytvetkJRICpAILYXU vR2nPYXb5J8wHoUY3ooCtartmWv1bIs2TMcfjGWtwPyP0GCoJ/kH2XK8ZFx3MsAD uZGeKk5qP4x3XDEZvllreYm/tG1lv+Uwh6Bv7BFTGPA10BFFOv/5NRt0tn5RT3ke jR2/Fx+RKZ+haw//DhsC87RqhsQg53Wg3PnumpzWL9BU/pH4iajsE3FE8kck3eHK DUanFwDMIeu6e2+xPrDtgNdBGZEC0eUzCf5AMZYInCPZ1vJOYGrYGJaUBC6bD+wU 2eHED1LKZ3kanPNnsP79AdtmOwFrJ94QW80Cy/hTqLk4bfPkRel9TKzDSJpeRWw= =J+5A -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Multiboot video mode request on EFI-gop
On 16.01.2012 16:50, Thomas Nilsen wrote: Hi again, Thanks for you help. That actually means that Grub2 is actually doing what it can and thats it? The rest is up to the os/kernel to handle directly with the GOP protocol driver? So its not possible to have the GOP driver initialize a mode and then return a LFB address? The GOP protocol in the machine's EFI bios is most definetly not video-hardware specialized, so between the GOP implementation and the VIDEO hardware there must be some sort of LFB type interface? Or am i misunderstanding? You misunderstand completely. I think you confuse 2 independent structures supplied by GRUB VBE info (available only on VBE platforms) and General video info (always available includes among other lfb address) The ideal solution for me would be if grub could initialize mode as it does very well, then in some way get the LFB pointer and bpp, etc and send as if it was from a Bios+vbe grub scenario. regards Thomas 2012/1/16 Phillip Susi ps...@ubuntu.com mailto:ps...@ubuntu.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/16/2012 10:22 AM, Thomas Nilsen wrote: Hi, I think i might have explained myself incorrect. What i mean is: 1. Grub2 runs very well on BIOS (U)EFI bios. Nice graphics as requested in gfxmode etc. 2. Grub2 loads multiboot kernel and gives it its requested videomode (from the videomode request part of multibootheader) 3. Grub2 does NOT load multiboot kernel and gives it its requested videomode. It seems to give it its mode, but the info is not right in the multiboot parameters.. So the kernel cannot tell what mode it is, where its LFB is and bpp etc. Ahh, yes, this is because gop doesn't set a vesa mode and let you play with the flat frame buffer. You actually make gop calls to perform the IO for you. Grub can leave the display in that state when passing off to the kernel, but the kernel has to have its own KMS video driver to take over; it can't just start poking at a frame buffer like it can with VESA. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPFEPEAAoJEJrBOlT6nu75SmgIAJq8XvbE8/g/dtwwVOmwLpgW ahFS5MQU1CCvkmXE54GteIfMVmdLxiRgBdlLH8VxXr4CW19YpYyAWtoi+ib038QB b7DeaReDw2WzYrikw7Ezt1mWejw7t4Ysv1eEjw0ppQlLMm+/Rnwf+qum5nddWeIh ognAT03nqcu+AsOv7G++wiSltNLKXfACrjhdr/VRAmibGT1a5/er0z26evGW1U5/ eXWX5kSpsNDuMQILBKvVkLkACK8cC4apKkhATBGA2pGENPgys+fu7NzTJm/j16dt sAuck2a+LpCEJ7os90JwouPVITLeQ05p07LwqJhMMfRkDApoIfgWYXGBFPlTbbE= =EUzD -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: not a valid root device error in UEFI chainloader command
On 18.01.2012 03:54, Keshav P R wrote:
Hi,
I tried to manually chainload UEFI shell from grub2 terminal in
x86_64 firmware. I get
insmod part_gpt
insmod fat
chainloader (hd0,gpt1)/shellx64.efi
error: not a valid root device
Setting root isn't just for convenience inside GRUB, with some loader
(multiboot, chainloader, bsd) it's actually passed to the payload as its
root. If you forget to set it, it obviously won't work
If I use
set pager=1
set debug=all
chainloader (hd0,gpt1)/shellx64.efi
[long rows of text - but no visible error]
boot
[shell launched]
However a menuentry like
menuentry UEFI Shell {
search --fs-uuid --no-floppy --set=root ${_uefi_sys_fs_uuid}
chainloader (${root})/shellx64.efi
}
works. I can reproduce this error everytime I try to manually
chainload from grub2 terminal, but does not occur even once when
loaded via menuentry. Thanks in advance.
Regards.
Keshav
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Multiboot video mode request on EFI-gop
If the GOP module is loaded and you are not satisfied with the video modes it provides, then AFAIK, you will need to either try a different motherboard ( that has a different EFI GOP implementation ) or get the specs for your video card and write your own EFI GOP driver. It's better to write a driver directly for GRUB if you want to make a driver at all. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Restore test for limits.h
On 14.12.2011 23:26, Mario Limonciello wrote: +2011-12-14 Mario Limonciellomario_limoncie...@dell.com + + * configure.ac: Add back in test for limits.h. + Applied, thanks. Sorry for the delay -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: undefined reference to 'system'
On 24.01.2012 15:40, Joachim Mammele wrote: Hi everybody, I have got a tablet with special frontkeys and I would like to install and adapt android on it. This works fine with the project android-x86.org The version you refer to, isn't supported anymore. Only GRUB2 is still developped. GRUB Legacy is abandoned. bits9 = system(readFrontKey); You can't use usual syscalls inside bootloader. GRUB2 has its own API which is somewhat posix-like but has no such things as system, pipes or forks, and normally there shouldn't be any need. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[RFC] FIEMAP and disk sync issues
Hello, all. When someone installs using blocklists (discouraged and unreliable), we use GRUB internal fs reader in order to determine core.img blocklists. With Linux we call fsync and an ioctl on partition in order to flush the cache. I also tried adding sync which didn't make any difference. Unfortunately it doesn't seem to be good enough on some filesystems e.g. ext2 (ext3 and ext4 seem to work). Does anyone know how to ensure flush of a file AND of all filesystem metadata needed to read it? Alternatively we can ask Linux itself to tell us the blocks the file resides in. There are 2 ioctls for this: FIBMAP and FIEMAP. FIBMAP is unfortunately limited to 32-bit blocks. Most of FS supported by both GRUB and Linux lack FIEMAP. If we exclude the 32-bit fs (which will work fine with FIBMAP as long as it uses the same block size as underlying FS, which seems reasonable but I haven't verified it) (minix1/2/3, reiserfs, hfs, jfs, udf, fat, affs) and read-only filesystems (unsuitable for install) (iso9660, romfs, squash4), the remaining trouble is NTFS and HFS+. So with this approach we'll be unable to install on 2TiB HFS+ or NTFS filesystems. I see following possibilities: - Someone write fiemap support for HFS+ and NTFS. This would be probably the best approach - We find a way to flush disk reliably. This would eliminate the necessity of having different branches for Linux and rest. - Ask Linux devs if they are willing to provide FIBMAP64 since internally 64-bits are used. Another problem with FIBMAP/FIEMAP is that fuse-mounted BFS lacks them altogether. We will need to find some other way of doing BFS install. Also some COW filesystems may supply a somewhat valid blocklist with FIBMAP/FIEMAP but which is unusable to GRUB because of COW nature. So we need an FS-whitelist. Experiment patch attached. Any thoughts? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko === modified file 'grub-core/fs/affs.c' --- grub-core/fs/affs.c 2012-01-14 14:44:34 + +++ grub-core/fs/affs.c 2012-01-27 11:55:52 + @@ -571,6 +571,7 @@ .label = grub_affs_label, #ifdef GRUB_UTIL .reserved_first_sector = 0, +.blocklist_install = 1, #endif .next = 0 }; === modified file 'grub-core/fs/bfs.c' --- grub-core/fs/bfs.c 2011-10-30 15:10:18 + +++ grub-core/fs/bfs.c 2012-01-27 11:56:05 + @@ -1026,6 +1026,7 @@ #endif #ifdef GRUB_UTIL .reserved_first_sector = 1, + .blocklist_install = 1, #endif }; === modified file 'grub-core/fs/btrfs.c' --- grub-core/fs/btrfs.c 2012-01-25 14:10:56 + +++ grub-core/fs/btrfs.c 2012-01-27 11:56:17 + @@ -1653,6 +1653,7 @@ #ifdef GRUB_UTIL .embed = grub_btrfs_embed, .reserved_first_sector = 1, + .blocklist_install = 0, #endif }; === modified file 'grub-core/fs/cpio.c' --- grub-core/fs/cpio.c 2011-12-24 14:09:26 + +++ grub-core/fs/cpio.c 2012-01-27 11:56:31 + @@ -714,6 +714,7 @@ .close = grub_cpio_close, #ifdef GRUB_UTIL .reserved_first_sector = 0, + .blocklist_install = 0, #endif }; === modified file 'grub-core/fs/ext2.c' --- grub-core/fs/ext2.c 2012-01-14 10:55:20 + +++ grub-core/fs/ext2.c 2012-01-27 11:56:43 + @@ -971,6 +971,7 @@ .mtime = grub_ext2_mtime, #ifdef GRUB_UTIL .reserved_first_sector = 1, +.blocklist_install = 1, #endif .next = 0 }; === modified file 'grub-core/fs/fat.c' --- grub-core/fs/fat.c 2011-12-13 00:41:16 + +++ grub-core/fs/fat.c 2012-01-27 11:56:56 + @@ -1158,6 +1158,7 @@ #else .reserved_first_sector = 1, #endif +.blocklist_install = 1, #endif .next = 0 }; === modified file 'grub-core/fs/hfs.c' --- grub-core/fs/hfs.c 2012-01-14 22:34:33 + +++ grub-core/fs/hfs.c 2012-01-27 11:57:13 + @@ -1356,6 +1356,10 @@ .label = grub_hfs_label, .uuid = grub_hfs_uuid, .mtime = grub_hfs_mtime, +#ifdef GRUB_UTIL +.reserved_first_sector = 1, +.blocklist_install = 1, +#endif .next = 0 }; === modified file 'grub-core/fs/hfsplus.c' --- grub-core/fs/hfsplus.c 2012-01-14 22:34:33 + +++ grub-core/fs/hfsplus.c 2012-01-27 11:57:20 + @@ -1084,6 +1084,7 @@ .uuid = grub_hfsplus_uuid, #ifdef GRUB_UTIL .reserved_first_sector = 1, +.blocklist_install = 1, #endif .next = 0 }; === modified file 'grub-core/fs/iso9660.c' --- grub-core/fs/iso9660.c 2011-12-13 15:35:12 + +++ grub-core/fs/iso9660.c 2012-01-27 11:57:51 + @@ -1092,6 +1092,10 @@ .label = grub_iso9660_label, .uuid = grub_iso9660_uuid, .mtime = grub_iso9660_mtime, +#ifdef GRUB_UTIL +.reserved_first_sector = 1, +.blocklist_install = 1, +#endif .next = 0 }; === modified file 'grub-core/fs/jfs.c' --- grub-core/fs/jfs.c 2011-12-13 22:11:48 + +++ grub-core/fs/jfs.c 2012-01-27 11:58:04 + @@ -906,6 +906,10 @@ .close = grub_jfs_close, .label = grub_jfs_label, .uuid = grub_jfs_uuid, +#ifdef GRUB_UTIL +.reserved_first_sector = 1, +.blocklist_install = 1, +#endif
Re: [RFC] FIEMAP and disk sync issues
On 27.01.2012 20:04, Phillip Susi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/27/2012 8:28 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: Hello, all. When someone installs using blocklists (discouraged and unreliable), we use GRUB internal fs reader in order to determine core.img blocklists. With Linux we call fsync and an ioctl on partition in order to flush the cache. I also tried adding sync which didn't make any difference. Unfortunately it doesn't seem to be good enough on By sync you mean running the sync command? Actually the sync () call If so, that absolutely, positively should flush everything to disk. If it isn't then there's a major kernel bug. An fsync() on the core.img file ( not the partition device ) also should flush everything needed to find that file, without flushing everything else that isn't. I'll recheck. But considering that I ran into some data loss it's possible that I have some kind of hardware or software failure (most likely because of new kernel and xen tests). Busy now doing the backups in case it gets worse Doing an fsync() on the partition device will flush buffers from a process directly opening the block dev and performing IO there, not the buffers for files within the filesystem on that block device. IIRC, ext2 uses the block buffers for directory access so that partition fsync will flush directories, but ext3 and ext4 do not. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPIvUhAAoJEJrBOlT6nu75ZSwH/2vgqHY3L+9xPGAsMDMzelAq ae6P0aKgqEsZPEiTDx6+sBNE9uvJO6va5mKv9eyvDhpmKeq64mLa3EDJBKUmnSL+ E/b/cAAYPV7RaJ7Rc3tUNa96PRC8rOPyOcGeOVQxqjFS5rmZOa4p+wrO3YitqIGR IUD7HSN8wt4PtmeS8thRXQPhcSICQwPy8rg4QVq2mFHxFws/WALAr7p5uVu/SH2Q E8lXARKdvqd6HPjxlo7A/WeDEVvRd25eb84vX33wAhaauAI9VFD2+eCWR5ayyVUe aymZ+DNyXpenEGK5JDdW38ovmAwIsWI+LbWVCh/gInEfHJkDVqN9XogtmCc9S68= =3Yxi -END PGP SIGNATURE- -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Patch] Robustly search for ZFS labels uberblocks
On 27.01.2012 20:04, Zachary Bedell wrote:
Thanks for plodding through my mess. It looks like the changes are committed
to trunk at this point, right? I'm trying to get a test together, but I've had
to forward port the other changes necessary to support build on Linux. I think
I have those changes done in a such a way as they won't conflict with other
platforms. I'll try submitting those changes again once I'm sure everything is
working.
I think I still have access to one of the pools that caused issues. In any
case, I have a pretty good memory of what the actual on-disk issues were, and
I'm pretty sure I can take a hex editor to a disk image and break them
appropriately. Assuming I'm successful with that, I'll try to make minimal
image files that can be posted somewhere for testing.
The pools in question were originally subject to an almost contrived level of
abuse. I was testing running swap on a ZVOL, and running into repeated kernel
panics in the ZFSonLinux code when the pool was under heavy I/O. Not a recipe for
good data integrity... In any case, the pools were always such that ZFS driver
could import them. In the majority of cases, they silently self-healed, in a few
(especially where the good label was at the end of the device), a `zpool scrub` was
necessary. My metric for this stuff has been if the ZFS tools report errors, I'm
not as worried if Grub can read the pool, but if ZFS says okay Grub breaks,
that worries me.
I agree. In most cases GRUB can even access to a heavily corrupted FS
not mountable otherwise due to not caring about most of features.
I have a patch for supporting zfs-fuse including multi-device ZFS
installs (they need special care in grub-probe) but I can't easily
retrieve it from my repo due to data loss (the files are still intact so
worst-case scenario I have to rebuild my repo and lose some history).
Few comments below...
On Jan 22, 2012, at 9:18 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
I've cleaned this patch up (attached). Can you test it on these 4K FSes or tell
me how to create one w/o really having such a disk?
On 19.01.2012 12:36, Richard Laager wrote:
static grub_err_t
-uberblock_verify (uberblock_phys_t * ub, int offset)
+uberblock_verify (uberblock_t * uber, int offset, struct grub_zfs_data *data)
{
- uberblock_t *uber =ub-ubp_uberblock;
grub_err_t err;
grub_zfs_endian_t endian = UNKNOWN_ENDIAN;
zio_cksum_t zc;
+ void *osp = NULL;
+ grub_size_t ospsize;
+
+ if (uber-ub_txg data-label_txg)
+return grub_error (GRUB_ERR_BAD_FS,
+ ignoring partially written label: uber_txg label_txg);
I've left this part out since outside loop already looks for the newest txg.
Gotta double check this, but I think you're right. Was a duplicate check.
if (grub_zfs_to_cpu64 (uber-ub_magic, LITTLE_ENDIAN) == UBERBLOCK_MAGIC
grub_zfs_to_cpu64 (uber-ub_version, LITTLE_ENDIAN) 0
@@ -361,7 +390,19 @@
zc.zc_word[0] = grub_cpu_to_zfs64 (offset, endian);
err = zio_checksum_verify (zc, ZIO_CHECKSUM_LABEL, endian,
-(char *) ub, UBERBLOCK_SIZE);
+(char *) uber, UBERBLOCK_SIZE(data-vdev_ashift));
+
+ if (!err)
+{
+ /* Check that the data pointed by the rootbp is usable. */
+ void *osp = NULL;
+ grub_size_t ospsize;
+ err = zio_read (uber-ub_rootbp, endian,osp,ospsize, data);
+ grub_free (osp);
+
+ if (!err ospsize OBJSET_PHYS_SIZE_V14)
+ return grub_error (GRUB_ERR_BAD_FS, uberblock rootbp points to invalid
data);
+}
Left this one out: why would it happen that uberblock checksum is valid but the
other data in it isn't?
This one I'm a little worried about. Had a case where the pool had a technically valid
UB (and it was the best one according to what I understand to be the proper
logic). The DVA in the UB was right, but the data that DVA pointed to was junk. Best I
could tell, the original Grub checking mechanism would drop to alt-DVA's if the physical
read failed, but it wouldn't if the checksum of data pointed by the DVA (but not the UB
itself's checksum) was bad. At that point, Grub would toss the entire UB, and unless it
happened to get lucky and find another one that was good enough, it would lose the pool.
I'm going to try to get my head back into this over the weekend. I got pulled away
from ZFS/Linux/Gentoo/Grub stuff for a while, and have been spending this week
bringing all the Gentoo overlay stuff I built up to date with latest of everything.
I've got Grub building detecting ZFS at this point, so I just need to figure
out why Dracut broke, and I think I'm fully back in business for testing.
Thanks again,
Zac
-- end of comments --
return err;
}
@@ -372,32 +413,40 @@
*Success - Pointer to the best uberblock.
*Failure - NULL
*/
-static uberblock_phys_t *
-find_bestub (uberblock_phys_t * ub_array, grub_disk_addr_t sector)
+static
Re: [Patch] Robustly search for ZFS labels uberblocks
(name, poolname))
+ /* Use strncmp() because poolname can technically have trailing
+spaces, which the sscanf() above will not catch. Since we've
+asked about this pool specifically, this should be safe. */
+ if (!strncmp (name, poolname, strlen(name)))
st++;
break;
case 2:
@@ -395,17 +439,71 @@
free (line);
}
+
+#ifdef __linux__
+/* The name returned by zpool isn't necessarily directly under /dev. */
+{
+ const char *disk_naming_schemes[] = {
+ /dev/disk/by-id/%s,
+ /dev/disk/by-path/%s,
+ /dev/disk/by-uuid/%s,
+ /dev/disk/by-partuuid/%s,
+ /dev/disk/by-label/%s,
+ /dev/disk/by-partlabel/%s,
+ /dev/%s,
Such a list is difficult to maintain. It's better to scan /dev/disk if
/dev/name is unavailable.
+mnttab = fopen (/proc/mounts, r);
+if (! mnttab)
+ mnttab = fopen (/etc/mtab, r);
+if (! mnttab)
+ return;
/etc/mtab is unreliable. As for /proc/mounts : is there a reason to suppose
that /proc/mounts would work when /proc/self/mountinfo doesn't
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'include/grub/emu/getroot.h'
--- include/grub/emu/getroot.h 2011-04-25 12:52:07 +
+++ include/grub/emu/getroot.h 2012-01-27 15:41:19 +
@@ -30,7 +30,7 @@
};
char *grub_find_device (const char *dir, dev_t dev);
-char *grub_guess_root_device (const char *dir);
+char **grub_guess_root_devices (const char *dir);
int grub_util_get_dev_abstraction (const char *os_dev);
char *grub_util_get_grub_dev (const char *os_dev);
char *grub_make_system_path_relative_to_its_root (const char *path);
=== modified file 'include/grub/emu/misc.h'
--- include/grub/emu/misc.h 2011-12-13 13:51:41 +
+++ include/grub/emu/misc.h 2012-01-27 15:23:40 +
@@ -80,6 +80,4 @@
int grub_device_mapper_supported (void);
#endif
-char *grub_find_root_device_from_mountinfo (const char *dir, char **relroot);
-
#endif /* GRUB_EMU_MISC_H */
=== modified file 'util/getroot.c'
--- util/getroot.c 2011-12-23 18:25:24 +
+++ util/getroot.c 2012-01-27 16:57:59 +
@@ -115,6 +115,149 @@
return path;
}
+static char **
+find_root_devices_from_poolname (char *poolname)
+{
+ char **devices = 0;
+ size_t ndevices = 0;
+ size_t devices_allocated = 0;
+
+#if defined(HAVE_LIBZFS) defined(HAVE_LIBNVPAIR)
+ zpool_handle_t *zpool;
+ libzfs_handle_t *libzfs;
+ nvlist_t *config, *vdev_tree;
+ nvlist_t **children, **path;
+ unsigned int nvlist_count;
+ unsigned int i;
+ char *device = 0;
+
+ libzfs = grub_get_libzfs_handle ();
+ if (! libzfs)
+return NULL;
+
+ zpool = zpool_open (libzfs, poolname);
+ config = zpool_get_config (zpool, NULL);
+
+ if (nvlist_lookup_nvlist (config, vdev_tree, vdev_tree) != 0)
+error (1, errno, nvlist_lookup_nvlist (\vdev_tree\));
+
+ if (nvlist_lookup_nvlist_array (vdev_tree, children, children, nvlist_count) != 0)
+error (1, errno, nvlist_lookup_nvlist_array (\children\));
+ assert (nvlist_count 0);
+
+ while (nvlist_lookup_nvlist_array (children[0], children,
+ children, nvlist_count) == 0)
+assert (nvlist_count 0);
+
+ for (i = 0; i nvlist_count; i++)
+{
+ if (nvlist_lookup_string (children[i], path, device) != 0)
+ error (1, errno, nvlist_lookup_string (\path\));
+
+ struct stat st;
+ if (stat (device, st) == 0)
+ {
+#ifdef __sun__
+ if (grub_memcmp (device, /dev/dsk/, sizeof (/dev/dsk/) - 1)
+ == 0)
+ device = xasprintf (/dev/rdsk/%s,
+device + sizeof (/dev/dsk/) - 1);
+ else if (grub_memcmp (device, /devices, sizeof (/devices) - 1)
+ == 0
+ grub_memcmp (device + strlen (device) - 4,
+ ,raw, 4) != 0)
+ device = xasprintf (%s,raw, device);
+ else
+#endif
+ device = xstrdup (device);
+ if (ndevices = devices_allocated)
+ {
+ devices_allocated = 2 * (devices_allocated + 8);
+ devices = xrealloc (devices, sizeof (devices[0])
+ * devices_allocated);
+ }
+ devices[ndevices++] = device;
+ }
+
+ device = NULL;
+}
+
+ zpool_close (zpool);
+#else
+ char *cmd;
+ FILE *fp;
+ int ret;
+ char *line;
+ size_t len;
+ int st;
+
+ char name[PATH_MAX + 1], state[257], readlen[257], writelen[257];
+ char cksum[257], notes[257];
+ unsigned int dummy;
+
+ cmd = xasprintf (zpool status %s, poolname);
+ fp = popen (cmd, r);
+ free (cmd);
+
+ st = 0;
+ while (1)
+{
+ line = NULL;
+ ret = getline (line, len, fp);
+ if (ret == -1)
+ break;
+
+ if (sscanf (line, %s %256s %256s %256s %256s %256s,
+ name, state, readlen, writelen, cksum, notes) = 5)
+ switch (st)
+ {
+ case 0:
+ if (!strcmp (name, NAME)
+ !strcmp (state, STATE)
+ !strcmp (readlen, READ)
+ !strcmp (writelen, WRITE
Re: [Patch] Robustly search for ZFS labels uberblocks
On 28.01.2012 19:40, Darik Horn wrote: 2012/1/28 Vladimir 'φ-coder/phcoder' Serbinenkophco...@gmail.com: I already commented on 10_linux.in changes. They are pretty sloppy. (mostly is it works for me and I don't care about other legitimate configs) How do you want these things changed? I searched the email archive and couldn't find where you gave an example of another legitimate configuration, or suggested to how improve any of the related submissions by Robert Millan, Richard Laager, or Zachary Bedell. Even if I didn't do before (I didn't recheck), I did it in another message in this thread Keep in mind that ZoL cannot resolve the grub mdnobj number, or use the Solaris bootpath or devid. The only thing that matters on the Linux command line is the pool name, and everything else is for interface compatibility with Solaris. Even this is already one piece of info which will be resolved wrong. (Also note that if you need only this particular info you should probably consider zfsinfo. In this case it doesn't matter because it's still wrong though) Also note that this code is in the latest ZFS patch: if (strcmp (name, mirror) !sscanf (name, mirror-%u,dummy) !sscanf (name, raidz%u,dummy) That format doesn't match the `zpool status` output on my current Solaris and Linux computers. The vdev names now have the RAID level number and a dash character like this: raidz1-0 raidz1-1 raidz2-0 raidz3-0 Does adding !sscanf (name, raidz1-%u,dummy)!sscanf (name, raidz2-%u,dummy) !sscanf (name, raidz3-%u,dummy) resolve this problem? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Unify raid and lvm handling
On 28.01.2012 15:36, Vladimir 'φ-coder/phcoder' Serbinenko wrote: Unify RAID and LVM into one unifomr diskfilter similar to device-mapper or geom. I went ahead and committed it after running a series of tests and fixing few bugs. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Patch] Robustly search for ZFS labels uberblocks
On 28.01.2012 19:33, Richard Laager wrote:
On Sat, 2012-01-28 at 13:51 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
Index: grub/util/grub.d/10_linux.in
===
--- grub.orig/util/grub.d/10_linux.in 2012-01-24 23:44:10.530591000 -0600
+++ grub/util/grub.d/10_linux.in2012-01-24 23:44:10.706928000 -0600
@@ -56,8 +56,10 @@
LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
fi
-if [ x`${grub_probe} --device ${GRUB_DEVICE} --target=fs 2/dev/null ||
true` = xbtrfs ] \
-|| [ x`stat -f --printf=%T /` = xbtrfs ]; then
+LINUX_ROOT_FS=`${grub_probe} --device ${GRUB_DEVICE} --target=fs 2/dev/null
|| true`
+LINUX_ROOT_STAT=`stat -f --printf=%T / || true`
+
+if [ x${LINUX_ROOT_FS} = xbtrfs -o x${LINUX_ROOT_STAT} = xbtrfs ]; then
rootsubvol=`make_system_path_relative_to_its_root /`
rootsubvol=${rootsubvol#/}
if [ x${rootsubvol} != x ]; then
@@ -76,6 +78,10 @@
GRUB_CMDLINE_EXTRA=$GRUB_CMDLINE_EXTRA crashkernel=384M-2G:64M,2G-:128M
fi
+if [ x${LINUX_ROOT_FS} = xzfs ]; then
+ GRUB_CMDLINE_LINUX=boot=zfs \$bootfs ${GRUB_CMDLINE_LINUX}
+fi
+
linux_entry ()
{
os=$1
@@ -114,6 +120,12 @@
fi
printf '%s\n' ${prepare_boot_cache}
fi
+ if [ x${LINUX_ROOT_FS} = xzfs ]; then
+cat EOF
+ insmod zfsinfo
+ zfs-bootfs (\$root) bootfs
This makes 3 wrong assumptions in a row:
- / and /boot may be different.
Despite the variable being called LINUX_ROOT_FS, this is really the
output from grub-probe --device ${GRUB_DEVICE}. When / != /boot, is
$GRUB_DEVICE the device of / or /boot?
- Linux may be in a non-root subvolume. Then the subvolid points to
wrong one.
By Linux, you're talking about the kernel, as opposed to the root
filesystem, correct?
What do you mean by non-root subvolume? That sounds like a btrfs term,
not a ZFS term, so I don't follow.
- / may be unaccessible to GRUB altogether.
Are you talking about at grub-install time or boot time? Can you provide
an example of when this might happen, so I can understand.
In short: this command line part has to be generated on grub-mkconfig
time and have a stable representation. I'd recommend UUID and subvolume
name.
By this command line part, are you talking about the path to the
kernel?
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'include/grub/emu/getroot.h'
--- include/grub/emu/getroot.h 2011-04-25 12:52:07 +
+++ include/grub/emu/getroot.h 2012-01-29 20:58:08 +
@@ -30,7 +30,7 @@
};
char *grub_find_device (const char *dir, dev_t dev);
-char *grub_guess_root_device (const char *dir);
+char **grub_guess_root_devices (const char *dir);
int grub_util_get_dev_abstraction (const char *os_dev);
char *grub_util_get_grub_dev (const char *os_dev);
char *grub_make_system_path_relative_to_its_root (const char *path);
=== modified file 'include/grub/emu/misc.h'
--- include/grub/emu/misc.h 2011-12-13 13:51:41 +
+++ include/grub/emu/misc.h 2012-01-29 20:58:08 +
@@ -80,6 +80,4 @@
int grub_device_mapper_supported (void);
#endif
-char *grub_find_root_device_from_mountinfo (const char *dir, char **relroot);
-
#endif /* GRUB_EMU_MISC_H */
=== modified file 'util/getroot.c'
--- util/getroot.c 2012-01-29 20:49:44 +
+++ util/getroot.c 2012-01-29 20:58:08 +
@@ -180,6 +180,149 @@
return path;
}
+static char **
+find_root_devices_from_poolname (char *poolname)
+{
+ char **devices = 0;
+ size_t ndevices = 0;
+ size_t devices_allocated = 0;
+
+#if defined(HAVE_LIBZFS) defined(HAVE_LIBNVPAIR)
+ zpool_handle_t *zpool;
+ libzfs_handle_t *libzfs;
+ nvlist_t *config, *vdev_tree;
+ nvlist_t **children, **path;
+ unsigned int nvlist_count;
+ unsigned int i;
+ char *device = 0;
+
+ libzfs = grub_get_libzfs_handle ();
+ if (! libzfs)
+return NULL;
+
+ zpool = zpool_open (libzfs, poolname);
+ config = zpool_get_config (zpool, NULL);
+
+ if (nvlist_lookup_nvlist (config, vdev_tree, vdev_tree) != 0)
+error (1, errno, nvlist_lookup_nvlist (\vdev_tree\));
+
+ if (nvlist_lookup_nvlist_array (vdev_tree, children, children, nvlist_count) != 0)
+error (1, errno, nvlist_lookup_nvlist_array (\children\));
+ assert (nvlist_count 0);
+
+ while (nvlist_lookup_nvlist_array (children[0], children,
+ children, nvlist_count) == 0)
+assert (nvlist_count 0);
+
+ for (i = 0; i nvlist_count; i++)
+{
+ if (nvlist_lookup_string (children[i], path, device) != 0)
+ error (1, errno, nvlist_lookup_string (\path\));
+
+ struct stat st;
+ if (stat (device, st) == 0)
+ {
+#ifdef __sun__
+ if (grub_memcmp (device, /dev/dsk/, sizeof (/dev/dsk/) - 1)
+ == 0)
+ device = xasprintf (/dev/rdsk/%s,
+device + sizeof (/dev/dsk/) - 1);
+ else if (grub_memcmp (device, /devices, sizeof (/devices) - 1)
+ == 0
+ grub_memcmp (device + strlen (device) - 4,
+ ,raw, 4) != 0)
+ device = xasprintf (%s,raw, device);
+ else
+#endif
Re: [Patch] Robustly search for ZFS labels uberblocks
On 30.01.2012 02:22, Richard Laager wrote: On Sat, 2012-01-28 at 13:51 +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: As for /proc/mounts : is there a reason to suppose that /proc/mounts would work when /proc/self/mountinfo doesn't /proc/self/mountinfo doesn't exist on older Linux kernels. What is upstream GRUB's minimum required version of Linux kernel? Any of 2.x or 3.x line should work. However on older ones we just scan /dev to find a device with the same major/minor as the one we've got from stat (). It's possible to try to use mtab or /proc/mounts as hint while still checking for major/minor match but it's not important. Also I don't suppose anyone will use ZFS with older kernels -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
grub-install revamp and grub-mkrescue adjustments
I was looking into Szymon Janc's patch to compress GRUB modules and
found out that adding decompression modules makes it grow bigger than
the embed zone. So I propose the following change: make boot sector
point to eltotito.img and use diskboot.img at this location. This has
given good results with using a very crude patch to xorriso (attached
for illustration purposes). I've seen that isohybrid image make similar
changes, what is the exact behaviour for isohybrid? PErhaps we can unify
it with ours?
Offsets aren't written in stone and I wanted to change boot.img for isos
a bit first to allow it botting as a floppy even on broken BIOSes (we
need few routines for those which are overwritten by partition table,
I'll move them to the space reserved for BBP, it's no big deal since
there is no BBP on iso9660).
This also allows to use other embed sectors to create alternative
filesystems. As for the roadmap for creating an iso bootable everywhere
as both USB stick and CDROM we'll need following adjustments
- i386-pc: detailed above.
- *-efi: we currently support only CD-ROMs. Supporting USB sticks needs
just to create a partition of type 0xEF pointing to EFI eltorito image.
- Macs would need an APM and HFS(+) filesystem. No need to have HFS span
over whole disk. It can just point to a small image. To have an APM we
need to have bytes
4552 0200 (512 sectors). Rest of table goes to sectors 1-n (n is the
number of partitions)
- IBM PPC require PreP (msdos with type=42) partition.
- ARC would require 0b e5 a9 41 at the beginning and so it's skipped
- Put i386-ieee1275 images to the same 0xef partition as EFI images.
- Have an ext2 partition for mipsel-loongson and i386-multiboot
- Sun would use most of sector 0, so it's skipped.
So the layout is:
4552 0200 grub code partition map: 0xef, 0x42, logical, empty 55 aa
APM entry covering partmap itselfAPM protective entry 1APM HFSAPM
protective entry 2usual iso9660, right after prep file, an EBR
Adjustments to xorriso:
- patch address in boot sector to eltorito.img. Patch 2nd sector of
eltorito.img to point to itself.
- set addresses to partitions to point to efi.img, prep.img and to an
EBR right after max (prep.img, efi.img, 4 x 512). Make EBR describe a
logical partition spanning the rest of iso9660. efi.img or prep.img may
be missing
- generate APM to point to the hfs.img
For supporting Sun (only, without any other one using sector 0):
-generate sun disklabel and patch an address and size to boot image in
sector 1.
For supporting ARC (only, without any other one using sector 0):
-generate DVH and set it to point to address of arc.img.
What do you think about this how reasonable is it?
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'ChangeLog'
--- ChangeLog 2012-01-30 00:18:02 +
+++ ChangeLog 2012-01-30 00:20:12 +
@@ -1,8 +1,18 @@
+ TREE
2012-01-30 Vladimir Serbinenko phco...@gmail.com
* grub-core/io/lzopio.c (uncompress_block): Fix use of incorrect
variable.
+===
+2012-01-29 Szymon Janc szy...@janc.net.pl
+
+ Put grub-mkrescue generated image on diet (modules compression and
+ xorriso options).
+
+ * util/grub-mkrescue.in: New option --compress.
+
+ MERGE-SOURCE
2012-01-29 Vladimir Serbinenko phco...@gmail.com
* grub-core/lib/posix_wrap/string.h (memchr): New function.
=== modified file 'grub-core/boot/i386/pc/diskboot.S'
--- grub-core/boot/i386/pc/diskboot.S 2011-07-06 18:05:26 +
+++ grub-core/boot/i386/pc/diskboot.S 2012-01-30 00:20:27 +
@@ -83,7 +83,7 @@
/* the maximum is limited to 0x7f because of Phoenix EDD */
xorl %eax, %eax
- movb $0x7f, %al
+ movb $0x1, %al
/* how many do we really want to read? */
cmpw %ax, 8(%di) /* compare against total number of sectors */
=== modified file 'util/grub-mkrescue.in'
--- util/grub-mkrescue.in 2012-01-24 12:17:36 +
+++ util/grub-mkrescue.in 2012-01-30 00:47:25 +
@@ -44,6 +44,7 @@
grub_mkimage=${bindir}/`echo grub-mkimage | sed ${transform}`
xorriso=xorriso
+compress=no
# Usage: usage
# Print the usage.
@@ -52,13 +53,14 @@
Usage: $self [OPTION] SOURCE...
Make GRUB rescue image.
- -h, --help print this message and exit
- -v, --version print the version information and exit
- -o, --output=FILE save output in FILE [required]
- --modules=MODULES pre-load specified modules MODULES
- --rom-directory=DIR save rom images in DIR [optional]
- --xorriso=FILE use FILE as xorriso [optional]
- --grub-mkimage=FILE use FILE as grub-mkimage
+ -h, --help print this message and exit
+ -v, --versionprint the version information and exit
+ -o, --output=FILEsave output in FILE [required]
+ --modules=MODULESpre-load specified modules MODULES
+ --rom-directory=DIR save rom images in DIR [optional]
+ --xorriso=FILE use FILE as xorriso [optional]
+ --grub
Re: [RFC] FIEMAP and disk sync issues
So it is a matter of implementing the right callback in BFS to support FIBMAP/FIEMAP. Same for ntfs3g. ntfs3g does implement bmap. Problem is that the only way to access this from userspace is FIBMAP which cuts to 32-bits. FIEMAP is implemented as a different ioctl rather than piggybacking on bmap. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-install revamp
On 30.01.2012 03:37, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Hello, all. It was a Robert's idea of having grub-install to install
all available (as in: the ones which were make install'ed) ports in a
single grub-install w/o having to keep and run one grub-install per port.
I've tried to write such a thing. I have met some problems in practice:
- I wanted also to integrate mactelbless in the same time. Unfortunately
Apple uses the same pointer for both i386 and x86_64 efi. So hfs(+)
partitions can hold only either 32-bit or 64-bit EFI binary. We could
use FAT Binary to workaround this but not all macs support this.
- If one of platform specific installs fail the script doesn't install
other platforms.
- When modifying nvram on EFI where to point it to? ESP or HFS? This is
easy: HFS if it's a mac and ESP otherwise. Or just always ESP.
- The same problem for ieee1275. While distinguishing between mac and
non-mac is easy (check vendor string), I don't know how to distinguish
the ones using PreP partition and the ones using a file on a FAT fs.
I would appreciate any input both on these specific problems and the
idea in general. Perhaps it's better to abandon it and have something
easier like auto-detect firmware and use it as default and specify it
manually if you need a different install.
The attached patch is just a small illustration to discuss about. It
doesn't work
This has an advantage of making the disk bootable in various ways
including ability to move it from one computer to another.
The first problem is the files collision. To resolve this the
modification will be to load modules from
$prefix/$cpu-$platform/$modname.mod. Also 2 new script constants will
be defined: $cpu and $platform.
The problem then is that different firmwares require different kind of
arrangements in order to be bootable.
i386-pc requires 55AA signature, some code in MBR and embedding zone.
A dummy msdos active partition is required on some systems.
*-efi require files on ESP and some nvram entries
i386-qemu, i386-coreboot, i386-qemu_mips and loongsoon-firmware are
firmware ports and we don't use grub-install for those but
grub-mkstandalone.
i386-multiboot just has to be readable by whatever is a coreboot payload.
mipsel-loongson has to be on ext2 msdos partition.
sparc64 requires SUN partition map and the code in sector 1
Powerpc (Apple) requires a file on HFS and nvram modification
PowerPC (IBM) uses PreP partition
ARC uses a special entry in the dvh partition table
I have no idea what i386-ieee1275 requires but I guess it's a fat
partition with special file + nvram modification.
So I propose following strategy: grub-install does the following
platform-specific installations:
- if /boot/efi is on fat, copy grub to
/boot/efi/efi/$boot_id/grub[ia32|x64|ia64].efi (replace $boot_id and
grub with boot if --removable is specified) and update nvram if no
--removable is specified and currently running EFI version matches the
installed one.
- if /boot/mac is on HFS or HFS+, create there a structure recognized
by both PPC and Intel macs and update nvram if architecture matches
- If /boot/ext2 is on ext*, put mipsel-loongson and i386-multiboot there.
- If /boot/olpc is on fat, install i386-ieee1275 there and update
nvram if architecture matches.
- For every argument that is an msdos or gpt disk, install i386-pc
bootsector.
- For every argument that is a sun disk, install sun bootsector.
- For every argument that is a dvh disk, install mips-arc.
- For every argument that is a prep partition install powerpc-ieee1275
While the copying to partitions is harmless and updating nvram is done
only if architecture and platform matches, the disk operations may be
harmful. While none of the current 4 configuration usually come in
contradictory combinations, it's possible to purposedly create a disk
of multiple types and it will confuse this logic. Also if we throw
e.g. hppa into the mix which requires just a signature on bytes 0-1
and some info in 0xf4-0xff then we can't know if msdos disk is for
BIOS or hppa install. So we need a way to specify them more precisely.
PreP and ARC came in only after 1.99 so we can make them accept only
the new way whatever it will be. In case of old way we can easily
distinguish sparc64-ieee1275 and i386-pc with e.g. uname -i. I propose
either of:
--device-bios=/dev/xyz --device-sun=/dev/xyz --device-arc=/dev/xyz
--device-prep=/dev/xyz
Or: bios:/dev/xyz sun:/dev/xyz arc:/dev/xyz prep:/dev/xyz
Also it may happen that installation of some port is undesirable. So
we need options
--install-only=...
--exclude=...
Any further ideas?
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'Makefile.util.def'
--- Makefile.util.def 2012-01-29 13:28:01 +
+++ Makefile.util.def 2012-02-01 17:43:10 +
@@ -309,39 +309,51 @@
};
program = {
- name = grub-setup;
- installdir = sbin;
- mansection = 8;
- common = util/grub-setup.c;
- common
OLPC status
Is anybody testing GRUB on OLPC at all? I have neither it nor any other i386-ieee1275 (I don't even know if there is one other than using coreboot+ieee1275, which is suboptimal, since you can achieve better results with GRUB as payload, if not it's a bug). It also doesn't seem to be any recent reports of GRUB either succeeding or failing on it. Additionally it seems that OLPC is very selective about whom to give the laptop and it comes tivoized. While one can use qemu with ieee1275, I don't know how representative it is. Some of the code like nand disks are available in qemu. In light of this OLPC port is a likely candidate for removal. But since it benefits from much of shared code for both i386 and ieee1275 it's easy to keep around but guaranteeing any quality is essentially impossible. I see following courses of action: 1) Find someone who is willing to test from time to time. 2) If someone can point me to a way to get one without running into pretty high cost and shipping fees (few offers I saw on ebay make it available only in USA and cost more than an ARM system and if I buy a system for porting, ARM is more important), I can give it a spin evry now and then and before releases. 3) Put prominent warnings and discourage people to use it 4) Remove the port altogether -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Patch] Robustly search for ZFS labels uberblocks
On 31.01.2012 09:45, Richard Laager wrote: Attached is a stack of trivial patches that apply*on top of* your zfs.diff from 2012-01-29. They each deal with one logical change and should be very easy to review. After your original patch and this stack have been dealt with, I'll submit an updated patch for native ZFS on Linux support, which is much shorter than before. -- Richard zfs-on-linux-rlaager0.patch Eliminate stray trailing spaces. We don't do it manually, just from time to time run it automatically on whole codebase. zfs-on-linux-rlaager1.patch Change device to devices in find_root_devices_from_libzfs committed zfs-on-linux-rlaager2.patch Change strlen to sizeof It doesn't matter since GCC changes strlen of const string to just a const. But applied for conformity with the rest of codebase zfs-on-linux-rlaager3.patch Avoid crashing when canonicalize_file_name() fails I could reproduce this with: grub-probe /dev/sda1 Committed zfs-on-linux-rlaager4.patch Drop an unused variable. committed. zfs-on-linux-rlaager5.patch Add braces around and indent the `zpool status` parsing loop Not needed. And we don't put a braces which are not needed. zfs-on-linux-rlaager6.patch Handle pool names with trailing spaces What about the ones with spaces in the middle? It feels like the logic is broken elsewhere and using strncmp is just a workaround which works only for one particular case zfs-on-linux-rlaager7.patch Handle all raidz types in `zpool status` output Committed. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Patch] Robustly search for ZFS labels uberblocks
On 02.02.2012 12:13, Richard Laager wrote:
Attached are two more patches to add to the stack.
Committed (see below for comments). Next time please attach ChangeLog
entry and use -p on diff.
-- Richard
zfs-on-linux-rlaager10.patch
Index: grub/util/grub-probe.c
===
--- grub.orig/util/grub-probe.c 2012-02-02 03:36:38.827815635 -0600
+++ grub/util/grub-probe.c 2012-02-02 03:39:22.727085000 -0600
@@ -323,6 +323,11 @@
if (path != NULL)
{
grub_path = canonicalize_file_name (path);
+ if (! grub_path)
+ {
+ grub_util_error (_(failed to get canonical path of %s), path);
+ return;
+ }
No need to return. grub_util_error never returns.
Index: grub/util/grub-probe.c
===
--- grub.orig/util/grub-probe.c 2012-02-02 04:04:16.154167324 -0600
+++ grub/util/grub-probe.c 2012-02-02 04:07:11.91609 -0600
@@ -363,6 +363,16 @@
}
*curdrive = 0;
+ if (print == PRINT_DRIVE)
+{
+ for (curdrive = drives_names; *curdrive; curdrive++)
+ {
+ printf ((%s), *curdrive);
+ putchar (delim);
+ }
+ return;
It should be goto end;
+}
+
if (print == PRINT_FS || print == PRINT_FS_UUID
|| print == PRINT_FS_LABEL)
{
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Don't create grubenv on ZFS
On 02.02.2012 12:16, Richard Laager wrote: GRUB can't write to ZFS. Creating a grubenv file leads to a misleading sparse file not allowed error on boot. The attached patch for grub-install skips the creation of a grubenv file on ZFS. This isn't specific to ZFS. BtrFS, squash4, all variants of cpio, tar and romfs are affected by the same problem. Could you expand your patch to handle those? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Don't create grubenv on ZFS
On 03.02.2012 11:07, Richard Laager wrote: On Fri, 2012-02-03 at 11:05 +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 02.02.2012 12:16, Richard Laager wrote: GRUB can't write to ZFS. Creating a grubenv file leads to a misleading sparse file not allowed error on boot. The attached patch for grub-install skips the creation of a grubenv file on ZFS. This isn't specific to ZFS. BtrFS, squash4, all variants of cpio, tar and romfs are affected by the same problem. Could you expand your patch to handle those? I suspect that handling them by name is not the best way to do this. How can I tell if a filesystem doesn't support writing? I think it's the best way. One could use grub-fstest blocklist but it has other problems. While btrfs and zfs don't hook blocklist on purpose (COW and, more importantly, checksums), others are just almost never sector-aligned or are compressed. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#632048: segfault in grub-setup
The problem with floppy part was fixed and the attempt to install on partionless disk was a user error. Closing On 06.09.2011 16:50, Stephane Chazelas wrote: 2011-09-06 09:18:57 +0100, Colin Watson: On Tue, Sep 06, 2011 at 08:39:24AM +0100, Stephane Chazelas wrote: I do get a segfault as well when doing a grub-setup/grub-install on a mdraid with 1.2 metadata. The segv is in: grub_util_biosdisk_is_floppy() because the disk-id for the root device is not a bios disk id, but a big number that is the array id. The patch below seems to fix it for me, though I can't tell it's the right fix or not (probably not). This fix makes sense to me; calling grub_util_biosdisk_is_floppy on disks that aren't GRUB_DISK_DEVICE_BIOSDISK_ID doesn't make sense. grub-devel, second opinion? --- a/util/grub-setup.c 2011-09-05 12:11:31.864955442 +0100 +++ b/util/grub-setup.c 2011-09-05 13:00:24.891368760 +0100 @@ -315,7 +315,7 @@ /* If DEST_DRIVE is a hard disk, enable the workaround, which is for buggy BIOSes which don't pass boot drive correctly. Instead, they pass 0x00 or 0x01 even when booted from 0x80. */ -if (!allow_floppy !grub_util_biosdisk_is_floppy (dest_dev-disk)) +if (!allow_floppy dest_dev-disk-dev-id == GRUB_DISK_DEVICE_BIOSDISK_ID !grub_util_biosdisk_is_floppy (dest_dev-disk)) /* Replace the jmp (2 bytes) with double nop's. */ *boot_drive_check = 0x9090; } [...] Well, anyway, even after that patch, it still doesn't work grub-install /dev/md0 reports success for nothing is written to any disk. grub-install /dev/sda or /dev/sdb doesn't work because it complains about a partition-less disk. Looks like it's not supported. Strange, as when started, grub can happily see files on 1.2 raids (using mdraid1x). Or did I miss something. I'll have to revert to 0.9 metadata for now. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Purposing an Alternative Feature Request: Make Use of Whole-Disk UUIDs
Keep the list CC'ed. On 04.02.2012 15:08, Jake Thomas wrote: If one only imaged/cloned partitions rather than whole disks, the disks' UUIDs wouldn't change, however, individual partitions would wind up with identical UUIDs. The partition UUIDs can easily be made unique afterwards with tune2fs, but I think using the whole-disk-UUID as your truly unique identifier would be even easier. So if in the bootloader that whole-disk-level UUID could be used to specify the hard drive, and then after that specify the number of the partition you want to go to within that drive, you'd be golden. You confuse FS and partition ID. Consult GPT format for an example I'm thinking that the flaw in using the hardware name as a unique identifier is that someone might buy a bunch of hard drives of the same exact model in bulk to start a server or something. Wouldn't they all have the same hardware disk-id? Or does the hardware disk-id include a unique identifer even amongst identical hardware? Whole-disk-level UUIDs can be easily changed if necessary. One can also easily avoid changing the whole-disk-level UUID by imaging/cloning only partitions and not the whole disk. Serial is unique. But then, of course, there is a land called China and it was known to sometimes produce a bulk of network cards with same mac. When I was saying --hd-uuid I meant for the hd to stand for hard drive just like it does in set root='(hd0,2)' . I didn't intend to convey that it could stand for hardware. In fact, arguably, if Grub ever did use hd to stand for hardware, that would be an inconsistency in it's naming conventions, because back in set root='(hd0,2)' , hd stands for something different. Yes and HD would refer to something inherent to hard disk even if you zero its contents out. I don't think partmap-uuid would be a better name for what I'm trying to describe because partmap-uuid is making a reference to partitions and/or possibly partition tables and/or memory mappings. partmap is the term we use to refer to partition tables and the UUID is stored exactly there. I'm not referring to any of those. I'm referring to something completely partition-independent that does not even exist in a partition table. Whole-disk UUIDs come before the partition table in both MBR and GPT structuring. You said it yourself. It comes from partmap I don't fully understand what you mean by is independent of actual partmap (e.g. search --partition-uuid is fine but search --gptuuid isn't). Does the syntax with a hyphen in the middle not use partmap while the one without a hyphen in the middle use partmap? I mean that the name shouldn't refer to any specific partmap. If you want it separate from partmap, wouldn't that be another reason to not name it partmap-uuid? No. I don't want it separate, I want it abstracted. Once you specify the hard drive by whole-disk-level UUID, syntax needs to provide a way to specify the partition within the choosen hard drive. I'm just trying to stay consistent with the syntax search --no-floppy --fs-uuid --set=root'(hd0,2)' . I thought search --no-floppy --hd-uuid --set=root '([UUID],[partition #])' was a good parallel. No need to brackets. What exactly does partmap do anyways? Does it write/ edit drivemappings in memory, or does Grub only use partmap to internally keep track of partitions and disks? partmap only discovers partitions. To modify them if needed (which is rarely the case) we have parttool Cheers, Jake -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [MERGE] Add a --disable-zfs configure flag.
On 04.02.2012 20:56, Mike Gilbert wrote: I happen to have the ZFS libraries installed on my machine, but I don't want my boot loader to use them. It seems to be broken for me at the moment in any case. I'm new to bazaar and this is my first submission to this mailing list, so please let me know if I've done something incorrectly. It's not maintainable to disable a feature every time we meet an issue with a part of code. Could you please detail on your issues? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] diskfilter: Treat an unrecognized RAID level as an error
On 04.02.2012 23:01, Richard Laager wrote: disk/diskfilter.c: In function 'grub_diskfilter_make_raid': disk/diskfilter.c:847:21: error: 'totsize' may be used uninitialized in this function [-Werror=uninitialized] Perhaps my patch should use assert() instead of return NULL? We don't use assert since assert failures are usually not fatal. And failing to boot just because some otherwise unused disk has a RAID-9 isn't reasonable. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Removal of payload command on ia64
Hello, all. When I was looking at the ambiguous strings and mistranslations I came accross payload ia64 command in Linux loader. Its description was so vague that it could do anything and still match the description. So I've decided to investigate to find out what it's about. But boot parameter structure in Linux files stops at initrd fields. Moreover the only reference on Google to ia64_boot_payload is our code. Could someone supply more details? If not I'll assume that it was just some debug feature during developpement and isn't used by anyone and remove it. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH V3 1/3] Update the Linux boot protocol
Go ahead.
On 08.02.2012 17:55, Matthew Garrett wrote:
The Linux boot header includes information on the kernel's desired load
address and alignment. Add support for that.
---
ChangeLog |6 ++
include/grub/i386/linux.h | 28 +++-
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index ede7f8e..2bdb3a0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2012-02-08 Matthew Garrettm...@redhat.com
+
+ * include/grub/i386/linux.h (linux_kernel_header): Update to
+ boot protocol 2.10.
+ (linux_kernel_params): Likewise
+
2012-02-07 Vladimir Serbinenkophco...@gmail.com
* grub-core/lib/i386/relocator16.S: Revert moving A20 code into PM
diff --git a/include/grub/i386/linux.h b/include/grub/i386/linux.h
index 6aa2391..8e27b93 100644
--- a/include/grub/i386/linux.h
+++ b/include/grub/i386/linux.h
@@ -86,7 +86,7 @@ enum
GRUB_VIDEO_LINUX_TYPE_SIMPLE = 0x70/* Linear framebuffer without any
additional functions. */
};
-/* For the Linux/i386 boot protocol version 2.03. */
+/* For the Linux/i386 boot protocol version 2.10. */
struct linux_kernel_header
{
grub_uint8_t code1[0x0020];
@@ -131,8 +131,16 @@ struct linux_kernel_header
grub_uint32_t initrd_addr_max;/* Highest address for initrd */
grub_uint32_t kernel_alignment;
grub_uint8_t relocatable;
- grub_uint8_t pad[3];
+ grub_uint8_t min_alignment;
+ grub_uint8_t pad[2];
grub_uint32_t cmdline_size;
+ grub_uint32_t hardware_subarch;
+ grub_uint64_t hardware_subarch_data;
+ grub_uint32_t payload_offset;
+ grub_uint32_t payload_length;
+ grub_uint64_t setup_data;
+ grub_uint64_t pref_address;
+ grub_uint64_t init_size;
} __attribute__ ((packed));
/* Boot parameters for Linux based on 2.6.12. This is used by the setup
@@ -276,10 +284,20 @@ struct linux_kernel_params
grub_uint32_t ramdisk_size; /* initrd size */
grub_uint32_t bootsect_kludge; /* obsolete */
grub_uint16_t heap_end_ptr; /* Free memory after setup end */
- grub_uint16_t pad1; /* Unused */
+ grub_uint8_t ext_loader_ver; /* Extended loader version */
+ grub_uint8_t ext_loader_type;/* Extended loader type */
grub_uint32_t cmd_line_ptr; /* Points to the kernel command line */
-
- grub_uint8_t pad2[164]; /* 22c */
+ grub_uint32_t initrd_addr_max; /* Maximum initrd address */
+ grub_uint32_t kernel_alignment; /* Alignment of the kernel */
+ grub_uint8_t relocatable_kernel; /* Is the kernel relocatable */
+ grub_uint8_t pad1[3];
+ grub_uint32_t cmdline_size; /* Size of the kernel command line */
+ grub_uint32_t hardware_subarch;
+ grub_uint64_t hardware_subarch_data;
+ grub_uint32_t payload_offset;
+ grub_uint32_t payload_length;
+ grub_uint64_t setup_data;
+ grub_uint8_t pad2[120]; /* 258 */
struct grub_e820_mmap e820_map[GRUB_E820_MAX_ENTRY];/* 2d0 */
} __attribute__ ((packed));
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH V3 3/3] Update Linux loader to follow the kernel's preferences
__attribute__ ((unused)), grub_memcpy (params-setup_sects,lh.setup_sects, sizeof (lh) - 0x1F1); params-ps_mouse = params-padding10 = 0; + params-code32_start = prot_mode_target; + params-kernel_alignment = (1 align); len = 0x400 - sizeof (lh); if (grub_file_read (file, (char *) real_mode_mem + sizeof (lh), len) != len) @@ -774,7 +821,7 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)), grub_file_seek (file, real_size + GRUB_DISK_SECTOR_SIZE); grub_dprintf (linux, bzImage, setup=0x%x, size=0x%x\n, - (unsigned) real_size, (unsigned) prot_size); + (unsigned) real_size, (unsigned) prot_file_size); /* Look for memory size and video mode specified on the command line. */ linux_mem_size = 0; @@ -911,7 +958,7 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)), maximal_cmdline_size - (sizeof (LINUX_IMAGE) - 1)); - len = prot_size; + len = prot_file_size; Any reason for rename? if (grub_file_read (file, prot_mode_mem, len) != len !grub_errno) grub_error (GRUB_ERR_FILE_READ_ERROR, N_(premature end of file %s), argv[0]); -- 1.7.7.6 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/4] Add grub_efi_get_variable
On 08.02.2012 17:51, Matthew Garrett wrote:
Code may wish to obtain system information from EFI variables. Add support
for making the platform call.
---
ChangeLog|6 ++
grub-core/kern/efi/efi.c | 32
include/grub/efi/api.h |4
include/grub/efi/efi.h |3 ++-
4 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index ca07786..e662f3d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
2012-02-08 Matthew Garrettm...@redhat.com
+ * grub-core/kern/efi/efi.c (grub_efi_get_variable): Add new function.
+ * include/grub/efi/efi.h: Likewise.
+ * include/grub/efi/api.h: Add guid for EFI-specified variables.
+
+2012-02-08 Matthew Garrettm...@redhat.com
+
* include/grub/efi/pci.h: New file to define EFI PCI protocols.
2012-02-07 Vladimir Serbinenkophco...@gmail.com
diff --git a/grub-core/kern/efi/efi.c b/grub-core/kern/efi/efi.c
index 9a2c5e6..d366f8a 100644
--- a/grub-core/kern/efi/efi.c
+++ b/grub-core/kern/efi/efi.c
@@ -182,6 +182,38 @@ grub_efi_set_virtual_address_map (grub_efi_uintn_t
memory_map_size,
return grub_error (GRUB_ERR_IO, set_virtual_address_map failed);
}
+void *
+grub_efi_get_variable(grub_uint8_t *var, grub_efi_guid_t *guid)
+{
+ grub_efi_status_t status;
+ grub_efi_uintn_t datasize = 0;
+ grub_efi_runtime_services_t *r;
+ grub_efi_char16_t *var16;
+ int i;
+ void *data;
+
+ var16 = grub_malloc((grub_strlen((char *)var) +1) * 2);
+
Indentation.
You also don't check that malloc succeeded. Also I recommend using
intermediary variable for length
+ for (i=0; i(int)grub_strlen((char *)var); i++)
+var16[i] = var[i];
+ var16[i] = '\0';
+
We use grub_utf8_to_utf16. Also don't forget to multiply the malloc
length by GRUB_MAX_UTF16_PER_UTF8 ((GRUB_MAX_UTF16_PER_UTF8 * length +
1) * sizeof (var16[0]))
+ r = grub_efi_system_table-runtime_services;
+
+ status = efi_call_5 (r-get_variable, var16, guid, NULL,datasize, NULL);
+
+ data = grub_malloc(datasize);
+
Again: no check for success.
+ status = efi_call_5 (r-get_variable, var16, guid, NULL,datasize, data);
+
+ grub_free(var16);
+
+ if (status == GRUB_EFI_SUCCESS)
+ return data;
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 3/4] Prefer GOP devices which implement the pci_io protocol
On 08.02.2012 17:51, Matthew Garrett wrote: Some systems (especially Apple) implement multiple GOP devices representing the same hardware. The preferred device is the one that also implements the PCI io protocol. Why not check which modes are supported by GOP rather than something we don't use otherwise? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 4/4] Add support for getting EDID via EFI
On 08.02.2012 17:51, Matthew Garrett wrote:
EFI gives a couple of defined methods for retrieving the EDID, so make use
of them. Some Apple devices don't provide these but do stash the EDID in an
nvram variable - grab it from there if it exists.
---
ChangeLog |8 +
grub-core/video/efi_gop.c | 69 +
2 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 26d779b..d46b3d1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
2012-02-08 Matthew Garrettm...@redhat.com
+ }
+
+ grub_memcpy (edid_info, edid-edid, sizeof(edid_info));
+
This code may copy more than actually present. You need to take minimum
of both length and fill the rest with zeros
+ return GRUB_ERR_NONE;
+}
+
+static grub_err_t
+grub_gop_get_preferred_mode (unsigned int *width, unsigned int *height)
+{
+ struct grub_video_edid_info edid_info;
+
+ if (grub_video_gop_get_edid(edid_info) == GRUB_ERR_NONE)
+{
+ if (grub_video_edid_checksum (edid_info) == GRUB_ERR_NONE
+ grub_video_edid_preferred_mode (edid_info, width, height)
+ == GRUB_ERR_NONE)
+ return GRUB_ERR_NONE;
+ else
+ grub_dprintf(video, invalid edid);
+}
+ return grub_error (GRUB_ERR_UNKNOWN_DEVICE, cannot get preferred mode);
Please reuse the error which actually happened. E.g:
err = grub_video_gop_get_edid(edid_info);
if (err)
return err;
err = grub_video_edid_checksum (edid_info);
if (err)
return err;
...
+}
+
+static grub_err_t
grub_video_gop_setup (unsigned int width, unsigned int height,
unsigned int mode_type,
unsigned int mode_mask __attribute__ ((unused)))
@@ -268,10 +319,18 @@ grub_video_gop_setup (unsigned int width, unsigned int
height,
unsigned bpp;
int found = 0;
unsigned long long best_volume = 0;
+ int preferred_mode = 0;
depth = (mode_type GRUB_VIDEO_MODE_TYPE_DEPTH_MASK)
GRUB_VIDEO_MODE_TYPE_DEPTH_POS;
+ if (width == 0 height == 0)
+{
+ grub_gop_get_preferred_mode (width,height);
+ if (grub_errno == GRUB_ERR_NONE)
+ preferred_mode = 1;
+}
+
You need to discard error if you continue
/* Keep current mode if possible. */
if (gop-mode-info)
{
@@ -306,6 +365,15 @@ grub_video_gop_setup (
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/4] Add grub_efi_get_variable
On 08.02.2012 21:04, Matthew Garrett wrote: On Wed, Feb 08, 2012 at 08:55:39PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: + for (i=0; i(int)grub_strlen((char *)var); i++) +var16[i] = var[i]; + var16[i] = '\0'; + We use grub_utf8_to_utf16. Also don't forget to multiply the malloc length by GRUB_MAX_UTF16_PER_UTF8 ((GRUB_MAX_UTF16_PER_UTF8 * length + 1) * sizeof (var16[0])) That's not currently exported. Any problem with changing that? It already is. The prototype and the define is in grub/charset.h -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/4] Add grub_efi_get_variable
On 08.02.2012 21:19, Matthew Garrett wrote: On Wed, Feb 08, 2012 at 09:09:23PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 08.02.2012 21:04, Matthew Garrett wrote: On Wed, Feb 08, 2012 at 08:55:39PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: + for (i=0; i(int)grub_strlen((char *)var); i++) +var16[i] = var[i]; + var16[i] = '\0'; + We use grub_utf8_to_utf16. Also don't forget to multiply the malloc length by GRUB_MAX_UTF16_PER_UTF8 ((GRUB_MAX_UTF16_PER_UTF8 * length + 1) * sizeof (var16[0])) That's not currently exported. Any problem with changing that? It already is. The prototype and the define is in grub/charset.h Oh, I was thinking of modules, but then this is already in core. Yes, I'll do that. grub_utf8_to_utf16 is in normal.mod. The easiest way to fix this problem is to inline grub_utf8_to_utf16. It's used only in 2 other different places. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH V3 2/3] Add support for avoiding firmware in relocations
On 08.02.2012 17:55, Matthew Garrett wrote: +if (type == GRUB_MEMORY_AVAILABLE) + return 0; + +if (target= addr target= end) + overlap = 1; + +if (target + size= addr target + size= end) + overlap = 1; This won't work. IEEE1275 declares only one type of memory range: available. Other ranges aren't declared at all. Also it would make sense to expand this implementation to other non-efi platforms (pc, coreboot, ...). -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH V3 2/3] Add support for avoiding firmware in relocations
On 08.02.2012 17:55, Matthew Garrett wrote: EFI and OF both support firmware regions which may be in use during loading. Add support for avoiding these. Also Seth Goldberg noticed that using chunk_align with start=end=target does exactly what we want (as if avoid=1). You may need to modify efi/relocator.c though as to which regions it considers available. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub 1.99 add own module / dep problem
On 09.02.2012 10:47, Robert Schumann wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Heyho guys!
I'm sorry if I didn't RTFM somewhere but I just couldn't find _any_
information on how to correctly add/patch own modules into the grub
1.99. The problem:
1. mymod.c depends on a function in biosdisk.c
Avoid this as much as possible. Biosdisk is arch-specific, use generic
disk functions.
2. mymod.c includes the biosdisk.h header correctly I suppose
3. I patched grub-core/Makefile.core.def with
module = {
name = mymod;
common = mymod/mymod.c;
enable = biosdisk;
enable=i386_pc; not biosdisk
};
4. I patched grub-core/Makefile.core.am with basically a copy from the
hello.c module stuff (although I should probably take the arch
dependend definitions from biosdisk mod? but I'm building i386 so it
should work any way?)
Don't touch this file. Just rerun ./autogen.sh
5. ./configure make works as expected for another module which
doesn't include a foreign function.
6. For mymod.c I receive
mymod/mymod.c:68: error: implicit declaration of function
'grub_biosdisk_get_diskinfo_standard'
This function is static (private). Moreover it's for very old C/H/S
addressing.
Looks like you're going the wrong way. Can you detail what's your end goal?
which is of course in biosdisk.c. Now my question: How do I solve this
mystery on a code/patch base? ;) I know that I can add the biosdisk.c
to the common code functions, but that shouldn't be necessary, huh? I
thought that enable = biosdisk would do the trick with linked
functions, but well... maybe you could shed some light on it.
Dependencies are tracked automatically.
Cheers
Robert
- --
|-address-+
| work: jacob-und-wilhelm-grimm-zentrum
|geschwister-scholl-str. 1, 10117 berlin
| mail: humboldt-universität zu berlin
|computer- und medienservice
|unter den linden 6, 10099 berlin
|-contact-+
| mail: schum...@informatik.hu-berlin.de
| icq: 93163687 | xmpp: betulichergutmen...@gmail.com
| fb:fb.com/rschumann | phone: +49(0)30-2093-70133
|-gpg/pgp-+
| key: remembrance.de/gpg/0xA5A5FAA2.asc
| fprnt: 9220-9732-7390-7A0C-5623-3336-4233-FDF8-A5A5-FAA2
|-+
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8zljkACgkQQjP9+KWl+qLypgCfb6Hbwo8YwvjTbGg7h9BVKZJd
QNQAoLSsg7RhpsZ/ovACGkuO42JpZozI
=oLeZ
-END PGP SIGNATURE-
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub 1.99 add own module / dep problem
On 09.02.2012 12:59, Robert Schumann wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Basically it's about NTFS system partition imaging. Relocating of the NT bootloader ntldr seems to need a run of ntfsreloc with the proper BIOS values in CHS format. I'm open to every better idea, but that seemed to be the only reliable way (at least on this i386 Win XP platform). Have a look at chainloader --bpb and ntldr commands. They both do the necessary patching. You need to change only partition start and bios disk values. I don't know the behaviour on a system which supports only C/H/S addressing (that would put it around 95, probably even earlier) but I'd expect that such an old machine is simply not powerful enough to run Windows XP. Also any modern system, especially with disks over C/H/S limit (8.3GB) emulate the same 255/63 geometry -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Various build failures in current bzr tree
On 09.02.2012 20:02, Lennart Sorensen wrote: I am trying to build a powerpc build using the current bzr tree, and have hit a few problems so far. I am trying to use gcc-4.4, which seems to cause issues with -Werror. I think that is gcc's fault, and --disable-werror gets around that, so not a big deal. What is the exact warning? I am hitting bug #35452 of course caused by commit r3826, but even after fixing that, commit r38xx does the same thing to another set of files. How did you fix it? I also hit that grub_arch_dl_get_tramp_got_size isn't defined. It appears it was cleaned up for powerpc as being unused recently, but dl.c still says that powerpc has it (along with ia64). Removing powerpc from: I have checked and it's still there and is still used. Please check that your checkout is correct and if so provide the full log #if defined (__ia64__) || defined (__powerpc__) grub_arch_dl_get_tramp_got_size (e,tramp,got); seems to fix that. Should I file bug reports, or will someone just fix these? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Various build failures in current bzr tree
On 09.02.2012 21:56, Lennart Sorensen wrote: On Thu, Feb 09, 2012 at 03:50:45PM -0500, Lennart Sorensen wrote: grub-install also still (as reported about 2 years ago) tries to use $grub_device rather than $install_device when getting the partition table type. However, I did now manage to boot after fixing that. So there is a chance I can make a patch to fix grub-install soon so it actually works on IBM power systems. Given I have a production machine and a new machine around for a few days I can experiment until it is right. Is this supposed to work: root@rceng03new:~# /usr/sbin/grub-probe --device /dev/md0 --target=abstraction diskfilter mdraid1x root@rceng03new:~# /usr/sbin/grub-probe --device /dev/md1 --target=abstraction /usr/sbin/grub-probe: error: Couldn't find PV (null). Check your device.map. md0 is raid1, md1 is raid5, but with a missing device at the moment. Does grub-probe not work if the raid5 isn't fully healthy? The problem is how to figure out which partmap module is used on the missing disk (which isn't necessarily the same as on the other disks). Do you have any ideas? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Unbreak help2man invocations
On 10.02.2012 13:11, Grégoire Sutre wrote: Following Vladimir's suggestion on IRC, the attached patch fixes bug http://savannah.gnu.org/bugs/?35452. Go ahead. Grégoire p.s. The patch uses @PACKAGE_TARNAME@ instead of @PACKAGE@ in the name of the directory that grub-mkconfig_lib is sourced from, to preserve the definition of pkgdatadir that was in grub-mkconfig.in. But I guess that those two are always equal for GRUB. @PACKAGE_TARNAME@ is more appropriate in this case but they are both equal in GRUB. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
GRUB warning level increase
Hello, all. I have increased the warning level in GRUB. This is done for quicker discovery and correction of the bugs which would be otherwise hard to track. Mostly it enabled warnings regarding guidelines which are already followed by GRUB. Most important one is -Wcast-align. x86 doesn't enforce any alignment but the other platforms do. And since platform-independent code is usually written and tested on x86, it's important to ensure that it's properly aligned. The invariants checked by -Wcast-align give the necessary guarantee as long as void * isn't involved. Some code is difficult to write in a way to satisfy the warning and/or is platform-specific, in this case #pragma exceptions can be done. For imported code we can add -Wno-* to module cflags for less important (mostly stylistic) warnings. Also if some warnings are too annoying we can drop them. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Various build failures in current bzr tree
On 10.02.2012 16:45, Lennart Sorensen wrote: On Thu, Feb 09, 2012 at 11:59:58PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 09.02.2012 20:02, Lennart Sorensen wrote: I am trying to build a powerpc build using the current bzr tree, and have hit a few problems so far. I am trying to use gcc-4.4, which seems to cause issues with -Werror. I think that is gcc's fault, and --disable-werror gets around that, so not a big deal. What is the exact warning? Complains about something like 'type punning breaks strict aliasing on diskfilter.19, diskfilter.20, etc. I saw it from the nv raid file. I can run it again if the exact message is important. Yes, those are annoying but important since otherwise GCC might misoptimise the code. Funny, the changelog says it was removed from powerpc about 3 weeks ago by you: 2012-01-18 Vladimir Serbinenkophco...@gmail.com * grub-core/kern/powerpc/dl.c (grub_arch_dl_get_tramp_got_size): Remove set but not used variable. Read again: I've just removed an unused variable. Actually removing powerpc from here builds successfully and grub is booting the machine, so it seems to work without it. It results in memory corruption. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Various build failures in current bzr tree
On 10.02.2012 16:54, Lennart Sorensen wrote: On Fri, Feb 10, 2012 at 12:02:52AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 09.02.2012 21:56, Lennart Sorensen wrote: On Thu, Feb 09, 2012 at 03:50:45PM -0500, Lennart Sorensen wrote: grub-install also still (as reported about 2 years ago) tries to use $grub_device rather than $install_device when getting the partition table type. However, I did now manage to boot after fixing that. So there is a chance I can make a patch to fix grub-install soon so it actually works on IBM power systems. Given I have a production machine and a new machine around for a few days I can experiment until it is right. Is this supposed to work: root@rceng03new:~# /usr/sbin/grub-probe --device /dev/md0 --target=abstraction diskfilter mdraid1x root@rceng03new:~# /usr/sbin/grub-probe --device /dev/md1 --target=abstraction /usr/sbin/grub-probe: error: Couldn't find PV (null). Check your device.map. md0 is raid1, md1 is raid5, but with a missing device at the moment. Does grub-probe not work if the raid5 isn't fully healthy? The problem is how to figure out which partmap module is used on the missing disk (which isn't necessarily the same as on the other disks). Do you have any ideas? Hmm, good question. So not working in this case is expected then at this time. However, is not returning the partition table of the devices you can find better than returning the partition map of what is found? Imagine following setup: 2 disks with msdos and one with gpt. GPT one is missing on install time and so no part_gpt is inserted. On boot time is then one of msdos disks is missing and so GPT one is needed to complete a readable device but it's inaccessible since no GPT module is loaded. By the way, does grub-probe have any way to return the underlying device of an md device? This and the rest of your e-mail is because of confusion of 2 concepts: grub_device and install_device. grub_device is whereever GRUB modules reside and is determined from $boot_directory/grub (default is /boot/grub) install_device is whereever the core is and is the argument to grub-install. They are independent since you want to put core wherever firmware will find it independently of where your root is. install_device is not infered from grub_device or vice-versa. In mdraid example grub_device=mduuid/UUID but install_device is still /dev/sdaX -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Various build failures in current bzr tree
On 09.02.2012 21:50, Lennart Sorensen wrote: On Thu, Feb 09, 2012 at 02:33:01PM -0500, Lennart Sorensen wrote: On Thu, Feb 09, 2012 at 02:02:04PM -0500, Lennart Sorensen wrote: I am trying to build a powerpc build using the current bzr tree, and have hit a few problems so far. I am trying to use gcc-4.4, which seems to cause issues with -Werror. I think that is gcc's fault, and --disable-werror gets around that, so not a big deal. I am hitting bug #35452 of course caused by commit r3826, but even after fixing that, commit r38xx does the same thing to another set of files. I also hit that grub_arch_dl_get_tramp_got_size isn't defined. It appears it was cleaned up for powerpc as being unused recently, but dl.c still says that powerpc has it (along with ia64). Removing powerpc from: #if defined (__ia64__) || defined (__powerpc__) grub_arch_dl_get_tramp_got_size (e,tramp,got); seems to fix that. Should I file bug reports, or will someone just fix these? grub-probe prints 'raid' rather than 'diskfilter' for the modulename to use when raid is in use. grub-install also still (as reported about 2 years ago) tries to use $grub_device rather than $install_device when getting the partition table type. This is not an error. (see other mail) install_device is only read from by firmware to locate the core. GRUB uses it only to infer root if $grub_device and $install_device refer to the same disk but $install_device isn't used otherwise by GRUB runtime. Please detail symptoms if any. If none, this is a non-issue. However, I did now manage to boot after fixing that. So there is a chance I can make a patch to fix grub-install soon so it actually works on IBM power systems. Given I have a production machine and a new machine around for a few days I can experiment until it is right. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Various build failures in current bzr tree
On 10.02.2012 19:15, Lennart Sorensen wrote: On Fri, Feb 10, 2012 at 05:02:42PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: Yes, those are annoying but important since otherwise GCC might misoptimise the code. I will grab the latest code again and run the compiler and get the exact message. Funny, the changelog says it was removed from powerpc about 3 weeks ago by you: 2012-01-18 Vladimir Serbinenkophco...@gmail.com * grub-core/kern/powerpc/dl.c (grub_arch_dl_get_tramp_got_size): Remove set but not used variable. Read again: I've just removed an unused variable. Hmm I misread it. You didn't remove grub_arch_dl_get_tramp_got_size, just something in it. I wonder why the linker can find grub_arch_dl_get_tramp_got_size then. Actually removing powerpc from here builds successfully and grub is booting the machine, so it seems to work without it. It results in memory corruption. Where should grub_arch_dl_get_tramp_got_size come from? The linker whines about it. So here are errors and warnings I am seeing with a current checkout: gcc-4.4 -DHAVE_CONFIG_H -I. -I../.. -Wall -W -I./include -DGRUB_UTIL=1 -DGRUB_LIBDIR=\/usr/lib/grub\ -DLOCALEDIR=\/usr/share/locale\ -DGRUB_MACHINE_EMU=1 -DGRUB_MACHINE=POWERPC_EMU -DGRUB_TARGET_CPU_POWERPC=1 -DGRUB_FILE=\util/getroot.c\ -I. -I../.. -I. -I../.. -I../../include -I./include -I./grub-core/gnulib -I../../grub-core/gnulib-g -Wall -O2 -Wall -W -Wshadow -Wold-style-declaration -Wold-style-definition -Wpointer-arith -Wmissing-prototypes -Wundef -Wextra -Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body -Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Winline -Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar -Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstack-protector -Wstrict-aliasing -Wstrict-overflow -Wswitch -Wsync-nand -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunreachable-code -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-result -Wunused-value -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wstrict-prototypes -Wpointer-sign -Werror -Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter -Wno-redundant-decls -Wno-unreachable-code -Wno-conversion -Wno-old-style-definition-c -o util/libgrubkern_a-getroot.o `test -f 'util/getroot.c' || echo '../../'`util/getroot.c cc1: warnings being treated as errors ../../util/getroot.c: In function 'find_partition': ../../util/getroot.c:1995: error: format '%lu' expects type 'long unsigned int', but argument 3 has type 'grub_disk_addr_t' ../../util/getroot.c: In function 'grub_util_biosdisk_get_grub_dev': ../../util/getroot.c:2025: error: format '%lu' expects type 'long unsigned int', but argument 3 has type 'grub_disk_addr_t' Then after changing %lu to %llu I get: gcc-4.4 -DHAVE_CONFIG_H -I. -I../.. -Wall -W -I./include -DGRUB_UTIL=1 -DGRUB_LIBDIR=\/usr/lib/grub\ -DLOCALEDIR=\/usr/share/locale\ -DGRUB_MACHINE_EMU=1 -DGRUB_MACHINE=POWERPC_EMU -DGRUB_TARGET_CPU_POWERPC=1 -DGRUB_FILE=\util/getroot.c\ -I. -I../.. -I. -I../.. -I../../include -I./include -I./grub-core/gnulib -I../../grub-core/gnulib-g -Wall -O2 -Wall -W -Wshadow -Wold-style-declaration -Wold-style-definition -Wpointer-arith -Wmissing-prototypes -Wundef -Wextra -Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body -Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Winline -Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar -Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstack-protector -Wstrict-aliasing -Wstrict-overflow -Wswitch -Wsync-nand -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunreachable-code -Wunused
Re: Various build failures in current bzr tree
On 10.02.2012 19:15, Lennart Sorensen wrote: Where should grub_arch_dl_get_tramp_got_size come from? The linker whines about it. It's in grub-core/kern/powerpc/dl.c I have no trouble to cross-compile ppc port on my amd64 machine. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Various build failures in current bzr tree
On 10.02.2012 19:18, Lennart Sorensen wrote: On Fri, Feb 10, 2012 at 05:11:16PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: Imagine following setup: 2 disks with msdos and one with gpt. GPT one is missing on install time and so no part_gpt is inserted. On boot time is then one of msdos disks is missing and so GPT one is needed to complete a readable device but it's inaccessible since no GPT module is loaded. Well I only hit this because one of Debian's update-grub scripts tried to do a grub-probe and failed. It wasn't an important one in my case, so I disabled that script. I do think most people would have a fully working system before installing the boot loader so not a major problem. I agree that it should be fixed but the question is how. This and the rest of your e-mail is because of confusion of 2 concepts: grub_device and install_device. grub_device is whereever GRUB modules reside and is determined from $boot_directory/grub (default is /boot/grub) install_device is whereever the core is and is the argument to grub-install. They are independent since you want to put core wherever firmware will find it independently of where your root is. install_device is not infered from grub_device or vice-versa. In mdraid example grub_device=mduuid/UUID but install_device is still /dev/sdaX So if I tell grub-install to use /dev/sda1 as install_device, should it not include the partition table support for sda? No Currently it only tries to include partition table support for grub_device, which being an md raid returns nothing. This is a problem. It should return the partmap of underlying device and we have code for that. What does grub-probe -t partmap -d /dev/mdX is? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Various build failures in current bzr tree
On 10.02.2012 20:14, Lennart Sorensen wrote: On Fri, Feb 10, 2012 at 02:08:52PM -0500, Lennart Sorensen wrote: On Fri, Feb 10, 2012 at 07:58:25PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 10.02.2012 19:15, Lennart Sorensen wrote: Where should grub_arch_dl_get_tramp_got_size come from? The linker whines about it. It's in grub-core/kern/powerpc/dl.c I have no trouble to cross-compile ppc port on my amd64 machine. I will get the exact error again once I get the new code to stop whining so much. :) Or I can put the defined(__powerpc__) back in the older code and try that again. OK I did that: Oh, it's powerpc-emu. That changes everything. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Various build failures in current bzr tree
On 10.02.2012 20:12, Lennart Sorensen wrote: root@rceng03new:~# grub-probe -t partmap -d /dev/md0 root@rceng03new:~# Found the error: diskfilter uses raw disks with offsets rather than partitions. Will fix soon. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Various build failures in current bzr tree
On 10.02.2012 20:12, Lennart Sorensen wrote:
On Fri, Feb 10, 2012 at 08:01:23PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
I agree that it should be fixed but the question is how.
I can't think of a way that would work if the disks were in fact using
different setups, which they could be.
No
OK, fair enough if the below worked then.
Currently it only
tries to include partition table support for grub_device, which being
an md raid returns nothing.
This is a problem. It should return the partmap of underlying device
and we have code for that. What does grub-probe -t partmap -d
/dev/mdX is?
root@rceng03new:~# grub-probe -t partmap -d /dev/md0
root@rceng03new:~#
So that would be a problem of course.
root@rceng03new:~# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md1 : active raid5 sda3[0] sdb3[1]
284773376 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
md0 : active raid1 sda2[0] sdb2[1]
976884 blocks super 1.2 [2/2] [UU]
unused devices:none
md0 is /boot
md1 is /
When I do the final install I will probably but lvm on md1 and put /
and swap and other things on that.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'docs/grub.texi'
--- docs/grub.texi 2012-01-31 21:59:32 +
+++ docs/grub.texi 2012-02-10 17:11:59 +
@@ -20,7 +20,7 @@
This manual is for GNU GRUB (version @value{VERSION},
@value{UPDATED}).
-Copyright @copyright{} 1999,2000,2001,2002,2004,2006,2008,2009,2010 Free Software Foundation, Inc.
+Copyright @copyright{} 1999,2000,2001,2002,2004,2006,2008,2009,2010,2011,2012 Free Software Foundation, Inc.
@quotation
Permission is granted to copy, distribute and/or modify this document
=== modified file 'gentpl.py'
--- gentpl.py 2011-12-24 14:09:26 +
+++ gentpl.py 2012-02-10 17:10:18 +
@@ -1,4 +1,19 @@
#! /usr/bin/python
+# GRUB -- GRand Unified Bootloader
+# Copyright (C) 2010,2011 Free Software Foundation, Inc.
+#
+# GRUB is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# GRUB is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GRUB. If not, see http://www.gnu.org/licenses/.
#
# This is the python script used to generate Makefile.tpl
=== modified file 'grub-core/disk/diskfilter.c'
--- grub-core/disk/diskfilter.c 2012-02-09 22:43:43 +
+++ grub-core/disk/diskfilter.c 2012-02-10 19:54:58 +
@@ -260,6 +260,24 @@
return list;
}
+void
+grub_diskfilter_print_partmap (grub_disk_t disk)
+{
+ struct grub_diskfilter_lv *lv = disk-data;
+ struct grub_diskfilter_pv *pv;
+
+ if (lv-vg-pvs)
+for (pv = lv-vg-pvs; pv; pv = pv-next)
+ {
+ grub_size_t s;
+ if (!pv-disk)
+ grub_util_error (_(Couldn't find physical volume `%s'.
+ Check your device.map), pv-name);
+ for (s = 0; pv-partmaps[s]; s++)
+ grub_printf (%s , pv-partmaps[s]);
+ }
+}
+
static const char *
grub_diskfilter_getname (struct grub_disk *disk)
{
@@ -964,6 +982,19 @@
pv-part_start = grub_partition_get_start (disk-partition);
pv-part_size = grub_disk_get_size (disk);
+#ifdef GRUB_UTIL
+ {
+ grub_size_t s = 1;
+ grub_partition_t p;
+ for (p = disk-partition; p; p = p-parent)
+ s++;
+ pv-partmaps = xmalloc (s * sizeof (pv-partmaps[0]));
+ s = 0;
+ for (p = disk-partition; p; p = p-parent)
+ pv-partmaps[s++] = xstrdup (p-partmap-name);
+ pv-partmaps[s++] = 0;
+ }
+#endif
if (start_sector != (grub_uint64_t)-1)
pv-start_sector = start_sector;
pv-start_sector += pv-part_start;
=== modified file 'include/grub/diskfilter.h'
--- include/grub/diskfilter.h 2012-01-29 13:28:01 +
+++ include/grub/diskfilter.h 2012-02-10 19:53:29 +
@@ -72,6 +72,9 @@
struct grub_diskfilter_pv *next;
/* Optional. */
grub_uint8_t *internal_id;
+#ifdef GRUB_UTIL
+ char **partmaps;
+#endif
};
struct grub_diskfilter_lv {
@@ -186,6 +189,8 @@
struct grub_diskfilter_pv *
grub_diskfilter_get_pv_from_disk (grub_disk_t disk,
struct grub_diskfilter_vg **vg);
+void
+grub_diskfilter_print_partmap (grub_disk_t disk);
#endif
#endif /* ! GRUB_RAID_H */
=== modified file 'util/getroot.c'
--- util/getroot.c 2012-02-10 12:17:12 +
+++ util/getroot.c 2012-02-10 18:48:24 +
@@ -372,7 +372,7 @@
char *buf = NULL;
size_t len = 0;
char **ret = NULL;
- int entry_len = 0, entry_max = 4;
+ grub_size_t entry_len = 0, entry_max = 4;
struct mountinfo_entry *entries;
struct mountinfo_entry parent_entry = { 0, 0, 0, , , , };
int i;
@@ -1991,7
Re: Various build failures in current bzr tree
On 10.02.2012 21:25, Lennart Sorensen wrote:
On Fri, Feb 10, 2012 at 08:25:32PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
On 10.02.2012 20:14, Lennart Sorensen wrote:
On Fri, Feb 10, 2012 at 02:08:52PM -0500, Lennart Sorensen wrote:
On Fri, Feb 10, 2012 at 07:58:25PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
On 10.02.2012 19:15, Lennart Sorensen wrote:
Where should grub_arch_dl_get_tramp_got_size come from? The linker
whines about it.
It's in grub-core/kern/powerpc/dl.c
I have no trouble to cross-compile ppc port on my amd64 machine.
I will get the exact error again once I get the new code to stop whining
so much. :)
Or I can put the defined(__powerpc__) back in the older code and try
that again.
OK I did that:
Oh, it's powerpc-emu. That changes everything.
Well I am using the debian package rules which build both emu and
ieee1275.
I am not using emu, but I am building it. Building doesn't take long
on a p710 after all.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'grub-core/kern/emu/full.c'
--- grub-core/kern/emu/full.c 2012-02-09 22:15:27 +
+++ grub-core/kern/emu/full.c 2012-02-10 20:37:43 +
@@ -50,7 +50,7 @@
grub_no_autoload = 1;
}
-#ifdef __ia64__
+#if defined (__ia64__) || defined (__powerpc__)
void grub_arch_dl_get_tramp_got_size (const void *ehdr __attribute__ ((unused)),
grub_size_t *tramp, grub_size_t *got)
{
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
gettext in scripts
Hello, all. It was requested to have a way to gettextize Super GRUB
disk. Original request was to extend gettext with -s options but it may
result in a mess to temporary variables. So I'd propose to rather use
$... syntax with the exception that we don't expand it after
translation to avoid some pitfalls. Sharing syntax with bash will allow
to use normal xgettext --language=Shell.
The real problem is as to how to include SGD strings in grub.pot. I see
following solutions:
1) Merge projects and put SGD inside GRUB2. It's possible if its authors
want it but many more questions would need to be discussed.
2) Import sgd.pot into grub.pot regularly. This creates an
administrative overhead and requires GRUB and scripts to have matching
versions. I don't know if it's easy to merge .pot files
3) Just have a few strings for usage by external projects. This would
heavily limit the extent of internationalisation and would result in a
lot of feature requests one after another for this or that string.
4) Have some way to load .mo from another directory. Perhaps something
like locale_dirs=$dir1:$dir2:$dir3. This creates some problems as to how
and when to load files and how to store them. The easiest way consisting
of having multiple opened gettext files and try each of it in turn.
Trouble is that then when adding a single directory we need to either
reload all files or compare the previous list with current to reload
only changed directories.
Any other ideas?
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'grub-core/script/execute.c'
--- grub-core/script/execute.c 2012-02-04 11:21:21 +
+++ grub-core/script/execute.c 2012-02-10 22:24:15 +
@@ -26,6 +26,7 @@
#include grub/lib/arg.h
#include grub/normal.h
#include grub/extcmd.h
+#include grub/i18n.h
/* Max digits for a char is 3 (0xFF is 255), similarly for an int it
is sizeof (int) * 3, and one extra for a possible -ve sign. */
@@ -312,8 +313,8 @@
struct grub_script_arg *arg = 0;
struct grub_script_argv result = { 0, 0, 0 };
- auto int append (char *s, int escape_type);
- int append (char *s, int escape_type)
+ auto int append (const char *s, int escape_type);
+ int append (const char *s, int escape_type)
{
int r;
char *p = 0;
@@ -379,12 +380,20 @@
break;
case GRUB_SCRIPT_ARG_TYPE_TEXT:
- if (grub_strlen (arg-str)
+ if (arg-str[0]
grub_script_argv_append (result, arg-str,
grub_strlen (arg-str)))
goto fail;
break;
+ case GRUB_SCRIPT_ARG_TYPE_GETTEXT:
+ {
+ const char *t = _(arg-str);
+ if (grub_script_argv_append (result, t, grub_strlen (t)))
+ goto fail;
+ }
+ break;
+
case GRUB_SCRIPT_ARG_TYPE_DQSTR:
case GRUB_SCRIPT_ARG_TYPE_SQSTR:
if (append (arg-str, 1))
=== modified file 'grub-core/script/yylex.l'
--- grub-core/script/yylex.l 2012-02-03 10:56:49 +
+++ grub-core/script/yylex.l 2012-02-10 22:20:27 +
@@ -131,15 +131,17 @@
SQCHR [^\']
DQCHR {ESC}|[^\\\]
DQSTR \{DQCHR}*\
+I18NSTR \$\{DQCHR}*\
SQSTR \'{SQCHR}*\'
SPECIAL \?|\#|\*|\@
VARIABLE${NAME}|$\{{NAME}\}|${DIGITS}|$\{{DIGITS}\}|${SPECIAL}|$\{{SPECIAL}\}
-WORD({CHAR}|{DQSTR}|{SQSTR}|{ESC}|{VARIABLE})+
+WORD({CHAR}|{DQSTR}|{SQSTR}|{ESC}|{VARIABLE}|{I18NSTR})+
MULTILINE {WORD}?((\{DQCHR}*)|(\'{SQCHR}*)|(\\\n))
%x SPLIT
%x DQUOTE
+%x I18NQUOTE
%x SQUOTE
%x VAR
@@ -215,6 +217,10 @@
yy_push_state (SQUOTE, yyscanner);
ARG (GRUB_SCRIPT_ARG_TYPE_TEXT);
}
+ \$\{
+ yy_push_state (I18NQUOTE, yyscanner);
+ ARG (GRUB_SCRIPT_ARG_TYPE_GETTEXT);
+}
\${
yy_push_state (VAR, yyscanner);
ARG (GRUB_SCRIPT_ARG_TYPE_TEXT);
@@ -280,6 +286,18 @@
(.|\n){ COPY (yytext, yyleng); }
}
+I18NQUOTE{
+ { COPY (\\, 1); }
+ \\\ { COPY (\, 1); }
+ \\\n { /* ignore */ }
+ [^n]+{ COPY (yytext, yyleng); }
+ \{
+ yy_pop_state (yyscanner);
+ ARG (GRUB_SCRIPT_ARG_TYPE_GETTEXT);
+}
+ (.|\n){ COPY (yytext, yyleng); }
+}
+
EOF {
yypop_buffer_state (yyscanner);
yyextra-lexerstate-eof = 1;
=== modified file 'include/grub/script_sh.h'
--- include/grub/script_sh.h 2011-11-11 19:34:37 +
+++ include/grub/script_sh.h 2012-02-10 20:30:33 +
@@ -53,6 +53,7 @@
{
GRUB_SCRIPT_ARG_TYPE_VAR,
GRUB_SCRIPT_ARG_TYPE_TEXT,
+ GRUB_SCRIPT_ARG_TYPE_GETTEXT,
GRUB_SCRIPT_ARG_TYPE_DQVAR,
GRUB_SCRIPT_ARG_TYPE_DQSTR,
GRUB_SCRIPT_ARG_TYPE_SQSTR,
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo
Re: Various build failures in current bzr tree
On 11.02.2012 00:14, Lennart Sorensen wrote:
On Fri, Feb 10, 2012 at 03:43:01PM -0500, Lennart Sorensen wrote:
On Fri, Feb 10, 2012 at 09:38:25PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
On 10.02.2012 21:25, Lennart Sorensen wrote:
On Fri, Feb 10, 2012 at 08:25:32PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
On 10.02.2012 20:14, Lennart Sorensen wrote:
On Fri, Feb 10, 2012 at 02:08:52PM -0500, Lennart Sorensen wrote:
On Fri, Feb 10, 2012 at 07:58:25PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
On 10.02.2012 19:15, Lennart Sorensen wrote:
Where should grub_arch_dl_get_tramp_got_size come from? The linker
whines about it.
It's in grub-core/kern/powerpc/dl.c
I have no trouble to cross-compile ppc port on my amd64 machine.
I will get the exact error again once I get the new code to stop whining
so much. :)
Or I can put the defined(__powerpc__) back in the older code and try
that again.
OK I did that:
Oh, it's powerpc-emu. That changes everything.
Well I am using the debian package rules which build both emu and
ieee1275.
I am not using emu, but I am building it. Building doesn't take long
on a p710 after all.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'grub-core/kern/emu/full.c'
--- grub-core/kern/emu/full.c 2012-02-09 22:15:27 +
+++ grub-core/kern/emu/full.c 2012-02-10 20:37:43 +
@@ -50,7 +50,7 @@
grub_no_autoload = 1;
}
-#ifdef __ia64__
+#if defined (__ia64__) || defined (__powerpc__)
void grub_arch_dl_get_tramp_got_size (const void *ehdr __attribute__
((unused)),
grub_size_t *tramp, grub_size_t *got)
{
That appears to fix the linker error on powerpc-emu builds. Yay!
OK I did a build with --disable-werror and captured the output using
gcc 4.5 rather than 4.4 this time, just to see if it made any difference.
It failed though with:
cat kernel_syms.lst syminfo.lst.new
for m in trig.module
regexp.module blocklist.module
boot.modulecat.module cmp.module
configfile.module date.module echo.module
extcmd.module gptsync.module halt.module
reboot.module hashsum.module
help.module hexdump.module keystatus.module
loadenv.module ls.module lsmmap.module
memrw.module minicmd.module
parttool.module password.module
password_pbkdf2.module probe.module
read.module search.module search_fs_file.module
search_fs_uuid.module search_label.module
sleep.moduleterminal.module test.module
true.module videoinfo.module
videotest.module xnu_uuid.module dm_nv.module
loopback.module cryptodisk.module luks.module
geli.module lvm.module ldm.module
mdraid09.module mdraid1x.module diskfilter.module
raid5rec.module raid6rec.module
scsi.module memdisk.module
font.moduleaffs.module afs.module
bfs.module btrfs.module cpio.module
cpio_be.module newc.module odc.module
ext2.module fat.module exfat.module
fshelp.module hfs.module hfsplus.module
iso9660.module jfs.module minix.module
minix2.module minix3.module nilfs2.module
ntfs.module ntfscomp.module reiserfs.module
romfs.module sfs.module squash4.module
tar.module udf.module ufs1.module
ufs2.module xfs.module zfs.module
zfscrypt.module zfsinfo.module gettext.module
gfxmenu.module hello.module gzio.module
bufio.moduleelf.module crypto.module
pbkdf2.module setjmp.module
normal.module part_acorn.module part_amiga.module
part_apple.module
Re: Bug#659460: grub-pc: grub-install can't install on raid0 device (grub-probe can't find /boot)
On 11.02.2012 12:02, John Hughes wrote: On 11/02/12 11:29, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 11.02.2012 11:14, John Hughes wrote: Package: grub-pc Version: 1.99-14 Severity: important Tags: d-i /usr/sbin/grub-probe: error: no such disk /dev/md126p5 This looks like fakeraid rather than a honest software raid. You need to manually add it to device.map. The difference is rather blurred now that it's mdadm that's handling it rather than the old dm-raid. This is exactly the problem. GRUB can't distinguish between the both. Do you know an ioctl, or at very least a command to distinguish them? Also honest raid doesn't try to scam you into believing that it's a hardware raid. I'll try adding it to the map by hand. Which seems to work. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#659460: grub-pc: grub-install can't install on raid0 device (grub-probe can't find /boot)
On 11.02.2012 12:36, John Hughes wrote: On 11/02/12 12:19, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 11.02.2012 12:02, John Hughes wrote: The difference is rather blurred now that it's mdadm that's handling it rather than the old dm-raid. This is exactly the problem. GRUB can't distinguish between the both. Do you know an ioctl, or at very least a command to distinguish them? Also honest raid doesn't try to scam you into believing that it's a hardware raid. What scam? As far as I can tell it's just a mdadm raid with an intel container format rather than a mdadm container format. Adding BIOS driver for this screws things up. And the scam is adding this to mobo features as a RAID and an attempt to make this pass as if it was a hardware RAID. GRUB currently considers mdX as a non-available through BIOS unless user overrides it in device.map, we need to add a logic to handle the fakeraid as a BIOS disk. It's possible to add support for intel RAID but it will be useless since the member disks aren't available through BIOS to begin with. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Various build failures in current bzr tree
On 12.02.2012 01:02, Lennart Sorensen wrote:
On Sat, Feb 11, 2012 at 12:38:41AM +0100, Vladimir 'φ-coder/phcoder'
Serbinenko wrote:
=== modified file 'configure.ac'
--- configure.ac 2012-02-10 15:48:48 +
+++ configure.ac 2012-02-10 23:28:12 +
@@ -373,9 +373,9 @@
LIBS=
# debug flags.
-WARN_FLAGS=-Wall -W -Wshadow -Wold-style-declaration
-Wold-style-definition -Wpointer-arith -Wmissing-prototypes -Wundef -Wextra
-Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align
-Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated
-Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body
-Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args
-Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Winit-self -Winline
-Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op
-Wmain -Wmissing-braces -Wmissing-field-initializers
-Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar
-Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith
-Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare
-Wstack-protector -Wstrict-aliasing -Wstrict-overflow -Wswitch -Wsync-nand
-Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas
-Wunreachable-code -Wunused -Wunused-function -Wunused-label
-Wunused-parameter -Wunused-result -Wunused-value -Wunused-variable
-Wvariadic-macros -Wvolatile-register-var -Wwrite-strings
-Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes
-Wnested-externs -Wstrict-prototypes -Wpointer-sign
+WARN_FLAGS=-Wall -W -Wshadow -Wold-style-declaration
-Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress
-Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align
-Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated
-Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body
-Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args
-Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Winit-self
-Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op
-Wmain -Wmissing-braces -Wmissing-field-initializers
-Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar
-Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith
-Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare
-Wstack-protector -Wstrict-aliasing -Wswitch -Wsync-nand -Wtrigraphs
-Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunreachable-code
-Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-result
-Wunused-value -Wunused-variable -Wvariadic-macros -Wvolatile-register-var
-Wwrite-strings -Wmissing-declarations -Wmissing-parameter-type
-Wmissing-prototypes -Wnested-externs -Wstrict-prototypes -Wpointer-sign
HOST_CFLAGS=$HOST_CFLAGS $WARN_FLAGS
-TARGET_CFLAGS=$TARGET_CFLAGS $WARN_FLAGS -g -Wredundant-decls
+TARGET_CFLAGS=$TARGET_CFLAGS $WARN_FLAGS -g -Wredundant-decls
-Wmissing-prototypes
TARGET_CCASFLAGS=$TARGET_CCASFLAGS -g
# Force no alignment to save space on i386.
=== modified file 'docs/grub.texi'
--- docs/grub.texi 2012-01-31 21:59:32 +
+++ docs/grub.texi 2012-02-10 17:11:59 +
@@ -20,7 +20,7 @@
This manual is for GNU GRUB (version @value{VERSION},
@value{UPDATED}).
-Copyright @copyright{} 1999,2000,2001,2002,2004,2006,2008,2009,2010 Free
Software Foundation, Inc.
+Copyright @copyright{}
1999,2000,2001,2002,2004,2006,2008,2009,2010,2011,2012 Free Software
Foundation, Inc.
@quotation
Permission is granted to copy, distribute and/or modify this document
=== modified file 'gentpl.py'
--- gentpl.py2011-12-24 14:09:26 +
+++ gentpl.py2012-02-10 17:10:18 +
@@ -1,4 +1,19 @@
#! /usr/bin/python
+# GRUB -- GRand Unified Bootloader
+# Copyright (C) 2010,2011 Free Software Foundation, Inc.
+#
+# GRUB is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# GRUB is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GRUB. If not, see http://www.gnu.org/licenses/.
#
# This is the python script used to generate Makefile.tpl
=== modified file 'grub-core/disk/diskfilter.c'
--- grub-core/disk/diskfilter.c 2012-02-09 22:43:43 +
+++ grub-core
Re: grub-0.97 reboot
On 21.02.2012 10:21, pulkit wrote: Hi all, I want to add a small feature to the grub-0.97. GRUB Legacy isn't developped anymore. Please upgrade to GRUB2. my disk partition layout is 1)partition1-Main kernel(A) and rootfs image(A) 2)partition2-Recovery kernel(B) and rootfs(B). I have made two entry for these in menu.lst with default set to 0 i.e always execute the main kernel. I am checking sha1 of the kernel during boot time and in case of sha1 mismatch i want to boot with the second recovery kernel and do firmware recovery. My sha1 is working fine but i am not able to boot with the second kernel during sha1 mismatch. Earlier i thought to edit the configuration file(menu.lst) in case of sha1 mismatch and use grub_reboot. But no write support is there for ext in grub-0.97. So I am looking for another methods Regards Pulkit ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2: Keeping debug symbols in an image
On 21.02.2012 00:16, Adrian Burns wrote: Hi, i had sent this out to help-g...@gnu.org but perhaps its best sent to devel Im looking for GRUB2's grub-mkimage to produce an efi file for target execution along with a matching elf file that has all the debug symbols included so that i can use a debugger to step through the GRUB2 code. So far i see that strip is used in grub/grub-core/genmod.sh.in to strip debug sections from the *.o files as the build generates the *.mod file (i used readelf to verify this after commenting out the strip command below) Then in grub-mkimage.c, the generate_image() function appears to make no attempt to preserve symbols. Is there a way to tell the build system to leave modules and images with full symbol table and debugging information? We don't put any debug symbols to the result image. Use *.image and *.module. They are exact counterpart or *.img and *.mod other than being ELF even if *.img isn't and not having module identication sections. for the imagehas anyone modified grub-mkimage.c to retain debug symbols in generated image? thanks, Adrian -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-0.97 reboot
On 21.02.2012 11:40, pulkit wrote: I can upgrade to grub2 but this can be done with grub2? yes 2012/2/21 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com mailto:phco...@gmail.com On 21.02.2012 10 tel:21.02.2012%2010:21, pulkit wrote: Hi all, I want to add a small feature to the grub-0.97. GRUB Legacy isn't developped anymore. Please upgrade to GRUB2. my disk partition layout is 1)partition1-Main kernel(A) and rootfs image(A) 2)partition2-Recovery kernel(B) and rootfs(B). I have made two entry for these in menu.lst with default set to 0 i.e always execute the main kernel. I am checking sha1 of the kernel during boot time and in case of sha1 mismatch i want to boot with the second recovery kernel and do firmware recovery. My sha1 is working fine but i am not able to boot with the second kernel during sha1 mismatch. Earlier i thought to edit the configuration file(menu.lst) in case of sha1 mismatch and use grub_reboot. But no write support is there for ext in grub-0.97. So I am looking for another methods Regards Pulkit ___ Grub-devel mailing list Grub-devel@gnu.org mailto:Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Freeze on 27 February
Hello, it's to announce that from 27th of February the GRUB will be frozen for 2.00 release. From that date on, no new features will be committed only bugfixes. If you have a patch which you think should be included in 2.00 you can ping me about it but I might answer that it's postponed after 2.00 @Richard Laager: Which of ZFS patches aren't committed yet? It's a bit tricky to see which ones were superseeded. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Unclear gettextized strings
On 05.02.2012 19:45, Mario Blättermann wrote: Am 05.02.2012 19:23, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: We use the word key several times to refer to the key that you press but the same word also means a key in catalog and both Yuri and Mario understood messages like unknown key in the second sense. I've rephrased those somehow, now it should be clear. I've translated key in sense of an encryption key and not a keyboard key, which could be wrong in some (or almost all?) cases. Besides your recent source code changes, you should add some translator comments and send the updated pot file to the TP Robot. I both agree and disagree. I agree that some of the strings are too short. But I also think that in most cases one should make the string themselves clearer. Also please don't do manual line-breaking in .po since GRUB already handles it and takes the real screen width into account. I've submitted the new tgz. It contains also .po which is fixed a bit. I hope that TP robot will pick those de.po and uk.po -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Lists and aliasing (Re: Freeze on 27 February)
On 21.02.2012 17:19, Lennart Sorensen wrote:
On Tue, Feb 21, 2012 at 05:12:12PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
Hello, it's to announce that from 27th of February the GRUB will be
frozen for 2.00 release. From that date on, no new features will be
committed only bugfixes.
If you have a patch which you think should be included in 2.00 you
can ping me about it but I might answer that it's postponed after
2.00
@Richard Laager: Which of ZFS patches aren't committed yet? It's a
bit tricky to see which ones were superseeded.
Any chance all these warnings will get fixed so powerpc can compile
without using --disable-werror?
At this point I can't figure out what to do to convince gcc that aliasing
the list structure should be allowed. It looks like the way lists are
done in grub is simply a big hack that gcc doesn't like.
Try attached patch
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'grub-core/kern/list.c'
--- grub-core/kern/list.c 2012-02-12 02:52:17 +
+++ grub-core/kern/list.c 2012-02-12 02:52:48 +
@@ -32,3 +32,24 @@
return NULL;
}
+
+void
+grub_list_push (grub_list_t *head, grub_list_t item)
+{
+ item-prev = head;
+ if (*head)
+(*head)-prev = item-next;
+ item-next = *head;
+ *head = item;
+}
+
+void
+grub_list_remove (grub_list_t item)
+{
+ if (item-prev)
+*item-prev = item-next;
+ if (item-next)
+item-next-prev = item-prev;
+ item-next = 0;
+ item-prev = 0;
+}
=== modified file 'include/grub/list.h'
--- include/grub/list.h 2012-02-12 02:52:17 +
+++ include/grub/list.h 2012-02-12 02:53:20 +
@@ -31,26 +31,8 @@
};
typedef struct grub_list *grub_list_t;
-static inline void
-grub_list_push (grub_list_t *head, grub_list_t item)
-{
- item-prev = head;
- if (*head)
-(*head)-prev = item-next;
- item-next = *head;
- *head = item;
-}
-
-static inline void
-grub_list_remove (grub_list_t item)
-{
- if (item-prev)
-*item-prev = item-next;
- if (item-next)
-item-next-prev = item-prev;
- item-next = 0;
- item-prev = 0;
-}
+void EXPORT_FUNC(grub_list_push) (grub_list_t *head, grub_list_t item);
+void EXPORT_FUNC(grub_list_remove) (grub_list_t item);
#define FOR_LIST_ELEMENTS(var, list) for ((var) = (list); (var); (var) = (var)-next)
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fix for pkgdatadir grub-mkconfig_lib in all util scripts and grub.d scripts
On 21.02.2012 17:36, Keshav P R wrote: 2012/2/21 Grégoire Sutregregoire.su...@gmail.com: On 02/20/2012 06:47 PM, Keshav P R wrote: Hi, Attached patch fixes runtime error due to sed transform used in pkgdatadir Maybe we should apply the sed transform to grub-mkconfig_lib's installation directory, i.e., install grub-mkconfig_lib alongside unicode.pf2 and friends? That might make it difficult for third party scripts in /etc/grub.d (like os-prober or memtest) to source grub-mkconfig_lib since they do not know about the sed transform. This is not an argument. Ad absurdum you could say the same about any binary or script name , yet their names are transformed Grégoire # /_grub_/grub_uefi_x86_64/bin/grub_uefi_x86_64-mkstandalone -h /_grub_/grub_uefi_x86_64/bin/grub_uefi_x86_64-mkstandalone: line 46: /_grub_/grub_uefi_x86_64/share/grub_uefi_x86_64/grub-mkconfig_lib: No such file or directory File is at /_grub_/grub_uefi_x86_64/share/grub/grub-mkconfig_lib (in my case). Please apply this. Thanks in advance. Regards. Keshav ___ 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 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: disable-libzfs configure flag (Re: Freeze on 27 February)
On 21.02.2012 20:04, Mike Gilbert wrote: 2012/2/21 Vladimir 'φ-coder/phcoder' Serbinenkophco...@gmail.com: Hello, it's to announce that from 27th of February the GRUB will be frozen for 2.00 release. From that date on, no new features will be committed only bugfixes. If you have a patch which you think should be included in 2.00 you can ping me about it but I might answer that it's postponed after 2.00 It would be really great if you would reconsider the --disable-libzfs flag that was proposed a few weeks ago. It was on my todo list to comment on it. The main problem is that it's not in line with other configure options: it has to be enable/disable and show the result in the status message (see e.g. SDL support) -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Lists and aliasing (Re: Freeze on 27 February)
On 21.02.2012 20:58, Lennart Sorensen wrote:
On Tue, Feb 21, 2012 at 01:46:27PM -0500, Lennart Sorensen wrote:
That actually seems to have done it. I am still trying to wrap my head
around why that made a difference since it appears to be identical code
moved somewhere else. It isn't inlined anymore, but should that make
a big difference?
Only 509 warnings left (down from 5000 or so).
Using gcc 4.6 drops that to 199 warnings, so gcc 4.4 is a bit more whiny
than 4.6.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
diff --exclude Makefile.util.am --exclude Makefile.in --exclude grub.info --exclude configure --exclude aclocal.m4 --exclude '*autom4te.cache*' -ur mainline/configure.ac mainline-mod/configure.ac
--- mainline/configure.ac 2012-02-21 14:29:15.0 +0100
+++ mainline-mod/configure.ac 2012-02-21 20:18:57.327763779 +0100
@@ -377,7 +377,7 @@
LIBS=
# debug flags.
-WARN_FLAGS=-Wall -W -Wshadow -Wold-style-declaration -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body -Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar -Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstack-protector -Wstrict-aliasing -Wswitch -Wsync-nand -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunreachable-code -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-result -Wunused-value -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wstrict-prototypes -Wpointer-sign
+WARN_FLAGS=-Wall -W -Wshadow -Wold-style-declaration -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body -Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar -Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-aliasing -Wswitch -Wsync-nand -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-result -Wunused-value -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wstrict-prototypes -Wpointer-sign
HOST_CFLAGS=$HOST_CFLAGS $WARN_FLAGS
TARGET_CFLAGS=$TARGET_CFLAGS $WARN_FLAGS -g -Wredundant-decls -Wmissing-prototypes
TARGET_CCASFLAGS=$TARGET_CCASFLAGS -g
diff --exclude Makefile.util.am --exclude Makefile.in --exclude grub.info --exclude configure --exclude aclocal.m4 --exclude '*autom4te.cache*' -ur mainline/grub-core/commands/testload.c mainline-mod/grub-core/commands/testload.c
--- mainline/grub-core/commands/testload.c 2012-02-08 00:13:14.0 +0100
+++ mainline-mod/grub-core/commands/testload.c 2012-02-21 20:57:08.003762787 +0100
@@ -100,7 +100,10 @@
{
char sector[GRUB_DISK_SECTOR_SIZE];
- pos -= GRUB_DISK_SECTOR_SIZE;
+ if (pos = GRUB_DISK_SECTOR_SIZE)
+ pos -= GRUB_DISK_SECTOR_SIZE;
+ else
+ pos = 0;
grub_file_seek (file, pos);
diff --exclude Makefile.util.am --exclude Makefile.in --exclude grub.info --exclude configure --exclude aclocal.m4 --exclude '*autom4te.cache*' -ur mainline/grub-core/fs/affs.c mainline-mod/grub-core/fs/affs.c
--- mainline/grub-core/fs/affs.c 2012-01-29 18:28:10.0 +0100
+++ mainline-mod/grub-core/fs/affs.c 2012-02-21 21:05:56.271763053 +0100
@@ -143,7 +143,7 @@
mod = (grub_uint32_t) fileblock % data-htsize;
/* Find the block that points to the fileblock we are looking up by
following the chain until the right table is reached. */
- for (curblock = node-last_block_cache + 1; curblock = target; curblock++)
+ for (curblock = node-last_block_cache + 1; curblock target + 1
Re: grub-mkfont generate errors when converting truetype fonts
On 22.02.2012 03:17, Towheed Mohammed wrote: Whenever you grub-mkfont is used to convert truetype fonts to PFF2 fonts, it generates several errors. For example: grub-mkfont -v -s 12 -r 0x0-0x7F -o ~/Documents/dejavu-sans-12.pf2 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf gives the following error: It's not errors. Just warnings that the resulting pf2 will be of lesser quality than source TTF This is a long-standing issue with grub-mkfont that started somewhere in the later releases of 1.98. This never occurred in earlier releaes of 1.98. The earlier versions just ignored the features altogether. Newer report them but it's *warnings*, not errors. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-mkfont generate errors when converting truetype fonts
On 22.02.2012 04:36, Towheed Mohammed wrote: But as you can see from the verbose output, because of these warnings, it produces only 95 glyphs as opposed to the expected 128. The codepoint ranges 0-0x1f and 0x7f are controls and have no glyph. Do you have the comparison of glyphs in questions? What glitches do you see? As for the quality, it is much lower than the fonts produced by earlier versions. - Original Message - From: Vladimir 'φ-coder/phcoder' Serbinenkophco...@gmail.com To: grub-devel@gnu.org Cc: Sent: Tuesday, February 21, 2012 11:23 PM Subject: Re: grub-mkfont generate errors when converting truetype fonts On 22.02.2012 03:17, Towheed Mohammed wrote: Whenever you grub-mkfont is used to convert truetype fonts to PFF2 fonts, it generates several errors. For example: grub-mkfont -v -s 12 -r 0x0-0x7F -o ~/Documents/dejavu-sans-12.pf2 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf gives the following error: It's not errors. Just warnings that the resulting pf2 will be of lesser quality than source TTF This is a long-standing issue with grub-mkfont that started somewhere in the later releases of 1.98. This never occurred in earlier releaes of 1.98. The earlier versions just ignored the features altogether. Newer report them but it's *warnings*, not errors. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ 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 -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GNU GRUB pxe.mod missing with efi
Please keep the list CC'ed On 22.02.2012 11:11, Timothy Wang wrote: Dear Vladimir Serbinenko, There is a bug in the bzr. Suppose to be after ver 3940 in dl.c function grub_dl_resolove_sumbols the function still checks for the old name grub_checkkey. I don't see what you mean, this function doesn't check for anything Also, for the arp problem I asked before. in net.c function grub_net_poll_cards in FOR_NET_CARDS the loop requires if( card - num_ifaces == 0 ) continue; to skip card without interfaces. Why? We poll them to see if we get any packet useful in the future (e.g. DHCP or SLAAC broadcast)-- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GNU GRUB pxe.mod missing with efi
Keep the list CC'ed. On 22.02.2012 14:24, Timothy Wang wrote: grub_dl_resolove_symbols gives me a error: symbol 'grub_checkkey' not found This means that core and module version mismatches The arp problem is harder to explain. I have three network cards in my computer the ethernet I am using is the second one. Grub keep listening on the first network card so the arp response can never be receive. I believe GRUB listens on all cards. If not it's a bug which isn't solved by skipping. Thank you Tim 2012/2/22 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com mailto:phco...@gmail.com Please keep the list CC'ed On 22.02.2012 11:11, Timothy Wang wrote: Dear Vladimir Serbinenko, There is a bug in the bzr. Suppose to be after ver 3940 in dl.c function grub_dl_resolove_sumbols the function still checks for the old name grub_checkkey. I don't see what you mean, this function doesn't check for anything Also, for the arp problem I asked before. in net.c function grub_net_poll_cards in FOR_NET_CARDS the loop requires if( card - num_ifaces == 0 ) continue; to skip card without interfaces. Why? We poll them to see if we get any packet useful in the future (e.g. DHCP or SLAAC broadcast)-- Regards Vladimir 'φ-coder/phcoder' Serbinenko -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How can write the menu grub on the right in arabic language?
On 19.04.2011 07:59, Elham Rastgoo wrote: When I write the menu grub in arabic language and move title to the right in grub.cfg , it just stays on the left :( Whereas I can move english title to the left or right !!! why?? Easy: you put the spaces before, so they are rendered to the *right* of the text, not to the left. Since there is still no translation of GRUB into ARabic there is no motivation to fix this. If someone translates GRUB into Arabic or Hebrew, I'll personally fix the layout, otherwise there is no reason to fix this. -- Best Regards E.R ___ 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 https://lists.gnu.org/mailman/listinfo/grub-devel
Re: cruft left over from make uninstall [was: failed to build bzr head on powerpc (ieee1275)]
Fixed On 22.02.2012 04:01, Daniel Kahn Gillmor wrote: On 02/21/2012 09:30 PM, Mike Gilbert wrote: I ran into that myself this weekend. Solution: regenerate POTFILES.in. find . -name '*.c' -print | sort po/POTFILES.in Thanks, that did indeed let the build complete. i completed building it as a non-privileged user, and then as the superuser, i did: make install make uninstall That appears to have left a few files in /usr/local that i think it shouldn't have. I think the uninstall target might have drifted a bit: 0 root@hollywood:/home/dkg/src/grub/grub# find /usr/local/ | grep grub /usr/local/lib/grub /usr/local/lib/grub/powerpc-ieee1275 /usr/local/etc/grub.d /usr/local/share/grub /usr/local/share/grub/widthspec.h /usr/local/share/grub/ascii.pf2 /usr/local/share/grub/unicode.pf2 /usr/local/share/grub/euro.pf2 /usr/local/share/grub/ascii.h 0 root@hollywood:/home/dkg/src/grub/grub# --dkg ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Lists and aliasing (Re: Freeze on 27 February)
So with this patch, gcc 4.4 is down to 201 warnings, and gcc 4.6 has 175. 102 of those warnings are about missing prototypes for argp_usage _option_is_short and _option_is_end in argp.h which leaves 99 warnings for gcc 4.4 and 73 for gcc 4.6. Hm we don't add -Wmissing-prototypes for utils -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Lists and aliasing (Re: Freeze on 27 February)
On 22.02.2012 17:25, Lennart Sorensen wrote: On Wed, Feb 22, 2012 at 11:18:54AM -0500, Lennart Sorensen wrote: Well it is in WARN_FLAGS and TARGET_CFLAGS in configure. And during build: gcc-4.4 -DHAVE_CONFIG_H -I. -I../.. -Wall -W -I./include -DGRUB_UTIL=1 -DGRUB_LIBDIR=\/usr/lib/grub\ -DLOCALEDIR=\/usr/share/locale\ -DGRUB_MACHINE_EMU=1 -DGRUB_MACHINE=POWERPC_EMU -DGRUB_TARGET_CPU_POWERPC=1 -DGRUB_FILE=\util/grub-mkimage.c\ -I. -I../.. -I. -I../.. -I../../include -I./include -I./grub-core/gnulib -I../../grub-core/gnulib -DGRUB_PKGLIBROOTDIR=\/usr/lib/grub\ -g -Wall -O2 -Wall -W -Wshadow -Wold-style-declaration -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body -Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op -Wmain -Wmissing-braces -W missing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar -Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-aliasing -Wswitch -Wsync-nand -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-result -Wunused-value -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wstrict-prototypes -Wpointer-sign -Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter -Wno-redundant-decls -Wno-unreachable-code -Wno-conversion -Wno-old-style-definition -c -o util/grub_mkimage-grub-mkimage.o `test -f 'util/grub-mkimage.c' || echo '../../'`util/grub-mkimage.c In file included from ../../util/grub-mkimage.c:45: ../../grub-core/gnulib/argp.h:610: warning: no previous prototype for 'argp_usage' ../../grub-core/gnulib/argp.h:616: warning: no previous prototype for '_option_is_short' ../../grub-core/gnulib/argp.h:628: warning: no previous prototype for '_option_is_end' So something sure adds it. That actually looks like a mistake. HOST_CFLAGS=$HOST_CFLAGS $WARN_FLAGS TARGET_CFLAGS=$TARGET_CFLAGS $WARN_FLAGS -g -Wredundant-decls -Wmissing-prototypes but WARN_FLAGS=-Wall -W -Wshadow -Wold-style-declaration -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body -Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar -Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-aliasing -Wswitch -Wsync-nand -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-result -Wunused-value -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wstrict-prototypes -Wpointer-sign So by having -Wmissing-prototypes in WARN_FLAGS it gets set twice in TARGET_CFLAGS and also set once in HOST_CFLAGS. Perhaps that was not meant to be in there and should only have been in TARGET_CFLAGS. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko === modified file 'conf/Makefile.common' --- conf/Makefile.common 2012-02-22 15:27:39 + +++ conf/Makefile.common 2012-02-22 16:29:31 + @@ -104,7 +104,7 @@ CFLAGS_GCRY = -Wno-error -Wno-missing-field-initializers CPPFLAGS_GCRY = -I$(top_srcdir)/grub-core/lib/libgcrypt_wrap -CFLAGS_GNULIB = -Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter -Wno-redundant-decls -Wno-unreachable-code -Wno-conversion -Wno-old-style-definition +CFLAGS_GNULIB = -Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter -Wno-redundant-decls -Wno-unreachable-code -Wno-conversion -Wno-old-style-definition -Wno-unsafe-loop-optimisations CPPFLAGS_GNULIB = -I$(top_builddir)/grub-core/gnulib -I$(top_srcdir)/grub-core/gnulib CFLAGS_POSIX = -fno-builtin === modified file 'configure.ac
Re: Lists and aliasing (Re: Freeze on 27 February)
I don't think -Wno-unsafe-loop-optimisations is valid. One has to
remove -Wunsafe-loop-optimisations instead, which is currently in
WARN_FLAGS.
It's just a question of spelling.
Also note that warnings from gnulib and minilzo are -Wno-error
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'conf/Makefile.common'
--- conf/Makefile.common 2012-02-22 15:27:39 +
+++ conf/Makefile.common 2012-02-22 17:26:03 +
@@ -104,7 +104,7 @@
CFLAGS_GCRY = -Wno-error -Wno-missing-field-initializers
CPPFLAGS_GCRY = -I$(top_srcdir)/grub-core/lib/libgcrypt_wrap
-CFLAGS_GNULIB = -Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter -Wno-redundant-decls -Wno-unreachable-code -Wno-conversion -Wno-old-style-definition
+CFLAGS_GNULIB = -Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter -Wno-redundant-decls -Wno-unreachable-code -Wno-conversion -Wno-old-style-definition -Wno-unsafe-loop-optimizations
CPPFLAGS_GNULIB = -I$(top_builddir)/grub-core/gnulib -I$(top_srcdir)/grub-core/gnulib
CFLAGS_POSIX = -fno-builtin
=== modified file 'configure.ac'
--- configure.ac 2012-02-22 03:56:45 +
+++ configure.ac 2012-02-22 16:51:06 +
@@ -377,9 +377,9 @@
LIBS=
# debug flags.
-WARN_FLAGS=-Wall -W -Wshadow -Wold-style-declaration -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body -Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar -Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-aliasing -Wswitch -Wsync-nand -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wstrict-prototypes -Wpointer-sign
+WARN_FLAGS=-Wall -W -Wshadow -Wold-style-declaration -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body -Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar -Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-aliasing -Wswitch -Wsync-nand -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wmissing-parameter-type -Wnested-externs -Wstrict-prototypes -Wpointer-sign
HOST_CFLAGS=$HOST_CFLAGS $WARN_FLAGS
-TARGET_CFLAGS=$TARGET_CFLAGS $WARN_FLAGS -g -Wredundant-decls -Wmissing-prototypes
+TARGET_CFLAGS=$TARGET_CFLAGS $WARN_FLAGS -g -Wredundant-decls -Wmissing-prototypes -Wmissing-declarations
TARGET_CCASFLAGS=$TARGET_CCASFLAGS -g
# Force no alignment to save space on i386.
=== modified file 'grub-core/commands/legacycfg.c'
--- grub-core/commands/legacycfg.c 2012-02-12 14:25:25 +
+++ grub-core/commands/legacycfg.c 2012-02-22 17:34:01 +
@@ -543,15 +543,17 @@
grub_uint8_t hash[MD5_HASHLEN];
};
+#pragma GCC diagnostic ignored -Wunsafe-loop-optimizations
+
static int
check_password_md5_real (const char *entered,
struct legacy_md5_password *pw)
{
- int enteredlen = grub_strlen (entered);
+ grub_size_t enteredlen = grub_strlen (entered);
unsigned char alt_result[MD5_HASHLEN];
unsigned char *digest;
grub_uint8_t ctx[GRUB_MD_MD5-contextsize];
- int i;
+ grub_size_t i;
GRUB_MD_MD5-init (ctx);
GRUB_MD_MD5-write (ctx, entered, enteredlen);
@@ -600,6 +602,8 @@
return (grub_crypto_memcmp (digest, pw-hash, MD5_HASHLEN) == 0);
}
+#pragma GCC diagnostic error -Wunsafe-loop-optimizations
+
static grub_err_t
check_password_md5 (const char *user,
const char *entered,
=== modified file 'grub
Re: Lists and aliasing (Re: Freeze on 27 February)
On 22.02.2012 19:41, Lennart Sorensen wrote: On Wed, Feb 22, 2012 at 01:28:06PM -0500, Lennart Sorensen wrote: Oh the feature for doing multiple #pragma statements throughout the code is new in gcc 4.6. It can't be done in earlier versions. In older versions whatever you say last applies to the whole file. Perhaps a slightly ugly solution could solve it by having a #if that checks that gcc is 4.6 or higher around the #pragma that reenables the warning. ie: #if __GNUC__ 4 || (__GNUC__ == 4 __GNUC_MINOR__= 6) #pragma GCC diagnostic error -Wunsafe-loop-optimizations #endif At least this way you get to have the warning for most of the code on newer gcc versions, but don't break older gcc versions that are still in common use. Well it compiles when I do that at least with gcc 4.4, although obviously it does mean -Wunsafe-loop-optimizations is disabled entirely for those 4 files rather than just for the one function that causes a problem. Alternative is to add a condition which will ensure the loop termination but don't interfere with it other wise by using the fact that min (UINT_MAX, r)=r if r is unsigned int. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko === modified file 'conf/Makefile.common' --- conf/Makefile.common 2012-02-22 15:27:39 + +++ conf/Makefile.common 2012-02-22 17:26:03 + @@ -104,7 +104,7 @@ CFLAGS_GCRY = -Wno-error -Wno-missing-field-initializers CPPFLAGS_GCRY = -I$(top_srcdir)/grub-core/lib/libgcrypt_wrap -CFLAGS_GNULIB = -Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter -Wno-redundant-decls -Wno-unreachable-code -Wno-conversion -Wno-old-style-definition +CFLAGS_GNULIB = -Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter -Wno-redundant-decls -Wno-unreachable-code -Wno-conversion -Wno-old-style-definition -Wno-unsafe-loop-optimizations CPPFLAGS_GNULIB = -I$(top_builddir)/grub-core/gnulib -I$(top_srcdir)/grub-core/gnulib CFLAGS_POSIX = -fno-builtin === modified file 'configure.ac' --- configure.ac 2012-02-22 03:56:45 + +++ configure.ac 2012-02-22 16:51:06 + @@ -377,9 +377,9 @@ LIBS= # debug flags. -WARN_FLAGS=-Wall -W -Wshadow -Wold-style-declaration -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body -Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar -Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-aliasing -Wswitch -Wsync-nand -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wstrict-prototypes -Wpointer-sign +WARN_FLAGS=-Wall -W -Wshadow -Wold-style-declaration -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body -Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar -Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-aliasing -Wswitch -Wsync-nand -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wmissing-parameter-type -Wnested-externs -Wstrict-prototypes -Wpointer-sign HOST_CFLAGS=$HOST_CFLAGS $WARN_FLAGS -TARGET_CFLAGS=$TARGET_CFLAGS $WARN_FLAGS -g -Wredundant-decls -Wmissing-prototypes +TARGET_CFLAGS=$TARGET_CFLAGS $WARN_FLAGS -g -Wredundant-decls -Wmissing-prototypes -Wmissing-declarations TARGET_CCASFLAGS=$TARGET_CCASFLAGS -g # Force no alignment to save space on i386. === modified file 'grub-core/commands/legacycfg.c' --- grub-core/commands
Re: The submenu command shows a text-based menu when using a GFX theme.
On 23.02.2012 02:50, Towheed Mohammed wrote:
If a gfx theme is being used and the submenu command is used to show a submenu,
the submenu does not use the gfx theme. Instead a text-based menu is shown.
The only way a regular user can workaround this at the moment is to reload the
theme after the submenu menuentry item is selected.
In Ubuntu's (about the only distro that uses the submenu command at this time)
use of the submenu in 10_linux:
if [ $list ] ! $in_submenu; then
in_submenu=:
fi
A regular user must patch 10_linux thus:
if [ $list ] ! $in_submenu; then
echo submenu \Previous Linux versions\ --class submenu {
if [ x$GRUB_THEME != x ] [ -f $GRUB_THEME ] \
is_path_readable_by_grub $GRUB_THEME; then
prepare_grub_to_access_device `${grub_probe} --target=device
$GRUB_THEME`
cat EOF
set theme=(\$root)`make_system_path_relative_to_its_root $GRUB_THEME`
EOF
fi
in_submenu=:
fi
What a perfect example of overengineering just to compensate for missing
export theme. I've fixed it in trunk
to reload the theme and have a themed submenu.
Will this be fixed in the 2.00 release?
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub RAID heuristics (how can we avoid superfluous RAID member (2 found))
On 02.02.2012 01:55, Daniel Kahn Gillmor wrote:
hi folks--
i was speaking with phcoder today on #grub, about getting messages like
this from grub when a partition that is part of a Linux SW RAID set
(with metadata 0.9x) is close to the end of its containing block device:
superfluous RAID member (2 found)
Try attached patch
Here's phcoder's explanation of the problem:
16:08 phcoder if you have 64KiB between end of disk and end of partition
the metadata is exactly in the same place for either if the
whole disks are raided or only partitions. And no field which
allows to distinguish those
[...]
16:09 phcoder thing is that mdraid format rounds it down to a 64K aligned
boundary
16:10 dkg0 64KiB aligned to the parent disk, or to the partition itself?
16:10 phcoder to whatever the host of the raid is. For your error to occur
it has to be both
16:10 dkg0 hm, i suppose if the partition itself starts evenly aligned with
a 64KiB boundary, it'd be the same thing.
It sounds like there might be some circumstances (e.g. a RAID0 set of
sda and sdb, creating md0, and a partition table on top of md0) where it
is legitimately difficult to decide the correct interpretation.
However, i think there might be a reasonable heuristic that can be used
in the case of RAID1 sets that would avoid the ambiguity (and the scary
messages/warnings to the user:
Select the smallest known block device that can completely enclose the
RAID member. The larger block device(s) should not be considered to be
exporting that RAID.
these heuristics would mean that RAID1 sets with 0.9x metadata on any
sort of disklabel would only have their member components show up once
during a scan, rather than treating them as a duplicate.
phcoder mentioned that the RAID code was undergoing something of an
overhaul. perhaps these heuristics could play into that update?
I'm not sure how to address it with RAID0 or RAID10, but if we could fix
the RAID1 case, that would be a big win for a lot of users.
Regards,
--dkg
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'grub-core/disk/diskfilter.c'
--- grub-core/disk/diskfilter.c 2012-02-12 14:25:25 +
+++ grub-core/disk/diskfilter.c 2012-02-23 05:42:14 +
@@ -972,35 +972,40 @@
: (pv-id.id == id-id))
{
struct grub_diskfilter_lv *lv;
+ grub_disk_t disk;
/* FIXME: Check whether the update time of the superblocks are
the same. */
+ disk = grub_disk_open (disk-name);
+ if (!disk)
+ return grub_errno;
+ if (disk pv-disk grub_disk_get_size (disk) = pv-part_size)
+ {
+ grub_disk_close (disk);
+ return GRUB_ERR_NONE;
+ }
+ pv-disk = disk;
/* This could happen to LVM on RAID, pv-disk points to the
raid device, we shouldn't change it. */
- if (! pv-disk)
- {
- pv-disk = grub_disk_open (disk-name);
- if (! pv-disk)
- return grub_errno;
- pv-part_start = grub_partition_get_start (disk-partition);
- pv-part_size = grub_disk_get_size (disk);
+ pv-start_sector -= pv-part_start;
+ pv-part_start = grub_partition_get_start (disk-partition);
+ pv-part_size = grub_disk_get_size (disk);
#ifdef GRUB_UTIL
- {
- grub_size_t s = 1;
- grub_partition_t p;
- for (p = disk-partition; p; p = p-parent)
- s++;
- pv-partmaps = xmalloc (s * sizeof (pv-partmaps[0]));
- s = 0;
- for (p = disk-partition; p; p = p-parent)
- pv-partmaps[s++] = xstrdup (p-partmap-name);
- pv-partmaps[s++] = 0;
- }
+ {
+ grub_size_t s = 1;
+ grub_partition_t p;
+ for (p = disk-partition; p; p = p-parent)
+ s++;
+ pv-partmaps = xmalloc (s * sizeof (pv-partmaps[0]));
+ s = 0;
+ for (p = disk-partition; p; p = p-parent)
+ pv-partmaps[s++] = xstrdup (p-partmap-name);
+ pv-partmaps[s++] = 0;
+ }
#endif
- if (start_sector != (grub_uint64_t)-1)
- pv-start_sector = start_sector;
- pv-start_sector += pv-part_start;
- }
+ if (start_sector != (grub_uint64_t)-1)
+ pv-start_sector = start_sector;
+ pv-start_sector += pv-part_start;
/* Add the device to the array. */
for (lv = array-lvs; lv; lv = lv-next)
if (!lv-became_readable_at lv-fullname is_lv_readable (lv))
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub legacy to grub2 upgrade path
On 23.02.2012 05:14, r...@frugalware.org wrote: I am a senior developer for the Frugalware Linux distribution, and I am trying to find an upgrade path so we can leave grub legacy behind. Normal disk installations work perfectly under testing, however I have found a snag with RAID installations we have to support that were setup under grub legacy, which we installed under metadata 0.90 because of the limitations of grub legacy. The problem appears to be this bug: http://savannah.gnu.org/bugs/?34250 See parallel thread for heuristics. However note that this setup is fundamentally broken It effects RAID setups that only use a single partition per disk, and in my tests I got errors from grub-install of this kind: http://frugalware.org/paste/13418 The problem seems to be that grub2 is unable to deduce *where* the RAID really is. I tried installing to the MBR of both disks and RAID device, using a simple grub-install command. (grub-install /dev/md0, etc.) I did my testing with a mostly vanilla 1.99 grub2. If any of our users happen to run into this issue, what are we to tell them to do? I'd like another option than forcing them to have to redo their RAID setup. Any insights would be appreciated. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Lists and aliasing (Re: Freeze on 27 February)
../../../grub-core/normal/charset.c: In function
'grub_bidi_line_logical_to_visual':
../../../grub-core/normal/charset.c:737: error: cannot optimize possibly
infinite
loops If I do what is already done for GRUB_LONG_MIN and use: #define
GRUB_INT_MIN (-0x7fff - 1) ...then gcc 4.6 is happy. gcc 4.4 goes on
complaining
about the inability to optimize possibly infinite loops.
in charset.c we actually want to ensure that it doesn't go negative. In
grub-mkfont.c it's ok to disable warning altogether. Here is the patch
(+grub-install fix)
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'conf/Makefile.common'
--- conf/Makefile.common 2012-02-22 15:27:39 +
+++ conf/Makefile.common 2012-02-22 17:26:03 +
@@ -104,7 +104,7 @@
CFLAGS_GCRY = -Wno-error -Wno-missing-field-initializers
CPPFLAGS_GCRY = -I$(top_srcdir)/grub-core/lib/libgcrypt_wrap
-CFLAGS_GNULIB = -Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter -Wno-redundant-decls -Wno-unreachable-code -Wno-conversion -Wno-old-style-definition
+CFLAGS_GNULIB = -Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter -Wno-redundant-decls -Wno-unreachable-code -Wno-conversion -Wno-old-style-definition -Wno-unsafe-loop-optimizations
CPPFLAGS_GNULIB = -I$(top_builddir)/grub-core/gnulib -I$(top_srcdir)/grub-core/gnulib
CFLAGS_POSIX = -fno-builtin
=== modified file 'configure.ac'
--- configure.ac 2012-02-22 03:56:45 +
+++ configure.ac 2012-02-22 16:51:06 +
@@ -377,9 +377,9 @@
LIBS=
# debug flags.
-WARN_FLAGS=-Wall -W -Wshadow -Wold-style-declaration -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body -Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar -Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-aliasing -Wswitch -Wsync-nand -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wstrict-prototypes -Wpointer-sign
+WARN_FLAGS=-Wall -W -Wshadow -Wold-style-declaration -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body -Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar -Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-aliasing -Wswitch -Wsync-nand -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wmissing-parameter-type -Wnested-externs -Wstrict-prototypes -Wpointer-sign
HOST_CFLAGS=$HOST_CFLAGS $WARN_FLAGS
-TARGET_CFLAGS=$TARGET_CFLAGS $WARN_FLAGS -g -Wredundant-decls -Wmissing-prototypes
+TARGET_CFLAGS=$TARGET_CFLAGS $WARN_FLAGS -g -Wredundant-decls -Wmissing-prototypes -Wmissing-declarations
TARGET_CCASFLAGS=$TARGET_CCASFLAGS -g
# Force no alignment to save space on i386.
=== modified file 'grub-core/commands/legacycfg.c'
--- grub-core/commands/legacycfg.c 2012-02-12 14:25:25 +
+++ grub-core/commands/legacycfg.c 2012-02-22 18:58:57 +
@@ -543,15 +543,17 @@
grub_uint8_t hash[MD5_HASHLEN];
};
+#pragma GCC diagnostic ignored -Wunsafe-loop-optimizations
+
static int
check_password_md5_real (const char *entered,
struct legacy_md5_password *pw)
{
- int enteredlen = grub_strlen (entered);
+ grub_size_t enteredlen = grub_strlen (entered);
unsigned char alt_result[MD5_HASHLEN];
unsigned char *digest;
grub_uint8_t ctx[GRUB_MD_MD5-contextsize];
- int i;
+ grub_size_t i;
GRUB_MD_MD5-init (ctx
Re: Freeze on 27 February
On 22.02.2012 06:35, Richard Laager wrote: On Tue, 2012-02-21 at 17:12 +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: @Richard Laager: Which of ZFS patches aren't committed yet? It's a bit tricky to see which ones were superseeded. I've attached my current patch set. The patches apply in the order listed. They're also roughly ordered by complexity, so I'd recommend reviewing them in this order. Also, if you have libzfs, a --disable-zfs or --without-zfs or similar patch is necessary to ensure that the zpool and zfs commands are used instead of libzfs. Not ZFS Related: Previously submitted, no feedback, trivial: grub-install-whitespace.patch Not previously submitted, trivial: bzrignore-updates.patch ZFS Related: Previously submitted, no feedback: zfs-poolname-spaces.patch zfs-devices.patch Not previously submitted: zfs-on-linux-rlaager8.patch With this, you should be able to boot with (native) ZFS-on-Linux, though you'll have to add whatever rpool specifiers (if any) required by your initrd. zfs-on-linux-rlaager9.patch Part of this is just to support ZFS roots (root=ZFS=rpool/ROOT/ubuntu, for example). The other part may need more design work. It moves some of the btrfs code to inside linux_entry (and likewise, the ZFS support is added there). Right now, GRUB supports the concept of multiple kernels. I think that needs to be extended to multiple root filesystems (in practice: subvols in btrfs, clones in ZFS). This is the first step in that process. The missing part is looping over the additional root filesystems. Even if we can't get the multiple root filesystems issue figured out, I'd really love to see everything else make it into the release. It'd be a huge step in the right direction for those of us working with native ZFS-on-Linux. -- Richard bzrignore-updates.patch === modified file '.bzrignore' Index: grub/.bzrignore === --- grub.orig/.bzrignore2012-02-04 17:30:15.295629000 -0600 +++ grub/.bzrignore 2012-02-04 17:30:49.356454000 -0600 @@ -104,6 +104,8 @@ partmap_test *.pp po/*.mo po/grub.pot +po/POTFILES +po/stamp-po stamp-h stamp-h1 stamp-h.in @@ -132,8 +134,10 @@ contrib grub-core/Makefile.core.am grub-core/Makefile.gcry.def grub-core/contrib +grub-core/gdb_grub grub-core/genmod.sh grub-core/gensyminfo.sh +grub-core/gmodule.pl grub-core/modinfo.sh grub-core/*.module grub-core/*.pp Committed zfs-poolname-spaces.patch Handle pool names with spaces Index: grub/util/getroot.c === --- grub.orig/util/getroot.c2012-02-03 05:21:06.838056692 -0600 +++ grub/util/getroot.c 2012-02-03 05:22:36.227364000 -0600 @@ -260,7 +260,7 @@ char cksum[257], notes[257]; unsigned int dummy; - cmd = xasprintf (zpool status %s, poolname); + cmd = xasprintf (zpool status \%s\, poolname); fp = popen (cmd, r); This is wrong if poolname contains weird characters. Can you make it similar to mdadm-related code? free (cmd); @@ -285,8 +285,7 @@ st++; break; case 1: - if (!strcmp (name, poolname)) - st++; + st++; break; case 2: if (strcmp (name, mirror) !sscanf (name, mirror-%u,dummy) @@ -420,6 +419,9 @@ if (sscanf (sep, %s %s, entry.fstype, entry.device) != 2) continue; + unescape (entry.fstype); + unescape (entry.device); + You need to increase the size of storage for these fields. Handle vdevs with full paths Index: grub/util/getroot.c === --- grub.orig/util/getroot.c2012-02-03 05:22:36.227364000 -0600 +++ grub/util/getroot.c 2012-02-03 05:22:41.255135000 -0600 @@ -301,7 +301,10 @@ devices = xrealloc (devices, sizeof (devices[0]) * devices_allocated); } - devices[ndevices++] = xasprintf (/dev/%s, name); + if (name[0] == '/') + devices[ndevices++] = xstrdup (name); + else + devices[ndevices++] = xasprintf (/dev/%s, name); } break; } This one is ok other than the missing ChangeLog. zfs-on-linux-rlaager8.patch ZFS on Linux Improvements 1. `zpool status` can output disk names which are under /dev/disk. 2. `zpool status` outputs the whole disk device for wholedisk pools, but GRUB needs the partition device. 3. Support native ZFS on Linux. Index: grub/util/getroot.c === --- grub.orig/util/getroot.c
Re: The submenu command shows a text-based menu when using a GFX theme.
On 24.02.2012 02:24, Towheed Mohammed wrote:
While 'export theme' fixes the issue more elegantly than what I had, it still
results in the theme reloading when the submenu menuentry is selected.
Reloading of the theme results in a screen flicker as the terminal window is
shown before the theme reloads.
I cannot code in C nor do I profess to be anywhere close to scripting as you
guys, but I think a better solution to fixing the submenu issue would be from
source code.
Is it at all possible to simply load the menuentry items under the submenu
command without having to reload the entire theme? If it can be done, wouldn't
it prevent the flicker seen as the theme reloads?
Problem is that it's possible to do something like:
submenu xyz {
theme=...
}
And thus change the theme for submenu.
While at it, could you also please fix the keyboard lag that results when a gfx
theme is used. This is an issue with many users of gfx themes .
Thank you.
Towheed Mohammed
- Original Message -
From: Vladimir 'φ-coder/phcoder' Serbinenkophco...@gmail.com
To: grub-devel@gnu.org
Cc:
Sent: Thursday, February 23, 2012 1:24 AM
Subject: Re: The submenu command shows a text-based menu when using a GFX theme.
On 23.02.2012 02:50, Towheed Mohammed wrote:
If a gfx theme is being used and the submenu command is used to show a submenu,
the submenu does not use the gfx theme. Instead a text-based menu is shown.
The only way a regular user can workaround this at the moment is to reload the
theme after the submenu menuentry item is selected.
In Ubuntu's (about the only distro that uses the submenu command at this time)
use of the submenu in 10_linux:
if [ $list ] ! $in_submenu; then
in_submenu=:
fi
A regular user must patch 10_linux thus:
if [ $list ] ! $in_submenu; then
echo submenu \Previous Linux versions\ --class submenu {
if [ x$GRUB_THEME != x ] [ -f $GRUB_THEME ] \
is_path_readable_by_grub $GRUB_THEME; then
prepare_grub_to_access_device `${grub_probe} --target=device
$GRUB_THEME`
cat EOF
set theme=(\$root)`make_system_path_relative_to_its_root $GRUB_THEME`
EOF
fi
in_submenu=:
fi
What a perfect example of overengineering just to compensate for missing
export theme. I've fixed it in trunk
to reload the theme and have a themed submenu.
Will this be fixed in the 2.00 release?
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-mount (ubuntu) hangs with hfs+ partition
On 23.02.2012 21:46, Kees Bakker wrote: Hi, In Ubuntu (and Debian I guess) there is a grub-mount command. It's added to grub with branch_fuse.patch, and in that file it mentions http://lists.gnu.org/archive/html/grub-devel/2011-01/msg00056.html I have a MacPro system with Ubuntu installed and some HFS+ partitions. Everytime I do a kernel update (and update-grub) it hangs when a grub-mount command is used on one of the HFS+ partitions. The grub-mount command does not hang on all my HFS+ partitions. But the fact that it hangs on one of them makes it very annoying. I've tried to debug this problem, but I am not making any progress. The program hangs in a while(1) loop at line 657 in grub-core/fs/hfsplus.c there is no loop at this location in the latest trunk. Could you use this please? Also what is the value of currnode on every loop iteration? BTW. I've also tried to contact Macro Gerards (the contributor of the HFS+ code), but I didn't get a reply from him. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Search for images within sub-directories of the theme's directory.
On 24.02.2012 03:29, Towheed Mohammed wrote: The following components: 1. image 2. progress_bar, and 3. circular_progress have the 'theme_dir' property. A theme designer can use this property to place image files within sub-directories of the theme's directory. However, 00_header searches for images only in the theme's directory: theme_dir isn't intended to be set in theme file. It's internal. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-mount (ubuntu) hangs with hfs+ partition
On 24.02.2012 21:28, Kees Bakker wrote: On 24-02-12 11:34, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 23.02.2012 21:46, Kees Bakker wrote: I've tried to debug this problem, but I am not making any progress. The program hangs in a while(1) loop at line 657 in grub-core/fs/hfsplus.c there is no loop at this location in the latest trunk. Could you use this please? Correct, the while (1) is at line 665. Here is the good news: the hang does not happen with the trunk version anymore. But there is still a minor bug that you can make this loop hang with a broken FS (btree loop). I've added standard Brent's check to avoid this. Great work Vladimir. You seem to have done quite a bit of work there, according to the ChangeLog. Thanks a lot. Now, if only Ubuntu would like to take a more recent upstream version ... -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: The submenu command shows a text-based menu when using a GFX theme.
On 24.02.2012 23:50, Towheed Mohammed wrote:
submenu xyz {
theme=...
}
So we can say it's a feature. Well then, could it be patched thus:
1. If the user specifies a new theme for the submenu, load the new theme. The
flicker is then not apparent as the new theme is loaded.
2. If the user wishes to use the currently loaded theme for the submenu, then
simply load the menuentry items of the submenu without reloading the theme.
This way, the screen flicker becomes non-existent/non-apparent.
We already reuse the loaded menu if the theme file hasn't changed.
In either case though, the terminal-window should never be seen when descending
into the submenu as it is now. The terminal-window should only be shown when a
menuentry item is selected or the user wishes to edit the commands or drop to
the command-line.
terminal appears because of a message Booting Move it into some
kind of status message is more long-term. Definitely post-2.0
Thank you
Towheed Mohammed
- Original Message -
From: Vladimir 'φ-coder/phcoder' Serbinenkophco...@gmail.com
To: The development of GNU GRUBgrub-devel@gnu.org
Cc:
Sent: Friday, February 24, 2012 3:44 AM
Subject: Re: The submenu command shows a text-based menu when using a GFX theme.
On 24.02.2012 02:24, Towheed Mohammed wrote:
While 'export theme' fixes the issue more elegantly than what I had, it still
results in the theme reloading when the submenu menuentry is selected.
Reloading of the theme results in a screen flicker as the terminal window is
shown before the theme reloads.
I cannot code in C nor do I profess to be anywhere close to scripting as you
guys, but I think a better solution to fixing the submenu issue would be from
source code.
Is it at all possible to simply load the menuentry items under the submenu
command without having to reload the entire theme? If it can be done, wouldn't
it prevent the flicker seen as the theme reloads?
Problem is that it's possible to do something like:
submenu xyz {
theme=...
}
And thus change the theme for submenu.
While at it, could you also please fix the keyboard lag that results when a gfx
theme is used. This is an issue with many users of gfx themes .
Thank you.
Towheed Mohammed
- Original Message -
From: Vladimir 'φ-coder/phcoder' Serbinenkophco...@gmail.com
To: grub-devel@gnu.org
Cc:
Sent: Thursday, February 23, 2012 1:24 AM
Subject: Re: The submenu command shows a text-based menu when using a GFX theme.
On 23.02.2012 02:50, Towheed Mohammed wrote:
If a gfx theme is being used and the submenu command is used to show a submenu,
the submenu does not use the gfx theme. Instead a text-based menu is shown.
The only way a regular user can workaround this at the moment is to reload the
theme after the submenu menuentry item is selected.
In Ubuntu's (about the only distro that uses the submenu command at this time)
use of the submenu in 10_linux:
if [ $list ]! $in_submenu; then
in_submenu=:
fi
A regular user must patch 10_linux thus:
if [ $list ]! $in_submenu; then
echo submenu \Previous Linux versions\ --class submenu {
if [ x$GRUB_THEME != x ][ -f $GRUB_THEME ] \
is_path_readable_by_grub $GRUB_THEME; then
prepare_grub_to_access_device `${grub_probe} --target=device
$GRUB_THEME`
catEOF
set theme=(\$root)`make_system_path_relative_to_its_root $GRUB_THEME`
EOF
fi
in_submenu=:
fi
What a perfect example of overengineering just to compensate for missing
export theme. I've fixed it in trunk
to reload the theme and have a themed submenu.
Will this be fixed in the 2.00 release?
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: disable-libzfs configure flag (Re: Freeze on 27 February)
On 25.02.2012 19:44, Mike Gilbert wrote: +if test x$libzfs_excuse = x ; then + # Only check for system headers if libzfs support has not been disabled. + AC_CHECK_HEADERS(libzfs.h libnvpair.h) +fi You should set excuse here if the headers aren't found. Also it should fail if libzfs is explicitly enable but unavailable -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: The submenu command shows a text-based menu when using a GFX theme.
On 26.02.2012 03:18, Towheed Mohammed wrote:
Also consider this. As in the case of the image component, it's file property
allows for a fully qualified filename:
+ image {
file = /usr/share/grub/themes/demo/images/gnu.jpg
This possibility is kept for backward compatibility but shouldn't be
used in new themes and is unreliable. Consider e.g. a case of separate
/boot. Perhaps we should remove this possibility altogether.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: The submenu command shows a text-based menu when using a GFX theme.
On 26.02.2012 17:20, Towheed Mohammed wrote: I have tested this on separate distros, including but not limited to: ArchLinux, Debian (and Debian-based distros), Slackware, Fedora, VectorLinux and openSUSE (some others I can't recall ATM), all with and without separate /boot partitions and all with GRUB 1.99 installed.. Actually, my demo theme is located in /usr/share/grub and not in /boot/grub. As it is, the fully qualified filename works as intended. Placing the themes in /usr/share/grub removes the incompatibility of having a separate /boot partition and also removes any incompatibility from some distro that use /boot/grub2 instead of /boot/grub. Then think about a separate /usr. theme files are static and have no way of knowing about adjusted for some reason directories. Moreover / and /usr may be unavailable to GRUB, e.g. it may be on NFS or encrypted. We can assume only that the $prefix with subdirectories and files needed to boot OS (in case of GNU/Linux it's Linux and initrd in /boot, other OS may have files outside /boot which may assume readable e.g. /mach_kernel for xnu). That's the reason I've adjusted grub-install to copy theme and fonts to $prefix/themes resp $prefix/fonts. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fix for pkgdatadir grub-mkconfig_lib in all util scripts and grub.d scripts
On 21.02.2012 00:57, Grégoire Sutre wrote: On 02/20/2012 06:47 PM, Keshav P R wrote: Hi, Attached patch fixes runtime error due to sed transform used in pkgdatadir Maybe we should apply the sed transform to grub-mkconfig_lib's installation directory, i.e., install grub-mkconfig_lib alongside unicode.pf2 and friends? It seems that the guys on autoconf ML use another convention for pkgdatadir/pkglibdir. So I made GRUB to behave more like what autoconf guys told me. I didn't use any of supplied patches since sed is faster than checking a patch by hand. Grégoire # /_grub_/grub_uefi_x86_64/bin/grub_uefi_x86_64-mkstandalone -h /_grub_/grub_uefi_x86_64/bin/grub_uefi_x86_64-mkstandalone: line 46: /_grub_/grub_uefi_x86_64/share/grub_uefi_x86_64/grub-mkconfig_lib: No such file or directory File is at /_grub_/grub_uefi_x86_64/share/grub/grub-mkconfig_lib (in my case). Please apply this. Thanks in advance. Regards. Keshav ___ 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 -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Infinite loop in __argp_get_display_len
On 26.02.2012 20:12, Mike Gilbert wrote: Running grub-mkimage --help triggers an infinite loop in __argp_get_display_len. Backtrace attached. Yes, I've just noticed it. I have a fix, just testing it. The following change seems to resolve it; I wonder if it should be applied to the other functions in argp-fmtstream.c? === modified file 'grub-core/gnulib/argp-fmtstream.c' --- grub-core/gnulib/argp-fmtstream.c 2012-02-26 18:07:59 + +++ grub-core/gnulib/argp-fmtstream.c 2012-02-26 19:04:10 + @@ -133,7 +133,7 @@ size_t s; s = mbrtowc (wc, ptr, end - ptr,ps); - if (s == (size_t) -1) + if (s == 0 || s == (size_t) -1 || s == (size_t) -2) break; r += wcwidth (wc); ptr += s; ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH V3 1/3] Update the Linux boot protocol
On 26.02.2012 22:01, Keshav P R wrote: Status of this patch in grub2 v2.00 code freeze? I have written what have to be fixed first. And one thing: your idea to put into distro a patch which has known serious issues that have to be resolved was a very bad one. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH V3 1/3] Update the Linux boot protocol
On 26.02.2012 22:22, Keshav P R wrote: Coming to the issue of distro package, has the uefi relocator hang (seen in many asus laptops) been fixed in bzr mainline? The reports feature one bug that debug=all caused relocator to hang. I don't know what happens in case when no debug is set and whether it's relocator's (or GRUB's at all for that matter) fault. On 27/02/2012, Keshav P Rthe.ridikulus@gmail.com wrote: I am asking about 'this' patch (patch 1/3) alone. Not the other two ones. And the distro package was never updated, it was just a test build with a bzr snapshot and these patches, given to users willing to test the code. - Keshav On 27/02/2012, Vladimir 'φ-coder/phcoder' Serbinenkophco...@gmail.com wrote: On 26.02.2012 22:01, Keshav P R wrote: Status of this patch in grub2 v2.00 code freeze? I have written what have to be fixed first. And one thing: your idea to put into distro a patch which has known serious issues that have to be resolved was a very bad one. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ 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 -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH V3 1/3] Update the Linux boot protocol
On 26.02.2012 22:18, Keshav P R wrote: I am asking about 'this' patch (patch 1/3) alone. 'This' patch by itself has no effect. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub2 and Xen menu entries
On 03.04.2011 13:36, Alexey Shvetsov wrote: Hi all! I'm using xen on gentoo with grub2 and seems there is and issue with default xen detection mechanism because it also adds menu entries for all xen symlinks in boot and for xen-syms [see grub.cfg.unpatched] that shouldn't happen. Contents of my boot directory is Just for record: this patch wasn't accepted because it's not POSIX-compatible. Please fix this. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] grub + FreeBSD's loader(8) + ZFS root
On 07.04.2010 22:21, Navdeep Parhar wrote:
2010/4/7 Vladimir 'φ-coder/phcoder' Serbinenkophco...@gmail.com:
Navdeep Parhar wrote:
Hello grub-devel,
Right now it's not possible to boot using FreeBSD's loader(8) from a ZFS
root filesystem. Grub doesn't indicate to the loader that there is a
ZFS root involved and consequently the loader fails to find the kernel.
The attached patch fixes this. It does not affect those that boot the
kernel directly. This is only for users that want to boot using
FreeBSD's loader.
Why would you want to? IMHO it is much simpler to boot indirectly using
the loader because in that case grub does not have to deal with
device.hints, kernel modules, kFreeBSD.xxx style variables,
/boot/zfs/zpool.cache, etc. As a FreeBSD user, I'm used to putting this
information in the normal config files (/boot/loader.conf, device.hints,
etc.) and not in a grub.cfg file. Grub only needs to know where the loader
is, nothing else:
menuentry FreeBSD 8 {
search -s -l fbsd8
kfreebsd -D /@/boot/zfsloader
}
(fbsd8 is the name of the ZFS root pool)
Eternal chainloading isn't the way to go. It limits grub usefullness and
scope and is to be used only when no alternative exists. In this case
the right direction would be to make a small C module to parse boot(8)
config or a shell script for 30_osprober.in to do the same job
Sure, chainloading doesn't have to be the preferred way of booting an
OS, but it shouldn't fail without a good reason either. Right now
FreeBSD can be chainloaded from a UFS root but not from ZFS root.
That's all that I'm trying to fix here. This patch doesn't imply that
chainloading is *the* way to load FreeBSD - just that it is a usable
alternate to direct loading, even from a ZFS root.
I've added this patch but only because since we support aout
/boot/loader it makes little sense not to support zfsloader but it's not
a recommended way to boot in either case.
Regards,
Navdeep
___
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
https://lists.gnu.org/mailman/listinfo/grub-devel
