| Summary: | Update request: drakxtools | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Martin Whitaker <mageia> |
| Component: | RPM Packages | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | andrewsfarm, neoser10, sysadmin-bugs, tarazed25 |
| Version: | 6 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.mageia.org/show_bug.cgi?id=9986 https://bugs.mageia.org/show_bug.cgi?id=21246 https://bugs.mageia.org/show_bug.cgi?id=21247 https://bugs.mageia.org/show_bug.cgi?id=21250 https://bugs.mageia.org/show_bug.cgi?id=21263 |
||
| Whiteboard: | MGA6-64-OK | ||
| Source RPM: | drakxtools-17.88.2-1.mga6 | CVE: | |
| Status comment: | |||
|
Description
Martin Whitaker
2018-05-29 23:16:10 CEST
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_update An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2018-0107.html Status:
ASSIGNED =>
RESOLVED |