Hi wilcal,

Do you still have the untouched root partition of that install, or did you already overwrite it?

If you still have it, then please mount that root partition.

There's a directory with a very long hexadecimal name in
 /that/partition's/var/log/journal/

please run, as root, 

  journalctl -D /path/into/that/hexadecimal/directory/ > journal.txt

and attach journal.txt to this bug report.
(compress the journal with xz if it's too large to attach)

If you already wiped that partition, then please install Mageia again, but, before starting MCC to change the video driver, run, as root:

   journalctl -f 2>&1 | tee journal_f.txt

and keep it running while reproducing this bug. After that, attach journal_f.txt to this report.

Btw, you mention 

> ctrl/alt/f2 is unresponsive

after telling about the boot problem. Did it refer to earlier, when the system froze after selecting Nvidia in MCC?

@ barjac

I don't tell wilcal how to restore his bootloader, because I don't know how to do that from a grub prompt (I always use a supergrub2 disk when I get stuck)

CC: (none) => kernel, marja11, zen25000

(In reply to Marja van Waes from comment #1)

> Do you still have the untouched root partition of that install, or did you
> already overwrite it?

The way I started this test is to wipe the drive clean and let the new LiveDVD iso do all the work. Nothing customized. It installed the nouveau driver and the install was a complete success. No problems at all. As soon as the nvidia driver installed the desktop pretty much became unresponsive so I forced the reboot and got the error message mentioned above.

I have preserved the drive and will get back to it tomorrow to see if I can get anything useful out of it. Remember it's completely unresponsive so trying to run journalctl won't work. Already tried that.

Best thing I think I can do here is to boot from another drive and mount this dead one and see if I can get into the directory structure. That I will try and have something, I hope, by QA meeting tomorrow. If you can think of something somewhere to look post it here and I'll take a look.

The system was running fine with nouveau. As soon as the nvidia driver was installed everything went in the trash can.

(In reply to William Kenney from comment #2)

> 
> Best thing I think I can do here is to boot from another drive and mount
> this dead one and see if I can get into the directory structure. 

That's exactly what the "journalctl -D" command is for :-)
The following should work on that install's root partition:

(In reply to Marja van Waes from comment #1)

> 
> There's a directory with a very long hexadecimal name in
>  /that/partition's/var/log/journal/
> 
> please run, as root, 
> 
>   journalctl -D /path/into/that/hexadecimal/directory/ > journal.txt
> 
> and attach journal.txt to this bug report.
> (compress the journal with xz if it's too large to attach)
> 

Apart from that, *unless* barjac tells you differently, please do also attach the output of

    ls -al /that/partition's/boot/ 

and attach:

    /that/partition's/boot/grub.cfg
and
    /that/partition's/boot/grub.cfg.old

Thanks :-)

oh, and please attach

   /that/partition's/etc/X11/xorg.conf

(In reply to Marja van Waes from comment #3)

> 
>     /that/partition's/boot/grub.cfg
> and
>     /that/partition's/boot/grub.cfg.old
> 

Please read

    /that/partition's/boot/grub2/grub.cfg
and
    /that/partition's/boot/grub2/grub.cfg.old

If you are left at a grub(2) prompt you can sometimes boot by using grub's built in commands.
ls
Should list the drives that it can see.
You can use search.file to find which drive/partition has a specific file e.g:
search.file /etc/mageia-release
Once you have the correct drive/partition then you can set that to the root variable e.g.:
root=(hd1,gpt3)
Assuming a simple/normal Mga installation then the following commands should boot it:
linux /boot/vmlinuz
initrd /boot/initrd.img
boot

The above assumes that grub2 is not broken and that the correct modules are installed to access the file system in use.

You can list loaded grub modules with:
lsmod

and load modules with:
insmod <modulename>


Hope that helps.

(In reply to Barry Jackson from comment #6)

> If you are left at a grub(2) prompt you can sometimes boot by using grub's
> built in commands.
> ls

grub> ls
(hd0) (hd0,msdos6) (hd0,msdos5) (hd0,msdos1)
grub>

I did not see this problem on my MBR system with the nvidia340 driver. I know Bill uses nvidia-current, and that may be making the difference, but my procedure was also somewhat different from his, and THAT could be making the difference.

I installed from the LiveDVD and updated as Bill did. (I activated the tainted repositories. Bill didn't say whether he did or not.) 

Where I differ is after installing the nvidia340 driver I used MCC to check the grub2 kernel boot options for the presence of "nokmsboot." It was not there, so I added it. (Bug 18084)

I too had to force a shutdown using the command line. (Bug 20153) Upon rebooting the process took longer than normal, as it usually does after this procedure, but it did complete to a working desktop. Another reboot took the normal amount of time.

CC: (none) => andrewsfarm

Created attachment 9013 [details]
journalctl.txt

Can you get anything out of this?

This looks good:
Mar 01 17:07:16 localhost drakx11[2547]: modify_append:  nokmsboot
Mar 01 17:07:16 localhost drakx11[2547]: moved file /boot/grub2/grub.cfg to /boot/grub2/grub.cfg.old
Mar 01 17:07:16 localhost drakx11[2547]: running: update-grub2

It ends with:

..drakx11[2547]: 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
                 done
..drakx11[2547]: created file /boot/.enough_space
..drakx11[2547]: removed files/directories /boot/.enough_space
..drakx11[2547]: ### Program is exiting ###

@ barjac

I suppose the "update-grub2 logs: mesg: ttyname failed: Inappropriate ioctl for device" line is unrelated and can be ignored?





There are a lot of KDE errors in the logs, but I don't see how they can

(In reply to Marja van Waes from comment #10)


> 
> There are a lot of KDE errors in the logs, but I don't see how they can

cause ending up in a grub shell.

Next task for me is to install the new x86_64 Plasma ISO and see how that does with nvidia. I'll get through that by Sunday, California time.

(In reply to William Kenney from comment #12)
> Next task for me is to install the new x86_64 Plasma ISO and see how that
> does with nvidia. I'll get through that by Sunday, California time.

Any feedback on that?

(In reply to Marja van Waes from comment #13)
> (In reply to William Kenney from comment #12)
> > Next task for me is to install the new x86_64 Plasma ISO and see how that
> > does with nvidia. I'll get through that by Sunday, California time.
> 
> Any feedback on that?

Ping? Do you still end up at a grub prompt when switching to nvidia after installing the pre-testing Mageia-6-rc-LiveDVD-Plasma-x86_64-DVD.iso ?

Or could you reproduce it in different cauldron (e.g. installed from a classical iso)?

Note that this bug wasn't assigned to anyone, yet!

Keywords: (none) => 6sta2
Whiteboard: 6sta2 => (none)

@ William

No reply and again no reply, so closing as OLD.


So this can no longer be reproduced with the QA 6RC isos?

Please reopen if the issue is still valid for current QA 6RC isos!

Status: NEW => RESOLVED
Resolution: (none) => OLD