Re: fs/ntfscomp.c:82:11: error: ‘flg’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
On 3/27/20 7:45 AM, Daniel Kiper wrote: >> _is_ a 'clear' env expected/recommended/required for a grub2 build? > > You control your own build environment. So, if you add options which are > not supported by the GRUB then there is pretty good chance that the > build or generated output will fall apart at some point. However, if you > think a given compiler option should be supported by the GRUB or even > used by default please provide a patch with good explanation why we > should take it. sure. builds using opensuse buildservice online are currently failing using 'default' build env. atm, that appears to be just to due to the patches, discussed here, not yet landing in release used. i can't yet say what, if anything, of the default _flags_ in use cause a problem -- need to check again if optimization, as causing a problem here, is among them. >> if so, does this need to be handled at config time? > > I am not sure what do you mean by that. just a simple check at 'configure' ... e.g. if optimization is set, raise an error. thx ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: fs/ntfscomp.c:82:11: error: ‘flg’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
On 3/26/20 1:39 AM, Paul Menzel wrote: > I am unable to reproduce this with 1st sanity re-check: I _am_ able to reproduce this consistently, with same error. I've tested now on multiple machines; not identical, but all similarly opensuse + GCC10 dev envs ... > Here is the code in question: snip > Why is it complaining complaining in line 82 and not 78, where `flg` is > already accessed? On 3/26/20 3:39 AM, Michael Chang wrote: > Looking into build log, the build option seems to have been overridden > with CFLAGS settings like this. > > CFLAGS="-O3 -Wall -fstack-protector-strong -funwind-tables > -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches > -march=native -mtune=native" > > I'm not sure if -O3 is considered as supported since that will result > in larger binaries we are striving to reduce all the time. Also the > optimization it brings would require careful review if we don't enable > it by default. > > In addition, -fstack-protector-strong breaks the build even harder with > a lot of __stack_chk_fail undefined symbol in the modules. > > If going with default build option, I also don't have this compliation > error. indeed. building with unset CC CPP + unset LD CFLAGS CPPFLAGS CXXFLAGS ./bootstrap ./autogen.sh ./configure \ --prefix=/usr/local/grub-build-test make V=1 completes without error, and installs, /usr/local/grub-build-test/bin/grub-mkrescue --version /usr/local/grub-build-test/bin/grub-mkrescue (GRUB) 2.05 which I can certainly manage easily enough for local build. > If going with default build option _is_ a 'clear' env expected/recommended/required for a grub2 build? if so, does this need to be handled at config time? in either case, this > Why is it complaining complaining in line 82 and not 78, where `flg` is > already accessed? doesn't make sense to me; code looks straightforward enough. the -03 optimization sounds a good 1st guess. also, Michael, fyi, I _think_ this^ started for me with linked GCC10 builds of grub2 on opensuse OBS ... where, iirc, the builds 1st failed, and I started testing locally. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: disk/mdraid1x_linux.c:181:15: warning: array subscript ...
On 3/25/20 8:29 PM, Michael Chang wrote: >> with your patches, no immediate mdraid1x or zfs build errors > > Thanks a lot for your test and validation. > >> one does surface, now, for ntfscomp ... > > I am also using openSUSE, somehow I didn't have the ntfscomp build error > on my gcc-10 build test. :( > > Would you mind to start a new thread for it ? > > Thanks, > Michael done --> https://lists.gnu.org/archive/html/grub-devel/2020-03/msg00240.html o/ ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
fs/ntfscomp.c:82:11: error: ‘flg’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
building cd grub git log | head -n5 commit 552c9fd08122a3036c724ce96dfe68aa2f75705f Author: Patrick Steinhardt Date: Sat Mar 7 17:29:09 2020 +0100 gnulib: Fix build of base64 when compiling with memory debugging with gcc --version gcc (SUSE Linux) 10.0.1 20200324 (experimental) [revision 75c24a08d697d6442fe6c26142f0559f803af977] patched patch -p1 < /tmp/grub_patches/grub_patches/0001-mdraid1x_linux-Fix-gcc10-error-Werror-array-bounds.patch patching file grub-core/disk/mdraid1x_linux.c patch -p1 < /tmp/grub_patches/grub_patches/0002-zfs-Fix-gcc10-error-Werror-zero-length-bounds.patch patching file grub-core/fs/zfs/zfs.c patching file include/grub/zfs/zap_leaf.h from https://lists.gnu.org/archive/html/grub-devel/2020-03/msg00222.html config's ok unset CC CPP ./bootstrap ./autogen.sh ./configure build FAILs make V=1 gcc -DHAVE_CONFIG_H -I. -Wall -W -DGRUB_UTIL=1 -D_FILE_OFFSET_BITS=64 -I./include -DGRUB_FILE=\"grub-core/fs/ntfscomp.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 -O3 -Wall -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches -march=native -mtune=native -D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64 -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 -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 -O3 -Wall -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches -march=native -mtune=native -MT grub-core/fs/libgrubmods_a-ntfscomp.o -MD -MP -MF grub-core/fs/.deps-util/libgrubmods_a-ntfscomp.Tpo -c -o grub-core/fs/libgrubmods_a-ntfscomp.o `test -f 'grub-core/fs/ntfscomp.c' || echo './'`grub-core/fs/ntfscomp.c grub-core/fs/ntfscomp.c: In function ‘read_block’: grub-core/fs/ntfscomp.c:82:11: error: ‘flg’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 82 | if (flg & 0x8000) | ^~~ grub-core/fs/ntfscomp.c:74:17: note: ‘flg’ was declared here 74 | grub_uint16_t flg, cnt; | ^~~ cc1: all warnings being treated as errors make[2]: *** [Makefile:7647: grub-core/fs/libgrubmods_a-ntfscomp.o] Error 1 make[2]: Leaving directory '/usr/local/src/grub' make[1]: *** [Makefile:11920: all-recursive] Error 1 make[1]: Leaving directory '/usr/local/src/grub' make: *** [Makefile:3772: all] Error 2 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: disk/mdraid1x_linux.c:181:15: warning: array subscript ...
On 3/25/20 8:52 AM, Paul Menzel wrote: > Thanks, but please follow the mailing list netiquette I was responding to a question asked by a developer in THIS thread ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: disk/mdraid1x_linux.c:181:15: warning: array subscript ...
On 3/25/20 12:27 AM, Michael Chang wrote:
> It would be great if you can help to test patch to solve the build
> problem for gcc-10 in your system or not.
with your patches, no immediate mdraid1x or zfs build errors
one does surface, now, for ntfscomp ...
gcc --version
gcc (SUSE Linux) 10.0.1 20200320 (experimental) [revision
7d4549b2cd209eb621453ce13be7ffd84ffa720a]
cd grub
git log -n1
1 commit 552c9fd08122a3036c724ce96dfe68aa2f75705f (HEAD -> master,
origin/master, origin/HEAD)
2 Author: Patrick Steinhardt
3 Date: Sat Mar 7 17:29:09 2020 +0100
patch -p1 <
/tmp/grub_patches/0001-mdraid1x_linux-Fix-gcc10-error-Werror-array-bounds.patch
patching file grub-core/disk/mdraid1x_linux.c
patch -p1 <
/tmp/grub_patches/0002-zfs-Fix-gcc10-error-Werror-zero-length-bounds.patch
patching file grub-core/fs/zfs/zfs.c
patching file include/grub/zfs/zap_leaf.h
unset CC CPP
./bootstrap
./autogen.sh
./configure
make V=1 -j${CORES}
...
make[2]: Entering directory '/usr/local/src/grub'
gcc -DHAVE_CONFIG_H -I. -Wall -W -DGRUB_UTIL=1 -D_FILE_OFFSET_BITS=64
-I./include -DGRUB_FILE=\"grub-core/fs/ntfscomp.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 -O3
-Wall -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables
-fmessage-length=0 -grecord-gcc-switches -march=native -mtune=native
-D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64 -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 -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 -O3 -Wall -fstack-protector-strong
-funwind-tables -fasynchronous-unwind-tables -fmessage-length=0
-grecord-gcc-switches -march=native -mtune=native -MT
grub-core/fs/libgrubmods_a-ntfscomp.o -MD -MP -MF
grub-core/fs/.deps-util/libgrubmods_a-ntfscomp.Tpo -c -o
grub-core/fs/libgrubmods_a-ntfscomp.o `test -f 'grub-core/fs/ntfscomp.c' ||
echo './'`grub-core/fs/ntfscomp.c
grub-core/fs/ntfscomp.c: In function ‘read_block’:
grub-core/fs/ntfscomp.c:82:11: error: ‘flg’ may be used uninitialized
in this function [-Werror=maybe-uninitialized]
82 | if (flg & 0x8000)
| ^~~
grub-core/fs/ntfscomp.c:74:17: note: ‘flg’ was declared here
74 | grub_uint16_t flg, cnt;
| ^~~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:7647: grub-core/fs/libgrubmods_a-ntfscomp.o]
Error 1
make[2]: Leaving directory '/usr/local/src/grub'
make[1]: *** [Makefile:11920: all-recursive] Error 1
make[1]: Leaving directory '/usr/local/src/grub'
make: *** [Makefile:3772: all] Error 2
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub/head build with pre-release GCC10 ; fail @ "grub-core/disk/mdraid1x_linux.c:181:15: error: ..."
my bad re: patch. pebkac (looking UP might help :-/ ) with diff -ur grub.ORIG/grub-core/disk/mdraid1x_linux.c grub/grub-core/disk/mdraid1x_linux.c --- grub.ORIG/grub-core/disk/mdraid1x_linux.c 2020-03-24 09:24:08.656640265 -0700 +++ grub/grub-core/disk/mdraid1x_linux.c2020-03-24 09:58:27.638619782 -0700 @@ -179,7 +179,8 @@ if (grub_disk_read (disk, sector, (char *) _roles[grub_le_to_cpu32 (sb.dev_number)] - - (char *) , + ((char *) _roles - (char *) sb) + + grub_le_to_cpu32 (sb.dev_number) * sizeof(grub_uint16_t), sizeof (role), )) return NULL; gcc10 build returns, ... make ... grub-core/disk/mdraid1x_linux.c: In function ‘grub_mdraid_detect’: grub-core/disk/mdraid1x_linux.c:182:6: error: cannot convert to a pointer type 182 | ((char *) _roles - (char *) sb) | ^ grub-core/disk/mdraid1x_linux.c:181:16: error: called object is not a function or function pointer 181 | (char *) _roles[grub_le_to_cpu32 (sb.dev_number)] |^~ make[2]: *** [Makefile:7059: grub-core/disk/libgrubmods_a-mdraid1x_linux.o] Error 1 make[2]: Leaving directory '/usr/local/src/grub' make[1]: *** [Makefile:11920: all-recursive] Error 1 make[1]: Leaving directory '/usr/local/src/grub' make: *** [Makefile:3772: all] Error 2 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub/head build with pre-release GCC10 ; fail @ "grub-core/disk/mdraid1x_linux.c:181:15: error: ..."
Thomas, On 3/24/20 7:51 AM, Paul Menzel wrote: > Dear PGNet Dev, > > > Already reported and analyzed [1]. It’d be nice, if you could verify Thomas’ > analysis. not sure I'm reading your intent from your post, > ... > I think that the following expression produces the same number without > virtual access to a virtual array member: > >(char *) _roles - (char *) sb >+ grub_le_to_cpu32 (sb.dev_number) * sizeof(grub_uint16_t) > ... with this, diff -ur grub.ORIG/grub-core/disk/mdraid1x_linux.c grub/grub-core/disk/mdraid1x_linux.c --- grub.ORIG/grub-core/disk/mdraid1x_linux.c 2020-03-24 09:24:08.656640265 -0700 +++ grub/grub-core/disk/mdraid1x_linux.c2020-03-24 09:25:20.615871693 -0700 @@ -178,8 +178,9 @@ return NULL; if (grub_disk_read (disk, sector, - (char *) _roles[grub_le_to_cpu32 (sb.dev_number)] - - (char *) , + (char *) _roles + - (char *) sb + + grub_le_to_cpu32 (sb.dev_number) * sizeof(grub_uint16_t), sizeof (role), )) return NULL; I'm seeing, ... gcc -DHAVE_CONFIG_H -I. -Wall -W -DGRUB_UTIL=1 -D_FILE_OFFSET_BITS=64 -I./include -DGRUB_FILE=\"grub-core/disk/mdraid1x_linux.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 -O3 -Wall -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches -march=native -mtune=native -D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64 -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 -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 -O3 -Wall -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches -march=native -mtune=native -MT grub-core/disk/libgrubmods_a-mdraid1x_linux.o -MD -MP -MF grub-core/disk/.deps-util/libgrubmods_a-mdraid1x_linux.Tpo -c -o grub-core/disk/libgrubmods_a-mdraid1x_linux.o `test -f 'grub-core/disk/mdraid1x_linux.c' || echo './'`grub-core/disk/mdraid1x_linux.c grub-core/disk/mdraid1x_linux.c: In function ‘grub_mdraid_detect’: grub-core/disk/mdraid1x_linux.c:183:6: error: cannot convert to a pointer type 183 | + grub_le_to_cpu32 (sb.dev_number) * sizeof(grub_uint16_t), | ^ make[2]: *** [Makefile:7059: grub-core/disk/libgrubmods_a-mdraid1x_linux.o] Error 1 my patch attempt wrong? or still needs tweaks? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
grub/head build with pre-release GCC10 ; fail @ "grub-core/disk/mdraid1x_linux.c:181:15: error: ..."
building curren head,
git clone https://git.savannah.gnu.org/git/grub.git
cd grub
git describe
grub-2.04-71-g552c9fd08
with soon(ish)-to-be-release GCC10
gcc --version
gcc (SUSE Linux) 10.0.1 20200320 (experimental) [revision
7d4549b2cd209eb621453ce13be7ffd84ffa720a]
config's OK
unset CC CPP
./bootstrap
./autogen.sh
./configure
build fails,
make V=1
...
gcc -DHAVE_CONFIG_H -I. -Wall -W -DGRUB_UTIL=1 -D_FILE_OFFSET_BITS=64
-I./include -DGRUB_FILE=\"grub-core/disk/mdraid1x_linux.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 -O3 -Wall -fstack-protector-strong -funwind-tables
-fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches
-march=native -mtune=native -D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64 -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 -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 -O3 -Wall -fstack-protector-strong -funwind-tables
-fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches
-march=native -mtune=native -MT grub-core/disk/libgrubmods_a-mdraid1x_linux.o
-MD -MP -MF grub-core/disk/.deps-util/libgrubmods_a-mdraid1x_linux.Tpo -c -o
grub-core/disk/libgrubmods_a-mdraid1x_linux.o `test -f
'grub-core/disk/mdraid1x_linux.c' || echo './'`grub-core/disk/mdraid1x_linux.c
grub-core/disk/mdraid1x_linux.c: In function ‘grub_mdraid_detect’:
grub-core/disk/mdraid1x_linux.c:181:15: error: array subscript
is outside array bounds of ‘grub_uint16_t[0]’ {aka ‘short unsigned
int[0]’} [-Werror=array-bounds]
181 | (char *) _roles[grub_le_to_cpu32 (sb.dev_number)]
| ^~~
grub-core/disk/mdraid1x_linux.c:98:17: note: while referencing
‘dev_roles’
98 | grub_uint16_t dev_roles[0]; /* Role in array, or 0x for a
spare, or 0xfffe for faulty. */
| ^
grub-core/disk/mdraid1x_linux.c:127:33: note: defined here ‘sb’
127 | struct grub_raid_super_1x sb;
| ^~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:7059:
grub-core/disk/libgrubmods_a-mdraid1x_linux.o] Error 1
make[2]: Leaving directory '/usr/local/src/grub'
make[1]: *** [Makefile:11920: all-recursive] Error 1
make[1]: Leaving directory '/usr/local/src/grub'
make: *** [Makefile:3772: all] Error 2
known/expected issue? bug-worthy? or still too early for GCC10 issues?
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: are posix-shell-compliant continuation lines valid/supported, or not, in /etc/default/grub ?
On 3/19/20 8:17 PM, PGNet Dev wrote: > On 3/19/20 8:04 PM, Eli Schwartz wrote: >> On 3/19/20 10:02 PM, Dimitri John Ledkov wrote: >>> I hope you do understand that it >>> is intended for all of the Ubuntu installer & upgrade integrations to keep >>> valid configs compatible. For anyone similarly interested, it looks like Ubu 18 *LTS* will NOT be getting a fast fix for 'this' Posix support for a bit, if at all, as it remains a ... "highly unusual configuration". https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1868138/comments/8 "So given that 8.13 is affected - which was released a year ago, and it's a highly unusual configuration, this is not in need of an urgent hotfix." ::facepalm:: Eli, your admonition to consider a more 'stable' option moves to the front of the line. Migrations to Grub + Arch & OpenSUSE spinning up today. Thx for the comments folks. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: are posix-shell-compliant continuation lines valid/supported, or not, in /etc/default/grub ?
On 3/19/20 8:04 PM, Eli Schwartz wrote: > On 3/19/20 10:02 PM, Dimitri John Ledkov wrote: >> I am sorry which email are the "quoted" phrases from? not from an email. directly from the bug I referenced, prior to coming here: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1868138/comments/4 , subsequent to chats in #irc >> Because that's nothing that I have said. sure. that's clear, and certainly not assumed! >> I hope you do understand that it >> is intended for all of the Ubuntu installer & upgrade integrations to keep >> valid configs compatible. That's the assumption -- or at least the hope -- for all the mainstream distros. And Grub's certainly about as consistent/portable/reliable/cross-everything as it gets. And appears to include aforementioned Posix script compliance for the config script. Ubu dev's proclaimation as otherwise is what caused the ... surprise ... & the questions here. Bottom line ... Grub continues to work exactly reliably/predictably, as it should. Ubu's install should be fixed, not hand-waved away for specious reasons. That can be dealt with best in the bug itself. thx. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: are posix-shell-compliant continuation lines valid/supported, or not, in /etc/default/grub ?
hi, On 3/19/20 6:41 PM, Eli Schwartz wrote: > In general, other distros avoid parsing and rewriting configs because > this should be the user's responsibility. :p > > The OP should consider that maybe such distros are more stable than Ubuntu? I do. Where I directly control them, they're in use. It includes my own spins ... All use Grub. "Happily". ;-) Ubu's a not-infrequent reality nonetheless. > The OP's question is > > "Does the grub project consider /etc/default/grub as a shell-compatible > file which is sourced, to be the PUBLIC INTERFACE of this configuration > file?" yep. well restated. > The conclusion is simple enough: if you are going to automatically > rewrite this grub file, i'd thought that non-mangling of it would be a reasonable position; that, apparently, is not a mandate, iiuc. tbh, i'm not clear _why_ it's being written at all. i agree with the "this should be the user's responsibility", and would add "only the user's prerogative". but that's me. well, maybe not JUST me ... > you must do so using a parser engine that > implements POSIX shell and knows how to properly tokenize and rewrite > the full range of language features permitted by POSIX shell. > > Doing otherwise is YOLO, rash, buggy, and prone to breakage as > demonstrated by the OP's bug report. > > If a downstream project making use of grub, then goes ahead and calls > the use of backslash escapes for the very simple purpose of line > continuation across multiple lines (of all the things one might do in a > POSIX sh formatted configuration file, this is pretty tame), an issue of > "highly unusual abuse of POSIX shell semantics", this is pretty bad I > have to say. +1 > Just my $0.02 as a distro person (not a grub dev). heh. cheap at twice the price! ;-) thx. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: are posix-shell-compliant continuation lines valid/supported, or not, in /etc/default/grub ?
hi On 3/19/20 5:57 PM, Dimitri John Ledkov wrote: > What is the bug number there? https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1868138 > In general, we advise to customize via grub.d drop-in files instead of > modifying etc/default/grub file itself. Sure, that's fine as advice. Fwiw, it's different for different distros. Declarations that using posix-compliant continuations is "highly unusual abuse of POSIX shell semantics" is a different matter. Changing/breaking behavior in managing valid/working grub configs, and rationalizing it by "I do not see a need to support it" is ... unhelpful. Particularly if Grub project/devs say that its usage *is* OK & compliant. Which is why I asked _here_; and, iiuc, seems that it *is*. Grub's stability, reproducibility and portability are critical. It all works great, particularly when the excellent docs are followed. Happy to take ongoing conversation to the bug. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
are posix-shell-compliant continuation lines valid/supported, or not, in /etc/default/grub ?
a recent grub package update, in ubuntu 18LTS, is breaking /etc/default/grub by mangling/overwriting users' entries, in the specific case of using continuation lines in the file/config. and, subsequently, the upgrade process on these servers. as stated clearly at https://www.gnu.org/software/grub/manual/grub/html_node/Simple-configuration.html#Simple-configuration-handling "... The file /etc/default/grub controls the operation of grub-mkconfig. It is sourced by a shell script, and so must be valid POSIX shell input; normally, it will just be a sequence of ‘KEY=value’ lines, but if the value contains spaces or other special characters then it must be quoted ..." per POSIX https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_01 "... Escape Character (Backslash) A that is not quoted shall preserve the literal value of the following character, with the exception of a . If a follows the , the shell shall interpret this as line continuation. The and shall be removed before splitting the input into tokens. Since the escaped is removed entirely from the input and is not replaced by any white space, it cannot serve as a token separator. ..." all that's to say that continuation lines appear to be supported in posix-shell-compliant /etc/default/grub they've been in use here, on 100s of servers, in grub configs for ages. with grub 2.04 on other, non Ubu OS, it continues to work fine. re: the use of continuation lines, ubu dev states that "Regardless of what the POSIX spec says, this is highly unusual abuse of POSIX shell semantics, and I do not see a need to support it" it'd be useful/helpful to get clear on what the 'official' grub project support for use of posix-shell-compliant continuation lines is ... are they 'supported' as valid use in /etc/default/grub, or not? also useful to know/understand whether any grub update can/should mangle a user's /etc/default/grub. allowed? expected? thx! ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub2 documentation of the GRUB_CMDLINE_*XEN* parameters -- unclear. What's _intended_?
On 11/22/2015 11:54 AM, Colin Watson wrote:
No, they aren't exclusive of one another, but are used to construct
different command lines. GRUB_CMDLINE_XEN* are used for the hypervisor
command line; GRUB_CMDLINE_LINUX_XEN_REPLACE* are used for the Linux
kernel command line (but if unset, the corresponding GRUB_CMDLINE_LINUX*
values are used instead).
The misleading description you quote was the one in 2.00, but was
clarified in git a while ago:
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=48f39bb4df5b903aaa66db9fdc6679571bff0dd9
That's exactly the helpful clarification needed. Thanks! It'd be useful
to have that updated on the grub2 website's docs -- it's just as valid
there.
And, what specifically gets mapped to Xen kernel's "options=" parameter
line?
E.g., a grub2-mkconfig-generated xen*.cfg takes the form
Upstream grub-mkconfig does not generate xen*.cfg at all. This is an
openSUSE-specific patch. From inspecting their source code, I believe
that the GRUB_CMDLINE_XEN* options will apply here.
I'd realized that there's different naming, e.g. the "grub2-mkconfig",
but had not realized this^^ diff as well.
The docs should clearly address which PARAMETERS map to the "options=" line,
and which to the kernel=" line in the Xen case.
No doubt, but it is up to the openSUSE maintainers to make sure that
Noted. The latest upgrade of the distro has proven to be quite
problematic, particularly in the real-world/modern { pv-kernel + Xen +
Grub2 + EFI } use case; and the docs are a bit of a mess. I'd
_strongly_ prefer a grub2 instance closer to upstream's. Not yet sure
what replacing the distro's with a 'clean' upstream build entails ...
Thanks again for the response.
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Grub2 documentation of the GRUB_CMDLINE_*XEN* parameters -- unclear. What's _intended_?
Grub2 documentation @ https://www.gnu.org/software/grub/manual/grub.html#Configuration states ... ‘GRUB_CMDLINE_XEN’ ‘GRUB_CMDLINE_XEN_DEFAULT’ The values of these options are appended to the values of ‘GRUB_CMDLINE_LINUX’ and ‘GRUB_CMDLINE_LINUX_DEFAULT’ for Linux and Xen menu entries. ‘GRUB_CMDLINE_LINUX_XEN_REPLACE’ ‘GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT’ The values of these options replace the values of ‘GRUB_CMDLINE_LINUX’ and ‘GRUB_CMDLINE_LINUX_DEFAULT’ for Linux and Xen menu entries. ... From these docs. it's not clear which values get mapped to which grub entries. One set 'appends', one set 'replaces'. Are they exclusive of one another? And, what specifically gets mapped to Xen kernel's "options=" parameter line? E.g., a grub2-mkconfig-generated xen*.cfg takes the form # disclaimer [global] #default= [config.1] options= dom0_mem= ... kernel=vmlinuz-4.3.0-16.gff1dcd9-xen ... ramdisk=initrd-4.3.0-16.gff1dcd9-xen ... whereas for a NON-xen grub*.cfg # disclaimer [global] #default= [config.1] kernel=vmlinuz-4.3.0-16.gff1dcd9-default ... ramdisk=initrd-4.3.0-16.gff1dcd9-default ... there's NO "options=..." line. The docs should clearly address which PARAMETERS map to the "options=" line, and which to the kernel=" line in the Xen case. To get there -- What's intended, by designn, from development in these specific *XEN* cases? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
