Bug#983435: you all forgot to fix stable
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
On Mon, 8 Mar 2021 12:20:56 +0900 bugsgrid+...@gmail.com wrote: > 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. > > Thank you for this. Your concerns should be address by: - exit() in https://lists.gnu.org/archive/html/grub-devel/2021-04/msg00118.html - misfiring in https://lists.gnu.org/archive/html/grub-devel/2021-05/msg00064.html (Note that v6 version of the patch was sent upstream now as well) Regards, Dimitri.
Bug#983435: confirmed reproducible
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:
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
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
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
On Fri, 26 Feb 2021 10:21:47 +0900 bugsgrid+...@gmail.com wrote: > 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... > > Reading the logs above I am not sure what is causing the misfire. I see that it fails to install any translations, are grub.mo from grub-common somehow excluded on the system? (i.e. with a dpkg filter) Is that the cause for the bug, or a red herring, I will try to test that. I would want to make it safer if I could. Indeed, duped by any fork() is painful. Intention is for the top level tool to decide if it is aborting or not, and unfortunately it doesn't do any sort of cleanup and just exits() whenever it is. 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? Regards, Dimitri.
Bug#983435: Regarding the backup/restore function
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...
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,