Re: [PATCH 2/2] autogen.sh: Detect python
On 8/18/21 1:19 AM, Petr Vorel wrote: On Mon, Aug 09, 2021 at 01:52:29PM +0200, Daniel Kiper wrote: On Fri, Aug 06, 2021 at 08:45:08AM +0200, Petr Vorel wrote: It help to avoid error on distros which has only python3 binary: ./autogen.sh: line 20: python: command not found Using bash builtin 'command -v' to avoid requiring which as extra dependency (usable on containers). It looks the bash dependency is not specified in the INSTALL file in "The Requirements" section. May I ask you to add it? ...and python requirement is missing from the list too. Additionally, please update autogen.sh python usage in the INSTALL file. There is Python 2.6 or later, not sure if it still works on 2.6 (which is EOL) or it requires now 2.7). Actually all of Python 2 is EOL for the last year and a half. https://www.python.org/doc/sunset-python-2/ -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06
On 4/20/21 12:50 PM, Mike Gilbert wrote: On Tue, Apr 20, 2021 at 1:34 PM Didier Spaier wrote: So, it's hard to understand for many end users that: 1. The issue appeared after gcc-10 began to be used, well after the release of grub 2.04. 2. It has been fixed long ago. 3. But for the fix to be effective one of these conditions should be met: a. A new grub version has been released and is provided by the distribution they use. b. The distributon they use patches the source of GRUB 2.04 to bring the fix. c. The distribution they use provides a package build from a source pulled from with the patch already committed. Unfortunately if none of these conditions is met many users tend to blame GRUB instead of the distributions and go saying in fora "I'll avoid to use GRUB, it's broken" My 2 cents: If a distro starts shipping a new version of GCC, they should really test their packages first and patch them as needed. If an end user installs a new version of GCC manually, I would hope they are smart enough to know that it might break things. If an end user builds GRUB manually, they are also responsible for applying any patches that are necessary for their toolchain. And my two cents: Actively maintained packages like GRUB should make releases more often than every 2-4 years. GCC is on a schedule to produce stable releases twice a year. GRUB should release new stable releases at least as often. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06~rc1 released
On 3/12/21 5:48 PM, Bruce Dubbs wrote: On 3/12/21 5:25 PM, Glenn Washburn wrote: Hi Bruce, On Fri, 12 Mar 2021 15:30:01 -0600 Bruce Dubbs wrote: On 3/12/21 1:57 PM, Daniel Kiper wrote: [snip] For LFS, we do a very simple build in a sparse environment. Here are a few observations. We use: ./configure --prefix=/usr \ --sbindir=/sbin \ --sysconfdir=/etc \ --disable-efiemu \ --disable-werror [snip] I'm curious, what compiler and version are you using? $ gcc --version gcc (GCC) 10.2.0 $ bison --version bison (GNU Bison) 3.7.5 For make check, I get 43 failures. Many appear to be due to our sparse environment. In most cases I think these tests should be SKIP instead of FAIL, but I'll follow up with a more detailed report later. I'm looking forward to the report. I think ideally the tests should use a very minimal common set of utilities (with some obvious exceptions like qemu and mkfs.*). The tests should only SKIP if its not an appropriate test for the configured target. More likely, they should ERROR to indicated that there was a failure to run the test, not a failure of what the test was testing. This lets the tester know that there's likely an environmental issue that needs to be fixed to get tests working as they should. I'll note that several tests require being run as the root user. I cannot find where that is specified. I only figured that out by directly looking at the test scripts. When I build in a full LFS/BLFS system I get: # TOTAL: 82 # PASS: 67 # SKIP: 11 # XFAIL: 0 # FAIL: 4 # XPASS: 0 # ERROR: 0 The SKIPs are due to not having the expected executables. squashfs_test hfsplus_test minixfs_test f2fs_test nilfs2_test romfs_test exfat_test udf_test hfs_test zfs_test lzocompress_test This test depends on an lzop executable which in not a part of the xz-5.2.5 distribution. I found it is from a lzop source package which is new to us at LFS. I doubt many systems will have most of the the software needed for these tests, but perhaps a listing of what GRUB expects would be useful. The FAILing tests are a bit more troubling: reiserfs_test mount: /tmp/tmp.t6gBOmoH4g/reiserfs_old_rw: can't read superblock on /dev/loop0. MOUNT FAILED. I have reiserfsprogs-3.6.27 installed. fat_test mkfs.vfat: Labels with characters *?.,;:/\|+=<>[]" are not allowed mkfs.fat 4.2 (2021-01-31) FAIL fat_test (exit status: 1) I have dosfstools-4.2 installed. btrfs_test ERROR: invalid sectorsize 256, expected range is [4K, 64K] btrfs-progs v5.10.1 See http://btrfs.wiki.kernel.org for more information. FAIL btrfs_test (exit status: 1) I have btrfs-progs-v5.10.1 installed. grub_func_test FAIL grub_func_test (exit status: 1) I cannot determine from the test what is expected. It would appear that many of the GRUB regression test results are distro specific and not really GRUB tests. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06~rc1 released
On 3/12/21 5:25 PM, Glenn Washburn wrote: Hi Bruce, On Fri, 12 Mar 2021 15:30:01 -0600 Bruce Dubbs wrote: On 3/12/21 1:57 PM, Daniel Kiper wrote: Hi all, The GRUB maintainers are proud to announce the GRUB 2.06~rc1 that has been just released. Congratulations. For LFS, we do a very simple build in a sparse environment. Here are a few observations. We use: ./configure --prefix=/usr \ --sbindir=/sbin\ --sysconfdir=/etc \ --disable-efiemu \ --disable-werror That works cleanly. However there are two files that generate warnings: ./grub-core/script/parser.y:92.1-12: warning: deprecated directive: ‘%pure-parser’, use ‘%define api.pure’ [-Wdeprecated] 92 | %pure-parser | ^~~~ | %define api.pure ./grub-core/script/parser.y: warning: fix-its can be applied. Rerun with option '--update'. [-Wother] grub-core/lib/libgcrypt-grub/cipher/rijndael.c: In function ‘do_setkey’: grub-core/lib/libgcrypt-grub/cipher/rijndael.c:229:9: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] 229 | ; | ^ grub-core/lib/libgcrypt-grub/cipher/rijndael.c:352:21: warning: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Wsign-compare] 352 | for (i = 0; i < keylen; i++) | ^ It seems that the above is run twice by make, but the fixes are trivial. I'm curious, what compiler and version are you using? $ gcc --version gcc (GCC) 10.2.0 $ bison --version bison (GNU Bison) 3.7.5 For make check, I get 43 failures. Many appear to be due to our sparse environment. In most cases I think these tests should be SKIP instead of FAIL, but I'll follow up with a more detailed report later. I'm looking forward to the report. I think ideally the tests should use a very minimal common set of utilities (with some obvious exceptions like qemu and mkfs.*). The tests should only SKIP if its not an appropriate test for the configured target. More likely, they should ERROR to indicated that there was a failure to run the test, not a failure of what the test was testing. This lets the tester know that there's likely an environmental issue that needs to be fixed to get tests working as they should. That's an interesting perspective. To my mind the failure of a test can be due to a problem with the grub code, the grub test, or the environment of the test system. In my case I'm sure that most of the failures, if not all, are due to the test environment. In my full environment, I only have qemu-system-x86_64, so I'll need to fix that. I should have everything else needed, but need to double check. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06~rc1 released
On 3/12/21 1:57 PM, Daniel Kiper wrote: Hi all, The GRUB maintainers are proud to announce the GRUB 2.06~rc1 that has been just released. Congratulations. For LFS, we do a very simple build in a sparse environment. Here are a few observations. We use: ./configure --prefix=/usr \ --sbindir=/sbin\ --sysconfdir=/etc \ --disable-efiemu \ --disable-werror That works cleanly. However there are two files that generate warnings: ./grub-core/script/parser.y:92.1-12: warning: deprecated directive: ‘%pure-parser’, use ‘%define api.pure’ [-Wdeprecated] 92 | %pure-parser | ^~~~ | %define api.pure ./grub-core/script/parser.y: warning: fix-its can be applied. Rerun with option '--update'. [-Wother] grub-core/lib/libgcrypt-grub/cipher/rijndael.c: In function ‘do_setkey’: grub-core/lib/libgcrypt-grub/cipher/rijndael.c:229:9: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] 229 | ; | ^ grub-core/lib/libgcrypt-grub/cipher/rijndael.c:352:21: warning: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Wsign-compare] 352 | for (i = 0; i < keylen; i++) | ^ It seems that the above is run twice by make, but the fixes are trivial. For make check, I get 43 failures. Many appear to be due to our sparse environment. In most cases I think these tests should be SKIP instead of FAIL, but I'll follow up with a more detailed report later. -- Bruce linuxfromscratch.org ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [SECURITY PATCH 000/117] Multiple GRUB2 vulnerabilities - 2021/03/02 round
On 3/2/21 1:37 PM, John Paul Adrian Glaubitz wrote: Hi Daniel! On 3/2/21 7:00 PM, Daniel Kiper wrote: The BootHole vulnerability [1][2] announced last year encouraged many people to take a closer look at the security of boot process in general and the GRUB bootloader in particular. Due to that, during past few months we were getting reports of, and also discovering various security flaws in the GRUB ourselves. You can find the list of most severe ones which got CVEs assigned at the end of this message. The patch bundle fixing all these issues in the upstream GRUB contains 117 patches. Huge thanks and kudos to everyone involved fixing all these vulnerabilities! Given the amount of patches, wouldn't it make sense to push an RC candidate for 2.06 in the near future so that distributions can start shipping the pre- release and avoiding to carry this large amount of patches? It makes sense to not rely on distros to do the job of GRUB. It's time to get on a release schedule and stick to it. Very complex packages like gcc, glibc, and binutils are on a six month schedule. Why not GRUB? From https://ftp.gnu.org/gnu/grub/: grub-1.99.tar.gz2011-05-14 grub-2.00.tar.gz2012-06-27 grub-2.02.tar.gz2017-04-26 grub-2.04.tar.gz2019-07-05 grub-2.06.tar.gz202?-??-?? If you are waiting for perfection, you will never get there. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
GRUB release schedule?
Is there a release schedule for the next stable version of GRUB? It would help for planning purposes. -- Bruce LFS ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 08/12] kern: Make grub_error() more verbose
On 3/6/20 11:03 AM, David Michael wrote: On Fri, Mar 6, 2020 at 9:02 AM Didier Spaier wrote: Le 06/03/2020 à 13:43, Daniel Kiper a écrit : If we go that way then we have to care about them by the end of the universe. And this means more and more issues like [1]. If somebody wants to use new GRUB then he/she have to reinstall the machine or something like that. IMO we should not care about users who do not want upgrade their machines or whatnot. Or at least their choices cannot impact GRUB development too much. And I think that this MBR constraint is hindering the project too much at this point. So, as above... Sorry for being blunt... Sorry to be off topic... In case of a GUID partition table, if I understand the UEFI specification[1], as the first usable LBA should be greater than or equal to 34 for a 512 bytes block size or 6 for a 4096 bytes logical block size, it could begin after a gap of 24K. Then, if we assume that the first partition begins @ 1MiB, can't GRUB use the space unused between the first usable LBA and 1MiB instead of a Bios Boot partition, in case of "legacy" booting and a GPT? I ask as then a Bios Boot partition wouldn't be necessary any more. It would be best to use a boot partition so the core.img space is reserved by the GPT, Just a terminology issue here. Please don't call it a boot partition. It conflicts with those who mount /boot as a separate partition. Please call it a grub partition. -- Bruce but I once wanted to tack i386-pc GRUB onto an existing UEFI GPT disk, so I wrote the commands that do what you're describing here: https://github.com/dm0-/installer/blob/master/examples/systems/fitpc.sh#L151-L178 I may be misremembering, but I think the core.img size was limited to around half a megabyte, so it should be safe to write it to the unused ~1MiB before the first partition after the GPT. But yes, using the boot partition would probably be for the best if you are formatting a new disk. Thanks. David ___ 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: gcc9.1 and f2fs
On 5/17/19 2:13 AM, Michael Chang wrote:
Hello John,
Except for lacking commit message and SOB, the fix is LGTM.
[snip]
---
grub-core/fs/f2fs.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/grub-core/fs/f2fs.c b/grub-core/fs/f2fs.c
index 1cad2615f..0dd09bc23 100644
--- a/grub-core/fs/f2fs.c
+++ b/grub-core/fs/f2fs.c
@@ -1235,6 +1235,12 @@ grub_f2fs_utf16_to_utf8 (grub_uint16_t *in_buf_le)
return out_buf;
}
+
+#if __GNUC__ >= 9
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Waddress-of-packed-member"
+#endif
+
static grub_err_t
grub_f2fs_label (grub_device_t device, char **label)
{
@@ -1255,6 +1261,10 @@ grub_f2fs_label (grub_device_t device, char **label)
return grub_errno;
}
+#if __GNUC__ >= 9
+#pragma GCC diagnostic pop
+#endif
+
static grub_err_t
grub_f2fs_uuid (grub_device_t device, char **uuid)
{
I would like to point out that it is not a good idea to make a stable
release using -Werror as a default. It is fine for development, but
grub has traditionally taken a long time between stable releases
(version 2.00 was in 2012 and version 2.02 was in 2017). After
release, a new version of a compiler has a high probability of producing
more warnings, which will break the build if using -Werrror.
At linuxfromscratch we add --disable-werror, but it really shouldn't be
needed.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: gcc9.1 and f2fs
On 5/6/19 12:15 PM, Neil MacLeod wrote: With the latest grub HEAD (620857c4dccb8f0548cdb855f6b2f46ebea3919e) I'm getting the following compilation error with gcc-9.1: /home/ubuntu/projects/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel/toolchain/bin/x86_64-libreelec-linux-gnu-gcc -DHAVE_CONFIG_H -I. -Wall -W -DGRUB_UTIL=1 -D_FILE_OFFSET_BITS=64 -I./include -DGRUB_FILE=\"grub-core/fs/xfs.c\" -I. -I. -I. -I. -I./include -I./include -I./grub-core/lib/libgcrypt-grub/src/ -I./grub-core/lib/minilzo -I./grub-core/lib/xzembed -I./grub-core/lib/zstd -DMINILZO_HAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -fno-builtin-gettext -Wall -W -Wshadow -Wpointer-arith -Wundef -Wchar-subscripts -Wcomment -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wfloat-equal -Wformat-extra-args -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-braces -Wmissing-format-attribute -Wmultichar -Wparentheses -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wswitch -Wtrigraphs/error -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value -Wunused-variable -Wwrite-strings -Wnested-externs -Wstrict-prototypes -Wcast-align -Wextra -Wattributes -Wendif-labels -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wmissing-field-initializers -Wnonnull -Woverflow -Wvla -Wpointer-to-int-cast -Wstrict-aliasing -Wvariadic-macros -Wvolatile-register-var -Wpointer-sign -Wmissing-include-dirs -Wmissing-prototypes -Wmissing-declarations -Wformat=2 -Werror -fno-builtin -Wno-undef -I/home/ubuntu/projects/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel/toolchain/x86_64-libreelec-linux-gnu/sysroot/usr/include -fomit-frame-pointer -D_FILE_OFFSET_BITS=64 -MT grub-core/fs/libgrubmods_a-xfs.o -MD -MP -MF grub-core/fs/.deps-util/libgrubmods_a-xfs.Tpo -c -o grub-core/fs/libgrubmods_a-xfs.o `test -f 'grub-core/fs/xfs.c' || echo './'`grub-core/fs/xfs.c grub-core/fs/f2fs.c: In function 'grub_f2fs_label': grub-core/fs/f2fs.c:1248:60: error: taking address of packed member of 'struct grub_f2fs_superblock' may result in an unaligned pointer value [-Werror=address-of-packed-member] 1248 | *label = (char *) grub_f2fs_utf16_to_utf8 (data->sblock.volume_name); |^~~~ cc1: all warnings being treated as errors make[3]: *** [Makefile:6943: grub-core/fs/libgrubmods_a-f2fs.o] Error 1 make[3]: *** Waiting for unfinished jobs Does anyone have a patch? Full build log: http://ix.io/1Iet Try building with ./configure ... --disable-werror -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.04 RC01 released
On 4/9/19 5:53 AM, Vladimir 'phcoder' Serbinenko wrote: Hello all. GRUB maintainers team is proud to announce 2.04~rc1 that we have just released. We’re not aware of any of the release-critical bugs but we’re sure that there are some so we need your help finding them. The tarball is available at http://alpha.gnu.org/gnu/grub/grub-2.04~rc1.tar.xz The -rc1 package builds and works fine in an LFS environment. Please note that our environment is quite limited: GRUB2 will be compiled with following components: Platform: i386-pc With devmapper support: No (need libdevmapper header) With memory debugging: No With disk cache statistics: No With boot time statistics: No efiemu runtime: No (explicitly disabled) grub-mkfont: No (need freetype2 library) grub-mount: No (need FUSE library) starfield theme: No (No build-time grub-mkfont) With libzfs support: No (need zfs library) Build-time grub-mkfont: No (need freetype2 library) Without unifont (no build-time grub-mkfont) With liblzma from -llzma (support for XZ-compressed mips images) I note two warnings using gcc8 if you want to address them: grub-core/lib/libgcrypt-grub/cipher/rijndael.c: In function 'do_setkey': grub-core/lib/libgcrypt-grub/cipher/rijndael.c:229:9: warning: suggest braces around empty body in an 'if' statement [-Wempty-body] ; ^ grub-core/lib/libgcrypt-grub/cipher/rijndael.c:352:21: warning: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare] for (i = 0; i < keylen; i++) I have one question. When do you expect to release the stable grub-2.04 version of GRUB? -- Bruce Dubbs linuxfromscratch.org ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
GRUB version numbering.
I have been following the grub-devel list for many years. It is my understanding that release of the next stable version of GRUB is imminent. That is great. grub-1.99 was in 2011, grub-2.00 in 2012, and grub-2.02 in 2017. May I suggest that the number of changes introduced in the last two years indicate a more substantive number bump. Generally most open source packages have a numbering scheme in the form of major.minor.patch. Would the changes introduced be sufficient to create the next stable version to be 3.0.0? Or perhaps 2.1.0? This would provide users an indication of the scope of the change just by looking at the version number. It would also encourage more rapid releases as new functionality is put into the package or bugs are fixed. Don't get me wrong. Packages can release too frequently from my perspective. Indeed, the Linux kernel outputs about two 'stable' releases a week. That is hardly 'stable'. For a package like GRUB, a release every six months on a schedule would be ideal, but that may not be best for this package. In any case, I appreciate and consideration you may give to this proposal. -- Bruce Dubbs linuxfromscratch.org ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
bash completions in GRUB
It appears that GRUB is not consistent with other applications when installing the bash completions script. I suggest the following patch: diff --git a/util/bash-completion.d/Makefile.am b/util/bash-completion.d/Makefile.am index 136287cf1..a15bef9c9 100644 --- a/util/bash-completion.d/Makefile.am +++ b/util/bash-completion.d/Makefile.am @@ -6,7 +6,7 @@ EXTRA_DIST = $(bash_completion_source) CLEANFILES = $(bash_completion_script) config.log -bashcompletiondir = $(sysconfdir)/bash_completion.d +bashcompletiondir = /usr/share/bash-completion/completions bashcompletion_DATA = $(bash_completion_script) $(bash_completion_script): $(bash_completion_source) $(top_builddir)/config.status -- We do have a simple workaround by just moving the file after installation, but that shouldn't be needed. Also, is there a new stable release being planned? If so is there a target date? The last release was April 2017. -- Bruce Dubbs linuxfromscratch.org ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2-common: grub.cfg gains wrong root settings for multi-OS system
Andrei Borzenkov wrote:
23.04.2017 08:43, Ralph Ronnquist пишет:
For all installs, I made it mount /dev/sda1 at /boot but only the
first install formatted it.
Shared /boot never worked reliably. With or without grub. Sorry.
It works perfectly if you don't use grub-mkconfig. For those using
multiple kernels/partitions, grub.config can be quite simple to maintain
with an editor.
http://www.linuxfromscratch.org/lfs/view/stable/chapter08/grub.html
That page shows a 7 line grub.cfg. For a new system you only need to add:
menuentry "New title" {
linux / root=/dev/ ro
}
An initrd line is only needed if you need an initial ram disk.
You do need to keep a backup as distros always want to overwrite grub.cfg
by running grub-mkconfig.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Grub 2.02
Is there an estimated time frame for the release of the stable 2.02 version of grub? The Linux From Scratch project is planning a new release around March 1st and would really like to update to a grub stable release. -- Bruce Dubbs linuxfromscratch.org ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bugs and tasks for 2.02[~rc1]
Vladimir 'phcoder' Serbinenko wrote: Hello, all. I went through the list of bugs and created a shortlist of bugs that need to be looked at for 2.02. I have marked them with plan_release_id set to 2.02. [snip] I would like to come up with a complete list of 2.02 blockers in one week time, so that we can have a reasonable timeline Is there an updated list of blockers? Is there a time estimate for the 2.02 release? -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fwd: RE: GRUB release schedule?
Any progress on this? Vladimir 'phcoder' Serbinenko wrote: -- Message transféré -- De : "Vladimir 'phcoder' Serbinenko" Date : 4 janv. 2016 10:40 PM Objet : RE: GRUB release schedule? À : "Elliott, Robert (Persistent Memory)" Cc : I'm currently running tests in order to make next beta. I see quite some failures and try to sort them out ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB release schedule?
Konrad Rzeszutek Wilk wrote: On Fri, Aug 21, 2015 at 09:24:33PM +0300, Andrei Borzenkov wrote: GRUB includes comprehensive amount of regression tests. Just run "make check". The practical problems are - many tests require additional tools (filesystem tests need at least mkfs for respective file system, LVM etc) - each platform must be built separately; that requires either native system or cross tools (which itself may not be trivial). So I e.g. am limited to x86 - tests are not really formalized, you get PASS/FAIL but what failed is up to human to understand - some tests require server part, e.g. to run anything involving HTTP server must be available - some tests are pretty heavy hit; it is better now when I have new hardware still I cannot dream running them continuously on my notebook ... Of course addition to regression testing is always welcome. Lets start with a list of priorities: - What are the most important platforms after x86? - What are the most important tests that MUST PASS all the time? - Which ones have been FAILing for years? Surely if we weed out the most important cases that cover 99% that will give the foundation for going out with a release? Although tests are very useful, not all packages ship tests. One prime example is the linux kernel, but there are many more. Tests depend on external programs and specific setups used by the developers, but often are not available on builder's systems. For example, in grub-2.02~beta2, I get: Testsuite summary for GRUB 2.02~beta2 # TOTAL: 78 # PASS: 12 # SKIP: 18 # XFAIL: 0 # FAIL: 48 # XPASS: 0 # ERROR: 0 That doesn't mean that the build is bad on a x86_64 system. It works quite well (although grub-mkconfig always produces an unusable configuration for us.) A lot of the FAILs are due to things like: FAIL: iso9660_test == cp: cannot stat '/usr/share/dict/linux.words': No such file or directory although I have other dictionaries. FAIL: pata_test === tar: Removing leading `/' from member names timeout: failed to run command 'qemu-system-i386': No such file or directory Although I have /usr/bin/qemu -> qemu-system-x86_64 This corresponds to 45 of the 48 "FAILs" above. Creating a symlink qemu-system-i386 to qemu-system-x86_64 allows most ot the tests to pass, but hangs after test_unset. In other words, the tests are highly sensitive to the user's system. Please do not let the tests shipped in the tarball hold up a release. Perfect is the enemy of good enough. -- Bruce Dubbs linuxfromscratch.org ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB release schedule?
Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 20.07.2015 21:25, Vladimir 'phcoder' Serbinenko wrote: I'll do next beta tomorrow and will assess current open bugs to see how far we're from release Fixing tests takes longer than expected. I'll continue tomorrow. Any more on this? Le 20 juil. 2015 20:23, "Peter Jones" mailto:pjo...@redhat.com>> a écrit : Hi everyone, Is there a plan for when upcoming GNU GRUB releases will happen? As far as I can tell, the last official release on ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta on http://alpha.gnu.org/pub/gnu/grub/ for the next version was 2.02~beta2 on 24-Dec-2013 . There are (give or take) 471 patches committed since that beta 18 months ago. In the mean time, nearly every Linux distro is shipping a package derived from the 2.02~beta2 release plus some number of patches, some from the upstream repo and some not, and it's cumbersome to rectify which ones aren't upstream vs which ones have been fixed upstream with /nearly/ the same patch, etc., with all the noise of so many patches since the release. I suspect this would be better for a lot of GRUB users if releases happened on a regular schedule, or if, relatively often (say once or twice per year), a release schedule that spans several weeks and organized some kind of alpha->beta->release progression were decided upon and followed. I agree. -- Bruce Dubbs linuxfromscratch.org ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: initrd loading, max size, addr_min, and page_align
Andrei Borzenkov wrote: В Sun, 08 Feb 2015 11:14:28 -0600 Bruce Dubbs пишет: Andrei Borzenkov wrote: В Thu, 5 Feb 2015 21:55:54 + Eric Ewanco пишет: Background: I need to use a really large initrd for x86_64 (Linux 3.4.47), and I'm near the limit, so I'm studying grub-core/loader/i386/linux.c to find out the whys and wherefores of the GRUB 2.00 size limit. GRUB 2.00 is way too old. But as far as I know grub-2.00 is the last "stable" release. There is the more current grub-2.02~beta2 that was released over a year ago, but some people prefer releases that upstream has designated as stable. If you want to discuss a problem on development list, you should at least verify if this problem exists in current code. I agree. In practice all ditros I'm aware of are using at least 2.02~beta2 or what effectively amounts to git snapshot. Indeed. We have gone to 2.02~beta2 also, although we prefer it when upstream labels a packages as stable. Has grub gone to a policy of git snapshots only and forgone stable releases? I do not think it is intentional. There are several packages that do not release stable releases but only snapshots (but it is uncommon), however AFAIK grub is one of the very few active packages that does not seem to have a regularly scheduled release process. It would actually help us if you just said that you are not going to designate stable, release candidate, beta, etc tarballs any more and it's up to the distro or individual to figure out what version to extract from version control. -- Bruce Dubbs LFS ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: initrd loading, max size, addr_min, and page_align
Andrei Borzenkov wrote: В Thu, 5 Feb 2015 21:55:54 + Eric Ewanco пишет: Background: I need to use a really large initrd for x86_64 (Linux 3.4.47), and I'm near the limit, so I'm studying grub-core/loader/i386/linux.c to find out the whys and wherefores of the GRUB 2.00 size limit. GRUB 2.00 is way too old. But as far as I know grub-2.00 is the last "stable" release. There is the more current grub-2.02~beta2 that was released over a year ago, but some people prefer releases that upstream has designated as stable. Has grub gone to a policy of git snapshots only and forgone stable releases? -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
grub-2.02-beta
I believe the grub-2.02-beta was announced last December. Are there any plans to do a "stable" release any time soon? -- Bruce Dubbs linuxfromscratch.org ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
What is the status of grub-2.02
grub-2.02~beta2 was released in December. What are the current plans for another beta or a stable release? -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-2.02~beta1 happened
Vladimir 'φ-coder/phcoder' Serbinenko wrote: Hello, all. I've just uploaded 2.02~beta1. This also means that we're now in freeze. I'm willing to consider exceptions on case-by-case basis but it would be exceptions. The major points to do before release: - ARM64 loader. - Yeeloong 3A support needs some love. - XEN would probably need config adjustments. - XNU loader needs fixes. - NEWS needs contents. - Documentation. - Loads and loads of testing and some bugfixes. There are a few warnings for rijndael.c with gcc 4.8.2. A couple of them are pretty trivial. Others probably should be turned off with -Wno-strict-aliasing. Do you want a patch? If so, is the following acceptable? #pragma GCC diagnostic ignored "-Wstrict-aliasing" -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-mkimage and other utils documentation
Andrey Borzenkov wrote:
I started to clean --pubkey in docs, hit grub-mkimage reference, hit
"grub-install is just a shell script" ... it really needs cleanup. Is
grub-install terse description intentional? If not, I'm going to
actually document all utilities and all options not defined as hidden.
We probably need to mention common options between various utilities
as well.
Or should some tools be skipped? I'm fine to document them in
grub-devel though, but I'd like to have them documented /somewhere/.
Things that can be run by a user or admin should be in the main
documentation. Those things run by a developer for
building/testing/debugging, etc should be in grub-devel.
I'd put any program that is installed in the file system
/{,usr/}{,s}bin directories in the category of admin.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB Manual Broken Link
Andrey Borzenkov wrote:
В Fri, 15 Nov 2013 10:04:15 -0600
Bruce Dubbs пишет:
I was notified by the GNU webmaster that he is getting complaints about
the manual at http://www.gnu.org/software/grub/manual/grub.html having a
broken link:
http://www.gnu.org/software/grub/manual/multiboot.html#Top
It should be
http://www.gnu.org/software/grub/manual/multiboot/multiboot.html
Although I do update the web information pages, I don't have a way to
update the main GRUB manual. I'm not sure, but I think Colin updated
the current manual (which is still listed as Manual 2.00~rc1).
Can we get this manual updated?
The bug is not in manual. Link is generated by texinfo when converting
grub.texi to HTML. It just need to be regenerated with correct texinfo
version that knows how to translate multiboot link. See message below:
From: Andrey Borzenkov
To: webmasters-comm...@gnu.org
Subject: Re: [gnu.org #832039] 404
Date: Fri, 31 May 2013 20:13:59 +0400
X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.18; x86_64-suse-linux-gnu)
В Wed, 29 May 2013 11:43:14 -0400
"Ineiev via RT" пишет:
[arvidj...@gmail.com - Wed May 29 01:28:37 2013]:
I'm not sure how. texinfo external references supports only base file
name and assume that everything is located on the same level.
Recent texinfo versions (5.0 and later) come with a database of
root URLs for different manuals; I'm not sure the manual you need
is included, but I think you could try (or at least ask on
bug-texinfo).
Which just confirms - it needs fixing elsewhere, not in grub2 sources :)
Assuming current web layout, it would be this patch below and grub
manual must be regenerated by texinfo 5.x that includes this patch. I'm
not really feel to be competent enough to submit this patch myself - I
simply do not know how web location is decided.
Index: util/htmlxref.cnf
===
--- util/htmlxref.cnf (revision 5259)
+++ util/htmlxref.cnf (working copy)
@@ -459,6 +459,9 @@
mtoolsmono${GS}/mtools/manual/mtools.html
+multiboot mono${GS}/grub/manual/multiboot/multiboot.html
+multiboot node${GS}/grub/manual/multiboot/html_node/
+
myserver nodehttp://www.myserverproject.net/documentation/
nano monohttp://www.nano-editor.org/dist/latest/nano.html
For now I made a hack to change the href entry in the html directly but
I didn't regenerate all the docs.
The latest version of texinfo is 5.2 and that does not have the patch
above, but the file says the latest is at
http://ftpmirror.gnu.org/texinfo/htmlxref.cnf. That file *does* have the
patch.
Rebuilding texinfo with the latest htmlxref.cnf does fix the problem.
There are a couple of warnings though. I'm using the GRUB-2.0.0 release
version since that's the latest official release and don't know if they
have been fixed in git or not.
Speaking of official releases, has there been any thought into a new
stable release of GRUB? It's been a while since 2.0 was released.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB Manual Broken Link
Andrey Borzenkov wrote:
В Fri, 15 Nov 2013 10:04:15 -0600
Bruce Dubbs пишет:
I was notified by the GNU webmaster that he is getting complaints about
the manual at http://www.gnu.org/software/grub/manual/grub.html having a
broken link:
http://www.gnu.org/software/grub/manual/multiboot.html#Top
It should be
http://www.gnu.org/software/grub/manual/multiboot/multiboot.html
Although I do update the web information pages, I don't have a way to
update the main GRUB manual. I'm not sure, but I think Colin updated
the current manual (which is still listed as Manual 2.00~rc1).
Can we get this manual updated?
The bug is not in manual. Link is generated by texinfo when converting
grub.texi to HTML. It just need to be regenerated with correct texinfo
version that knows how to translate multiboot link. See message below:
From: Andrey Borzenkov
To: webmasters-comm...@gnu.org
Subject: Re: [gnu.org #832039] 404
Date: Fri, 31 May 2013 20:13:59 +0400
X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.18; x86_64-suse-linux-gnu)
В Wed, 29 May 2013 11:43:14 -0400
"Ineiev via RT" пишет:
[arvidj...@gmail.com - Wed May 29 01:28:37 2013]:
I'm not sure how. texinfo external references supports only base file
name and assume that everything is located on the same level.
Recent texinfo versions (5.0 and later) come with a database of
root URLs for different manuals; I'm not sure the manual you need
is included, but I think you could try (or at least ask on
bug-texinfo).
Which just confirms - it needs fixing elsewhere, not in grub2 sources :)
Assuming current web layout, it would be this patch below and grub
manual must be regenerated by texinfo 5.x that includes this patch. I'm
not really feel to be competent enough to submit this patch myself - I
simply do not know how web location is decided.
Index: util/htmlxref.cnf
===
--- util/htmlxref.cnf (revision 5259)
+++ util/htmlxref.cnf (working copy)
@@ -459,6 +459,9 @@
mtoolsmono${GS}/mtools/manual/mtools.html
+multiboot mono${GS}/grub/manual/multiboot/multiboot.html
+multiboot node${GS}/grub/manual/multiboot/html_node/
+
myserver nodehttp://www.myserverproject.net/documentation/
nano monohttp://www.nano-editor.org/dist/latest/nano.html
OK. I do have texinfo 5.1 and I see now where that manual is located.
on the web site I'll see if I can get it fixed.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
GRUB Manual Broken Link
I was notified by the GNU webmaster that he is getting complaints about the manual at http://www.gnu.org/software/grub/manual/grub.html having a broken link: http://www.gnu.org/software/grub/manual/multiboot.html#Top It should be http://www.gnu.org/software/grub/manual/multiboot/multiboot.html Although I do update the web information pages, I don't have a way to update the main GRUB manual. I'm not sure, but I think Colin updated the current manual (which is still listed as Manual 2.00~rc1). Can we get this manual updated? -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] update grub web page with reference to GIT instead of bzr.
Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 27.10.2013 17:23, Bruce Dubbs wrote: If you do have commit privs, please do not update the html directly. I do not know until I try :) Feel free to commit. I'll do that, but would like confirmation. Vladimir, does this look OK to you? Yes, it does. Thanks for taking care of this. OK, updated. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] update grub web page with reference to GIT instead of bzr.
Andrey Borzenkov wrote: В Sun, 27 Oct 2013 11:02:09 -0500 Bruce Dubbs пишет: Andrey Borzenkov wrote: В Sun, 27 Oct 2013 19:24:28 +0400 Andrey Borzenkov пишет: That's where website lags behind. GRUB switched to GIT a while ago. See https://savannah.gnu.org/git/?group=grub As for web site - I do not know; Vladimir, who can edit this? Not sure if I can commit, but - does below look sane? The files are actually maintained via templates and a Makefile to attach headers and footers that can be updated easily. The file that you want to change is templates/grub-download.body. Usually generated files are not placed under SCM control ... thank you for the hint. That's what I inherited, but the web site works directly off the commits so I think it's needed. If you do have commit privs, please do not update the html directly. I do not know until I try :) Feel free to commit. I'll do that, but would like confirmation. Vladimir, does this look OK to you? -- Bruce Index: templates/grub-download.body === RCS file: /web/grub/grub/templates/grub-download.body,v retrieving revision 1.1 diff -u -p -r1.1 grub-download.body --- templates/grub-download.body5 Jan 2012 23:35:45 - 1.1 +++ templates/grub-download.body27 Oct 2013 16:09:34 - @@ -8,29 +8,18 @@ site ftp://ftp.gnu.org/gnu/grub All the development is done through a http://bazaar.canonical.com/"; >Bazaar repository. If you are +href="http://git-scm.com/"; >GIT repository. If you are interested in the cutting-edge version of GNU GRUB, for example, to test a newer version or to add new features, we strongly recommend giving the latest repository version a try. You can obtain the latest GRUB source from the -Bazaar: +GIT: -bzr branch http://bzr.savannah.gnu.org/r/grub/trunk/grub +git clone git://git.savannah.gnu.org/grub.git For developers with write access via ssh, use: -bzr branch bzr+ssh://<membername>@bzr.savannah.gnu.org/grub/trunk/grub +git clone <membername>@git.sv.gnu.org:/srv/git/grub.git -You can also use scp and rsync if needed. - -In the Bazaar repository, a number of other development trees may be found. -Notably the experimental branch of GRUB is a staging area where less tested (or -more intrusive) changes are put before they are merged into trunk. - - -Other branches are listed at the GRUB http://bzr.savannah.gnu.org/r/grub/branches/";>branch index and http://bzr.savannah.gnu.org/r/grub/people/";>individual developer -repositories. These branches are not browsable, but can be checked -out with Bazaar. +You can also use HTTP if needed. [% INCLUDE footer %] ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] update grub web page with reference to GIT instead of bzr.
Andrey Borzenkov wrote: В Sun, 27 Oct 2013 19:24:28 +0400 Andrey Borzenkov пишет: That's where website lags behind. GRUB switched to GIT a while ago. See https://savannah.gnu.org/git/?group=grub As for web site - I do not know; Vladimir, who can edit this? Not sure if I can commit, but - does below look sane? The files are actually maintained via templates and a Makefile to attach headers and footers that can be updated easily. The file that you want to change is templates/grub-download.body. If you do have commit privs, please do not update the html directly. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: BUGS: btrfs multi-device support fixes
Andrey Borzenkov wrote:
В Sun, 27 Oct 2013 10:47:45 -0400
Gene Czarcinski пишет:
On 10/27/2013 02:54 AM, Andrey Borzenkov wrote:
В Sat, 26 Oct 2013 16:16:19 -0400
Gene Czarcinski пишет:
On 10/26/2013 12:27 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Rejected, similar patches is in trunk since some time.
Thanks. I was not aware that the problem had been addressed. Can you
point me where to look to see what has been addressed?
This is commit 588744d0dc655177d5883bdcb8f72ff5160109ed.
And that sure looks like something I would expect to see from a git
repository!
Look, I am not stupid but I sure am confused! The grub2 website
(http://www.gnu.org/software/grub/) says that all grub2 development done
through bazaar repository and that you get a copy of the latest grub2
source with: |
bzr branch http://bzr.savannah.gnu.org/r/grub/trunk/grub|
Well, I tried doing that and all I get is an error saying: "bzr: ERROR:
Not a branch:"
That's where website lags behind. GRUB switched to GIT a while ago. See
https://savannah.gnu.org/git/?group=grub
As for web site - I do not know; Vladimir, who can edit this?
I can edit it, but I thought the git site was still under
development/testing. Is the url above the best current value?
-- Bruce
Now fedora has a local git repository for grub2 located here:
git://pkgs.fedoraproject.org/grub2.git and when I look at what is there
I see that the updates (when they come in) appear to be in git format.
On other little thing. I I sent this current message there were TWO bug
fixes (TWO patch files). I well believe that the first one was already
in trunk since I had originally reported that problem in January 2013.
The reason I reported it again is because it had not been pick up by fedora.
However, there is that second bug fix which I only recently found and
fixed. This problem occurs when you have /boot on BTRFS either as a
separate subvolume or simply as directory under the root subvolume. In
10_linux, when grub2-probe is call for hint, it returns multi-device
hints separated by "\n" which completely screws things up. The patch is:
diff --git a/util/grub-probe.c b/util/grub-probe.c
index a46f0b1..dd5de00 100644
--- a/util/grub-probe.c
+++ b/util/grub-probe.c
@@ -543,7 +543,7 @@ probe (const char *path, char **device_names, char
delim)
print_full_name (map, dev);
printf ("' ");
}
- printf ("\n");
+ printf (" "); /* new-line causes problems for multi-device btrfs
volumes */
grub_device_close (dev);
continue;
___
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: [RFC] Moving from Bazaar (bzr) to git
Paul Menzel wrote: Dear GRUB folks, this is *not* the start of a flame war about what VCS is the best. Hopefully everyone will agree, that git is the most popular one in the FOSS world (Linux, freedesktop.org, GNOME, KDE, …) and a lot of people are now familiar with the basic git commands. So using Bazaar is one more thing to deal with for new contributors before making a contribution to GRUB. (I know there is git-bzr-ng, but it is still one more step.) Talking to Vladimir and Colin in #grub, they did not oppose a migration to git and Vladimir asked me to bring it up on the list. Personally, I prefer subversion, but I'm not a GRUB developer. The choice of version control can be similar emacs/vi or Bourne Shell/C Shell, so it really should be the choice of the primary developers. Using Google for 'git vs subversion' provides a lot of interesting opinions. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Support for UEFI ESP in os-prober
Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 05.06.2013 19:58, Andrey Borzenkov wrote: В Wed, 05 Jun 2013 12:21:54 -0500 Bruce Dubbs пишет: Mads Kiilerich wrote: On 05/31/2013 07:03 PM, Bruce Dubbs wrote: Vladimir 'φ-coder/phcoder' Serbinenko wrote: I must say I'm generally disappointed with os-prober and have ideas to move away from it. I'll start another topic for it. I agree. I would prefer adding an include command so grub.cfg could just do something like: include /boot/grub/grub.d/*.cfg and have an install procedure drop in one or more menu items instead of every os install or update rewriting the entire grub.cfg every time. http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ describes such a configuration structure, and http://pkgs.fedoraproject.org/cgit/grub2.git/plain/0362-blscfg-add-blscfg-module-to-parse-Boot-Loader-Specif.patch implements it as a grub command. Although that's a good start, it seems a little too specific. What I had in mind would be the equivalent to the source command in bash. grub already has "source" command. For example, if condition; then include (hd0,3)/grub/custom/themes/themeA.cfg else include (hd0,2)/boot/grub/themes/themeB.cfg fi # Get menuentries include /boot/grub/grub.d/*.cfg Implementing full-fledged globbing in grub is probably overkill; adding "source_dir" command looks more doable. Something like We already have globbing. Trouble with this approach is that ->dir method may be slow or (especially on network systems) absent. It should not be relied upon unless absolutely necessary. This reminds me of the phrase "perfect is the enemy of good". What percentage of systems rely on network capabilities for booting? source_dir --suffix .cfg /boot/grub/grub.d ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Support for UEFI ESP in os-prober
Mads Kiilerich wrote: On 05/31/2013 07:03 PM, Bruce Dubbs wrote: Vladimir 'φ-coder/phcoder' Serbinenko wrote: I must say I'm generally disappointed with os-prober and have ideas to move away from it. I'll start another topic for it. I agree. I would prefer adding an include command so grub.cfg could just do something like: include /boot/grub/grub.d/*.cfg and have an install procedure drop in one or more menu items instead of every os install or update rewriting the entire grub.cfg every time. http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ describes such a configuration structure, and http://pkgs.fedoraproject.org/cgit/grub2.git/plain/0362-blscfg-add-blscfg-module-to-parse-Boot-Loader-Specif.patch implements it as a grub command. Although that's a good start, it seems a little too specific. What I had in mind would be the equivalent to the source command in bash. For example, if condition; then include (hd0,3)/grub/custom/themes/themeA.cfg else include (hd0,2)/boot/grub/themes/themeB.cfg fi # Get menuentries include /boot/grub/grub.d/*.cfg I have no preference to the keyword. Either include or source would work. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub2 designer's guide.
Seth Goldberg wrote: On Jun 4, 2013, at 1:59 AM, Vladimir Testov wrote: I've completed the article I was working on. http://wiki.rosalab.ru/en/index.php/Grub2_theme_/_designer%27s_guide Please, take a look. Looks great! Thanks so much for putting this together. This should be included in the grub2 docs (or linked explicitly), Do you mean like http://www.gnu.org/software/grub/grub-documentation.html? -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Support for UEFI ESP in os-prober
Vladimir 'φ-coder/phcoder' Serbinenko wrote: I must say I'm generally disappointed with os-prober and have ideas to move away from it. I'll start another topic for it. I agree. I would prefer adding an include command so grub.cfg could just do something like: include /boot/grub/grub.d/*.cfg and have an install procedure drop in one or more menu items instead of every os install or update rewriting the entire grub.cfg every time. -- Bruce Dubbs linuxfromscratch.org ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: USB3 3TB HDD boot
Chris Murphy wrote: On Mar 15, 2013, at 8:51 AM, Lennart Sorensen wrote: On Thu, Mar 14, 2013 at 08:56:18PM -0600, Chris Murphy wrote: Right, for a 4Kn drive, to read LBA 1 and get the GPT header I'd need: sudo dd if=/dev/disk3 skip=8 count=1 2>/dev/null | hexdump -C Wouldn't using 'bs=4096' make things simpler and more obvious? How would it? These structures are still predicated on a 512 byte block. The MBR is always 512 bytes, but on a 4096/4096 4Kn drive, LBA 0 is 4096 bytes. So if I don't want to see 3584 bytes of useless garbage, I can't set the dd block size to 4096, or I get extra information. If I want to see just the GPT header, which while only ~92 bytes, by spec it gets its own sector, there's far less superfluous information using a bs of 512 bytes than 4096 bytes. There is more than one way to do things. sudo dd if=/dev/disk3 bs=4096 skip=1 count=1 | cut -c 1-92 | hexdump -C is one way that matches the physical drive. The first mentioned way works too, but doesn't reflect as well what is really going on. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Console Resolution with GRUB2
D.J.J. Ring, Jr. wrote: This is way too complicated for the average user. Yes. I have to agree with that. My comments were directed at advanced users. Also some distro's don't have menu.list - I have none for example with Arch Linux. menu.lst was the configuration file for Grub Legacy. GRUB2 uses grub.cfg. GRUB used to have a way of just adding at the grub menu the vga mode. It was simple. Can't that be done with GRUB2? I believe that's a distro issue. They all do the grub configuration a little differently. You either do a custom configuration file or use the distro's method of building it. -- Bruce On Thu, Feb 28, 2013 at 7:13 PM, Bruce Dubbs wrote: D.J.J. Ring, Jr. wrote: Hello Bruce, The "problem" with this is that grub.cfg says "Do Not Edit this File". The reason it says this is that it is embedded in the script grub-mkconfig. It overwrites the grub.cfg, but if you don't run that and only do manual edits, then it's not there. The problem is that many distros think they know more than the user (usually true, but not always) and always run grub-mkconfig every time the they update the kernel whether you want that or not. Why cannot grub2 have an easy way to change console resolution? I believe that's hardware dependent. When I open console programs, the display is tiny. Also console programs with ncurses graphics are tiny. These would be full screen if I could make console mode 640x480. That's probably because the kernel is configured to use a framebuffer by default. It's not a grub issue at that point. To disable the freamebuffer, see the advice in https://wiki.ubuntu.com/** FrameBuffer <https://wiki.ubuntu.com/FrameBuffer> Grub had an easy way to do this. I haven't tried Bruce's method because it says not to edit the file. Also when I upgrade a kernel and regenerate the grub menu, the settings will be overwritten. Keep a backup of /boot/grub/grub.cfg and restore it after upgrading the kernel. Then edit the file to add the new kernel. -- Bruce __**_ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/**listinfo/grub-devel<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: Console Resolution with GRUB2
D.J.J. Ring, Jr. wrote: Hello Bruce, The "problem" with this is that grub.cfg says "Do Not Edit this File". The reason it says this is that it is embedded in the script grub-mkconfig. It overwrites the grub.cfg, but if you don't run that and only do manual edits, then it's not there. The problem is that many distros think they know more than the user (usually true, but not always) and always run grub-mkconfig every time the they update the kernel whether you want that or not. Why cannot grub2 have an easy way to change console resolution? I believe that's hardware dependent. When I open console programs, the display is tiny. Also console programs with ncurses graphics are tiny. These would be full screen if I could make console mode 640x480. That's probably because the kernel is configured to use a framebuffer by default. It's not a grub issue at that point. To disable the freamebuffer, see the advice in https://wiki.ubuntu.com/FrameBuffer Grub had an easy way to do this. I haven't tried Bruce's method because it says not to edit the file. Also when I upgrade a kernel and regenerate the grub menu, the settings will be overwritten. Keep a backup of /boot/grub/grub.cfg and restore it after upgrading the kernel. Then edit the file to add the new kernel. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Console Resolution with GRUB2
D.J.J. Ring, Jr. wrote:
Hello Peter and the rest of the group.
I appreciate Peter's efforts to help.
However, nothing so far works as needed.
With the old grub users who needed larger size characters simply added a
vga= line to the boot code. It was simple.
Now it seems to be very complex.
In fact all the answers I can find on the various newsgroups no longer
work. Also there is no one answer, but many answers, and then there are
comments like "this no longer works".
font
Would someone make it so that users can make large fonts in the console?
There are those of us who are nearly blind but still like to see the
characters on the screen. We are comfortable using 640 x 480 configuration.
Completely blind people of course have no need to change the font size. I
understand and have changed the font size in the grub menu, but unless I
can keep that resolution in the console, it is not what I want and need.
If I could keep that character size in console while running the screen at
high resolution it would be perfect.
However, the problem still remains: It is very difficult to do for a new
user who wishes to use a console only system as many blind users wish to.
I am disappointed that I cannot find an answer to this question, if there
is a better place to ask, I would be most happy to know of it, and I will
ask there.
I don't know what others may say, but I just use a custom grub.cfg file.
Avoid the scripts in /etc/grub.d. After all the only thing really
needed in grub.cfg is:
### grub.cfg
set default=0
set timeout=5
insmod ext2
set root=(hd0,1)
menuentry "entry1" {}
menuentry "entry2" {}
etc. Adjust values to need.
Using this simple configuration, grub never changes the screen
resolution. Any other changes are OS specific.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB and the risk of block list corruption in extX
Lennart Sorensen wrote: On Fri, Feb 08, 2013 at 06:17:57PM +0100, Martin Wilck wrote: In my case, the reason is a multiboot setup based on chainloading the indiviual installed OS's bootloaders from a central, primary bootloader. This is easily accomplished by installing the individual OS's bootloaders in their respective "/" or "/boot" partitions. Linux distributions have encouraged this kind of setup over several years - "install boot loader in first sector of root/boot partition" used to be a prominent option somewhere in the installation process (these distributions were usually GRUB 0.9x based - GRUB 0.9x developers didn't seem to have a big issue with stage1_5 being loaded via block lists). Recent GRUB2-based distributions like Fedora have removed this option, and some users are dissatisfied with that. I would like to understand what the actual risk is. So I'd appreciate examples for the "pretty serious problems" you mention. grub 2 has a lot more features, is a lot bigger, and might not fit in your embedding area of some filesystems. Of course the block list breaks if the file in the filesystem is modified or moved without updating the block list, which used to break lilo all the time whenever one forgot to run the lilo command after making a change. Sure grub 0.9x was a bit less fragile than lilo, but block lists for files that could potentially be changed is fragile. Embedding enough of grub in the first track or a boot partition (as EFI systems support, as do a number of non x86 architectures) gives a much more reliable system since it can read anything else it needs using the filesystem and hence doesn't break if files are changed. You don't need an EFI system to give GRUB enough space. You just need to partition the drive so the first partition starts at 1MB instead of sector 63. I think using a GPT partition scheme is quite preferred over the MSDOS scheme designed 30 years ago. I will note that this causes problems for some systems, but I haven't seen it since I don't do windows. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
GRUB 2.00 build and flex-2.5.37
The latest flex makes the GRUB-2.00 build fail. I can work around the issues with --disable-werror, but grub-core/script/yylex.l causes two warnings that do not work with -Werror. ./grub-core/script/yylex.l: At top level: grub_script.yy.c:2351:13: error: 'yy_fatal_error' defined but not used This can be fixed by removing #define YY_FATAL_ERROR(msg) in yylex.l. grub_script.yy.c: In function 'yy_scan_bytes': grub_script.yy.c:2296:17: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] This one is a little more difficult because it is generated by flex. I don't know how to fix this except with a sed after grub_script.yy.c is generated by flex. The gcc version -s 4.7.1. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
grub-2.00 build problem (gets)
I ran into a minor problem building GRUB-2.00 with glibc-2.16.0. I had to run a simple command to bypass the problem: sed -i -e '/gets is a security/d' grub-core/gnulib/stdio.in.h This may already be fixed, but I thought I'd post just in case. This has also been showing up in several other packages. -- Bruce linuxfromscratch.org ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Secure Boot. Why don't you take the wind out of their sails?
richardvo...@gmail.com wrote: Maybe I'm missing something, but when I read this, it doesn't say the hardware must have Secure Boot enabled by default. Rather, it must be enabled by the OEM as part of the Windows preinstallation process, so that it's enabled when it reaches the end user. System builders are still going to purchase UEFI Secure Boot-capable motherboards with Secure Boot disabled-by-default, and they will "just work" if you want to install Linux. For people who are not experts, trying Linux or another operating system becomes much more intimidating. They have to go into the BIOS and change something. Then, to go back to Windows, they have to do it again. Will this discourage users from trying something else? You bet. End-users who bought pre-installed Windows will have to change the configuration option in system setup, which for someone planning to install a new OS from scratch is not a major hurdle. It will be a minor road bump for people using live-CD style media (including USB), but won't be a showstopper if the user actually has permission from the computer owner to boot the alternate media. What likely is that it will prevent unauthorized (by the owner) rebooting public computers using alternate media, but that's not exactly a valid scenario to begin with. But is is for private computers. My LUG frequently gives out DVDs with various Live system and say try it. That will become much more problematic. I still don't know how someone is supposed to be able to boot Windows within a VM with this new paradigm. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Minor documentation issue
Mike Gilbert wrote: On Fri, Jun 29, 2012 at 11:32 AM, Bruce Dubbs wrote: By the way, the html is not well formed. There are many missing tags. HTML 4 and earlier do not require closing tags for . Yes, you are right of course. They are allowed though. All my pages are xhtml strict, so I'm more used to them being required. I'm a little more interested why some dash (ASCII 0x2d) characters are converted to _002d. In href="#Making-a-GRUB-bootable-CD_002dROM" there are 3 dashes that are OK and one converted. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Minor documentation issue
The web site still has the 2.00~rc1 manual. I was asked a question about GRUB and CD-ROMS and checked the sites's html documentation. There are at least two places where the html is generated from the texi file incorrectly. texi: * Installing GRUB using grub-install:: * Making a GRUB bootable CD-ROM:: html: 3.1 Installing GRUB using grub-install 3.2 Making a GRUB bootable CD-ROM The _002d sequences (instead of a dash) in the hrefs show up in url address lines. I'm sure this has something to do with texinfo, but I don't know how to fix it. By the way, the html is not well formed. There are many missing tags. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Release of 2.00~rc1
Vladimir 'φ-coder/phcoder' Serbinenko wrote: Hello, all. I'm proud to introduce 2.00~rc1 to you. It's available as ftp://alpha.gnu.org/gnu/grub/grub-2.00~rc1.tar.gz or ftp://alpha.gnu.org/gnu/grub/grub-2.00~rc1.tar.xz Looks very good. From an LFS point of view, the only trivial warnings I got were: grub-core/lib/libgcrypt-grub/cipher/rijndael.c: In function 'do_setkey': grub-core/lib/libgcrypt-grub/cipher/rijndael.c:173:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] lib/libgcrypt-grub/cipher/rijndael.c: In function 'do_setkey': lib/libgcrypt-grub/cipher/rijndael.c:173:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] It looks like the same warning but built twice: ./grub-core/lib/libgcrypt/cipher/rijndael.c ./grub-core/lib/libgcrypt-grub/cipher/rijndael.c I'm not sure why two files have the same name with different code, even if they are in different directories. Compiler is gcc-4.7.0. -- Bruce ___ 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.
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. If the unreliability is because of separate /boot partitions and/or other distros using /boot/grub2 instead of /boot/grub then please consider placing themes in /usr/share/grub instead of /boot/grub. This removes the unreliability and ensures the theme will display properly across all distros and all partitioning schemes. I don't think users should place files in /boot/grub. Files there should only be those necessary for the bootloader to function properly. Although it's a protected directory, it's all to easy for 'inexperienced' users to simply 'su' and delete critical files (unintentionally while working on themes) thus preventing their system from booting. Please keep this feature and consider placing themes in /usr/share/grub. This is not a good suggestion. I have several instances of /usr/share on my system in different root filesystem partitions. Which one would grub use? All the files for the boot process need to be in a single partition. /boot/grub2 is a distro specific issue and distros that use it need to maintain it. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Various build failures in current bzr tree
Lennart Sorensen wrote:
Looks like they all come from double-linked list code. This should help:
=== modified file 'include/grub/list.h'
--- include/grub/list.h2012-01-29 17:09:53 +
+++ include/grub/list.h2012-02-12 01:00:48 +
@@ -24,6 +24,10 @@
#include
#include
+struct grub_list __attribute__ ((may_alias));
+struct grub_named_list __attribute__ ((may_alias));
+struct grub_prio_list __attribute__ ((may_alias));
+
struct grub_list
{
struct grub_list *next;
I think you got it.
Doing a clean build to be sure.
You posted at the bottom. That's good. But did you really have to
quote 428 lines from the previous message to post your 2 lines of input?
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
GNU Grub Web Page
At the request of the GNU Webmasters, I've renamed all the pages for the web site from filename.en.html to just filename.html and adjusted all the links at http://www.gnu.org/software/grub/. If I missed anything or a page needs an update, please let me know. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[Fwd: GRUB 1.99 Documentation Observation]
Forwarding. -- Bruce Original Message Subject: GRUB 1.99 Documentation Observation Date: Tue, 20 Dec 2011 11:55:54 -0800 (PST) From: Douglas Morris Reply-To: Douglas Morris Thanks for your work on documenting grub which I plan to use with my installation of GNU/Linux. I have a comment on the GRUB documentation posted online for version 1.99. 3.4 BIOS Installation, MBR section says: "there are two ways to install GRUB: it can be embedded in the area between the MBR and the first partition (...), or the core image can be installed in a file system and a list of the blocks that make it up can be stored in the first sector of that partition." However, when I look at 3.1 Installing GRUB using grub-install, there is no explanation about where the 'core image' is installed or how its placement is controlled. My observation comes from trying to find out if I can boot GRUB if I 'install' it in a /boot logical partition on an MBR harddrive. I will just try it not knowing the particulars and see what happens. I can always start over using Clonezilla, which seems to have worked for me once. It seems that OEM Windows 7 installed in an MBR format will not adapt to the GPT format and I am not paying for MS installation CDs. So no GPT for me. Happy Holidays and any religious salutations suitable to your self-identity. Doug Morris ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
New bash-completion script for GRUB utilities
I just noticed that GRUB 1.99 installs two files /etc/bash_completion.d. Why are these library functions installed in /etc instead of /lib? -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub 1.99 configuration
Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 12.06.2011 04:28, Bruce Dubbs wrote: I'm trying to manually run grub-mkconfig to establish grub-1.99 installation instructions for Linux From Scratch. I am getting: grub-mkconfig -o /boot/grub/grub.cfg /usr/sbin/grub-probe: error: cannot stat `/dev/root' Doing some investigating grub-mkconfig is running: /usr/sbin/grub-probe --target=device / Drilling down, grub-probe is doing: device_name = grub_guess_root_device (path); Which in turn is doing: grub_find_root_device_from_mountinfo( "/", NULL ); This is reading /proc/self/mountinfo. The problem here is that this file does not give the device, but specifies /dev/root: 13 1 8:15 / / rw,relatime - ext3 /dev/root rw,errors=continue,barrier=0,data=writeback The kernel is 2.6.39.1, but 2.6.37 seems to give the same thing. grub-probe should be able to detect /dev/sda15, but fails on newer kernels. grub-probe for grub-1.98 works fine. A grep there shows no use of /proc/self/mountinfo. Suggestions? update either udev or grub. normally /dev/root should be a symlink. Newer grub-probe can cope with some other arrangements as well Well I'm using udev-171. That is the most recent version. We don't like to non-release package versions in LFS, but we do occasionally patch files. I don't know when /dev/root became a 'device'. Udev doesn't create it. We also don't use an initrd. That's not needed when you know in advance what your hardware configuration is. I did work around the problem by manually creating the symlink. I do not know of anything other than GRUB that needs it, but I don't use lvm. In any case, I don't think GRUB should choke because /dev/root is missing. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub 1.99 configuration
Colin Watson wrote: On Sat, Jun 11, 2011 at 09:28:13PM -0500, Bruce Dubbs wrote: grub-mkconfig -o /boot/grub/grub.cfg /usr/sbin/grub-probe: error: cannot stat `/dev/root' http://bugs.debian.org/627587 You can fix it by backporting r3318 from trunk: http://bazaar.launchpad.net/~vcs-imports/grub/grub2-bzr/revision/3318 The backport to 1.99 is not entirely straightforward. Here's a version that works with 1.99: http://anonscm.debian.org/loggerhead/pkg-grub/trunk/grub/revision/2435/debian/patches/lazy_stat.patch Thanks for the info. I'll check it out. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
grub 1.99 configuration
I'm trying to manually run grub-mkconfig to establish grub-1.99 installation instructions for Linux From Scratch. I am getting: grub-mkconfig -o /boot/grub/grub.cfg /usr/sbin/grub-probe: error: cannot stat `/dev/root' Doing some investigating grub-mkconfig is running: /usr/sbin/grub-probe --target=device / Drilling down, grub-probe is doing: device_name = grub_guess_root_device (path); Which in turn is doing: grub_find_root_device_from_mountinfo( "/", NULL ); This is reading /proc/self/mountinfo. The problem here is that this file does not give the device, but specifies /dev/root: 13 1 8:15 / / rw,relatime - ext3 /dev/root rw,errors=continue,barrier=0,data=writeback The kernel is 2.6.39.1, but 2.6.37 seems to give the same thing. grub-probe should be able to detect /dev/sda15, but fails on newer kernels. grub-probe for grub-1.98 works fine. A grep there shows no use of /proc/self/mountinfo. Suggestions? -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Grub Wiki
The link http://grub.enbug.org/ is dead. I have a link to that page in the GRUB Web page at http://www.gnu.org/software/grub/. Is there an updated link or should I just remove the link? -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Minor GRUB manul issue
http://www.gnu.org/software/grub/manual/grub.html#Obtaining-and-Building-GRUB Needs to be updated for new GRUB location. s/alpha/ftp/ in two places. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Change download URL on grub web site
KESHAV P.R. wrote: On Sun, May 29, 2011 at 20:28, Bruce Dubbs wrote: Metatech wrote: Hello, Please change the download URL for grub. On page http://www.gnu.org/software/grub/grub-download.en.html it still links to ftp://alpha.gnu.org/gnu/grub/ and it should now point to the new URL : ftp://ftp.gnu.org/gnu/grub/ OK, done. Â Thanks for the reminder. Â -- Bruce Seems like even the GRUB Manual need to be changed - http://www.gnu.org/software/grub/manual/grub.html#Obtaining-and-Building-GRUB . It shows ftp://alpha.gnu.org/gnu/grub/grub-1.99.tar.gz instead of ftp://ftp.gnu.org/gnu/grub/grub-1.99.tar.gz . I don't do the manual, but I'll send a reminder. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Change download URL on grub web site
Metatech wrote: Hello, Please change the download URL for grub. On page http://www.gnu.org/software/grub/grub-download.en.html it still links to ftp://alpha.gnu.org/gnu/grub/ and it should now point to the new URL : ftp://ftp.gnu.org/gnu/grub/ OK, done. Thanks for the reminder. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 1.99 released
Vladimir 'φ-coder/phcoder' Serbinenko wrote: Hello, all I'm proud to announce the release of GNU GRUB version 1.99. Congratulations on the release. As one who builds almost everything form source, the download and build went very smoothly. Thank you. I want to share some nits with you. Use them or ignore them as you please. -- Bruce 1. The install creates an empty directory: /usr/share/grub 2. There were several trivial build warnings: grub_script.yy.h:293: warning: 'yy_flex_strncpy' declared 'static' but never defined grub_script.yy.c:2241: warning: unused parameter 'yyscanner' grub_script.yy.c:2482: warning: unused parameter 'yyscanner' config.status: WARNING: 'util/grub.d/10_linux.in' seems to ignore the --datarootdir setting config.status: WARNING: 'util/grub.d/20_linux_xen.in' seems to ignore the --datarootdir setting config.status: WARNING: 'util/grub-install.in' seems to ignore the --datarootdir setting config.status: WARNING: 'util/grub-mknetdir.in' seems to ignore the --datarootdir setting fs/btrfs.c: In function 'grub_btrfs_read_logical': fs/btrfs.c:592: warning: 'err' may be used uninitialized in this function grub_script.yy.h:293: warning: 'yy_flex_strncpy' declared 'static' but never defined grub_script.yy.c: In function 'yy_fatal_error': grub_script.yy.c:2241: warning: unused parameter 'msg' grub_script.yy.c:2241: warning: unused parameter 'yyscanner' grub_script.yy.c: At top level: grub_script.yy.c:2279: warning: no previous prototype for 'yyget_column' grub_script.yy.c:2322: warning: no previous prototype for 'yyset_column' grub_script.yy.c: In function 'yy_flex_strncpy': grub_script.yy.c:2482: warning: unused parameter 'yyscanner' lib/libgcrypt-grub/cipher/camellia.c:450: warning: no previous prototype for 'camellia_setup128' lib/libgcrypt-grub/cipher/camellia.c:661: warning: no previous prototype for 'camellia_setup256' lib/libgcrypt-grub/cipher/camellia.c:947: warning: no previous prototype for 'camellia_setup192' lib/libgcrypt-grub/cipher/camellia.c: In function 'camellia_setup192': lib/libgcrypt-grub/cipher/camellia.c:951: warning: implicit declaration of function 'memcpy' lib/libgcrypt-grub/cipher/camellia.c: At top level: lib/libgcrypt-grub/cipher/camellia.c:969: warning: no previous prototype for 'camellia_encrypt128' lib/libgcrypt-grub/cipher/camellia.c:1059: warning: no previous prototype for 'camellia_decrypt128' lib/libgcrypt-grub/cipher/camellia.c:1152: warning: no previous prototype for 'camellia_encrypt256' lib/libgcrypt-grub/cipher/camellia.c:1266: warning: no previous prototype for 'camellia_decrypt256' lib/libgcrypt-grub/cipher/rijndael.c: In function 'do_setkey': lib/libgcrypt-grub/cipher/rijndael.c:173: warning: comparison between signed and unsigned lib/libgcrypt-grub/cipher/serpent.c: In function 'serpent_key_prepare': lib/libgcrypt-grub/cipher/serpent.c:589: warning: comparison between signed and unsigned reed_solomon.c: Assembler messages: reed_solomon.c:2: Warning: ignoring changed section attributes for .text ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[Fwd: wiki]
I don't have access to modify this page, but the link Reinhardrefers to does need to be removed. -- Bruce Original Message Subject: wiki Date: Thu, 14 Apr 2011 09:04:01 +0200 From: Reinhard Echle To: Dear Bruce, sorry, I didn't found an address to report a stupid link in the wiki, maybe you can forward this mail. http://grub.enbug.org/FrontPage?action=show&redirect=StartSeite Topic: GRUB Legacy (0.9x) second link: Pflaster verfugen regards Reinhard ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Your contributions to grub.enbug.org
Vladimir 'φ-coder/phcoder' Serbinenko wrote: Hello, when discussing after the temporary wiki problems it was decided that it would be better to migrate the information from wiki into the manual and developper manual where legal reasons permit. You have contributed to the wiki, would you agree to consider that your contributor agreement covers wiki as well? Yes. No problem. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
Chris Murphy wrote:
On Mar 29, 2011, at 9:19 AM, Patrick Strasser wrote:
Moreover googling is no alternative to proper documentation. I'd
like to contribute examples that I found to the grub docs, but the
manual gives no hint how to do so... ;-)
It's the developers task and skill to document features.
I agree, but from this outsider's perspective, it's abundantly clear
the developers have totally abdicated on this.
That's a bit harsh. The devs are a very small group and the technical
details are vast. There is some effort going on to do the
documentation, but it takes time. It is only a .98 release right now
which means it is under development. To describe what GRUB2 does will
take a moderate size book.
The entire project is a mini-operating system. I personally don't
really think a lot of the bells and whistles (e.g. scripting, graphics)
are needed for something that most users will look at for 5 seconds as
they boot (if at all).
My own grub.cfg looks like:
### grub.cfg
set default=0
set timeout=5
insmod ext2
set root=(hd0,1)
menuentry "LFS SVN 20110204, Linux 2.6.37" {
linux /linux-2.6.37 root=/dev/sda14 ro
}
menuentry "LFS SVN 20100627, Linux 2.6.34-label" {
linux /linux-2.6.34 root=LABEL=lfs-svn ro
}
and it works fine. On the other hand, I don't do Windows, BSD, MAC,
serial IO for boot, nfs boot, tftp boot, a boot sector on raid, EFI,
initrd, grub-mkconfig, or a myriad of other things that GRUB supports.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
Leslie Rhorer wrote: I sympathize, but only to a point. No matter how dreary or how daunting the volume of work, it is essential it be done. I agree. I looked into helping do some of the documentation, but found that I just did not know enough of the internals to properly do it. I think a good example of this is the sort order of the items in the boot list. Under GRUB legacy, editing the menu list order was quite simple. I did some significant searching to try to find a way to do this with GRUB 2, but as far as I was able to determine, there is no way to do it. There is a way. Use emacs or vim. There is nothing that demands you use grub-mkconfig. It is fine for someone who uses a distribution and knows very little about the internals, but in my opinion, it just gets in the way of knowledgeable users. I'd like to contribute examples that I found to the grub docs, but the manual gives no hint how to do so... ;-) Send patches against docs/grub.texi in GRUB trunk. If that's too hard, send plain-text suggestions and somebody can deal with marking them up. Well, I might also like to contribute in some way, but speaking for myself, I don't even know where to start. Knowing where and how to submit documentation is not really the starting point. First one must know what GRUB can do and how one can make it do it. For those of us who did not develop GRUB 2, it's rather a chicken and egg problem. I agree. About the only was is to study the source and look at other (e.g. Multiboot) documentation. Unfortunately the source is really hard for a newbie to follow. You really have to understand the intricacies of a lot of different systems. I understand what's needed for the PC for DOS and Linux, but get lost in all the other file systems and BIOS issues. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Minor GRUB manual issue
http://www.gnu.org/software/grub/manual/grub.html
The on-line manual has a link problem. There are several references to
http://www.gnu.org/software/grub/manual/multiboot.html#Top
that should be
http://www.gnu.org/software/grub/manual/multiboot/multiboot.html
I traced the problem to grub.texi where the link is specified by
@pxref{Top, Multiboot Specification, Motivation, multiboot, The
Multiboot Specification}, on lines 165, 272, 376, and 781.
I'm sure the fix is simple, but I don't know enough about texinfo to do it.
Thanks to Roberth Kulbin for the report.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: AMI Aptio EFI booting problems on ASUS G73SW-A1
Nate Weibley wrote:
Per your suggestion I tried other linux distros with various kernels. So far
none of the EFI enabled distros are working. They do work if booted via BIOS
though, of course. Windows 7 64bit *does * boot appropriately via EFI, so
it's hard to say where the fault is. If Windows is booting though, it seems
more likely something is going wrong in the Linux kernel EFI handling, or
perhaps as you say GRUB is passing incorrect pointers. Either way, they all
exhibit the exact same behavior... the kernel is loaded, and at the point
init should be called, the system stalls with no debug or error message.
I will continue testing as kernel revisions are released, but I'm not sure
how else I can bang away at trying to get EFI to boot without any sort of
error message or debugging info.
I am not an expert in GRUB or EFI, but what it sounds like to me is that
the initrd for the systems you are using does not have EFI support.
Personally, I never use initrd but build my own kernels with all
capabilities needed built in (not modules). You can test this by
building your own kernel and ensure EFI_PARTITION is built in during the
configure phase.
-> File systems
-> Partition Types
-> Advanced partition selection (PARTITION_ADVANCED [=y])
Then if the kernel image is, say, /boot/linux-2.6.37, an entry in
boot.cfg like:
menuentry "My test kernel" {
set root=(hd0,)
linux /boot/linux-2.6.37 root=/dev/ ro
}
would be all that's needed.
That may not be your final answer, but if it does boot, then GRUB is
doing it's job and the problem is in the distro you are using.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Documentation bug?
Chris Jones wrote: On Mon, Jan 24, 2011 at 09:22:36PM EST, Bruce Dubbs wrote: Chris Jones wrote: I plan to make extensive changes to a multi-boot environment and I looked in ‘GNU GRUB Manual 1.99~beta0’ for a way to create a CD/DVD that would reflect the state of my grub environment, (including my /boot/grub/menu.cfg) that would let me boot the system as if I was booting from the HD. I don't know where you looked, but the information you refer to is for GRUB Legacy. The configuration file for GRUB 2 is /boot/grub/grub.cfg Same place as usual :-) http://www.gnu.org/software/grub/manual/grub.html#Making-a-GRUB-bootable-CD_002dROM OK wise guy.. I meant ‘grub.cfg’ .. The file referred to in the _grub 1.99_ manual (grub 1.99.. that should be grub2 right?) and that is missing from _both_ the ubuntu 10.10 system _and_ the tarball, is *stage2_eltorito*. You referred to grub.cfg and stage2*. AFAIK those are GRUB Legacy and not GRUB 2. There does indeed seem to be a problem with the GRUB 2 documentation. Most of the files in /usr/lib/grub/i386-pc/ are of type .mod and .img. I think the file you want is cdboot.img, but I'm not sure how to use it. Try http://grub.enbug.org/Manual Never heard of this site.. That's the GRUB Wiki. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Documentation bug?
Chris Jones wrote: Sorry for the catchy ’Subject:’ above, I am not sure at this point whether it is appropriate. I plan to make extensive changes to a multi-boot environment and I looked in ‘GNU GRUB Manual 1.99~beta0’ for a way to create a CD/DVD that would reflect the state of my grub environment, (including my /boot/grub/menu.cfg) that would let me boot the system as if I was booting from the HD. I don't know where you looked, but the information you refer to is for GRUB Legacy. The configuration file for GRUB 2 is /boot/grub/grub.cfg Try http://grub.enbug.org/Manual My understanding is that the correct procedure is described in section 3.2 of the above manual: Making a GRUB bootable CD-ROM. The first step specifies the following: | Copy the file stage2_eltorito: | | $ cp /usr/lib/grub/i386-pc/stage2_eltorito iso/boot/grub I looked on the ubuntu 10.10 system where my grub environment happens to live and was unable to find any file named ‘stage2_eltorito’ anywhere on the system and definitely not in the above directory. I have just downloaded a tarball of grub-1.99~rc1, and a ‘find’ command on the untarred tree did not return any positives either. Is this file part of another package that complements grub? Is the documentation in the process of being updated? Am I missing something? If the above procedure is not longer current, please let me know how I could create a bootable copy of my current grub environment, preferably on a CD or DVD, so that I could use it as a simple backup solution in the event I am no longer able to boot my systems from the hard drive. Thanks, cj ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub-devel Digest, Vol 79, Issue 2
James Miller wrote: If you've any comments on the document I've attached then let me know. Can you put it into a more open source friendly format please. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: next release of grub2?
KESHAV P.R. wrote: This the only site that currently hosts whatever documentation grub2 carries. Did you see http://www.gnu.org/software/grub/manual/html_node/index.html -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: my thoughts about grub 2
Lennart Sorensen wrote: grub2 is multi architecture, modular, extendible, and much more robust than grub1. The fact it no longer depends on any block maps to work is a great thing. The fact it uses modules to build the required features in and loads any others needed on demand means it can support a lot more filesystems than grub1 since grub1 would have gotten too big adding all those features. I agree with your general comments, but at the same time think grub2 is suffering form a severe case of feature-itis. Just because something can be done, doesn't mean is should be done. For example, I've never seen a real need for a boot loader to work with software raid. Users can very easily create a separate non-raid partition in a reasonably common format and boot from that. Is there a real need for the boot partition to be encrypted? In the effort to be complete, the whole thing has become very complicated. Sure grub1's config was simple and the syntax had a lot less in it, but it was also limiting the ability to add new features. Now for debian users, they already had an update-grub command that generated the grub config file for them, so going to grub2 really doesn't change anything from the users point of view, unless they happen to want to custize something. And if you have some non-debian kernels, that are not recognized either grub.cfg or an intermediate shell script needs to be edited manually. I'd rather edit grub.cfg myself and have the distros keep away from grub.cfg. Now those customizations happen in /etc not /boot/grub/menu.lst. That's actually a good thing, since all config SHOULD be in /etc, not /boot. So grub1 was actually the one that was doing the wrong thing before. Using /etc only applies to Unix-like operating systems. If you *are* in a Unix-like OS, just put a symbolic link into /etc. Isn't native mdraid, lvm, dmraid, piles of filesystems and multi architecture support worth it? How about multiple partition table types (disks or raids over 2GB don't work with msdos partition tables after all, and grub2 supports EFI style GPT partition tables.) I'm afraid I don't agree. Too many options leads to complications. A boot partition does not need all those specialized partition types. Even a graphical interface is overkill when the vast majority of users will only be in the boot screen 10 seconds or less waiting for a timeout for the default boot. For really novice users, just set the timeout to zero and skip the boot screen completely. So how does installing a new kernel update the boot loader then if it is only configured by itself? That's why they invented emacs and vi (or ed). For me to add a new kernel means that I need to add basically two lines to grub.cfg. For many users though that's way too much. However, once a user has a working configuration, the only thing that should happen is for the distro to add a file to a directory with a menuentry entry. I don't need or want a customized boot screen for Debian, or Ubuntu, or Red Hat, or SuSE. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
grub.texi
There are several problems in grub.texi.
1. There are several references to Multiboot using @pxref or @xref, but
Multiboot is not a node within grub.texi. This causes a 404 on the website.
@Section History of GRUB
@section GRUB features (2 times)
@subsection How to boot an OS directly with GRUB
They resolve properly in grub.info where there should be a separate
entry for Multiboot in dir, but not in the html files (single or
multi-page).
I don't know if these references should be changed to @uref or not.
2. The following nodes are not found on the website. I ran makeinfo
and they seem to be generated.
@node Shell-like scripting
@node Themes
@node acpi
@node badram
@node GRUB only offers a rescue shell
@node Invoking grub-mkconfig
@node Invoking grub-mkpasswd-pbkdf2
@node Getting the source code
@node Finding your way around
3. A minor bug in @node Naming convention
s/@samp{1}/@samp{2}/
I fixed #1 and #3 above manually for the plain html files, but grub.texi
needs to be updated for a permanent fix. I also added the missing files
to get rid of the 404s in #2.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Web site redesign
Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 06/07/2010 11:09 PM, Colin Watson wrote: Hi Bruce, I just committed a couple of typo fixes to the website, and suddenly the redesign you committed back in February went live, rather to my surprise when the page I was editing vanished. I guess the GNU admins fixed the commit trigger! Now people are reporting some dead links. I fixed up http://www.gnu.org/software/grub/grub-legacy.en.html by restoring grub-legacy-support.en.html, but Jordan Uggla reported a link to grub-2.en.html on the front page which is now dead. I wasn't actually intending to get involved in a web site redesign. Now that changes appear to be going live in a timely fashion, do you think you could fix this up? Apparently Bruce is busy right now. Could you then revert the changes that broke website and send the patch of changes you reverted to ML? This way we keep a record of it but it doesn't stall you. I fixed the links. What errors are you seeing? -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GCC 4.5
Vladimir 'φ-coder/phcoder' Serbinenko wrote: Hello, all. I've noticed that GCC 4.5 is released and is available in debian. With this version -mregparam=3 bug is fixed. So I intend to remove all NESTED_FUNC_ATTR and use -mregparm=3 only on gcc >=4.5 and -mregparam=1 otherwise. This has the disadvatantage of increasing binary size with pre-4.5 gcc but it also greatly reduces the bug surface and so will eventually result in better quality. Any oppositions? I do not intend to require gcc 4.5, only highly recommend it. There have been reports of problems with -Os in gcc-4.5.0. In one case, the linux kernel is not functional. Specifically the file arch/x86/kernel/tsc.c causes a kernel panic. I advise caution in this area. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 back to lilo ?
Colin D Bennett wrote:
Perhaps instead of pre-generating the entire GRUB configuration
(e.g. from a particular Distro like Ubuntu 9.10) things could be
inserted into the main grub.cfg at GRUB boot time.
Here's just a portion of what Ubuntu 10.04 puts in the generated
grub.cfg (of course with a stern warning not to hand modify the file):
The warning is a bit too strong. It should be more like "Don't modify
by hand unless you know what you are doing."
I personally think that grub-mkconfig goes too far. At least the
distros go too far in completely overwriting grub.cfg. They make
assumptions that the users don't know what they're doing. That is not
always true. If there is an existing grub.cfg, the user should at least
be given a prompt that grub.cfg is going to be overwritten and given a
chance to bail out.
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Ubuntu, with Linux 2.6.32-22-generic' --class ubuntu --class
gnu-linux --class gnu --class os { recordfail
insmod ext2
set root='(hd0,3)'
search --no-floppy --fs-uuid --set
534672c7-9930-407e-a13d-66a8e873a842 linux /vmlinuz-2.6.32-22-generic
root=UUID=a5c8657b-e206-47d5-8cc2-30cc6cbfc77e ro quiet splash
initrd /initrd.img-2.6.32-22-generic
}
### etc. etc.
Now what if specific OS parts could be separated out into another file,
which could be referred to by GRUB at boot time. Something like:
--- grub.cfg
# General settings
set timeout=10
set root='(hd0,3)'
# OS-specific parts
include ubuntu-10.04.cfg
include macos.cfg
include windows_xp.cfg
This is a reasonable thing to do, but where are the include files found?
I would suggest grub/config.d/
Is there anything that goes in these include files other than menuentries?
One problem is that many distros install in one partition, including
/boot. You then have the same problem of having to access another
partition of various types (reiser, ext4, jfs, xfs, etc) on possibly a
different drive to find the other /boot partitions. If we can educate
user and distros to always have a dedicated small /boot partition, then
there are several good options.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Broken build
Vladimir 'φ-coder/phcoder' Serbinenko wrote: Bruce Dubbs wrote: Vladimir 'φ-coder/phcoder' Serbinenko wrote: Carles Pina i Estany wrote: Hi, On Mar/17/2010, Bruce Dubbs wrote: With the addition of the internationalization code, building GRUB in a separate directory fails. I'll take a look into it "soon" (next days or next week) Probably it's an easy thing, if someone checks it before please report :-) cd $(srcdir) && $(XGETTEXT) -ctranslate --from-code=utf-8 -o $@ -f $< --keyword=_ --keyword=N_ to cd $(srcdir) && $(XGETTEXT) -ctranslate --from-code=utf-8 -o $@ -f po/POTFILES --keyword=_ --keyword=N_ Feel free to test & commit I don't think so. Well you have a funny way of disagreeing arriving to the same result as I told: replace cd $(srcdir) && $(XGETTEXT) -ctranslate --from-code=utf-8 -o $@ -f $< --keyword=_ --keyword=N_ with cd $(srcdir) && $(XGETTEXT) -ctranslate --from-code=utf-8 -o $@ -f po/POTFILES --keyword=_ --keyword=N_ Have you tested it? Yes, have you? tar -xf grub-1.98.tar.gz cd grub-1.98 mkdir build cd build ../configure #edit line 528 of Makefile as above make cd .. && /usr/bin/xgettext -ctranslate --from-code=utf-8 -o ../po/grub.pot -f po/POTFILES --keyword=_ --keyword=N_ /usr/bin/xgettext: cannot create output file "../po/grub.pot": No such file or directory make: *** [../po/grub.pot] Error 1 As I said before, the error is that -o $@ is invalid because of the change of directory. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Broken build
Vladimir 'φ-coder/phcoder' Serbinenko wrote: Carles Pina i Estany wrote: Hi, On Mar/17/2010, Bruce Dubbs wrote: With the addition of the internationalization code, building GRUB in a separate directory fails. I'll take a look into it "soon" (next days or next week) Probably it's an easy thing, if someone checks it before please report :-) cd $(srcdir) && $(XGETTEXT) -ctranslate --from-code=utf-8 -o $@ -f $< --keyword=_ --keyword=N_ to cd $(srcdir) && $(XGETTEXT) -ctranslate --from-code=utf-8 -o $@ -f po/POTFILES --keyword=_ --keyword=N_ Feel free to test & commit I don't think so. When generated, the makefile has: $(srcdir)/po/$(PACKAGE).pot: po/POTFILES po/POTFILES-shell cd $(srcdir) && $(XGETTEXT) -ctranslate --from-code=utf-8 -o $@ -f $< --keyword=_ --keyword=N_ which when instantiated by make is: ../po/grub.pot: po/POTFILES po/POTFILES-shell cd .. && /usr/bin/xgettext -ctranslate --from-code=utf-8 \ -o ../po/grub.pot -f po/POTFILES --keyword=_ --keyword=N_ /usr/bin/xgettext: cannot create output file "../po/grub.pot": No such file or directory If I change this to: po/grub.pot: $(srcdir)/po/POTFILES $(srcdir)/po/POTFILES-shell mkdir -p po $(XGETTEXT) -ctranslate --from-code=utf-8 -o $@ \ -f $< --keyword=_ --keyword=N I get the error: /usr/bin/xgettext: error while opening "commands/acpi.c" for reading: No such file or directory We need something like: po/grub.pot: $(srcdir)/po/POTFILES $(srcdir)/po/POTFILES-shell mkdir -p po DIR=$PWD cd $(srcdir) && $(XGETTEXT) -ctranslate --from-code=utf-8 \ -o $(DIR)/$@ -f po/POTFILES --keyword=_ --keyword=N The use of $< is wrong here because of the cd command. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Broken build
With the addition of the internationalization code, building GRUB in a separate directory fails. mkdir build cd build ../configure make cd .. && /usr/bin/xgettext -ctranslate --from-code=utf-8 -o ../po/grub.pot -f ../po/POTFILES --keyword=_ --keyword=N_ /usr/bin/xgettext: error while opening "../po/POTFILES" for reading: No such file or directory make: *** [../po/grub.pot] Error 1 This is a regression from GRUB-1.97.2 -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: pointers to bzr location
Colin Watson wrote: On Sat, Feb 20, 2010 at 08:39:45AM -0600, Dustin Kirkland wrote: http://www.gnu.org/software/grub/grub-2-download.en.html led me to http://savannah.gnu.org/bzr/?group=grub which says: Anonymous read-only access bzr branch http://bzr.savannah.gnu.org/r/grub . Note: these paths are the default paths. Maybe the project is using a different layout. Indeed, this did not work: $ bzr branch http://bzr.savannah.gnu.org/r/grub bzr: ERROR: Not a branch: "http://bzr.savannah.gnu.org/r/grub/.bzr/branch/": location is a repository. The correct URL for the trunk is: http://bzr.savannah.gnu.org/r/grub/trunk/grub You can guess this by looking at the first URL in a web browser. Unfortunately the text on Savannah is autogenerated by the Savannah software, and I don't think we can change it. Maybe it would be best to copy the text onto http://www.gnu.org/software/grub/grub-2-download.en.html and correct it? I already did this in a complete rewrite of the web site. It seems to commit fine to cvs, but the site never got updated. I thought the site autogenerated from cvs head, but It didn't work. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Antialiased fonts patch.
Evgeny Kolesnikov wrote: If we really care about speed we should use 1-bit fonts. Nothing can be faster. And 1-bit fonts will stay here. But if we care about eye-candy view, we should not throw away any bits from FT library result. This will not be fast enough to replace 1-bit fonts, and it will differ from other desktop apps. So, what the profit? You also may concern about font size itsef (15-30 Mb for sub-pixel AA), but who really care about it when 1 Tb HDD costs less than 100$? Also we can gzip entire font file later if it will really be the problem. Actually I don't understand why AA fonts are needed for a screen that most users will look at for about 3 seconds to select their OS and boot. I suspect most distros will set up grub to skip the GRUB screen completely. Is the effort worth the cost? I suppose doing it 'because you can' or because someone is 'scratching and itch' is OK, but I don't think it should be a major consideration. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Simplified Chinese screenshots
Carles Pina i Estany wrote: Hi, On Feb/01/2010, Chris Jones wrote: On Mon, Feb 01, 2010 at 04:32:14PM EST, Carles Pina i Estany wrote: Hi, Aron Xu sent me some screenshots of Grub booting time in Chinese: http://carles.lastdot.org/Screenshot-QEMU.png http://carles.lastdot.org/Screenshot-QEMU-1.png http://carles.lastdot.org/Screenshot-QEMU-2.png Thanks for posting this -- quite impressive. It would be nice to upload a few such multi-lingual screenshots to a grub-gallery section of the wiki, don't you think..? When more translations will be done I will consider/do it. If someone wants to do please go ahead :-) Nice to see that there are users who are able to do some useful stuff with the new grub, especially since lately, I have seen a couple of trolls spreading some pretty inane FUD about the new grub on the debian-user mailing list. I haven't read the insane FUD(s). One important thing that we are on it (Bruce I think) is writing documentation. Ok, we usually don't like it, but the time spent writting http://grub.enbug.org/TestGettext payedback very fast with the screenshots and I hope that more translators testing the translations... and people understanding a bit how it works or how to test it. Yes, I'm working on documentation, but am concentrating on user level docs. Programing documentation is another matter. Progress is slow due to outside commitments, but I'm close to updating all the web (not wiki) pages. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix a special case when accessing partition on linux
Vladimir 'φ-coder/phcoder' Serbinenko wrote: Because of cache coherency problem grub accesses partitions on linux by hdaX device and not by hda with correct offset. The problem is that because of 4K cache blocks disk.c may read sectors before the partition and hence making hostdisk.c try to read from negative offset. I'm sad that we need such workarounds for free systems. I would think it beneficial for long term code maintenance to put the above comments into the code itself. // Because of a cache coherency problem grub accesses partitions // on linux by an hdaX device and not by hda with the correct offset. // The problem is that because of 4K cache blocks, disk.c may // read sectors before the partition and hence make // hostdisk.c try to read from a negative offset. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Building Grub2 manual?
BandiPat wrote: Quick question guys! I notice there is a grub.texi file that is suppose to be built as a grub.info.gz during the build, which gives you the new manual? I'm not getting that with my build. Now maybe I don't have a program installed it needs to make that conversion, but I do not get any complaints from the build about something missing. I do get an odd empty /boot/info directory though, but this probably doesn't have anything to do with the manual build. Normally there is a manual file in different form which creates something you can read using the "man grub" command, but it appears you guys went another way? I'm working on the documentation, but it's not very close to a point where I can submit it yet. I intend to be able to have html, man and info files available from the .texi base. In the meantime, I'd recommend browsing the wiki. http://grub.enbug.org/ -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
GRUB FAQ
I'm working on updating the GRUB FAQ. So far I've got the following questions. Does anyone have any corrections or additional questions? After I define the questions, I'll work on the answers. :) -- Bruce 1. I have questions about GRUB! 2. Why did you need to rewrite GRUB? 3. How does GNU GRUB differ from GRUB Legacy? 4. Where is the documentation? 5. Can GRUB boot my operating system from large hard disks? 6. How are partitions specified? It seems to be very different from the notation in my operating system. 7. How can I boot Windows (or DOS) from a non-first disk? 8. Can I install GRUB to a partition boot sector? 9. How do I uninstall GRUB from my hard disk drive? 10. I installed GRUB, but it just hangs up. What now? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Is it possible to have grub2's boot.img as my MBR, but have it look in a separate partition for core.img?
Wesley Smith wrote: It would be nice if Grub2 could both make a partition bootable and also install an MBR that relied on that partition (rather than the embedded core.img). I know this is "dangerous," but it is necessary sometimes, and it was not at all difficult to accomplish with legacy Grub. I'm not a core GRUB developer, but how would you do it? Let's see, you have 512 bytes minus some space for the partition table. You want to access the file system in the space. Lets see, is that fat, ext, reiser, jfs, xfs, ntfs, lvm, raid, or something else? Do you want a splash screen with that? Somebody will. Are you booting over a serial line? A network card? Do you want that for linux, one of the bsd's, windows, solaris, or beos? Is that for intel, sparc, or powerpc? Remember, you have about 448 bytes... -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] nested partitions
Robert Millan wrote: On Fri, Jan 22, 2010 at 07:03:21PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: Partition types are easily screwed. Why not just check for the presence of the label? I have a feeling I already explained this somewhere. Doesn't seem to be in this thread, maybe on IRC? Anyway, it won't hurt to ellaborate on it... First of all, the whole label type proliferation problem is inherently impossible to resolve by technical means. Labels overlap each other, they can coexist without any garantee that the user expects them to be there at all or include meaningful data. There is a fairly long thread at util-linux-ng that discusses this problem in the context of very slow and very small devices. It starts approximately at http://marc.info/?l=util-linux-ng&m=126353611105795&w=2 The ultimate solution was to not search for multiple partition type signatures on small devices. You *can't* reliably check for any partition label. ... So instead of supporting things like: (hd0,1) (hd0,2) (ambigous; what does this mean in an hybrid MSDOS/GPT ? What about other hybrid schemes? GRUB can't tell!) ... we could support: (hd0,msdos1) (hd0,gpt1) (hd0,msdos2) (hd0,gpt2) whose meaning is pretty clear. Then the user can nest as much as they like, but they will also have to deal with the problem of identifiing the labels. I like this idea, but wonder if it would be useful to have something like (grub drive, partition type, filesystem type) for each partition to consider. For example: (hd0,gpt1,ext2) Minix: (hd0,msdos1,msdos1) Solaris: (hd0,msdos2,sun1) *BSD: (hd0,msdos3,bsd1) With this approach, the burden is no longer in GRUB. Then I don't care how weird disk layouts can become, because GRUB doesn't have to probe them. We can even support things like this if it makes users happy: (hd0,bsd2,msdos1,sun1,apple4,msdos1) Can you translate that. I don't understand. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bazaar workflow for GRUB
BVK Chaitanya wrote: Attached is the initial version of workflow document for GRUB contributions. I am yet to get right DVCS right, so I suspect it might have minor differences from what other developers are following already. I can't comment on details, but thank you for this. It is very helpful to me. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Dynamic device.map
Felix Zielcke wrote: Am Donnerstag, den 07.01.2010, 23:27 -0600 schrieb Bruce Dubbs: OK, I didn't realize set root was capable of using UUIDs. I did know that the two root entries were different. I got that mixed up with the search command combined with the root=UUID=... which I think needs initrd. Do I have it right now? set root only supports plain GRUB devices. search --set sets $root (for GRUB, not for Linux) to the first device found with that UUID, LABEL or file. Depending on the other argument to search command. Should 'set root' be renamed to 'set grubroot'? I think something like that would prevent some confusion. I don't get why there's a confusion at all. It should be clear that the value specified with the linux command is for it and not for GRUB. It's not confusing if you've been around GRUB for a while, but it is confusing for new users. The term 'root' is overloaded and only distinguished by context. The two contexts do have similar meanings so the differences are really fairly subtle. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Dynamic device.map
Colin Watson wrote: On Thu, Jan 07, 2010 at 04:18:37PM -0600, Bruce Dubbs wrote: Robert Millan wrote: On Wed, Jan 06, 2010 at 04:00:23PM +, Colin Watson wrote: Just leave it with (/dev/foo). You mean literally with the parentheses? I don't understand, since /dev/ names will be unintelligible to GRUB when running outside an operating system. Yes. This just means we'd have "set root=(/dev/foo)" statements in grub.cfg, but those are just meant as a backward compatibility hack for pre-UUID GRUB installs. Are you are implying that UUID will be the only way? I don't use initrd's on my systems so I need root=(hd0,x) or root=(/dev/foo). AFAIK initrd is the only way to load with UUIDs. I think you're mixing up two different things. There are two 'root' variables involved: 1) GRUB's 'root' variable, its base for filesystem operations 2) The root= parameter passed to the Linux kernel, which identifies the desired root filesystem Robert is talking about 1), but whether you use an initrd/initramfs is only relevant to 2). OK, I didn't realize set root was capable of using UUIDs. I did know that the two root entries were different. I got that mixed up with the search command combined with the root=UUID=... which I think needs initrd. Do I have it right now? Should 'set root' be renamed to 'set grubroot'? I think something like that would prevent some confusion. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Dynamic device.map
Robert Millan wrote: On Wed, Jan 06, 2010 at 04:00:23PM +, Colin Watson wrote: Just leave it with (/dev/foo). You mean literally with the parentheses? I don't understand, since /dev/ names will be unintelligible to GRUB when running outside an operating system. Yes. This just means we'd have "set root=(/dev/foo)" statements in grub.cfg, but those are just meant as a backward compatibility hack for pre-UUID GRUB installs. Are you are implying that UUID will be the only way? I don't use initrd's on my systems so I need root=(hd0,x) or root=(/dev/foo). AFAIK initrd is the only way to load with UUIDs. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB Faq
Robert Millan wrote: On Tue, Jan 05, 2010 at 12:08:28AM -0600, Bruce Dubbs wrote: I've been working on grub.texi and I notice a reference to http://www.gnu.org/software/grub/grub-faq.html. I will change that to grub-2-faq.en.html before I submit it. Actually, I'd rather ditch the old FAQ and replace it completely. In general, references to "GRUB 2" need to disappear from the website, wiki and documentation. Now that GRUB Legacy is completely obsolete it's not necessary to make the distinction in most contexts. Would you be interested in adapting the website? I can do that if I have permissions. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [BRANCH] Bidi support.
Vladimir 'φ-coder/phcoder' Serbinenko wrote: Bruce Dubbs wrote: Is there a location where the grub.cfg file that generated the image can be viewed? Attached. Mostly based on Colin's overlay grub.cfg. Excellent. It helps me a lot. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [BRANCH] Bidi support.
Vladimir 'φ-coder/phcoder' Serbinenko wrote: Hello, all. I'm here to announce initial bidi support in one of my branches, namely people/phcoder/bidi. Looks very nice. Is there a location where the grub.cfg file that generated the image can be viewed? -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB Faq
Lapohos Tibor wrote: To clarify, I was talking about the headings: Building / Installation from Source Build Prerequisites Example This is covered in the INSTALL file. I've submitted a new one, but it hasn't been committed. In the meantime you can get most of what you need from: http://www.linuxfromscratch.org/lfs/view/development/chapter06/grub.html http://www.linuxfromscratch.org/lfs/view/development/chapter08/grub.html It covers the basics, but many distros add a lot of customization and automation that is not in the above links. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
GRUB Faq
I've been working on grub.texi and I notice a reference to http://www.gnu.org/software/grub/grub-faq.html. I will change that to grub-2-faq.en.html before I submit it. I think we should come up with a new list of FAQs here and agree on the answers. I'll be glad to format it. The current questions are: Why do you need to rewrite GRUB? What is the status of GRUB 2? I would remove both of these and and start with: I have questions about GRUB2! What operating systems does GRUB2 support? What hardware platforms does GRUB2 support? How does GRUB2 differ from GRUB Legacy (GRUB1)? How do I create a GRUB2 boot floppy? How do I create a GRUB2 boot CD-ROM? How are partitions specified? That seems to be very different from the notation in my operating system... How do I uninstall GRUB2 from my hard disk drive? I installed GRUB, but it just hangs up. What now? --- What others would you suggest? By the way, validator.w3.org says grub-2-faq.en.html has 24 errors, but that cascades errors. I only see 5 errors. I imagine the page is formatted by a standard header + body + standard footer, but there is one html error in the header too: ... alt="image of the Head of a GNU" width="129" height"122" /> height is missing an = sign. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: autogen.sh warnings
Robert Millan wrote:
On Mon, Dec 28, 2009 at 09:50:47PM -0600, Bruce Dubbs wrote:
Robert Millan wrote:
What is exactly the problem?
Using automake without Makefile.am is non-standard and not provided for
within automake. The only thing we use automake for is to copy
config.{guess,sub} to the root of the root of the source.
Also, building as one large monolithic Makefile with includes built via
scripts is probably not optimal from a comprehension point of view.
That's a long-standing problem, with no easy solution.
That's for sure.
But as for automake,
I don't think it'd be a bad idea to migrate Makefile.in to Makefile.am. We
already have kludges in Makefile.in (e.g. docs/version.texi generation) which
would completely disappear if this file was automake'd.
Any takers?
I thought about it, but I really don't have much experience writing for
autotools. AFAICT, it would require getting rid of all the ruby and
gen*.sh scripts and generally be very invasive.
As you know, GRUB supports many OSes, file systems, and BIOSes. The
nature of the process is closer to an operating system than a standard
program. The more I look at it, the more impressed I am that you guys
get as much as you do working.
I think it would take many iterations to get an autotooled build system
right.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.info
Bruce O. Benson wrote: If the brz repo guys want to use another manual, then perhaps the wiki page could be moved to "QuickStart" or something fitting. Ideally, the wiki 'Manual' page and the info document would track each other. I don't know how copyright issues would be handled though. -- Bruce Dubbs ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.info
Bruce O. Benson wrote: If I: - ...merged the contents of both existing documents into a new one... - ...that adhered to the outline you enumerated... - ...assigned copyright to FSF... - ...rendered in texi, html, and pdf. ...Would that be useful for someone to check in to trunk/docs? I don't wanna get deep into a piece of work like that if it's not wanted. Well I volunteered to do the texi. That's not my favorite format, but it's the Gnu standard. If I was choosing formats, I'd do it in XML and generate text, html, and pdf from the same source. Currently I've been studying code to try to get the appropriate background for the texi, but I do have a preliminary text file started, but it really is only an outline right now. I don't have a schedule established. but was thinking I'd have sometihng for review in the next month or two. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.info
Bruce O. Benson wrote:
I have examined the hierarchy of the manual and it currently has the
structure below. I also did some research and propose a different
layout, also shown below.
The current layout of the grub2 manual is actually here:
http://grub.enbug.org/Manual
From one Bruce to another:
The content of bzr trunk/docs has a file, grub.texi. Line 6 says:
@settitle GNU GRUB Manual @value{VERSION}
The wiki is indeed helpful, but not the official GRUB Manual. Both
'Manuals' are terribly incomplete.
-- Bruce Dubbs
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
