Bug#983435: you all forgot to fix stable

2021-07-22 Thread bugsgrid+deb
Control: found -1 2.02+dfsg1-20+deb10u3
Control: found -1 2.04-10
Control: fixed -1 2.04-19
# adding back versions for reopen

Seriously, I reported that the issue exists in sid _too_,
just for your convenience,
and then you fixed only sid...  what is this?

If refreshing the patch is so hard to take a time,
why not just revert it already?

IMO the offending patch itself is not suitable for stable from the very first.
I believe "stable" should prefer stable in behavior,
not some random additon of seemingly good intention.
It is not solving any bug or whatsoever, and introduced an actual bug.

Now "stable" is just stale at broken state.



Bug#983435: confirmed reproducible

2021-03-07 Thread bugsgrid+deb
Control: reassign -1 src:grub2
Control: found -1 2.04-10
Control: notfound -1 2.04-9
Control: found -1 2.02+dfsg1-20+deb10u3
Control: notfound -1 2.02+dfsg1-20+deb10u2

Turned out that the symptom was not specific to grub-efi.
It does reproduce on grub-pc too.

Short steps to test:
1) rename /bin/udevadm to something else
2) run grub-install {/dev/sda}
3) make sure no error has happened
4) look, all modules are gone!

thanks very much.



Bug#983435:

2021-03-05 Thread bugsgrid+deb
Control: retitle -1 upgrade or grub-install breaks system if udev is
not installed

May I ask what I'm supposed to do next?
As any grub packages in usual debian repositories are no longer
working for me, I'm forced to dig up snapshot.debian.org to revert
(yes I forgot to save working .deb locally, stupid was mine).
Well, I don't care any security holes only relevant under SecureBoot,
but I'm not sure if I'm actually supposed to keep hold on grub for
eternity.

Thanks,



Bug#983435: Regarding the backup/restore function

2021-02-27 Thread bugsgrid+deb
Ah, my router doesn't have udev!
In osdep/linux/hostdisk.c:sysfs_partition_path(), calling udevadm
through grub_util_exec_pipe() will fail and fall through to
*unpatched* exit().
Sounds plausible?

If my guess is right, perhaps sid is affected too.
Sorry I don't have any testbed, if anyone could confirm please adjust
bugtitle and severity accordingly.  I'm not sure about appropriate
value.

... I thought a debian installation without udev is still not illegal
nor broken ...
Thanks,



Bug#983435: Regarding the backup/restore function

2021-02-26 Thread bugsgrid+deb
On Fri, 26 Feb 2021 15:21:59 +
Dimitri John Ledkov  wrote:

>are grub.mo from grub-common somehow excluded on the system?

I have no idea, I don't have localepurge installed on that machine.
I belive those missing grub.mo's are actually not in debian's
grub-common, or rather, not in the entire debian archive.  At least,
packages.debian.org/search doesn't show e.g. /fa/LC_MESSAGES/grub.mo
anywhere anysuite, so no one in debian world should have that file...?

Being just a router, the machine have very minimum packages installed
(besides gcc to compile kernel), so there may be some missing
executables used by grub-install.  For reference, the list of
installed packages (distilled from /var/lib/dpkg/status of the disk
image) is pasted below.

>For me to avoid doing it on_exit()
>would mean to rewrite all the places where grub_install tries to exit
>to try to do cleanups & restores. Would doing it in grub-install
>without on_exit inspire more confidence, or guarding to only do
>anything in the main_pid of grub-install? Should the log of actions be
>maintained and then rolled back only if they can be?

I'm not familiar to codes, take with a grain of salt:

Given the structure of upstream code, entirely avoiding on_exit()
would result to more intrusive patch.
As for log-and-rewind strategy (with or without on_exit)... I thought
that first, but then isn't it better to stop creating new installs
in-place from the very first?  Instead create new in temporary, and
finally swap old with new.  As the modules directory should once have
been created by grub-install itself, I thought we're allowed to move
it around, and then we don't have to track all of individual old
files...?

But for now, guarding by main_pid, patching up every fork()'s, and
proper logging for --verbose would be nice to have, I guess.  Of
course, BIG RED BOLD BANNER and couple of beeps should be put whenever
detected misfire :-)

Thanks in advance,

list of installed packages on my problematic router:

adduser apt aptitude aptitude-common attr base-files base-passwd bash
bc binutils binutils-common binutils-x86-64-linux-gnu bison
bsdmainutils bsdutils build-essential bzip2 conntrack
console-setup-linux console-setup-mini coreutils cpio cpp cpp-8 dash
debconf debian-archive-keyring debianutils dhcpcd5 diffutils dmsetup
dns-root-data dnsmasq dnsmasq-base dosfstools dpkg dpkg-dev e2fsprogs
ethtool fakeroot false-sendmail false-strongswan-starter
false-unbound-anchor fcron fdisk findutils flex g++ g++-8 gcc gcc-8
gcc-8-base gettext-base gpgv grep groff-base grub-common
grub-efi-amd64 grub-efi-amd64-bin grub2-common gzip hostname ifupdown
init init-system-helpers initscripts insserv iproute2
iputils-tracepath kbd keyboard-configuration kmod ldnsutils libacl1
libapt-pkg5.0 libasan5 libatomic1 libattr1 libaudit-common libaudit1
libbinutils libbison-dev libblkid1 libboost-iostreams1.67.0
libboost-system1.67.0 libbsd0 libbz2-1.0 libc-bin libc-dev-bin
libc-l10n libc6 libc6-dev libc6-i386 libcap-dev libcap-ng0 libcap2
libcap2-bin libcc1-0 libcom-err2 libcurl4 libcwidget3v5 libdb5.3
libdbus-1-3 libdebconfclient0 libdevmapper1.02.1 libdpkg-perl
libefiboot1 libefivar1 libelf1 libevent-2.1-6 libexpat1 libext2fs2
libfakeroot libfdisk1 libffi6 libfreetype6 libfuse2 libgcc-8-dev
libgcc1 libgcrypt20 libgdbm3 libglib2.0-0 libgmp10 libgomp1
libgpg-error0 libhogweed4 libidn11 libip4tc0 libip6tc0 libisl19
libitm1 libivykis0 libjansson4 libjson-c3 libkmod2 libldns2
liblocale-gettext-perl liblsan0 liblz4-1 liblzma5 libmnl0 libmount1
libmpc3 libmpdec2 libmpfr6 libmpx2 libncurses-dev libncurses6
libncursesw6 libnet1 libnetfilter-acct1 libnetfilter-conntrack3
libnetfilter-log1 libnettle6 libnewt0.52 libnfnetlink0 libnftables1
libnftnl11 libpam-modules libpam-modules-bin libpam-runtime libpam0g
libpcap0.8 libpcre3 libperl5.24 libpipeline1 libpng16-16 libpopt0
libprocps7 libprotobuf-c1 libpython3.7 libpython3.7-minimal
libpython3.7-stdlib libquadmath0 libreadline7 libselinux1
libsemanage-common libsemanage1 libsepol1 libsigc++-2.0-0v5
libsigsegv2 libslang2 libsmartcols1 libsqlite3-0 libss2 libssl-dev
libssl1.1 libstdc++-8-dev libstdc++6 libstrongswan
libstrongswan-standard-plugins libsystemd0 libtinfo6 libtsan0
libubsan1 libudev1 libustr-1.0-1 libutempter0 libuuid1 libwrap0
libxapian30 libxtables12 linux-image-4.19.171 linux-libc-dev
linux-source-4.19 locales login lsb-base lv m4 make makedev man-db
mawk mime-support mount ncurses-base ncurses-bin netbase nftables
ngetty openssl passwd patch perl perl-base perl-modules-5.24
pkg-config procps readline-common rng-tools5 screen sed sensible-utils
startpar strongswan-charon strongswan-libcharon strongswan-swanctl
syslog-ng-core syslog-ng-mod-getent syslog-ng-mod-journal sysv-rc
sysvinit-core sysvinit-utils tar tzdata ucf ulogd2 ulogd2-pcap unbound
util-linux watchdog whiptail xz-utils zlib1g zlib1g-dev

(note: false-* is dummies to shut up dpkg, but I'm fairly sure they're
not related to grub, never.)



Bug#983435: Regarding the backup/restore function

2021-02-25 Thread bugsgrid+deb
Regarding the backup/restore function
in the commit bb3205709aa9f83e1c8cb91e7f6f9f110d41b34e,
for me it seems bringing in more critical dangers than the safety it provides.

The logic is too error prone, it relies on on_exit() absolutely never
duped by any fork()'s,
meaning it's requiring absolutely every fork() in the entire code to be patched.
And there is no safeguard against misfiring of restore_backup_on_exit().
It itself is "just irrevocably removing them as the first action,"
even if there is nothing to be restored.
Oh well.

I bet it's better to set onhold on grub for now...



Bug#983435: Just a wild guess...

2021-02-25 Thread bugsgrid+deb
Hi mainteners,

Given the observations, I feel it very likely being caused by
misfiring of restore_backup_on_exit(), and looking around the source
tree I found something suspicious:

In the commit 5dec0f2f9cd4d4dd0109c25cd2b399a780179020,
| unix exec: avoid atexit handlers when child exits
| Needed in buster to avoid problems with backup/restore in grub-install.

exit()'s in grub-core/osdep/unix/exec.c:grub_util_exec_redirect_all()
are all replaced with _exit(),
but grub_util_exec_pipe() and grub_util_exec_pipe_stderr() are left
as-is, having exit() right after execvp() which is same to
grub_util_exec_redirect_all() before the patch.  Is this correct?

Sorry this is just a wild guess, I don't know if this actually can
cause the simptom, nor if this path is actually run...

Additional info:
- GPT partitions are just FAT32 EFI system + ext4 single flat root,
there's nothing else.
- It's just a router, nothing fancy is installed.  Yay sysvinit.
- The kernel is built from debian linux-source-4.19 (currently at 4.19.171-2)
-- everything built-in without modules, with a minor patch
(pastebin.com/raw/ikQKniWK).
--- because of the mentioned glitch, the official debian linux-image
doesn't work very well. (sure it boots, it doesn't hang, but...)

Thanks in advance,