Bug 12566 - Mageia 4: Emergency mode when booting
Summary: Mageia 4: Emergency mode when booting
Status: RESOLVED DUPLICATE of bug 10179
Alias: None
Product: Mageia
Classification: Unclassified
Component: Release (media or process) (show other bugs)
Version: 4
Hardware: x86_64 Linux
Priority: Normal major
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-04 11:13 CET by Raphaël Vinet
Modified: 2014-05-17 18:37 CEST (History)
5 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
similar boot screen? (163.75 KB, image/jpeg)
2014-02-04 22:46 CET, Filip Komar
Details
boot.log when booting Mageia 4 (5.61 KB, text/x-log)
2014-02-06 19:32 CET, Raphaël Vinet
Details
fstab when using Mageia 3 (382 bytes, application/octet-stream)
2014-02-06 19:33 CET, Raphaël Vinet
Details
fstab after updating M3 to M4 (391 bytes, application/octet-stream)
2014-02-06 19:33 CET, Raphaël Vinet
Details
fstab after adding nofail for windows partition (398 bytes, application/octet-stream)
2014-02-06 19:34 CET, Raphaël Vinet
Details

Description Raphaël Vinet 2014-02-04 11:13:44 CET
Description of problem:
No boot on Mageia 4 after upating from Mageia 3
After booting you have the initial screen with Mageia (and the little flowers :p) and direct after you have a shell with the message below:
"Welcome to emergency mode ! After logging in, type "Journalctl -xb" to view systmen logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot into default mode. Give root password for maitnenance (or press Control-D to continue):"
- Ctrl - D do nothing
- Using the last kernel of Mageia 3 do nothing else
- Using the 'mode sans échec' do nothing else


Rmks:
- Notebook Asus G74S with Nvidia GeForce GTX 560M and dual boot with windows 8.1
- No problem to (re)install (DVD x86_64) and use Mageia 3
- Not possible to do a fresh install/update/repair with the iso DVD (see bug 12549) 

Version-Release number of selected component (if applicable):


How reproducible:
Done 2 times with same error

Steps to Reproduce:
1. Install mageia 3 (DVD x86_64)
2. Update mageia 3
3. Update to mageia 4
- su
- urpmi.removemedia -a
- urpmi.addmedia --distrib --mirrorlist http://mirrors.mageia.org/api/mageia.4.x86_64.list
- urpmi --replacefiles --auto-update --auto (2 times as written in the wiki)
4. Reboot
5. Select Mageia 4



Reproducible: 

Steps to Reproduce:
Filip Komar 2014-02-04 22:25:47 CET

CC: (none) => filip.komar

Comment 1 Filip Komar 2014-02-04 22:46:34 CET
Created attachment 4931 [details]
similar boot screen?
Comment 2 Filip Komar 2014-02-04 22:59:46 CET
I had a similar trouble. It might not be the same but it could be connected.

I upgraded OK. Then after a few succesful days I decide for a small cleanup. So I uninstalled old kernels and I also relabel my test root partition in mcc from Mageia_4 to Mageia_4_test. Unfortunatelly fstab was not updated in the process and I got very serious screen as you can see in attachment 4931 [details] above.

Luckily I just fixed fstab and I was able to start mga4 right away normally by systemctl default.


Raphaël can you please check that fstab is in line with blkid?
Comment 3 Manuel Hiebel 2014-02-04 23:35:13 CET
Raphael, maybe you can tell a little what does said the logs ?
Comment 4 Remco Rijnders 2014-02-05 10:16:00 CET
I had the same problem after upgrading my dual boot laptop from 3 to 4. The first reboot after the upgrade landed me in emergency mode. I think bug #11869, bug #10179, and bug #5806 are all related.

For me the fix was (seemed to have been) to add the nofail option to /etc/fstab for both Windows partitions.

Note that the suggested 'systemctl default' appears to do nothing and returns one to the same prompt, as does 'systemctl reboot' after a reboot. Ctrl-D also takes one back to the same prompt. Leaving only Journalctl -xb which is enough to scare any new user away. For this, I am raising the severity.

CC: (none) => mageia
Severity: normal => major

Comment 5 Raphaël Vinet 2014-02-05 17:58:58 CET
Hi,

I will try another update these night, so:
- urpmi.removemedia -a
- urpmi.addmedia --distrib --mirrorlist http://mirrors.mageia.org/api/mageia.4.x86_64.list
- urpmi --replacefiles --auto-update --auto (2X)

After coming back from work I will generate a log file (and taking account the comment for fstab to see the possible work around;))

Rmk:
The only difference now that is I don't use propriatary driver for Nvidia
Comment 6 Raphaël Vinet 2014-02-06 19:31:50 CET
Hi,

As promissed ...

You can find in attachments :
- /var/log/boot.log
- fstab_m3 (/etc/fstab before updating M3 to M4)
- fstab_m4_ini (/etc/fstab after updating M3 to M4)
- fstab_m4_mod (/etc/fstab after adding nofail for the windows partition)

==> so why it was OK without nofail with M3 and not with M4 after a 'simple' update ?


So you can see with fstab_m4_mod the solution provided by Remco (Thx !:)) is good for me ... but just for me
Comment 7 Raphaël Vinet 2014-02-06 19:32:41 CET
Created attachment 4949 [details]
boot.log when booting Mageia 4
Comment 8 Raphaël Vinet 2014-02-06 19:33:09 CET
Created attachment 4950 [details]
fstab when using Mageia 3
Comment 9 Raphaël Vinet 2014-02-06 19:33:36 CET
Created attachment 4951 [details]
fstab after updating M3 to M4
Comment 10 Raphaël Vinet 2014-02-06 19:34:06 CET
Created attachment 4952 [details]
fstab after adding nofail for windows partition
Comment 11 Filip Komar 2014-02-06 20:15:56 CET
This is just workaround I suppose. Is your windows partition mounted anyway?

Did it worked before?
Comment 12 Raphaël Vinet 2014-02-06 20:32:43 CET
Yes it is 'just' the workaround to 'just' boot Mageia 4

No it is not mounted:

[root@localhost ~]# mount | grep '/dev/sd'
/dev/sda5 on / type ext4 (rw,noatime,data=ordered)
/dev/sda7 on /home type ext4 (rw,noatime,data=ordered)


And it seems I can't mount
[root@localhost ~]# mount /media/windows/
Windows is hibernated, refused to mount.
Failed to mount '/dev/sda2': Opération non permise
The NTFS partition is in an unsafe state. Please resume and shutdown
Windows fully (no hibernation or fast restarting), or mount the volume
read-only with the 'ro' mount option.
Comment 13 Filip Komar 2014-02-06 20:46:22 CET
(In reply to Raphaël Vinet from comment #12)
> And it seems I can't mount
> [root@localhost ~]# mount /media/windows/
> Windows is hibernated, refused to mount.
> Failed to mount '/dev/sda2': Opération non permise
> The NTFS partition is in an unsafe state. Please resume and shutdown
> Windows fully (no hibernation or fast restarting), or mount the volume
> read-only with the 'ro' mount option.

If that's true is what is suppose to be. Hibernating system doesn't expect change on it's file system so all changes would be lost if you write to it. And even worse. File system could be severely corrupted in that case.

If that's not true I would first try to run Windows and do a full check of it's file system like this:
chkdsk c: /f

Please report the result.
Comment 14 Colin Guthrie 2014-02-06 21:00:54 CET
It's likely a fix in newer ntfs-4g to NOT mount any NTFS volumes if hibernate data is detected. I certainly remember reading about this in the past and how it can cause corruption if the disk is mounted rw and then the hibernation session is resumed.

So this likely explains the change in behaviour between mga3+4 -> ntfs-4g got more clever, and as systemd has always been able to mount the disk before, you've never been dropped to the prompt.

AFAICS, this is everything working correctly.
Comment 15 Raphaël Vinet 2014-02-06 21:15:52 CET
(In reply to Filip Komar from comment #13)

As asked
- Starting PC
- Choose Windows
- Shell in administrator mode
- chkdsk c: /f (not possible to execute when connected so for the next start)
- Shutdown
- Boot
- Choose Windows (no special error messages or something)
- Login
- Shutdown (so no hibernate or sleep or ... a shutdown)
- Boot
- Mageia 4

... and no windows mounted and not possible to mount

"Une erreur est survenue en accédant à « OS ». Le système a répondu :The requested operation has failed: Error mounting system-managed device /dev/sda2: Command-line `mount "/media/windows"' exited with non-zero exit status 14: Windows is hibernated, refused to mount. Failed to mount '/dev/sda2': Operation not permitted The NTFS partition is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting), or mount the volume read-only with the 'ro' mount option."
Comment 16 Filip Komar 2014-02-06 21:45:10 CET
Nasty. Unfortunately this is beyond my ability to help. Good luck.
Comment 17 Sander Lepik 2014-02-06 23:15:20 CET
You are running Windows 8 - that means that by default windows doesn't shut down, it is using some weird hybrid shutdown that they call "Fast Startup". You can disable it, see this url: http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html

It probably would work if you restart the system, then it doesn't use the hybrid hibernation that kicks in during shutdown..

CC: (none) => mageia

Comment 18 Raphaël Vinet 2014-02-07 05:10:16 CET
(In reply to Sander Lepik from comment #17)
Hi,


No time to read all now (time to take train for work;)) but the fast solution provided in your reference link
- Boot
- Wndows
- Login
- Shutdown by the Win + X keys
- Boot
- Mageia 4
- Login

... and windows is now well mounted
/dev/sda2 on /media/windows type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096) ==> read/write is good

But jesus !
- A shutdown must be a SHUDOWN !
and/or
- A shudown with Win + X and a shutdown with the normal way must be SAME ! If not call it with different words win$ !! We will see whith the future Win 8.1 update 1 if something is changed ;)


... that shutdown problem with the 'nofail' problem are not something specialy good for new users :/


Thx Sander !
Florian Hubold 2014-02-07 11:35:47 CET

CC: (none) => doktor5000

Florian Hubold 2014-02-07 21:56:38 CET

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=4042

Comment 19 Florian Hubold 2014-05-17 18:37:08 CEST
Marking as duplicate of https://bugs.mageia.org/show_bug.cgi?id=10179 as this is the same root cause (nofail missing)

*** This bug has been marked as a duplicate of bug 10179 ***

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


Note You need to log in before you can comment on or make changes to this bug.