Re: [Xen-devel] [PATCH, RFC] Allow running with non-terminated boot services in multiboot2
On 09.12.2013 09:40, Daniel Kiper wrote: On Sat, Dec 07, 2013 at 12:13:05PM +0100, Vladimir '??-coder/phcoder' Serbinenko wrote: Patch to spec and GRUB attached. @ xen: don't forget to put wlan card to sleep when you finish boot services Thank you for your work. At first sight it looks quite nice but I am not able to do tests right now. I am going to continue my work on GRUB2/EFI stuff for Xen at the beginning of next year. Can you confirm that that's what you want? I'd like it to make into 2.02 release but it would be useless if it's not what you want. Daniel signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] pvgrub2 is merged
Il 07/12/2013 11:06, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: On 06.12.2013 16:22, Fabio Fantoni wrote: Il 06/12/2013 15:55, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: On 06.12.2013 15:44, Fabio Fantoni wrote: Il 06/12/2013 12:32, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: On 06.12.2013 12:11, Fabio Fantoni wrote: Il 03/12/2013 17:16, Fabio Fantoni ha scritto: Il 03/12/2013 16:33, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: On 03.12.2013 15:00, Fabio Fantoni wrote: Il 03/12/2013 12:29, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: On 03.12.2013 12:22, Fabio Fantoni wrote: Il 03/12/2013 11:33, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: On 03.12.2013 11:31, Fabio Fantoni wrote: If you need more tests/informations tell me and I'll post them. I've already asked you for exact kernel that I can download (and SHA512 to check it's the same one) and got only vague response Thanks for reply. The actual kernel used is from this package: http://packages.debian.org/sid/linux-image-3.11-2-amd64 I already checked kernel's files integrity with md5 (using the debian package's md5sums file and is correct). Same domU with pygrub with manual and minimal grub.cfg configuration and it boots correctly, but with pvgrub2 and grub.cfg created automatically (see attachment of previous mail) it doesn't boot. With HEAD: phcoder@debian:12:21:06:~/compile/bt/x86_64-xen$ ar x ~/downloads/linux-image-3.11-2-amd64_3.11.8-1_amd64.deb phcoder@debian:12:23:29:~/compile/bt/x86_64-xen$ tar --xz -xf data.tar.xz phcoder@debian:12:28:36:~/compile/bt/x86_64-xen$ sha512sum boot/vmlinuz-3.11-2-amd64 002bc39cfc0191614ec380a44993d20691e1dc8791a8c6f3a163777ef6fb733243d3da48760b2eedfc3ab9b8bd7b8fe2d473cdd3a91eb3d855eb4f3db9f7b6df boot/vmlinuz-3.11-2-amd64 phcoder@debian:12:23:38:~/compile/bt/x86_64-xen$ ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o grub.xen -O x86_64-xen -d grub-core/ boot/vmlinuz-3.11-2-amd64 GNU GRUB version 2.00 Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions. grub insmod xzio grub linux /boot/vmlinuz-3.11-2-amd64 grub boot [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct I've uploaded my grub.xen to http://download-mirror.savannah.gnu.org/releases/grub/phcoder/grub.xen.xz Thanks for any reply. Thanks for your reply. I tried with your build and gave me: Caricamento Linux 3.11-2-amd64... errore: not xen image. Caricamento ramdisk iniziale... errore: ? necessario caricare il kernel prima. I also rebuilt pvgrub2 from clean directory, full logs of configure, make and xl create on attachment. Also in this case domU destroys on kernel and initrd loading. I not understand what are my errors and/or forgetfulness. $ sha512sum /boot/vmlinuz-3.11-2-amd64 sha512sum /mnt/tmp/boot/vmlinuz-3.11-2-amd64 002bc39cfc0191614ec380a44993d20691e1dc8791a8c6f3a163777ef6fb733243d3da48760b2eedfc3ab9b8bd7b8fe2d473cdd3a91eb3d855eb4f3db9f7b6df /mnt/tmp/boot/vmlinuz-3.11-2-amd64 Did you try with kernel embed in GRUB? I tried with ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O x86_64-xen -d grub-core/ /mnt/tmp/boot/vmlinuz-3.11-2-amd64 Probably I did something wrong or missed about this test. On xl create it arrives to grub console, so I tried to set root and include the grub.cfg of domU but gave nothing, only new console line. Can you give me more details to do a complete and correct test? Did you try root/linux/initrd/boot sequence manually? I presume you mean to do insmod, set root and all other command manually without using grub.cfg, could you confirm that or give me an exact howto? I tried manually sequence instead of do it with grub.cfg (I hope to did it correctly): ... grub insmod part_msdos grub insmod xzio grub insmod ext2 grub insmod gzio grub set root=(xen/xvda,msdos1) grub linux /boot/vmlinuz-3.11-2-amd64 root=UUID=3ab55964-09d1-4853-be38-661b56a14 ro console=tty0 debug grub initrd /boot/initrd.img-3.11-2-amd64 grub boot xc: debug: hypercall buffer: total allocations:237 total releases:237 xc: debug: hypercall buffer: current allocations:0 maximum allocations:4 xc: debug: hypercall buffer: cache current size:4 xc: debug: hypercall buffer: cache hits:226 misses:4 toobig:7 unfortunately the result is the same :( Hm, that is different from previous. Previously you spoke about not a xen image message. I'd remove console=tty0 and also try without initrd. Without console and initrd: ... grub insmod part_msdos grub insmod xzio grub insmod ext2 grub insmod gzio grub set root=(xen/xvda,msdos1) grub linux /boot/vmlinuz-3.11-2-amd64 root=UUID=3ab55964-09d1-4853-be38-661b5a476a14 ro debug grub boot xc: debug: hypercall buffer: total allocations:247 total releases:247
Re: [Xen-devel] [PATCH, RFC] Allow running with non-terminated boot services in multiboot2
On Mon, Dec 09, 2013 at 10:22:25AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 09.12.2013 09:40, Daniel Kiper wrote: On Sat, Dec 07, 2013 at 12:13:05PM +0100, Vladimir '??-coder/phcoder' Serbinenko wrote: Patch to spec and GRUB attached. @ xen: don't forget to put wlan card to sleep when you finish boot services Thank you for your work. At first sight it looks quite nice but I am not able to do tests right now. I am going to continue my work on GRUB2/EFI stuff for Xen at the beginning of next year. Can you confirm that that's what you want? I'd like it to make into 2.02 release but it would be useless if it's not what you want. Just one nitpick. FinishBootServices() should be replaced by ExitBootServices() in doc/multiboot.texi file. Yes, it is what I want but I think that it will be nice to test this new feature. However, I am busy right now and I am not able to do that. When are you going to make 2.02 release? Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub mishandles corrupt/missing primary GPT
On 09.12.2013 16:28, Phillip Susi wrote: On 10/23/2013 9:49 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: partmap module is size-critical and CRC32 verification is pretty big. There are 3 problems with backup header: The grub core no longer fits in 63 sectors in all but the most trivial configurations as it is, Not true. I've checked: all configs not involving compressed fs or diskfilter fit in 31K. and a 2048 sector embed area has been standard now for several years, so I don't think size is a problem. We're speaking abut GPT, nothing to do with MBR embed area. My problem with that is that it increases complexity a lot in currently simple code. And also I had experience with backup header out of place due to disk reconfiguration and primary header corrupted but still well enough to have valid partitions. I could boot this system by using gpt linux option. With proposed changes this system would become unbootable. signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Quick question?
Hello, I see that grub-devel changed from bzr to git. What will be the equivalent of: http://bzr.savannah.gnu.org/lh/grub/trunk/grub/changes ? This link does not work anymore. How to find what is the GRUB version, from the current snapshot taken from git (git clone git://git.savannah.gnu.org/grub.git)? Thank you, Zoran ___ Most of The Time you should be intel inside to be capable to think out of the box. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Quick question?
On 09.12.2013 16:59, Stojsavljevic, Zoran wrote: Hello, I see that grub-devel changed from bzr to git. What will be the equivalent of: http://bzr.savannah.gnu.org/lh/grub/trunk/grub/changes ? This link does not work anymore. How to find what is the GRUB version, from the current snapshot taken from git (git clone git://git.savannah.gnu.org/grub.git)? Doesn't sounds like question for grub-devel or something you'd add persons manually to CC. Thank you, Zoran ___ Most of The Time you should be intel inside to be capable to think out of the box. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Quick question?
В Mon, 9 Dec 2013 15:59:19 + Stojsavljevic, Zoran zoran.stojsavlje...@intel.com пишет: Hello, I see that grub-devel changed from bzr to git. What will be the equivalent of: http://bzr.savannah.gnu.org/lh/grub/trunk/grub/changes ? This link does not work anymore. I think http://git.savannah.gnu.org/cgit/grub.git/log/ comes close. How to find what is the GRUB version, from the current snapshot taken from git (git clone git://git.savannah.gnu.org/grub.git)? Could you really do it from bzr checkout? Usually it is git describe HEAD as long as project maintains release tags. Thank you, Zoran ___ Most of The Time you should be intel inside to be capable to think out of the box. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: kern/efi/mm.c - MAX_USABLE_ADDRESS
On 09.12.2013 18:30, Leif Lindholm wrote: Hi, The EFI memory management code contains a hard-wired limit restricting physical (and virtual, all 1:1 mapped in UEFI) addresses to 32-bit. While this may be the right thing to do on x86, and hasn't caused me any issues on 32-bit ARM, I have received reports of at least two upcoming 64-bit ARM platforms with no RAM in the lower 4GB of physical address space. A simple fix would be to just stack the ifdefs, but a better one might be to move the define to one of cpu/efi/memory.h (which is currently a dummy for all platforms, simply including efi/memory.h) or types.h. cpu/efi/memory.h is a possibility. cpu/types.h isn't because it's, at least partially, EFI limitation (due to EFI bugs), not CPU. Real restrictions is a mix of unrelated restriction but it seem to align well with CPU. Increasing it beyond 0x will need chacking that efi/mm.c can handle it without overflow. The limits are: -0x on 32-bit platforms due to address space size (i386, arm) -0x7fff when x86_64 compiled without -mcmodel=large due to compiler assumptions -0x on x86_64 because some EFI implementations don't map memory above 4G contrary to spec. - On ia64 it's probably unlimited but I didn't test and there is always a danger of EFI bugs similar to x86_64 one, so better to be conservative about it - arm64. You're the expert. --- a/include/grub/i386/types.h +++ b/include/grub/i386/types.h @@ -25,6 +25,12 @@ /* The size of long. */ #define GRUB_TARGET_SIZEOF_LONG4 +#if defined (__code_model_large__) +#define MAX_USABLE_ADDRESS 0x +#else +#define MAX_USABLE_ADDRESS 0x7fff +#endif + Should be MAX_USABLE_ADDRESS 0x signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Arch Linux specific grub-mkconfig fixes
Hi,
This patch has been used in Arch Linux's GRUB(2) package for quite some
time (ever since the release of grub 2.00).
The main feature that distinguishes Arch Linux from other distros is that
its kernel and initramfs (core/linux pkg) are always installed at
/boot/vmlinuz-linux and /boot/initramfs-linux.img and this path does not
contain the actual kernel version info and therefore does not change with
kernel updates, unlike other distros.
Also Arch Linux includes a secondary (fallback) initramfs image
at /boot/initramfs-linux-fallback.img which contains modules, that are
excluded by autodetect hook in the normal initramfs image
at /boot/initramfs-linux.img . Thus if the user is unable to boot
using /boot/initramfs-linux.img, he/she may be able to boot
using /boot/initramfs-linux-fallback.img . Arch Linux and its derivatives
use this kind of fallback initramfs setup. This patch also adds detection
of this fallback initramfs image.
I have attached the patch instead of sending this via git-send-mail,
because 1) I haven't setup git-send-mail, and 2) Mail program seems to
screw up the line indentation.
With Best Regards,
Keshav
From 009ecc71a0b397faed8fafb3c4d62e96d0d86a8a Mon Sep 17 00:00:00 2001
From: Keshav Padram Amburay the.ridikulus@gmail.com
Date: Wed, 6 Nov 2013 21:49:40 +0530
Subject: [PATCH] Add Arch Linux specific grub-mkconfig fixes
Patch modified based on ideas from Felix aka fstirlitz,
given at https://bugs.archlinux.org/task/37904?getfile=11257
---
util/grub-mkconfig.in | 2 ++
util/grub-mkconfig_lib.in | 3 +++
util/grub.d/00_header.in | 8
util/grub.d/10_linux.in | 27 ---
4 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
index 3390ba9..c416489 100644
--- a/util/grub-mkconfig.in
+++ b/util/grub-mkconfig.in
@@ -218,6 +218,8 @@ export GRUB_DEFAULT \
GRUB_THEME \
GRUB_GFXPAYLOAD_LINUX \
GRUB_DISABLE_OS_PROBER \
+ GRUB_COLOR_NORMAL \
+ GRUB_COLOR_HIGHLIGHT \
GRUB_INIT_TUNE \
GRUB_SAVEDEFAULT \
GRUB_ENABLE_CRYPTODISK \
diff --git a/util/grub-mkconfig_lib.in b/util/grub-mkconfig_lib.in
index a9cf7fc..7eb8950 100644
--- a/util/grub-mkconfig_lib.in
+++ b/util/grub-mkconfig_lib.in
@@ -245,6 +245,9 @@ version_test_gt ()
*.old:*.old) ;;
*.old:*) version_test_gt_a=`echo -n $version_test_gt_a | sed -e 's/\.old$//'` ; version_test_gt_cmp=gt ;;
*:*.old) version_test_gt_b=`echo -n $version_test_gt_b | sed -e 's/\.old$//'` ; version_test_gt_cmp=ge ;;
+*-lts:*-lts) ;;
+*-lts:*) version_test_gt_a=`echo -n $version_test_gt_a | sed -e 's/-lts$//'` ; version_test_gt_cmp=gt ;;
+*:*-lts) version_test_gt_b=`echo -n $version_test_gt_b | sed -e 's/-lts$//'` ; version_test_gt_cmp=ge ;;
esac
version_test_numeric $version_test_gt_a $version_test_gt_cmp $version_test_gt_b
return $?
diff --git a/util/grub.d/00_header.in b/util/grub.d/00_header.in
index d2e7252..8259f45 100644
--- a/util/grub.d/00_header.in
+++ b/util/grub.d/00_header.in
@@ -125,6 +125,14 @@ cat EOF
EOF
+if [ x$GRUB_COLOR_NORMAL != x ] [ x$GRUB_COLOR_HIGHLIGHT != x ] ; then
+cat EOF
+set menu_color_normal=$GRUB_COLOR_NORMAL
+set menu_color_highlight=$GRUB_COLOR_HIGHLIGHT
+
+EOF
+fi
+
serial=0;
gfxterm=0;
for x in ${GRUB_TERMINAL_INPUT} ${GRUB_TERMINAL_OUTPUT}; do
diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index 00d1931..f403585 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -81,6 +81,8 @@ linux_entry ()
case $type in
recovery)
title=$(gettext_printf %s, with Linux %s (recovery mode) ${os} ${version}) ;;
+ fallback)
+ title=$(gettext_printf %s, with Linux %s (fallback initramfs) ${os} ${version}) ;;
*)
title=$(gettext_printf %s, with Linux %s ${os} ${version}) ;;
esac
@@ -94,7 +96,7 @@ linux_entry ()
else
echo menuentry '$(echo $os | grub_quote)' ${CLASS} \$menuentry_id_option 'gnulinux-simple-$boot_device_id' { | sed s/^/$submenu_indentation/
fi
- if [ x$type != xrecovery ] ; then
+ if [ x$type != xrecovery ] [ x$type != xfallback ] ; then
save_default_entry | grub_add_tab
fi
@@ -126,7 +128,8 @@ linux_entry ()
fi
printf '%s\n' ${prepare_boot_cache} | sed s/^/$submenu_indentation/
fi
- message=$(gettext_printf Loading Linux %s ... ${version})
+
+ message=$(gettext_printf Loading Linux %s ... ${version})
sed s/^/$submenu_indentation/ EOF
echo '$(echo $message | grub_quote)'
linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}
@@ -185,6 +188,12 @@ while [ x$list != x ] ; do
linux_root_device_thisversion=${LINUX_ROOT_DEVICE}
initrd=
+
+ if echo ${basename} | grep -q 'vmlinuz-linux' ; then
+version=`echo ${basename} | sed -e 's,vmlinuz-linux-,,g'` kernel
+initramfs_arch=`echo ${basename} | sed -e 's,vmlinuz,initramfs,g'`
+ fi
+
for i in initrd.img-${version} initrd-${version}.img
Re: [PATCH] Arch Linux specific grub-mkconfig fixes
This patch clearly doesn't have right attributions, not split according to functional changes and some of parts were already discussed. As-is patch is unacceptable, the biggest problem being the lack of right attribution. E.g. some parts are apparently by WIP patch by Alexander Kurtz yet he's never mentioned at all. Please never ever send patches to GRUB under wrong authorship acknowledges. On 09.12.2013 20:11, Keshav Padram Amburay wrote: Hi, This patch has been used in Arch Linux's GRUB(2) package for quite some time (ever since the release of grub 2.00). The main feature that distinguishes Arch Linux from other distros is that its kernel and initramfs (core/linux pkg) are always installed at /boot/vmlinuz-linux and /boot/initramfs-linux.img and this path does not contain the actual kernel version info and therefore does not change with kernel updates, unlike other distros. Also Arch Linux includes a secondary (fallback) initramfs image at /boot/initramfs-linux-fallback.img which contains modules, that are excluded by autodetect hook in the normal initramfs image at /boot/initramfs-linux.img . Thus if the user is unable to boot using /boot/initramfs-linux.img, he/she may be able to boot using /boot/initramfs-linux-fallback.img . Arch Linux and its derivatives use this kind of fallback initramfs setup. This patch also adds detection of this fallback initramfs image. I have attached the patch instead of sending this via git-send-mail, because 1) I haven't setup git-send-mail, and 2) Mail program seems to screw up the line indentation. With Best Regards, Keshav ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: kern/efi/mm.c - MAX_USABLE_ADDRESS
On 09.12.2013 20:08, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 09.12.2013 18:30, Leif Lindholm wrote: Hi, The EFI memory management code contains a hard-wired limit restricting physical (and virtual, all 1:1 mapped in UEFI) addresses to 32-bit. While this may be the right thing to do on x86, and hasn't caused me any issues on 32-bit ARM, I have received reports of at least two upcoming 64-bit ARM platforms with no RAM in the lower 4GB of physical address space. A simple fix would be to just stack the ifdefs, but a better one might be to move the define to one of cpu/efi/memory.h (which is currently a dummy for all platforms, simply including efi/memory.h) or types.h. cpu/efi/memory.h is a possibility. cpu/types.h isn't because it's, at least partially, EFI limitation (due to EFI bugs), not CPU. Real restrictions is a mix of unrelated restriction but it seem to align well with CPU. Increasing it beyond 0x will need chacking that efi/mm.c can handle it without overflow. The limits are: -0x on 32-bit platforms due to address space size (i386, arm) -0x7fff when x86_64 compiled without -mcmodel=large due to compiler assumptions -0x on x86_64 because some EFI implementations don't map memory above 4G contrary to spec. - On ia64 it's probably unlimited but I didn't test and there is always a danger of EFI bugs similar to x86_64 one, so better to be conservative about it - arm64. You're the expert. If you want to increase it to 0x you'll need patch at bottom of this mail. All other uses of MAX_USABLE_ADDRESS seem to be fine. With this patch we would lose the last usable page but it's just 4K and this page is dangerous for overflows anyway so better to avoid. I'd suggest using something lower (perhaps 1M lower) to avoid potential bugs in EFI. diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c index 6e9dace..2becb7b 100644 --- a/grub-core/kern/efi/mm.c +++ b/grub-core/kern/efi/mm.c @@ -30,6 +30,7 @@ ((grub_efi_memory_descriptor_t *) ((char *) (desc) + (size))) #define BYTES_TO_PAGES(bytes) (((bytes) + 0xfff) 12) +#define BYTES_TO_PAGES_DOWN(bytes) ((bytes) 12) #define PAGES_TO_BYTES(pages) ((pages) 12) #if defined (__code_model_large__) || !defined (__x86_64__) @@ -343,9 +344,9 @@ filter_memory_map (grub_efi_memory_descriptor_t *memory_map, #if 1 if (BYTES_TO_PAGES (filtered_desc-physical_start) + filtered_desc-num_pages - BYTES_TO_PAGES (MAX_USABLE_ADDRESS+1LL)) + BYTES_TO_PAGES_DOWN (MAX_USABLE_ADDRESS)) filtered_desc-num_pages - = (BYTES_TO_PAGES (MAX_USABLE_ADDRESS+1LL) + = (BYTES_TO_PAGES_DOWN (MAX_USABLE_ADDRESS) - BYTES_TO_PAGES (filtered_desc-physical_start)); #endif signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Arch Linux specific grub-mkconfig fixes
On Tue, Dec 10, 2013 at 12:47 AM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: This patch clearly doesn't have right attributions, not split according to functional changes and some of parts were already discussed. As-is patch is unacceptable, the biggest problem being the lack of right attribution. E.g. some parts are apparently by WIP patch by Alexander Kurtz yet he's never mentioned at all. Please never ever send patches to GRUB under wrong authorship acknowledges. I was not aware of WIP patch by Alexander Kurtz with respect to the GRUB_COLOR_* changes. Regarding the code adding detection of Arch Linux kernel and initramfs files by grub-mkconfig, it is difficult to find out via the current Arch Linux SVN based repo structure as to who was the original author of this patch, and who all have contributed changes to it (apart from me, Tobias Powalowski and Ronald Van Haren), so for now I withdraw this patch. Sorry for the mistake. On 09.12.2013 20:11, Keshav Padram Amburay wrote: Hi, This patch has been used in Arch Linux's GRUB(2) package for quite some time (ever since the release of grub 2.00). The main feature that distinguishes Arch Linux from other distros is that its kernel and initramfs (core/linux pkg) are always installed at /boot/vmlinuz-linux and /boot/initramfs-linux.img and this path does not contain the actual kernel version info and therefore does not change with kernel updates, unlike other distros. Also Arch Linux includes a secondary (fallback) initramfs image at /boot/initramfs-linux-fallback.img which contains modules, that are excluded by autodetect hook in the normal initramfs image at /boot/initramfs-linux.img . Thus if the user is unable to boot using /boot/initramfs-linux.img, he/she may be able to boot using /boot/initramfs-linux-fallback.img . Arch Linux and its derivatives use this kind of fallback initramfs setup. This patch also adds detection of this fallback initramfs image. I have attached the patch instead of sending this via git-send-mail, because 1) I haven't setup git-send-mail, and 2) Mail program seems to screw up the line indentation. With Best 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
Re: kern/efi/mm.c - MAX_USABLE_ADDRESS
On Mon, Dec 09, 2013 at 08:08:39PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: A simple fix would be to just stack the ifdefs, but a better one might be to move the define to one of cpu/efi/memory.h (which is currently a dummy for all platforms, simply including efi/memory.h) or types.h. cpu/efi/memory.h is a possibility. cpu/types.h isn't because it's, at least partially, EFI limitation (due to EFI bugs), not CPU. Ah, ok - that makes sense then. Real restrictions is a mix of unrelated restriction but it seem to align well with CPU. Increasing it beyond 0x will need chacking that efi/mm.c can handle it without overflow. The limits are: -0x on 32-bit platforms due to address space size (i386, arm) -0x7fff when x86_64 compiled without -mcmodel=large due to compiler assumptions -0x on x86_64 because some EFI implementations don't map memory above 4G contrary to spec. - On ia64 it's probably unlimited but I didn't test and there is always a danger of EFI bugs similar to x86_64 one, so better to be conservative about it - arm64. You're the expert. Thank you - that makes it very clear. / Leif ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] improve formatting and content of target list in grub-probe help
On 07.12.2013 14:27, Andrey Borzenkov wrote: + ret = xasprintf (%s\n%s %s [default=%s], _(print TARGET), where does print come from?h signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub mishandles corrupt/missing primary GPT
On Dec 9, 2013, at 8:54 AM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: On 09.12.2013 16:28, Phillip Susi wrote: On 10/23/2013 9:49 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: partmap module is size-critical and CRC32 verification is pretty big. There are 3 problems with backup header: The grub core no longer fits in 63 sectors in all but the most trivial configurations as it is, Not true. I've checked: all configs not involving compressed fs or diskfilter fit in 31K. and a 2048 sector embed area has been standard now for several years, so I don't think size is a problem. We're speaking abut GPT, nothing to do with MBR embed area. My problem with that is that it increases complexity a lot in currently simple code. And also I had experience with backup header out of place due to disk reconfiguration and primary header corrupted but still well enough to have valid partitions. I could boot this system by using gpt linux option. With proposed changes this system would become unbootable. Technically if the alternate is invalid by being in the wrong location (either end of disk or where the primary header says it should be located), and the header is also invalid because the header is corrupt, then the disk has an invalid GPT. So long as GRUB knows a valid MBR without an 0xEE entry means any found GPT is stale (or rather, simply doesn't go looking for the GPT), it seems possibly reasonable for GRUB to blindly use the primary partition table. If it fails, it fails, even if it's unfortunate there's no fallback to a valid alternate GPT. Maybe someone could argue it's a security problem for an invalid GPT being used despite being invalid? Also, I have some evidence that newer Apple EFI firmware are repairing these cases. I have one older computer that I can consistently corrupt, and it remains corrupted through boot, even to the degree the (linux) kernel face plants by default if the primary header or table is corrupt, unless the gpt kernel parameter is used. Yet a newer computer boots without the kernel complaining, and upon startup completion the GPT is fixed. Identically performed installations were performed in those cases. So maybe it can be argued the firmware has a role to play in fixing up GPT? Or maybe this is a hideously bad idea for firmware, which as we know is slightly less than massively bug ridden, to have such write privileges to the disk. Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub mishandles corrupt/missing primary GPT
On Dec 9, 2013, at 5:55 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: On 10.12.2013 01:11, Chris Murphy wrote: Technically if the alternate is invalid by being in the wrong location (either end of disk or where the primary header says it should be located), and the header is also invalid because the header is corrupt, then the disk has an invalid GPT. So long as GRUB knows a valid MBR without an 0xEE entry means any found GPT is stale (or rather, simply doesn't go looking for the GPT), it seems possibly reasonable for GRUB to blindly use the primary partition table. If it fails, it fails, even if it's unfortunate there's no fallback to a valid alternate GPT. It's already the case. Probably the real remaining points are: - Should we use backup headers under some conditions? It would be nice. But if not by validating at least the table checksum, how? I don't know how big the CRC32 code is in comparison to code needed to evaluate the table some with some heuristic approach. Also it seems like a bit flip of the most important partition data, the needed partition's start sector value (is the end value needed?) is a really rare case. The more likely scenario is some software alters the GPT and has a bad write or crash at that moment, in which case the cause of boot failure isn't a complete mystery. - Should msdos partitions be visible? Always? When it's not a PMBR? Or when GPT is corrupt? I suggest parsing LBA 0 first for a conventional MBR, if it is, don't even parse LBA1 looking for a GPT. If the MBR is either hybrid or PMBR, then parse the GPT. I don't think it's a good idea to get into a case where GRUB looks at both MBR and GPT and has to figure out which partitions to honor or ignore if they aren't in sync. Even in the constrained Apple OS X Boot Camp implementation there has been a lot of data loss due to missteps in interpreting hybrid MBRs. So maybe it can be argued the firmware has a role to play in fixing up GPT? Or maybe this is a hideously bad idea for firmware, which as we know is slightly less than massively bug ridden, to have such write privileges to the disk. Firmware writing to disk without being explicitly asked for it is a bugware or spyware. Yes I definitely find this really interesting behavior. If the firmware does have the ability to write, I wonder if an arbitrary EFI application could have write permission? If so, it seems like a potentially huge attack vector. I don't see what else could be repairing the GPT: computer firmware, SSD firmware, GRUB, linux kernel. I think GRUB and linux are out, otherwise one of them would have fixed the GPT on other hardware that used an identical installation source. Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub mishandles corrupt/missing primary GPT
On 10.12.2013 02:56, Chris Murphy wrote: On Dec 9, 2013, at 5:55 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: On 10.12.2013 01:11, Chris Murphy wrote: Technically if the alternate is invalid by being in the wrong location (either end of disk or where the primary header says it should be located), and the header is also invalid because the header is corrupt, then the disk has an invalid GPT. So long as GRUB knows a valid MBR without an 0xEE entry means any found GPT is stale (or rather, simply doesn't go looking for the GPT), it seems possibly reasonable for GRUB to blindly use the primary partition table. If it fails, it fails, even if it's unfortunate there's no fallback to a valid alternate GPT. It's already the case. Probably the real remaining points are: - Should we use backup headers under some conditions? It would be nice. But if not by validating at least the table checksum, how? I don't know how big the CRC32 code is in comparison to code needed to evaluate the table some with some heuristic approach. Also it seems like a bit flip of the most important partition data, the needed partition's start sector value (is the end value needed?) is a really rare case. The more likely scenario is some software alters the GPT and has a bad write or crash at that moment, in which case the cause of boot failure isn't a complete mystery. We need end value as well. Here the interesting part is that the data you need is about 1% of checksummed area, so in most cases checksum check gets more in the way than it helps. - Should msdos partitions be visible? Always? When it's not a PMBR? Or when GPT is corrupt? I suggest parsing LBA 0 first for a conventional MBR, if it is, don't even parse LBA1 looking for a GPT. If the MBR is either hybrid or PMBR, then parse the GPT. I don't think it's a good idea to get into a case where GRUB looks at both MBR and GPT and has to figure out which partitions to honor or ignore if they aren't in sync. Even in the constrained Apple OS X Boot Camp implementation there has been a lot of data loss due to missteps in interpreting hybrid MBRs. GRUB has handling of multiple partmap scenarios but it won't handle all the cases of desync correctly. E.g. partitions with same start but different end would be recognized as same UUID with most filesystems but the files may be unreadable in case of premature partition end. So maybe it can be argued the firmware has a role to play in fixing up GPT? Or maybe this is a hideously bad idea for firmware, which as we know is slightly less than massively bug ridden, to have such write privileges to the disk. Firmware writing to disk without being explicitly asked for it is a bugware or spyware. Yes I definitely find this really interesting behavior. If the firmware does have the ability to write, I wonder if an arbitrary EFI application could have write permission? If so, it seems like a potentially huge attack vector. I don't see what else could be repairing the GPT: computer firmware, SSD firmware, GRUB, linux kernel. I think GRUB and linux are out, otherwise one of them would have fixed the GPT on other hardware that used an identical installation source. Firmware has full write capability. BIOS, EFI, IEEE1275, ARC(S) all have disk write functions usable by bootloader U-Boot has only read functions. Remaining GRUB platforms have no disk functions and GRUB uses own drivers. Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] improve formatting and content of target list in grub-probe help
В Tue, 10 Dec 2013 00:55:06 +0100 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com пишет: On 07.12.2013 14:27, Andrey Borzenkov wrote: + ret = xasprintf (%s\n%s %s [default=%s], _(print TARGET), where does print come from?h You mean print as in print TARGET or as in `targets[print]'? + ret = xasprintf (%s\n%s %s [default=%s], _(print TARGET), + _(available targets:), t, targets[print]); The latter has always been there: static int print = PRINT_FS; static unsigned int argument_is_device = 0; signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
