On up-to-date MGA 7, running `urpmi -v --auto-update' over ssh, which brings in the new kernel, the process seems to hang at "Creating: target|kernel|dracut args|basicmodules" as this is the last message in the terminal, never returning to prompt, even after more than half an hour. This has happened on the last two kernel upgrades. I try Ctrl-C, which has no effect, then Ctrl-Z, which returns the prompt. However, the urpmi command is still running, database locked. I try `kill -sighup [pid]', which doesn't stop urpmi, then `kill -9'. Reboot is to a grub prompt. There is no menu from which I might choose another kernel. I recover with eufi net-install and choose to upgrade the MGA7 installation. This last time, I checked /boot before rebooting, saw the new kernel, and noticed one anomaly: vmlinuz-desktop pointed to the new kernel but vmlinuz pointed to the previous one, or the other way around. :P After recovering, both links are to the new kernel. There are many machines on the LAN and four are actively kept up-to-date with MGA7. Consequently, for one reason, memories of what happens when, where are not always clear. The main desktop, from which I usually administer the others over ssh, did the same update in the rpmdrake gui without incident. The previous update on that desktop might or might not have been in terminal. Once recovered from the latest problem, as stated, there was an additional problem with dhcp ethernet network wherein the adapter was reported as "deactivated". The applet was spinning and seemed to be cycling through the connection attempt, returning to "deactivated" every couple of seconds. I briefly tried re-making the connection in mcc but have resorted to running from the older kernel. This problem is probably separate. Some details about the machine where this occurred: [root@z170i rolf]# inxi -b X11 connection rejected because of wrong authentication. System: Host: z170i Kernel: 5.3.13-desktop-2.mga7 x86_64 bits: 64 Console: tty 0 Distro: Mageia 7 mga7 Machine: Type: Desktop Mobo: ASUSTeK model: Z170I PRO GAMING v: Rev X.0x serial: 151056350800230 UEFI: American Megatrends v: 3805 date: 05/16/2018 CPU: Quad Core: Intel Core i5-6500 type: MCP speed: 3309 MHz min/max: 800/3600 MHz X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. Graphics: Device-1: Intel HD Graphics 530 driver: i915 v: kernel Display: server: X.org 1.20.5 driver: intel,v4l tty: 109x29 Message: Advanced graphics data unavailable for root. Network: Device-1: Intel Ethernet I219-V driver: e1000e Device-2: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter driver: ath10k_pci I am only guessing at kernel as the relevant source rpm. Thanks.
Created attachment 11408 [details] record of manually running dracut I forgot to state that bluetooth, paired to a PS3 BD controller and automatically connecting with previous kernels, has also stopped working as expected. I tried re-creating initrd.img with `dracut -f /boot/initrd-5.4.2-desktop-1.mga7.img 5.4.2-desktop-1.mga7' (over ssh) and a record of that exercise is attached. Network and bluetooth symptoms look to be unchanged.
Such problems can arise simply because the partition holding /boot/ is full up. I doubt that you would allow or not notice this, but please check just in case. Assigning this to the kernel team.
Assignee: bugsquad => kernel
I can overlook anything, given the chance, but full partitions doesn't seem to be the cause. Thanks. [rolf@z170i ~]$ df Filesystem Size Used Avail Use% Mounted on devtmpfs 7.8G 0 7.8G 0% /dev tmpfs 7.8G 546M 7.3G 7% /dev/shm tmpfs 7.8G 1.8M 7.8G 1% /run /dev/sdb2 25G 17G 7.7G 69% / tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup tmpfs 7.8G 96K 7.8G 1% /tmp /dev/sdb3 63G 37G 26G 59% /home /dev/sdb1 247M 128K 247M 1% /boot/EFI 192.168.1.101:/home/rolf/jobs 1.7T 1.1T 600G 66% /jobs 192.168.1.101:/News/Pan 306G 207G 99G 68% /Pan 192.168.1.109:/mnt/750 699G 244G 456G 35% /mnt/750 192.168.1.101:/movie 684G 514G 171G 76% /movie 192.168.1.104:/mnt/sda2/stuff 3.6T 3.5T 125G 97% /mnt/stuff 192.168.1.186:/mnt/sda2/Public/RW 917G 552G 365G 61% /mnt/320a 192.168.1.104:/mnt/323/Public/RO/ 3.6T 2.8T 621G 83% /mnt/323 tmpfs 1.6G 24K 1.6G 1% /run/user/501
FWIW, using the gui rpmdrake on the z170i machine, I removed all the kernels and kernel-devels, from -latest on back, except the newest working 5.3.13-desktop-2.mga7. The new kernel-latest installed without incident, bootloader was installed, and I was able to boot into kernel-desktop-5.4.2-1. [rolf@z170i mga7]$ ll /boot/ total 50825 -rw-r--r-- 1 root root 229609 Nov 25 15:01 config-5.3.13-desktop-2.mga7 -rw-r--r-- 1 root root 231103 Dec 5 12:37 config-5.4.2-desktop-1.mga7 drwxr-xr-x 2 root root 48 Mar 26 2019 dracut/ drwxrwxrwx 3 root root 512 Dec 31 1969 EFI/ -rwxr-xr-x 1 root root 581120 Dec 13 19:09 gfxmenu* drwxr-xr-x 7 root root 408 Dec 15 04:54 grub2/ -rw------- 1 root root 14643111 Dec 7 06:04 initrd-5.3.13-desktop-2.mga7.img -rw------- 1 root root 14700336 Dec 15 04:54 initrd-5.4.2-desktop-1.mga7.img lrwxrwxrwx 1 root root 31 Dec 15 04:54 initrd-desktop.img -> initrd-5.4.2-desktop-1.mga7.img lrwxrwxrwx 1 root root 31 Dec 15 04:54 initrd.img -> initrd-5.4.2-desktop-1.mga7.img -rw-r--r-- 1 root root 191732 Nov 25 15:01 symvers-5.3.13-desktop-2.mga7.xz -rw-r--r-- 1 root root 193000 Dec 5 12:37 symvers-5.4.2-desktop-1.mga7.xz -rw-r--r-- 1 root root 4145949 Nov 25 15:01 System.map-5.3.13-desktop-2.mga7 -rw-r--r-- 1 root root 4136558 Dec 5 12:37 System.map-5.4.2-desktop-1.mga7 lrwxrwxrwx 1 root root 28 Dec 15 04:54 vmlinuz -> vmlinuz-5.4.2-desktop-1.mga7 -rw-r--r-- 1 root root 6437248 Nov 25 15:01 vmlinuz-5.3.13-desktop-2.mga7 -rw-r--r-- 1 root root 6486400 Dec 5 12:37 vmlinuz-5.4.2-desktop-1.mga7 lrwxrwxrwx 1 root root 28 Dec 15 04:54 vmlinuz-desktop -> vmlinuz-5.4.2-desktop-1.mga7 [rolf@z170i mga7]$ rpm -qa | grep kernel kernel-desktop-latest-5.4.2-1.mga7 kernel-desktop-devel-5.3.13-2.mga7-1-1.mga7 kernel-doc-5.4.2-1.mga7 kernel-userspace-headers-5.4.2-1.mga7 kernel-desktop-5.4.2-1.mga7-1-1.mga7 kernel-desktop-devel-latest-5.4.2-1.mga7 kernel-desktop-devel-5.4.2-1.mga7-1-1.mga7 kernel-firmware-nonfree-20190926-1.mga7.nonfree kernel-firmware-20190603-1.mga7 kernel-desktop-5.3.13-2.mga7-1-1.mga7 [rolf@z170i mga7]$ However, ethernet gets deactivated and configuring in the network applet doesn't get it going. The kernel module, e1000e that works in previous kernels gets loaded but the adapter is deactivated. [rolf@z170i ~]$ sudo lsmod | grep e1 e1000e 286720 0 ptp 20480 1 e1000e [rolf@z170i ~]$ inxi -n Network: Device-1: Intel Ethernet I219-V driver: e1000e IF: enp0s31f6 state: down mac: f8:32:e4:9f:2f:7a [rolf@z170i ~]$ On the working kernel: [rolf@z170i ~]$ inxi -n Network: Device-1: Intel Ethernet I219-V driver: e1000e IF: enp0s31f6 state: up speed: 1000 Mbps duplex: full mac: f8:32:e4:9f:2f:7a [rolf@z170i ~]$ That looks like for another bug but I'll leave this one open to possibly test the ssh update on the next one.
A similar cli upgrade of the kernel on another machine via ssh worked as expected. Slightly different inxi output from before issuing `urpmi -v --auto-update`: [root@d90d7 ~]# inxi -b System: Host: d90d7 Kernel: 5.3.13-desktop-2.mga7 x86_64 bits: 64 Console: tty 0 Distro: Mageia 7 mga7 Machine: Type: Desktop System: WYSE product: D CLASS v: Rev 1 serial: 9FEDLA02266 Mobo: Inventec model: D CLASS v: A02 serial: 9FEDLA02266 UEFI: Phoenix v: 3.0D date: 05/06/2013 CPU: Dual Core: AMD G-T48E type: MCP speed: 1397 MHz min/max: 777/1400 MHz Graphics: Device-1: AMD Wrestler [Radeon HD 6250] driver: radeon v: kernel Display: tty server: Mageia X.org 1.20.5 driver: radeon,v4l FAILED: ati resolution: 1440x900~60Hz OpenGL: renderer: llvmpipe (LLVM 8.0 128 bits) v: 3.3 Mesa 19.2.6 Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 Drives: Local Storage: total: 14.91 GiB used: 7.27 GiB (48.8%) Info: Processes: 153 Uptime: 17d 22h 04m Memory: 3.45 GiB used: 1.54 GiB (44.6%) Shell: bash inxi: 3.0.33 and after reboot: [root@d90d7 rolf]# inxi -b X11 connection rejected because of wrong authentication. System: Host: d90d7 Kernel: 5.4.2-desktop-1.mga7 x86_64 bits: 64 Console: tty 0 Distro: Mageia 7 mga7 Machine: Type: Desktop System: WYSE product: D CLASS v: Rev 1 serial: 9FEDLA02266 Mobo: Inventec model: D CLASS v: A02 serial: 9FEDLA02266 UEFI: Phoenix v: 3.0D date: 05/06/2013 CPU: Dual Core: AMD G-T48E type: MCP speed: 1397 MHz min/max: 777/1400 MHz X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. Graphics: Device-1: AMD Wrestler [Radeon HD 6250] driver: radeon v: kernel Display: server: X.org 1.20.5 driver: radeon,v4l FAILED: ati tty: 109x29 Message: Advanced graphics data unavailable for root. Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 Drives: Local Storage: total: 14.91 GiB used: 6.95 GiB (46.6%) Info: Processes: 148 Uptime: 30m Memory: 3.45 GiB used: 940.3 MiB (26.6%) Shell: bash inxi: 3.0.33
kernel-desktop-latest-5.4.6-2.mga7.x86_64 appeared on the mirrors and I was notified by the applet 12/25. Merry Christmas! On the desktop: [rolf@z77x4 ~]$ sudo urpmi -v --auto-select Just now, after next boot: [rolf@z77x4 ~]$ uname -r 5.4.6-desktop-2.mga7 All is as expected on the desktop. As promised, in an ssh session from this primary desktop to the machine that exhibited the hang initially, I started a tmux session, in order to be able to shut down the desktop without disturbing the processes. In that session, I did `sudo urpmi -v --auto-select'. The update stopped at the same place. I detached tmux, exited ssh, shut down the desktop, and went to sleep. Now, it is about 9 hours later and the urpmi process is still running on the problematic machine: [rolf@z170i ~]$ ps aux | grep urpmi rolf 16669 0.0 0.0 12136 760 pts/0 S+ 04:24 0:00 grep --color urpmi root 20371 0.0 0.0 17720 5072 pts/1 S+ Dec25 0:00 sudo urpmi -v --auto-select root 20376 0.0 1.0 190928 174108 pts/1 S+ Dec25 0:10 /usr/bin/perl /sbin/urpmi -v --auto-select The tmux session is where I left it: ... removing upgraded package lib64xatracker2-19.2.6-1.mga7.x86_64 47/49: removing lib64xatracker2-19.2.6-1.mga7.x86_64 ########################################################################## removing upgraded package lib64xfs1-5.2.1-1.mga7.x86_64 48/49: removing lib64xfs1-5.2.1-1.mga7.x86_64 ########################################################################## removing upgraded package xfsprogs-5.2.1-1.mga7.x86_64 49/49: removing xfsprogs-5.2.1-1.mga7.x86_64 ########################################################################## Creating: target|kernel|dracut args|basicmodules FWIW: [rolf@z170i ~]$ rpm -qa --last | grep kernel-desktop-latest kernel-desktop-latest-5.4.6-2.mga7.x86_64 Wed 25 Dec 2019 07:59:17 PM PST On two other active machines on the LAN, 64-bit thin clients, the same procedure ends successfully: ... 38/39: removing xfsprogs-5.2.1-1.mga7.x86_64 ########################################################################## 39/39: removing cpupower-5.4.2-1.mga7.x86_64 ########################################################################## Creating: target|kernel|dracut args|basicmodules You should restart your computer for kernel-desktop-5.4.6-2.mga7 [rolf@d90d7 ~]$ I'll not reboot them for a while, in case some information can be retrieved. Thanks.
Almost two days later, I killed the hung urpmi process. Then, I tried removing 5.4.6-desktop-2.mga7 in CLI and with rpmdrake directly on the machine. These processes did not complete. I found 98 processes involving grub commands associated with the kernel installation, most from my attempts on the 27th and at least one from the 25th. I killed them with a for-do loop. Ultimately, I was able to install the new kernel and boot to it but the ethernet activate-deactivate loop is present. I rebuilt the initrd with dracut to get a file that differed in size a small percentage from what the kernel install scripts produced but network still is not working. Next kernel, I'll try upgrading with rpmdrake directly on the machine and, if that goes normally, I'll open a bug if network remains dysfunctional as these failed ssh updates don't inspire confidence about reproducibility.
kernel-desktop-5.4.12-1.mga7-1-1.mga7.x86_64 was included in the update applet announcement today. I used the gui for a successful update, including this kernel, on the main desktop. I am using tmux in an ssh session for the three other active computers on the LAN, so I can keep the process alive, if necessary, and shut down the primary desktop. Two Wyse D90D7 thin clients got the kernel installed and rebooted into it. However, the ASUS Z170I PRO GAMING is stuck at the same point, after I issued the command in tmux over ssh, `# urpmi -v --auto-update': Creating: target|kernel|dracut args|basicmodules rpm is giving credit for the kernel having been installed since soon after I started the update: [root@z170i rolf]# rpm -qa --last | grep kernel-desktop kernel-desktop-5.4.12-1.mga7.x86_64 Fri 17 Jan 2020 05:37:33 AM PST but the process has not completed, the installkernel script still there: [root@z170i rolf]# ps aux | grep kernel root 12939 0.0 0.0 12136 824 pts/2 S+ 08:18 0:00 grep --color kernel root 30562 0.0 0.0 12468 2844 pts/1 S+ 05:40 0:00 /bin/sh /sbin/installkernel 5.4.12-desktop-1.mga7 root 30563 0.0 0.1 45772 31912 pts/1 S+ 05:40 0:00 /usr/bin/perl /sbin/bootloader-config --kernel-version 5.4.12-desktop-1.mga7 --initrd-options --action add-kernel and, perhaps, waiting on grub?: [root@z170i rolf]# ps aux | grep grub root 1905 0.0 0.0 12468 2864 pts/1 S+ 05:40 0:00 /usr/bin/sh /bin/update-grub2 root 1906 0.0 0.0 13444 3148 pts/1 S+ 05:40 0:00 su --login root -c /usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg root 1913 0.0 0.0 12732 3080 pts/1 S+ 05:40 0:00 /usr/bin/sh /usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg root 5577 0.0 0.0 12732 3160 pts/1 S+ 06:03 0:00 /bin/sh /etc/grub.d/46_os-prober root 5930 0.0 0.0 12732 1820 pts/1 S+ 06:03 0:00 /bin/sh /etc/grub.d/46_os-prober root 5974 99.3 0.3 75468 56616 ? Rs 06:03 134:16 grub2-mount /dev/sda1 /var/lib/os-prober/mount root 12947 0.0 0.0 12136 760 pts/2 R+ 08:18 0:00 grep --color grub It's been over 2.5 hours. Is there a clue where to look in the running system for a cause? I'm reminded that grub had spawned many instances in my previous failed CLI kernel upgrade attempts, grub didn't get installed, and I might try starting with killing those, getting the prompt back, and trying to install grub. Thanks.
That's a grub2/os-prober issue. You can disable usage of os-prober by unchecking "Probe Foreign OS" in drakboot I guess it's time for bootloader.pm to call set_default_timeout() to set up a timeout for os-prober (like 2minutes). The issue being we won't be able to set the timeout on os-prober per se but on "update-grub2"…
CC: (none) => thierry.vignaud
Source RPM: kernel-5.4.2-1.mga7.src.rpm => grub2, os-prober
Ok. As sda1 seems implicated in the hung process, I first mounted it to see an old Rosa install, there, with these sorts of things in /boot: -rw-r--r-- 1 root root 185562 Aug 17 2016 config-4.4.18-nrj-desktop-1rosa-x86_64 -rw-r--r-- 1 root root 187968 Jun 9 2016 config-4.5.7-nrj-desktop-1rosa-x86_64 -rw-r--r-- 1 root root 190696 Aug 17 2016 config-4.6.7-nrj-desktop-1rosa-x86_64 drwxr-xr-x 2 root root 48 Dec 9 2016 dracut/ drwxr-xr-x 6 root root 256 May 30 2017 grub2/ -rw-r--r-- 1 root root 11636601 Nov 25 2016 initrd-4.1.25-nrj-desktop-1rosa-x86_64.img -rw------- 1 root root 11633813 Nov 25 2016 initrd-4.1.25-nrj-desktop-1rosa-x86_64_old.img -rw-r--r-- 1 root root 11590215 Nov 25 2016 initrd-4.4.18-nrj-desktop-1rosa-x86_64.img -rw------- 1 root root 11589307 Nov 25 2016 initrd-4.4.18-nrj-desktop-1rosa-x86_64_old.img -rw-r--r-- 1 root root 11680901 Nov 25 2016 initrd-4.5.7-nrj-desktop-1rosa-x86_64.img -rw------- 1 root root 11678425 Nov 25 2016 initrd-4.5.7-nrj-desktop-1rosa-x86_64_old.img -rw-r--r-- 1 root root 14973510 Jan 4 2017 initrd-4.6.7-nrj-desktop-1rosa-x86_64.img -rw-r--r-- 1 root root 11697365 Nov 25 2016 initrd-4.6.7-nrj-desktop-1rosa-x86_64_old.img -rw-r--r-- 1 root root 182704 Feb 18 2016 memtest.bin -rw-r--r-- 1 root root 255644 May 24 2016 symvers-4.1.25-nrj-desktop-1rosa-x86_64.xz -rw-r--r-- 1 root root 262312 Aug 17 2016 symvers-4.4.18-nrj-desktop-1rosa-x86_64.xz -rw-r--r-- 1 root root 265216 Jun 9 2016 symvers-4.5.7-nrj-desktop-1rosa-x86_64.xz -rw-r--r-- 1 root root 269636 Aug 17 2016 symvers-4.6.7-nrj-desktop-1rosa-x86_64.xz -rw-r--r-- 1 root root 3433957 May 24 2016 System.map-4.1.25-nrj-desktop-1rosa-x86_64 -rw-r--r-- 1 root root 3614813 Aug 17 2016 System.map-4.4.18-nrj-desktop-1rosa-x86_64 -rw-r--r-- 1 root root 3622464 Jun 9 2016 System.map-4.5.7-nrj-desktop-1rosa-x86_64 -rw-r--r-- 1 root root 3703552 Aug 17 2016 System.map-4.6.7-nrj-desktop-1rosa-x86_64 -rw-r--r-- 1 root root 4678176 May 24 2016 vmlinuz-4.1.25-nrj-desktop-1rosa-x86_64 -rw-r--r-- 1 root root 4860560 Aug 17 2016 vmlinuz-4.4.18-nrj-desktop-1rosa-x86_64 -rw-r--r-- 1 root root 4862224 Jun 9 2016 vmlinuz-4.5.7-nrj-desktop-1rosa-x86_64 -rw-r--r-- 1 root root 4978320 Aug 17 2016 vmlinuz-4.6.7-nrj-desktop-1rosa-x86_64 I then umounted and did `reiserfsck --fix-fixable' to see if that would jog something but it didn't. Finally, htop showed one of the os-prober processes was using ~100% of a core and I wound up having to kill it with -9, which immediately allowed installkernel to exit, telling me to reboot. I had a concern that grub install had not completed, as before. Running the boot module in mcc and unchecking the 'probe foreign os' made sure that was done and reboot: [rolf@z170i ~]$ uname -r 5.4.12-desktop-1.mga7 Of course, I think it would be better to have entries for other os in the menu, generally, but I don't know what's the problem. Thanks.
Next time please attach as a file rather than paste a big block of text: 1) it makes the bug report unreadable 2) the listing if often wrapped Regarding your question, either killing os-prober or disabling it in drakboot as I advertised won't break installing grub2. It'll only suppress the other OSes entry You'd better report an issue upstream with os-prober, which is https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=os-prober;dist=unstable (yeah really)
(In reply to Thierry Vignaud from comment #11) > Next time please attach as a file rather than paste a big block of text: > 1) it makes the bug report unreadable > 2) the listing if often wrapped > Sorry, I tried to anticipate, weigh and balance the convenience of deciphering wrap vs having to open a new window, as I see it. (Maybe we could have a post Preview at some point?) > Regarding your question, either killing os-prober or disabling it in > drakboot as I advertised won't break installing grub2. > It'll only suppress the other OSes entry I meant with probe disabled, I won't get the foreign os entries, in the event I want them, do I? > > You'd better report an issue upstream with os-prober, which is > https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=os-prober;dist=unstable > (yeah really) I tried but need some help as reasoning for filing, there, is being requested: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949311 Thanks.
Mageia 7 is EOL since July 1st 2021. There will not have any further bugfix for this release. You are encouraged to upgrade to Mageia 8 as soon as possible. @reporter, if this bug still apply with Mageia 8, please let us know it. @packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead. This bug report will be closed OLD if there is no further notice within 1st September 2021.
The machine is on MGA8 and, apparently, I have not had an issue since my last comment in January. Thanks!
Resolution: (none) => FIXEDStatus: NEW => RESOLVED