Bug 18902

just again an information why it would be good to find an automatic solution. If I update the grub configuration with drakboot and check "Fremde OS testen" (="test fremd os" or similar) than again a entry for \EFI\Microsoft\Boot\bootmgfw.efi is created so that the EFI windows configuration is reseted and Mageie don't start any more...

I understand you can boot into the just installed Mageia, after attaching a Mageia Live USB-stick.

Please do so and then:

* If you installed from a Live iso, then please boot into the new install and, as root, run 

  journalctl -a > journal.txt

and attach journal.txt to this bug report

 
* However, if you did a traditional (non-Live) install, then please attach 

   /root/drakx/report.bug.xz

from that install instead.

CC: (none) => marja11, zen25000
Keywords: (none) => NEEDINFO

Dear Marja,
Thanks a lot for your work and your help!. Enclosed you will find the output of journalctl -a. But this output is created after I have booted my machine several times!!!! If you need the output of the first boot of the new installed Mageia (or better after I booted the live usb stick after the installation and executed the hack above to boot into the new installed system), please let me know. Then I would have to reinstall Mageia 6 again, but this would take one or two days...

I hope this works. Here you can find the file (is too large for an attachement!)

https://www.wetransfer.com/downloads/91a1710b24bc1428bf162f2184bff86220160709130906/78eb47829ecbd4e64cfd54816ac41cd820160709130906/431008

Created attachment 8145 [details]
Max's journalctl -a output, compressed

(In reply to Max Perl from comment #3)
> Dear Marja,
> Thanks a lot for your work and your help!. Enclosed you will find the output
> of journalctl -a. But this output is created after I have booted my machine
> several times!!!! 

That shouldn't matter, when I do "journalctl -a" the logs begin in April 2016, despite daily reboots. If I hadn't vacuumed them, they'd go back to when I installed Mageia.

It is only "journalctl -b" that starts at the very last boot.

Your logs show:

-- Logs begin at Sa 2016-07-09 09:16:24 CEST, end at Sa 2016-07-09 14:54:47 CEST. --

And the first kernel boot line shows:
Jul 09 09:16:24 localhost kernel: Command line: BOOT_IMAGE=/boot/vmlinuz root=mgalive:LABEL=Mageia-6-GNOME-LiveDVD splash quiet noiswmd rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0

So first you started the Live.

and later it shows that you're running draklive-install:
Jul 09 09:17:44 localhost draklive-install[2166]: ### Program is starting ###

However, this looks odd (the message about your /boot/EFI partition maybe being corrupted):
Jul 09 09:19:40 localhost draklive-install[2166]: mount_part: device=sda2 mntpoint=/boot/EFI isMounted= real_mntpoint= device_UUID=84ED-F292
Jul 09 09:19:40 localhost draklive-install[2166]: mounting /dev/sda2 on /mnt/install/boot/EFI as type vfat, options
Jul 09 09:19:40 localhost draklive-install[2166]: created directory /mnt/install/boot/EFI (and parents if necessary)
Jul 09 09:19:40 localhost draklive-install[2166]: running: mount -t vfat /dev/sda2 /mnt/install/boot/EFI -o check=relaxed
Jul 09 09:19:41 localhost kernel: FAT-fs (sda2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

You have two succesful reboots into sda8:
Jul 09 10:42:30 localhost.localdomain kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.6.3-desktop-1.mga6 root=UUID=1b748a98-b282-4dd2-b2f4-d040eafffe48 ro

Jul 09 11:03:21 localhost.localdomain kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.7.0-desktop-0.rc6.3.mga6 root=UUID=1b748a98-b282-4dd2-b2f4-d040eafffe48 ro

But the "Some data may be corrupt"-message about your EFI-boot partition keeps appearing, the last one is:
Jul 09 14:53:31 localhost.localdomain kernel: FAT-fs (sda2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.


When you updated your kernel, I saw a message about

Jul 09 10:56:34 linux bootloader-config[6598]: update-grub2 logs: mesg: ttyname fehlgeschlagen: Unpassender IOCTL (I/O-Control) für das Gerät
But there were 4 more such messages, always with update-grub2.

I don't know which device is meant by "das Gerät", could that be /dev/sda2 ?

Also, there are 1329 lines of 
    linux kernel: toshiba_acpi: Unknown event received 93
of which I don't have a clue what they mean.

Anyway, could you try to run (as root):

   fsck.fat -a /dev/sda2

That command should check the filesystem of your EFI partition and automatically fix it.

After that installing the Mageia bootloader to the EFI parition will hopefully work better.

Dear Marja,

Thanks for your answer. I don't think that the EFI problems have to do with the not properly unmounted EFI partition. As I said, I had the EFI partition with several distributions (e.g. opensuse). But some (e.g. ubuntu, mind and I think fedora) handles the worse EFI implementation on my toshiba better and it would be great if Mageia could do this, too. I think this is really a hardware issue. The toshiba laptops are "windows branded" and the EFI implementation is therefore a disaster! Perhaps this is not a real Mageia bug but more an enhancement proposal.

Nevertheless here the output of "fsck.fat -a /dev/sda2"

fsck.fat 4.0 (2016-05-06)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
  44:fe/02, 45:64/00
  Not automatically fixing this.
Performing changes.
/dev/sda2: 365 files, 52270/98304 clusters

A real bug I see with drakboot: If I try to add some kernel options with drakboot, nothing is written to /etc/default/grub (Manual editing and manual start of update-grub2) is no problem. But I saw this in the Mageia 6 Errata for the installation process. Was it known, that this issue also occurs with drakboot in a running system? And is this issue already fixed? I believe this because on my other laptop drakboot works without problems?

I have tested it at the moment again (after fsck.fat)
The output of "LC_ALL=C journalctl -r | grep drakboot" you will find attached (only the messages of today, the others I have deleted).

Created attachment 8147 [details]
try to add kernel options with drakboot

PS.: I have forgotten to mention, that my system is dualboot Linux and Windows (OEM from toshiba). I think, I had no problems (even if I cannot guarantee it) if I would delete all partitions or if I would install a normal, buyed Windows. I attach the output of "fdisk -l"

PSS.: A further problem is that inactivating with efibootmgr doesn't work. It is not a big problem as I can delete the EFI entries with efibootmgr -b XXXX -B...

Created attachment 8148 [details]
output of fdisk -l

It's a pity everyone in BugSquad has been too busy to assign this bug report when all requested information was supplied.

Or that we didn't manage, like I don't now (despite trying for 20 minutes), to correctly process the information in this report.

Assigning to the mageiatools maintainers, who'll reassign if they're the wrong assignee.

Assignee: bugsquad => mageiatools
Keywords: NEEDINFO => (none)

Max
I have come across this looking at other things. As I understand the original comment, Windows booted instead of just-installed Mageia - a common problem; but other Linux's managed to get themselves booted.
This bug is old and goes back to 2016. We have just issued Mageia 7.1. Do you want to persue this? I would ask you questions, but no logs, just efibootmgr outputs. It all depends on how well or badly behaved the EFI firmware is. Some ignore Active, others BootOrder.
I notice there is no BootNext in the O/P (nor on my box), but efibootmgr has a parameter for it: n|N.
It should be possible to pinpoint the NVRAM setup differences between a 'works' Linux installation and Mageia.

CC: (none) => lewyssmith

No news on This. Closing

Resolution: (none) => OLD
Status: NEW => RESOLVED
CC: (none) => yves.brungard_mageia