Created attachment 9051 [details] install.log from first installation. Hardware: Gigabyte motherboard; Seagate 500 GB HD. Downloaded new sta2 DVD ISO via BitTorrent. Checked that md5sum was correct. Burned ISO to USB stick with isodumper and installed to a 32 GB partition. Message that one script had failed, but proceeded to the bootloader stage. Bootloader installation seemed normal, set up sources and installed updates. On rebooting, should have seen Cauldron's Grub2 menu. Instead got a Grub2 default prompt. Able to start from another EFI menu (OpenSuse.) Booting into runlevel 5 got as far as the 3 question marks, then changed to text. Hung at stage âChecking for new hardware,â followed by repeated Audit lines. Did a clean reinstall. Same outcome. Discovered that /boot/grub2/grub.cfg was grub.cfg.new. Renamed it. That allowed nVidia RPM to install to dkms, but still hung at âChecking for new hardware.â (nokmsboot was present in /etc/default/grub.) Able to boot successfully into Recovery mode from Suse menu. Ran grub-install and update-grub again. I now had a Grub2 menu with only two sta2 entries, normal and recovery. Os-prober was installed but hadn't run. The normal launch from that menu stopped at the same place. This menu had replaced 5.1's menu. Still starting 5.1 from Suse bootloader. No idea where to look next. install.log from first attempt and latest report.bug.xz attached.
Created attachment 9052 [details] Current /root/drakx/report.bug.xz
Created attachment 9053 [details] journalctl -b1 points to a failed graphical boot.
It was suggested that I reinstall without the nVidia driver. That was a partial solution only. I now have a working grub2 menu, and can boot into 5.1 and sta2 Recovery mode from it. /etc/grub.conf is correctly named. But I still can't boot into a graphical desktop. System hangs at the same point. I am attaching the journal for the last attempt. The only important error I can see is a failure to start the virtual console service. Maybe, for completeness, I should try runlevel 3.
(In reply to Doug Laidlaw from comment #3) > It was suggested that I reinstall without the nVidia driver. That was a > partial solution only. > > I now have a working grub2 menu, and can boot into 5.1 and sta2 Recovery > mode from it. > /etc/grub.conf is correctly named. > > But I still can't boot into a graphical desktop. System hangs at the same > point. I am attaching the journal for the last attempt. The only important > error I can see is a failure to start the virtual console service. > > Maybe, for completeness, I should try runlevel 3. (In reply to Doug Laidlaw from comment #2) > Created attachment 9053 [details] > journalctl -b1 points to a failed graphical boot. sddm is indeed looping. $ xzcat Downloads/20429report.bug.xz | grep Card Card:NVIDIA GeForce 420 series and later: NVIDIA Corporation|GM107 [GeForce GTX 750] [DISPLAY_VGA] (subv:1458 subd:362e) $ CC'ing some people who know a lot more about video cards and drivers, sddm, grub2 and such than me. This might be two different issues, one for the nouveau install, and a different one with NVidia :-/
CC: sysadmin-bugs => isobuild, kde, kernel, marja11, zen25000Component: BuildSystem => InstallerVersion: unspecified => CauldronAssignee: sysadmin-bugs => bugsquadProduct: Infrastructure => MageiaSummary: Installation of sta2 from DVD ISO fauils to boot. => Installation of sta2 from DVD ISO fails to boot (gets grub prompt) with NVidia driver, ends with SDDM loop with Nouveau.
(Assigning to mageiatools maintainers, even if there's a good chance stage2 isn't the culprit at all... please reassign, if needed, when more becomes clear.)
Assignee: bugsquad => mageiatools
I don't want to complicate things further, but discovered that my video card has a Maxwell chip, and nouveau doesn't support it without extracting software from the proprietary driver. Booting directly into the nVidia RPM probably avoids the issue. https://forums.gentoo.org/viewtopic-t-1057046.html?sid=c3c511e0d2cd95730c4ce3dd9fd1b438
(In reply to Doug Laidlaw from comment #6) > I don't want to complicate things further, but discovered that my video > card has a Maxwell chip, and nouveau doesn't support it without extracting > software from the proprietary driver. Booting directly into the nVidia RPM > probably avoids the issue. > > https://forums.gentoo.org/viewtopic-t-1057046. > html?sid=c3c511e0d2cd95730c4ce3dd9fd1b438 Oh, but it does... Atleast basic modesetting works with both nouveau and modesetting driver... Even then brand new GTX10xx cards works (basic display functions) with nouveau It's the hardware acceleration that needs proprietary firmware... We already ship the signed firmwares in kernel-firmware-nonfree-20170301-1.mga6.nonfree And the newly released x11-driver-video-nouveau-1.0.14 (currently building) should improve Maxwell support
CC: (none) => tmb
IIRC, my Xorg.0.log had the same message as in the Gentoo forum. Yes: [ 193.849] (II) v4l driver for Video4Linux overlay mode (V4L2) [ 193.849] (II) NOUVEAU driver [ 193.849] (II) NOUVEAU driver for NVIDIA chipset families : [ 193.849] RIVA TNT (NV04) [ 193.849] RIVA TNT2 (NV05) [ 193.849] GeForce 256 (NV10) [ 193.849] GeForce 2 (NV11, NV15) [ 193.849] GeForce 4MX (NV17, NV18) [ 193.849] GeForce 3 (NV20) [ 193.849] GeForce 4Ti (NV25, NV28) [ 193.849] GeForce FX (NV3x) [ 193.849] GeForce 6 (NV4x) [ 193.849] GeForce 7 (G7x) [ 193.849] GeForce 8 (G8x) [ 193.849] GeForce GTX 200 (NVA0) [ 193.849] GeForce GTX 400 (NVC0) [ 193.849] (WW) Falling back to old probe method for v4l [ 193.849] (II) v4l: Initiating device probe [ 193.849] (II) [drm] nouveau interface version: 1.3.1 [ 193.849] (EE) Unknown chipset: NV117 [ 193.849] (II) [drm] nouveau interface version: 1.3.1 [ 193.849] (EE) Unknown chipset: NV117 [ 193.849] (WW) Falling back to old probe method for v4l [ 193.849] (II) v4l: Initiating device probe [ 193.849] (II) [drm] nouveau interface version: 1.3.1 [ 193.849] (EE) Unknown chipset: NV117 [ 193.849] (II) [drm] nouveau interface version: 1.3.1 [ 193.849] (EE) Unknown chipset: NV117 [ 193.849] (EE) No devices detected. [ 193.849] (EE) Mine is a GTX 750.
Please update your system so you get x11-driver-video-nouveau-1.0.14-1.mga6 and try again
Please don't mix different issues in the same report next time That's not an installer bug, but: - for gfx: a driver issue (which I just got uploaded) - for boot: a grub2 issue Which is a bit more complicated for grub2. The interesting part is: - some files got moved between mga5 & mga6, between grub2 & the new grub2-common sub package (eg: /etc/default/grub) - /boot/grub2/grub.cfg is no more packaged and thus got renamed by rpm when upgrading (it should not have been packaged in the first place) @Doug: can you confirm there was no /boot/grub/grub.cfg? But a grub2.cfg.rpmsave file? I don't think your grub2.cfg.new is accurate @Barry: 1) We want to kept the old /etc/default/grub as it's a config file and we don't want to overwrite it on upgrade (thus loosing your settings). However we should check that an altered /etc/default/grub remains as it after the upgrade from mga5 (I'm wondering if the fact this %config file is moving between subpkgs might be get us loosing mga5 changes due to tricking rpm) We might need a trigger in order to handle that move when upgrading from mga5 2) we might have to add a trigger in order to handle the fact that grub2.cfg is no more packaged when upgrading from mga5 you might want to add sg like: %triggerpostun common -- %{name} < 2.02-0.git9752.18, %{name}-efi < 2.02-0.git9752.18 if [[ -f /boot/%{name}/grub.cfg.rpmsave ]] && [[ ! -e /boot/%{name}/grub.cfg ]]; then mv /boot/%{name}/grub.cfg{.rpmsave,} fi Now the strange part is that we run update-grub2 anyway and Doug's logs do show we did generate grub.cfg: * running: update-grub2 with root /mnt * update-grub2 logs: mesg: ttyname failed: Inappropriate ioctl for device Generating grub configuration file ... Found theme: /boot/grub2/themes/maggy/theme.txt Found linux image: /boot/vmlinuz-4.9.13-desktop-1.mga6 Found initrd image: /boot/initrd-4.9.13-desktop-1.mga6.img Found linux image: /boot/vmlinuz-desktop Found initrd image: /boot/initrd-desktop.img rmdir: failed to remove '/var/lib/os-prober/mount': No such file or directory grub2-probe: error: cannot find a GRUB drive for /dev/sdf1. Check your device.map. Found Windows Boot Manager on /dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi Found Mageia 5 (5) on /dev/sda6 done * running: grub2-set-default linux with root /mnt * running: sh /boot/grub2/install.sh with root /mnt * step "summary" took: 0:02:26 * step `summary' finished All of which happens after the upgrade... Plus we do have "grub2: grub.cfg" in report.bug.xz
CC: (none) => thierry.vignaudComponent: Installer => RPM PackagesSource RPM: (none) => x11-driver-video-nouveau, grub2
(In reply to Thomas Backlund from comment #9) > Please update your system so you get x11-driver-video-nouveau-1.0.14-1.mga6 > and try again Difficult without a GUI. I have two Cauldron installations, the original, and the one set for nouveau I changed both to "vesa" in Xorg.conf. I am into the original with sddm; the other kept asking for a reboot. The plot thickens. It is past my bedtime (00:45 here) and my mind is switching off. Please post what you would like me to do next, and I will look at it tomorrow.
What works for me is to add modprobe.blacklist=nouveau to the kernel boot command line. Have you tried that, Doug?
CC: (none) => hamnisdude
CC: kde => (none)
Assignee: mageiatools => kernel
CC: isobuild => (none)
I can't sleep, so I might as well answer the above. @Thierry: I did suspect there were multiple bugs, but I was chasing my tail so much that I just put up what happened. If you guys want to split it, go ahead. The filename was definitely grub.cfg.new. It was brief and was probably the one created by the installer. I have never seen a grub.cfg.rpmsave, and I expected it to become grub.cfg.old. Importantly, there was no plain grub.cfg. But it didn't happen when I reinstalled, so it is probably history. Maybe it was a teething problem? @ Kris: No, I haven't, but I have read about its being done in other distros. I wasn't sure of the correct syntax for Mageia. At present, I am booting sta2 into runlevel 3, then using startx. That gives me the default Plasma interface on a vesa screen. It enabled me to update my urpmi sources (a USB key is never found on rebooting.) I need to check out the gfx issue further tomorrow.
(In reply to Thierry Vignaud from comment #10) > Please don't mix different issues in the same report next time Yes I'm confused is this about a clean install or an upgrade? > @Barry: > 1) We want to kept the old /etc/default/grub as it's a config file and we > don't want to overwrite it on upgrade (thus loosing your settings). However > we should check that an altered /etc/default/grub remains as it after the > upgrade from mga5 (I'm wondering if the fact this %config file is moving > between subpkgs might be get us loosing mga5 changes due to tricking rpm) > We might need a trigger in order to handle that move when upgrading from mga5 > I will test for this, however I have done several Mga5 -> Mga6 net-upgrades recently without hitting any issues. > 2) we might have to add a trigger in order to handle the fact that grub2.cfg > is no more packaged when upgrading from mga5 > > you might want to add sg like: > %triggerpostun common -- %{name} < 2.02-0.git9752.18, %{name}-efi < > 2.02-0.git9752.18 > if [[ -f /boot/%{name}/grub.cfg.rpmsave ]] && [[ ! -e > /boot/%{name}/grub.cfg ]]; then > mv /boot/%{name}/grub.cfg{.rpmsave,} > fi We already have a %triggerpostun common for upgrade from Mga5 that removes all *.rpm* files (Mga#17263 grub2 updates creates several .rpmnew which remove grub.cfg) and also runs grub2mkconfig. > > > Now the strange part is that we run update-grub2 anyway and Doug's logs do > show we did generate grub.cfg: If this was an upgrade from Mga5 then yes the trigger above would do that. > > * running: update-grub2 with root /mnt > * update-grub2 logs: mesg: ttyname failed: Inappropriate ioctl for device > Generating grub configuration file ... > Found theme: /boot/grub2/themes/maggy/theme.txt > Found linux image: /boot/vmlinuz-4.9.13-desktop-1.mga6 > Found initrd image: /boot/initrd-4.9.13-desktop-1.mga6.img > Found linux image: /boot/vmlinuz-desktop > Found initrd image: /boot/initrd-desktop.img > rmdir: failed to remove '/var/lib/os-prober/mount': No such file or directory > grub2-probe: error: cannot find a GRUB drive for /dev/sdf1. Check your > device.map. > Found Windows Boot Manager on /dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi > Found Mageia 5 (5) on /dev/sda6 > done > * running: grub2-set-default linux with root /mnt > * running: sh /boot/grub2/install.sh with root /mnt > * step "summary" took: 0:02:26 > * step `summary' finished > > All of which happens after the upgrade... > > Plus we do have "grub2: grub.cfg" in report.bug.xz
> Yes I'm confused is this about a clean install or an upgrade? It was a clean install, Barry. Upgrades bring too many problems.
(In reply to Barry Jackson from comment #14) > (In reply to Thierry Vignaud from comment #10) > > @Barry: > > 1) We want to kept the old /etc/default/grub as it's a config file and we > > don't want to overwrite it on upgrade (thus loosing your settings). However > > we should check that an altered /etc/default/grub remains as it after the > > upgrade from mga5 (I'm wondering if the fact this %config file is moving > > between subpkgs might be get us loosing mga5 changes due to tricking rpm) > > We might need a trigger in order to handle that move when upgrading from mga5 > > > > I will test for this, however I have done several Mga5 -> Mga6 net-upgrades > recently without hitting any issues. > Yes it seems that /etc/default/grub is being modified on upgrade: This test upgrade was in a VBox VM ##################### [baz@localhost default]$ diff -ur grub.old grub --- grub.old 2017-03-09 23:09:20.198347467 +0000 +++ grub 2017-03-09 23:31:34.531778122 +0000 @@ -1,12 +1,13 @@ -GRUB_TERMINAL_OUTPUT=gfxterm -GRUB_GFXPAYLOAD_LINUX=auto -GRUB_GFXMODE=1024x768x32 -GRUB_DISTRIBUTOR=Mageia -GRUB_THEME=/boot/grub2/themes/maggy/theme.txt -GRUB_ENABLE_CRYPTODISK=y +GRUB_CMDLINE_LINUX_DEFAULT=" splash quiet noiswmd resume=UUID=66a5d496-63e5-43a6-bb26-7e3f20619870 audit=0" +GRUB_DEFAULT=saved GRUB_DISABLE_OS_PROBER=false -GRUB_CMDLINE_LINUX_DEFAULT=" splash quiet noiswmd nokmsboot resume=UUID=66a5d496-63e5-43a6-bb26-7e3f20619870" GRUB_DISABLE_RECOVERY=false -GRUB_TIMEOUT=10 GRUB_DISABLE_SUBMENU=n -# This is a check to see if this file gets changed. \ No newline at end of file +GRUB_DISTRIBUTOR=Mageia +GRUB_ENABLE_CRYPTODISK=y +GRUB_GFXMODE=1024x768x32 +GRUB_GFXPAYLOAD_LINUX=auto +GRUB_SAVEDEFAULT=true +GRUB_TERMINAL_OUTPUT=gfxterm +GRUB_THEME=/boot/grub2/themes/maggy/theme.txt +GRUB_TIMEOUT=10 ###################### It drops nokmsboot It adds: audit=0 GRUB_DEFAULT=saved GRUB_SAVEDEFAULT=true We could add a check for grub.old and move it to grub in the existing %posttriggerun if you feel that would be beneficial, however we would then lose audit=0 etc. which were added for Mga6. I think that it may be more acceptable to allow the changes as this is an upgrade not an update. WDYT?
nokmsboot was missing in mine after upgrade. I like to have a specific entry as the default. This is still there, but "GRUB_DEFAULT=saved" is added at the bottom and takes precedence.
I just reinstalled sta2 with Vesa display. Problem reading synth files for update until I rebooted. grub.cfg is O.K. /etc/default/grub from the DVD did not include nokmsboot, so I added it and ran update-grub. After updating packages, nokmsboot was present. Successfully upgraded video driver to nouveau. Next step is to try the nonfree packages. sddm, looping at beginning, has had no issues.
(In reply to Barry Jackson from comment #16) > > I think that it may be more acceptable to allow the changes as this is an > upgrade not an update. NO. We dont intentionally break stuff on upgrades
The spin-offs from my report seem to be more important than the report itself. I have a desktop, and will just sit on the side. The updated nouveau package fixed the issue there. With it came a new os-prober package. Now my menu has every system that 5.1 lists.
Not sure what is happening here but I tried the following in the grub2 spec: ########################## Index: SPECS/grub2.spec =================================================================== --- SPECS/grub2.spec (revision 1092460) +++ SPECS/grub2.spec (working copy) @@ -20,7 +20,7 @@ %global tarversion 2.02~beta3 %global pc_arch i386-pc %define git 10463 -%define rel 5 +%define rel 5.1 Name: grub2 Version: 2.02 @@ -388,6 +388,10 @@ %triggerpostun common -- %{name} < 2.02-0.git10101.4, %{name}-efi < 2.02-0.git10101.4 rm -f /boot/%{name}/grub.cfg.rpmnew %{name}-mkconfig -o /boot/%{name}/grub.cfg && rm -f /boot/%{name}/grub.cfg.rpmsave +# This also covers upgrades from Mga5->6 where rpm fails to preserve /etc/default/grub +# due to package move, so put it back. (part of Mga#20429) +[[ -f /etc/default/grub ]] && cp -f /etc/default/grub /etc/default/grub.new +[[ -f /etc/default/grub.old ]] && mv -fT /etc/default/grub.old /etc/default/grub # Take this opportunity to remove some unwanted logs rm -f /var/log/%{name}_preun.log rm -f /var/log/%{name}_post.log ######################### The %triggerpostun should run after the removal of the old grub2-efi. At which time /etc/default/grub should be the new one installed by Mga6 grub2 which I have saved as grub.new. The grub.old should be the original Mga5 /etc/default/grub which I have mv'd back to /etc/default/grub. However on performing the upgrade with the new grub2 version available, on reboot I get: grub.new == grub.old == original Mga5 grub grub is new Mga6 default. Any ideas?
ping: ^^ thierry? thomas?
(In reply to Doug Laidlaw from comment #20) > The spin-offs from my report seem to be more important than the report > itself. I have a desktop, and will just sit on the side. > > > The updated nouveau package fixed the issue there. With it came a new > os-prober package. Now my menu has every system that 5.1 lists. Just did a fresh install setting the driver to Vesa. Couldn't reboot. My /home/doug/.Xauthority was owned by root. That is not relevant to this bug, but seems to happen where the file doesn't exist already. Fixed that, and was able to install the nVidia drivers. On the grub2 side, /etc/default/grub contained a reference to nokmsboot, which didn't disappear later.
I re-tested my upgrade with the modified grub2. I added a comment to grub and grub.old that already existed in Mga5.1 before the upgrade. After the upgrade I have: ---------------------------------------------- grub.new (which was grub in Mga5.1 GRUB_TIMEOUT=10 GRUB_TERMINAL_OUTPUT=gfxterm GRUB_DISABLE_RECOVERY=false GRUB_GFXPAYLOAD_LINUX=auto GRUB_GFXMODE=1024x768x32 GRUB_DISABLE_OS_PROBER=false GRUB_THEME=/boot/grub2/themes/maggy/theme.txt GRUB_ENABLE_CRYPTODISK=y GRUB_DISTRIBUTOR=Mageia GRUB_CMDLINE_LINUX_DEFAULT="noiswmd nokmsboot resume=UUID=b3feef83-eac8-4459-a027-8af2f1847d50" GRUB_DISABLE_SUBMENU=n # Mga5 grub ----------------------------------------------- grub.old (Which was the grub.old from Mga5.1) # NOTE - do not manually edit the GRUB_THEME= line below (if present) unless you wish to # add a theme of your own. It is automatically added and removed when the grub2-mageia-theme # package is installed or removed. # Feel free to edit or add other lines if you know what you are doing ;) # # After any edits to this file you must run update-grub to apply the changes. # GRUB_DISTRIBUTOR=Mageia GRUB_TIMEOUT=10 GRUB_CMDLINE_LINUX_DEFAULT="splash" GRUB_DISABLE_RECOVERY=true GRUB_DISABLE_SUBMENU=n GRUB_GFXMODE=1024x768x32 GRUB_GFXPAYLOAD_LINUX=text GRUB_TERMINAL_OUTPUT=gfxterm GRUB_DISABLE_OS_PROBER=false GRUB_ENABLE_CRYPTODISK=y GRUB_THEME=/boot/grub2/themes/maggy/theme.txt # Mga5 grub.old ------------------------------------------------ grub (Which is the newly created one from the install of Mga6) GRUB_CMDLINE_LINUX_DEFAULT=" splash quiet noiswmd resume=UUID=b3feef83-eac8-4459-a027-8af2f1847d50 audit=0" GRUB_DEFAULT=saved GRUB_DISABLE_OS_PROBER=false GRUB_DISABLE_RECOVERY=false GRUB_DISABLE_SUBMENU=n GRUB_DISTRIBUTOR=Mageia GRUB_ENABLE_CRYPTODISK=y GRUB_GFXMODE=1024x768x32 GRUB_GFXPAYLOAD_LINUX=auto GRUB_SAVEDEFAULT=true GRUB_TERMINAL_OUTPUT=gfxterm GRUB_THEME=/boot/grub2/themes/maggy/theme.txt GRUB_TIMEOUT=10 ------------------------------------------------- So this indicates to me that %triggerpostun is being run *before* the installation of the new package, not after the removal of the old one. Maybe I misunderstand the ordering of the scriplets. @thierry ??
I have tried other approaches but I think the installer is editing /etc/default/grub after the package upgrade, so I don't think this can be fixed in the spec. @thierry???
Barry Jackson: Do you get a successful boot into SDDM if you add $vt_handoff modprobe.blacklist=nouveau to the kernel boot command line?
(In reply to Kristoffer Grundström from comment #26) > Barry Jackson: Do you get a successful boot into SDDM if you add $vt_handoff > modprobe.blacklist=nouveau to the kernel boot command line? Sadly there are two issues in one report here. I'm not involved with the nvidia one as I have no nvidia graphics hardware. In fact I will fork the grub2 issue into another bug report now. https://bugs.mageia.org/show_bug.cgi?id=20596 (Upgrade Mga5->6 overwrites /etc/default/grub losing custom settings)
CC: zen25000 => (none)
Closing this bug report as there has been no further action since March 2017 and the Cauldron release has seen many changes since then.
Status: NEW => RESOLVEDResolution: (none) => OLD