This provides fixes for a number of bugs: Bug 9986 - harddrake2 displays some multimedia devices as keyboards Bug 21246 - Video mode selection in drakboot is ignored when using grub2 Bug 21247 - Invalid menu entries when switching from grub2 to grub bootloader (and may silently fail to install the grub bootloader) Bug 21250 - service_harddrake cannot add/remove nokmsboot option when using grub2, leading to endless reboot loop Bug 21263 - Endless reboot loop after switching from nouveau to nvidia proprietary driver plus updates to hardware detection (for new devices supported by the 4.14 series kernels) and numerous translation updates. Note that this only fixes the first part of bug 21247. SRPM: drakxtools-17.88.2-1.mga6.src.rpm RPMs: drakx-finish-install-17.88.2-1.mga6.x86_64.rpm drakxtools-17.88.2-1.mga6.x86_64.rpm drakxtools-backend-17.88.2-1.mga6.x86_64.rpm drakxtools-curses-17.88.2-1.mga6.x86_64.rpm drakxtools-debuginfo-17.88.2-1.mga6.x86_64.rpm drakxtools-gtk2-compat-17.88.2-1.mga6.x86_64.rpm drakxtools-http-17.88.2-1.mga6.x86_64.rpm harddrake-17.88.2-1.mga6.x86_64.rpm harddrake-ui-17.88.2-1.mga6.x86_64.rpm Test procedures: 1. Bug 9986 Before the update, in MCC->Hardware->Browse and configure hardware, expand the Keyboard entry in the left-hand pane. If you have any HDA sound devices, they are likely to be listed there. After the update, they should instead be listed under Soundcard. Validated on my desktop with Intel HDA. 2. Bug 21246 On a system using the GRUB2 bootloader, in drakboot, click on Next to go on to the second screen, click on Advanced, select a video mode, click on OK to close the pop-up window, and click on Finish. Before the update, on reboot your selection will have been forgotten. After the update, it will be remembered, and the appropriate vga= option will be present in /proc/cmdline. 3. Bug 21247 On a system using the GRUB bootloader (e.g. one upgraded from an older version of Mageia), save a copy of /boot/grub/menu.lst, then in drakboot, switch to using the GRUB2 bootloader, then switch back to using GRUB. Compare the saved and new versions of /boot/grub/menu.lst. Before the update, you will find the "initrd" lines are missing in the new version. After the update, those lines should be present. Note that without those lines, your system will fail to boot. If in doubt, restore your saved copy of /boot/grub/menu.lst. This one is only for the brave! 4. Bug 21250/Bug 21263 On a system with a NVIDIA graphics card, switch from using the free (nouveau) driver to using the proprietary (nvidia-current/nvidia340/nvidia304) driver (or vice-versa). Before the update, on reboot the system will go into an endless reboot loop as it attempts to automatically add (or remove) the nokmsboot boot option. You can get out of this loop by manually editing the boot command line in the boot menu and adding (or removing) the nokmsboot option yourself. After the update, the system should reboot cleanly. 5. and finally Generally use the drakx tools to make sure there are no regressions.
Mageia 6, x86_64 Before updates: 1) Confirmed. HDA Intel and HDA NVIDIA sound devices listed under keyboard. 2) Confirmed. 1600x1200:15 not set 3) ! 4) nvidia (GTX770) -> nouveau (Xeon E3-1200) DVI interface. Reboot failed - no endless loop - just hangs Tried removing nokmsboot but still no boot. Tried 'startx --bpp 24' -> X server already running - cannot connect to X server Tried nomodeset but got no further. "Started Notify NFS peers of a restart" Ended up running drakx11 in console mode to recover the nvidia driver. Ran the updates. - drakxtools-17.88.2-1.mga6.x86_64 - drakxtools-backend-17.88.2-1.mga6.x86_64 - drakxtools-curses-17.88.2-1.mga6.x86_64 - harddrake-17.88.2-1.mga6.x86_64 - harddrake-ui-17.88.2-1.mga6.x86_64 Added: drakx-finish-install drakxtools-gtk2-compat drakxtools-http 1) The sound devices have disappeared from the Keyboard menu and now appear under Soundcard. 2) Now that was interesting. $ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.14.44-tmb-desktop-1.mga6 root=UUID=bab44640-7e76-4778-8527-7ea923bd7f04 ro nokmsboot splash quiet noiswmd resume=UUID=6be1b032-b4aa-4be1-99bf-c7f3d0a76492 audit=0 vga=796 So that bit works, but login involved the credentials sequence which users encounter with a Live iso; language, licence, country, keyboard etc. and to cap it all I was forced to invent a new user before I could log in as myself. Weirdness. 3) Pass. 4) drakx11 for nouveau driver. Noted that all heads need to be configured independently - choosing the Xeon card results in the Intel driver being specified. No problem with reboot. # lsmod | grep nouveau nouveau 1867776 3 mxm_wmi 16384 1 nouveau wmi 28672 2 mxm_wmi,nouveau ttm 106496 1 nouveau video 45056 2 nouveau,i915 button 16384 2 nouveau,i915 i2c_algo_bit 16384 2 nouveau,i915 drm_kms_helper 180224 2 nouveau,i915 drm 409600 9 nouveau,i915,ttm,drm_kms_helper $ cat /etc/X11/xorg.conf ................ Section "Device" Identifier "device1" Driver "nouveau" Screen 0 Option "DPMS" EndSection Section "Device" Identifier "device2" VendorName "Intel Corporation" BoardName "Intel 810 and later" Driver "intel" Screen 0 BusID "PCI:0:2:0" Option "DPMS" EndSection ............. Had a a quick look at drakconf and used drakfont to install concetta.ttf. No regressions noted. harddrake2 is still behaving itself and the boot command retains vga=796. Over to you Martin.
CC: (none) => tarazed25
Thanks Len. IIRC, we couldn't get the nouveau driver to work with your hardware when we were testing the Mageia 6 ISOs, so I'm not too surprised you couldn't get far enough to see the looping reboot bug. The strange behaviour in (2) comes from drakx-finish-install. It's normally only installed on Live systems. It runs each time you boot the Live system, and also the first time you boot a system installed from the Live ISO. Because you installed it on a system where it wasn't previously installed, it ran through all the finish-install actions. This shouldn't be a problem for ordinary users, as if it isn't already installed, it shouldn't be offered as an update.
Yes, well remembered Martin. I have had mixed results with nouveau on my various bits of hardware. And I kind of guessed that drakx-finish-install was to blame in (2). What to do about (3) though? Wait to see if anybody is using grub? If nobody bites I might try downgrading to grub on a system that could be sacrificed.
I just checked (4). Too tired tonight to try much else. I knew the old tools had the problem, as I have run into it several times, so I did not look for it. After instaling the new tools, I told the system to switch from nvidia340 to nouveau, closed the tools, and attempted to reboot, running into Bug 20153 again. Using the "reboot" command, I used "e" in grub2 to check the kernel options, and "nokmsboot" was gone. I allowed the boot to proceed, and it was successful. I switched back to nvidia340, and ran into Bug 20153 again, but the reboot from the command line was again successful. As before, "Leave was functioning again.
CC: (none) => andrewsfarm
Tested the additional draktools draksound drakboot diskdrake (requires more testing tonight: create, format, label and remove partitions) drakx (teased the probe configuration button) graficaleffects (compis fusion enabling) display manager switching
CC: (none) => neoser10
(In reply to Len Lawrence from comment #3) > What to do about (3) though? Wait to see if anybody > is using grub? If nobody bites I might try downgrading to grub on a system > that could be sacrificed. I tested (3) in a VM, cloning the Mageia 5.1 VM I'm keeping for upgrade tests, upgrading to 6, then switching bootloader from GRUB to GRUB2, then back again. I don't see any need to test this on real hardware.
Glad you did that Martin. I could not switch a GRUB2 system to GRUB on real hardware. drakboot --boot exited with the message that it could not find stage1. Out of my depth at that point.
Revisited (4) on a laptop. Successfully switched to the nouveau driver but had no problems with rebooting. nokmsboot remained in place. However something killed wifi so I had to switch to ethernet. Switched back to the nvidia driver and again no problems with booting but wifi was still missing. Rebooted to another partition with nvidia and wifi was reestablished. Went back to the original partition and wifi was still dead. $ rfkill list 0: ideapad_wlan: Wireless LAN Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: yes Hard blocked: no $ rfkill unblock 2 That brought wifi back immediately. So there is another bug somewhere - possibly nothing to do with drakxtools. Anyway I cannot duplicate (4).
(In reply to Len Lawrence from comment #7) > Glad you did that Martin. I could not switch a GRUB2 system to GRUB on real > hardware. drakboot --boot exited with the message that it could not find > stage1. Out of my depth at that point. Was this the message: grub> setup --stage2=/boot/grub/stage2 (hd0) Checking if "/boot/grub/stage1" exists... no Checking if "/grub/stage1" exists... no Error 14: Filesystem compatibility error, cannot read whole file grub> quit If so, your /boot is on a filesystem GRUB can't read - most likely ext4 with the 64bit extension enabled. This was the main driver for switching to GRUB2 by default in Mageia 6. The other, unfixed, part of bug 21247 is that if you don't start drakconf/drakboot from the command line, you don't see this message, so don't find out it's failed until you come to reboot. The good news is that it hasn't disabled GRUB2 at that point, so you can still boot.
Exactly that message. The filesystem is ext4. Thanks for the insider information. It is quite difficult to find adequate documentation on GRUB. Googled, and on one site found this list: e2fs_stage1_5 fat_stage1_5 ffs_stage1_5 jfs_stage1_5 minix_stage1_5 reiserfs_stage1_5 vstafs_stage1_5 xfs_stage1_5 Where do we go from here, considering that my tests do not cover all the bases? We have passed other bugs on the basis of a clean installation and no regressions. In the present case we do have positive results from some tests.
Ni Qa team Let me try tonight the third test with a recently installed mga6 but in extended three fs :)
Tested the remotion of all ntfs partitions: OK Tested creating ext4 partition (4000 mb as proposed by diskdrake) OK Exiting from diakdrake (inside MCC) and restarting diskdrake, the partition is labeled "system reserved" size=4000 mb and ntfs!!! This is repeteable if you "insert" a ntfs disk, remove all partitions and, create only one partition Is repeteable using advanced or normal wizard To have in the radar, that this vmdsk was clean, the partitions were created by windows 7 installer and used it to test this update candidate Tomorrow, will test the grub2 to grub1 downgrade (21247)
(In reply to Mauricio Andrés Bustamante Viveros from comment #12) > Tested the remotion of all ntfs partitions: OK > Tested creating ext4 partition (4000 mb as proposed by diskdrake) OK > Exiting from diakdrake (inside MCC) and restarting diskdrake, the partition > is labeled "system reserved" size=4000 mb and ntfs!!! > > This is repeteable if you "insert" a ntfs disk, remove all partitions and, > create only one partition > Is repeteable using advanced or normal wizard Did you format the ext4 partition? diskdrake detects and displays the partition format in preference to the partition type. If you don't format the new partition, the old partition information is still there on the disk. I think this behaviour is confusing, but that's what it is designed to do. > Tomorrow, will test the grub2 to grub1 downgrade (21247) Don't forget that /boot must be on a partition that grub1 can read. When formatted by Mageia 6, ext2/3/4 partitions will default to having the 64-bit feature enabled, which grub1 can't handle.
(In reply to Len Lawrence from comment #10) > Where do we go from here, considering that my tests do not cover all the > bases? > We have passed other bugs on the basis of a clean installation and no > regressions. In the present case we do have positive results from some > tests. I have verified everything (as it's nearly a year since I submitted the fixes, this comes close to being an independent check!). You have verified (1) and (2). TJ and Mauricio have verified (4). Mauricio has done a lot of extra checks for regressions. All but (1) have been in Cauldron since February without any complaints. I'd be comfortable with validating now, but if Mauricio can confirm (3), that would be better still.
Confirm reproducible test case in MGA6 changing to GRUB2 and reverting back to GRUB1 https://drive.google.com/open?id=14sA3_5t4HL1MyaiInTGBTEkM2fNQjGlN Installed the update in testing (some mirrors appears outdated, because did not list the draktools update in testing) Closing all mageia control center apps, and retrying the tests, the test is sucessfull https://drive.google.com/open?id=1v6xseqO_IdGjMWY_Ki6WT63Ly4Q11Gr1 For me this is a full OK
In that case we should send this on its way.
Whiteboard: (none) => MGA6-64-OK
And thank you Mauricio.
(In reply to Len Lawrence from comment #16) > In that case we should send this on its way. I agree. An advisory can be composed from information in the description. Validating...
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Advisory uploaded (comment 0)
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2018-0107.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED