Boot into failsafe mode

This forum is dedicated to basic help and support :

Ask here your questions about basic installation and usage of Mageia. For example you may post here all your questions about getting Mageia isos and installing it, configuring your printer, using your word processor etc.

Try to ask your questions in the right sub-forum with as much details as you can gather. the more precise the question will be, the more likely you are to get a useful answer

Boot into failsafe mode

Postby gohlip » Feb 26th, '14, 09:23

I was testing some distro and the installation created a new UUID for my swap partition.
Normally, this won't pose a problem as I will change the fstab for the other existing distros and the resume=xxxxxx line (if any) in the grub.cfg and I think I had done this successfully for Mageia 2 or 3 in the past.

Now using Mageia 4, despite changing the fstab and grub.cfg, I was dropped to dracut prompt with something like this..
Code: Select all
dracut
/dev/disk/by-uuid/xxxxxxxxxxxxxx does not exist

The uuid refers to the old swap uuid.
Also note my other distros boot up without problem after changing their fstabs.

I decided to boot into failsafe mode so I can redo dracut to correct the issue.
So I added "single", "1", "BOOT_IMAGE=failsafe" (one at a time) in the grub linux line.
Each time I was shown the same dracut error message above.

Mageia's livecd repair console does not help. (unless perhaps I chroot into Mageia and perform the repair, which I think is ...overkill, and for that matter, my other installed distros may do the job).

Can someone help me get into recovery/failsafe mode?
Thanks.

ps: I am using my own grub 2, but I can boot using Mageia's grub 2 if need be (but I note there is no failsafe entry in the advanced section).
but I do not have grub-legacy.
Why do we live? To prove not everything in nature has a purpose.
gohlip
 
Posts: 573
Joined: Jul 9th, '12, 10:50

Re: Boot into failsafe mode

Postby unklar » Feb 26th, '14, 12:02

Go with "e" in the processing of the kernel line
delete them there the resume = UUID = xxxxx ... entry
boot it on with Ctrl+x started

in the system, they change the fstab and bootloader configuration

see: bug 12305 https://wiki.mageia.org/en/Mageia_4_Err ... ade_Issues
and
https://wiki.mageia.org/en/Mageia_2_Err ... t_in_fstab
from doktor5000

Please report it
I myself have not had the error 8-)
unklar
 
Posts: 40
Joined: Apr 10th, '12, 20:30

Re: Boot into failsafe mode

Postby gohlip » Feb 26th, '14, 13:48

Thanks for the reply, unklar. I have changed Mageia's fstab to new swap UUID, corrected the "resume=xxxx" entry and tried another time to remove this "resume=xxxx" entry too. All won't boot.
Normally, even if everything works, removing the "resume=xxxxx" will boot. Not this time.

I think there is more issues here, possibly initrd is tied in to the fstab entries, but I don't really know. That is why I wanted to boot in safe mode (failsafe/recovery, whatever different distro's call it) and redo the initrd; but then again, if that is the case, I am beginning to think nothing else will work except a reinstall. And that is really silly for just a UUID change. I recall for some distros, having wrong swap UUID will still boot and correct itself, but of course, we should always maintain good practices. And distros should not willy-nilly change swap UUID on installations.

Oh, Mageia is now fully on systemd, and I tried to include "systemd.unit=rescue" in the linux line. Won't work too (tested and works on chakra (nothing wrong here) - to boot in rescue mode).
Ah well, I am slightly dissappointed. Mageia (through Mandrake) has a personal connection for me. But perhaps I should move on.

Thanks again, unklar.

[added] - Also tried to boot current and older kernels and initrd directly (3.12.8-desktop-2.mga, etc) . Nothing works. Don't look promising.
Why do we live? To prove not everything in nature has a purpose.
gohlip
 
Posts: 573
Joined: Jul 9th, '12, 10:50

Re: Boot into failsafe mode

Postby unklar » Feb 26th, '14, 16:06

Thank you for your feedback
Until now I believed that it only affects users of Grub-legacy ..

Have you tried the option "nofail"?

I think the "failsafe mode" is not suitable.
Probably "chroot" must be used.

I do not understand why mga4 of this rule differs.

man mount wrote:..
The recommended setup is to use LABEL=<label> or UUID=<uuid> tags rather than /dev/disk/by-{label,uuid}
udev symlinks in the /etc/fstab file. The tags are more readable, robust and portable. The mount(8) command
internally uses udev symlinks, so the use symlinks in /etc/fstab has no advantage over LABEL=/UUID=. For
more details see libblkid(3).
..
unklar
 
Posts: 40
Joined: Apr 10th, '12, 20:30

Re: Boot into failsafe mode

Postby gohlip » Feb 26th, '14, 18:01

unklar, in this particular case, I don't think it's a matter of device naming [*] but I am 100% certain. Appreciate your input.

Cheers and thanks.
[*] - Though you are right that Mageia can be better in this respect - I have labelled all my partitions as well. Note you can search/set for device using file search too (--file not just --uuid and --label)
Why do we live? To prove not everything in nature has a purpose.
gohlip
 
Posts: 573
Joined: Jul 9th, '12, 10:50

Re: Boot into failsafe mode

Postby claire » Feb 27th, '14, 16:00

The failsafe is really to workaround grphical issues. I think it removes the resume too but could be mistaken.
The rescue system is part of the installer dvd. It will allow you to mount your partitions or reinstall grub.

It's maybe worth checking that the symlinks point to the correct things in /boot
Help to make Mageia! Get involved.. Please come and join us
claire
 
Posts: 161
Joined: May 28th, '11, 19:17
Location: UK

Re: Boot into failsafe mode

Postby gohlip » Feb 27th, '14, 19:06

Correct, failsafe is useful for things like wrong install of proprietary graphics drivers (like when inintrd dkms'ed the wrong drivers) and that's why I tried to boot to failsafe, not so much for the drivers but on the possibility the initrd includes other things that make my system kaput. Yes, I also tried removing resume=xxxxxxxxxxxxxxx and use the the install dvd, to reinstall grub (no luck - I unstalled grub-leagcy and maybe that's why); I used the rescue part which drop to shell, probably expecting me to mount partitions and chroot. And I did try to boot not just the sym-link but the actual vmlinuz-3.12-x-xx-desktop-x.mgax and their actual initrd too, including the older kernels.

Looks like I tried everything. :)
I know it's easier to reinstall (really, I have separate partitions for data and another for config files, so it's quite easy and I lose nothing too) but a part of me wants to 'crack' it (like I upgraded to M4 from M3 - lots of problems, cracked it, but unfortunately forgot what I did :) )

So, do not worry too much for me. I'm fine; appreciate the concern (thanks, unklar too) and taking a break. Someday I might resume. It was fun.
Thanks, everybody. Cheers. [grube, doktor, lan, danke]
ps: I think it is the inodes in the Mageia partition, but heck, what would I know about such things.
Why do we live? To prove not everything in nature has a purpose.
gohlip
 
Posts: 573
Joined: Jul 9th, '12, 10:50

Re: Boot into failsafe mode

Postby ohmysql » Dec 5th, '14, 06:20

Just to add to this thread since I'm having the same problem.

By the time I get to dracut, /etc/fstab doesn't exist. There is only /etc/fstab.empty.

So that's a problem. I try to correct in by booting Mint instead. When I look at the Mageia partition under Mint, the problem causing line in Mageia/etc/fstab is commented out, so I can't even figure out where it's getting the idea to call the old swap UUID??? That is really confusing. Where else could something be calling it? I also changed Mageia/etc/fstab.bak just in case, but that clearly doesn't seem to be the problem.

Help?
ohmysql
 
Posts: 39
Joined: Nov 8th, '12, 16:59

Re: Boot into failsafe mode

Postby gohlip » Dec 5th, '14, 07:00

so I can't even figure out where it's getting the idea to call the old swap UUID???
As you can read from my posts, I am unable to solve this also (despite changing fstab UUID entries). Hope someone else can answer this for us. I too like to know. Also, per my posts, I am back (on Mageia 5) with new install and it looks much better (grub2 works - with grub-mkrescue, nice).

But rethinking back, maybe an "updatedb" may help? I don't know for sure, but you can try. Let us know, ya?
Code: Select all
# updatedb

Oh, to boot to prompt with networking (important), add "systemd.unit=multi-user.target" (without appos) in the linux line of grub menu and boot.
Code: Select all
linux   /boot/vmlinuz-desktop root=UUID=xxxxxxxxxxxxxxxx   nokmsboot systemd.unit=multi-user.target   ro
Why do we live? To prove not everything in nature has a purpose.
gohlip
 
Posts: 573
Joined: Jul 9th, '12, 10:50

Re: Boot into failsafe mode

Postby jiml8 » Dec 5th, '14, 07:02

You guys are getting buggered by systemd.

That magnificent pile of excrement will not drop you into a repair shell when it can't find a disk; it just hangs - which, to my mind, is totally unacceptable. Nonetheless, that's the way it is.

You have two choices.

Basically, the UUID of the partition the system boots from and the partition that is swap is embedded into the initrd. So, you either rebuild the initrd, or you change the UUID of the affected partition(s). The tune2fs command makes changing the UUID of the system partition easy enough, but if swap is your problem it won't work. If swap is your problem, you have to rebuild your initrd.

To rebuild your initrd, you have to boot into a linux live distro. I recommend using a Mageia USB stick or bootable DVD because that will give the most similar kernel. After booting this system, turn off all swap, then mount your system drive. To do this, open a console window, su to root, then execute these commands:
Code: Select all
swapoff -a
mount /dev/sda1 /mnt

This assumes your system partition is on /dev/sda1, that /mnt exists, and that this is where you want to mount it.

Now, you have to build your running system on this partition by mounting /proc, /sys, /dev, and /tmp here.

To do this:
Code: Select all
mount -o bind /dev /mnt/dev
mount -o bind /sys /mnt/sys
mount -o bind /proc /mnt/proc
mount -o bind /tmp /mnt/tmp


If your boot partition is a separate partition, make sure you mount it on /mnt/boot.

Now, chroot into your mounted system partition so that you are running from it:
Code: Select all
chroot /mnt


At this point, you should be running off of your real system on your hard drive, with all the system features you have to have properly mounted.

Now cd into /etc and edit fstab to make sure the entry for the system and swap is correct, with the proper UUIDs or - if you use partition labels (as I do) with the proper partition labels. After doing this, fix up anything else you need to fix up (crypttab, mdadm, or whatever). Once you have the entire system fixed up for the new drive(s), issue the dracut command to rebuild the initrd.

After this completes without error, you should be able to reboot the computer and have everything working.
jiml8
 
Posts: 1253
Joined: Jul 7th, '13, 18:09

Re: Boot into failsafe mode

Postby gohlip » Dec 5th, '14, 07:36

Well, first, I am also using Manjaro, which uses what you call "that pile of shit" (use the right term, dude), systemd. And as I pointed out above, no problem when I change the fstab UUID entry. Only Mageia gets 'buggered'.
So maybe Mageia's systemd cannot resolve this or Manjaro's systemd can. Whatever.

Nevertheless, there's a HOOKS line in mkinitcpio (dracut for Mageia) which is missing in dracut.conf. (not in mk2fs.conf).
There is one in /etc/dracut.conf.d/51-mageia-resume.conf and will changing that alone fix it?
I don't know.

But thanks for your suggestion, maybe ohmysql can try it. I'll say again, I've reinstalled M5.
Why do we live? To prove not everything in nature has a purpose.
gohlip
 
Posts: 573
Joined: Jul 9th, '12, 10:50

Re: Boot into failsafe mode

Postby doktor5000 » Dec 5th, '14, 12:31

gohlip wrote:Nevertheless, there's a HOOKS line in mkinitcpio (dracut for Mageia) which is missing in dracut.conf. (not in mk2fs.conf).
There is one in /etc/dracut.conf.d/51-mageia-resume.conf and will changing that alone fix it?

Nope, as that is only taken into account when (re)generating initrd's, so you would have to run dracut after changing /etc/dracut.conf.d/51-mageia-resume.conf

Where the UUID is also used is in grub configuration for the resume= parameter, maybe it's sufficient to simply edit kernel command line before booting, removing the resume= option?

FWIW, you can see the UUIDs used in the initrd for the currently booted kernel e.g. via
Code: Select all
lsinitrd /boot/initrd-$(uname -r).img | grep -e by\-uuid
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 17603
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: Boot into failsafe mode

Postby gohlip » Dec 5th, '14, 13:12

Where the UUID is also used is in grub configuration for the resume= parameter, maybe it's sufficient to simply edit kernel command line before booting, removing the resume= option?


Thanks for answering, doktor5000. As I pointed out above, I've done that. No dice (won't work).
The thing is I've just changed the fstab entries for my other OS's and they all boot. Most use systemd (kubuntu is 'partial' systemd) without needing to 'dracut' (mkinitcpio/update-initramfs/whatever).
Also, I recall (if correctly), I've done the same thing on Mageia 2 or Mageia 3 (as written in above posts) and Mageia boots then. And if I recall (again if correctly) it was using systemd then also. [I think I wrote in a topic I was amazed Mageia took on systemd early because it is usually a 'laggard' in adopting new things - think grub2, still :) and more]. So I was surprised this time in M4, it got 'buggered' (ha! nice term).

Of course, we can deliberately replicate the problem (by changing swap UUID -easy) but I'll pass :) (I won't do it).

Oh, what I am asking (sorry I was not clear) is that in my other systemd systems, I can remove the 'resume' in HOOKS in a initramfs (dracut) config file and redoing initramfs (dracut) and I don't have to bother with swap uuid (of course, I cannot hibernate, but that's fine). How do I do that in Mageia? Would removing/changing 51-mageia-resume.conf do?

Thanks for all the input (jim18 too). Cheers.
Why do we live? To prove not everything in nature has a purpose.
gohlip
 
Posts: 573
Joined: Jul 9th, '12, 10:50

Re: Boot into failsafe mode

Postby doktor5000 » Dec 5th, '14, 21:27

gohlip wrote:The thing is I've just changed the fstab entries for my other OS's and they all boot. Most use systemd (kubuntu is 'partial' systemd) without needing to 'dracut' (mkinitcpio/update-initramfs/whatever).
Also, I recall (if correctly), I've done the same thing on Mageia 2 or Mageia 3 (as written in above posts) and Mageia boots then. And if I recall (again if correctly) it was using systemd then also.


Actually there is no relation between dracut and systemd. We had dracut before we had systemd, and such issues happened before.
Problem is that systemd by default refuses to boot when normal filesystems (not marked as nofail or _netdev or similar) cannot be mounted - that is, it drops to an emergency console. It's easy to continue from there if you know what the problem is.

This issue with the swap UUID has been caused by Mageia users - believe it or not :o To explain, many people had issues when resuming from hibernation or suspend.
And then /etc/dracut.conf.d/51-mageia-resume.conf was added to fix those bugs, but somehow now as fallout it seems to fail for others sometimes.
Mainly the UUID for the swap partition should enable dracut to enable swap when using LVM, which is not that uncommon.

For more information see one recent threads on -dev ml:
https://ml.mageia.org/wwsympa-wrapper.f ... 00053.html
And an older one from february, specifically about dracut/initrd and UUID:
https://ml.mageia.org/wwsympa-wrapper.f ... 00006.html


Still I basically fail to understand why the UUID of a swap partition should change during normal usage, when not reinstalling or installing another distro, which formats swap partition ...
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 17603
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: Boot into failsafe mode

Postby jiml8 » Dec 6th, '14, 00:34

Actually there is no relation between dracut and systemd. We had dracut before we had systemd, and such issues happened before.
Problem is that systemd by default refuses to boot when normal filesystems (not marked as nofail or _netdev or similar) cannot be mounted - that is, it drops to an emergency console. It's easy to continue from there if you know what the problem is.


Actually, in this circumstance it does NOT drop to an emergency console. It SAYS it is going to an emergency console, then it hangs. Only way out is to reboot into a repair distro.

As far as that goes, I consider it to be incorrect behavior to go to an emergency console due to a missing drive, unless that missing drive is essential to booting the system. Thus, so long as / and /boot (and, probably, /etc and /usr) are available, the system should come up, even if it comes up incompletely. Most Linux systems will come up missing /tmp, missing /home, and missing a lot of other things. This is very very helpful when presented with a problem; at least you can get the system up and work within the system to solve whatever the problem is.

As it stands, when there is even a minor problem with drives, you have to boot into a rescue system.
jiml8
 
Posts: 1253
Joined: Jul 7th, '13, 18:09

Re: Boot into failsafe mode

Postby doktor5000 » Dec 6th, '14, 01:51

jiml8 wrote:As far as that goes, I consider it to be incorrect behavior to go to an emergency console due to a missing drive, unless that missing drive is essential to booting the system.

Partly agreed, but only considering it to be incorrect will not fix that behaviour. Feel free to (constructively) comment on the relevant bugs marked as release_blocker for Mageia 5:

https://bugs.mageia.org/show_bug.cgi?id=4042
https://bugs.mageia.org/show_bug.cgi?id=7673
https://bugs.mageia.org/show_bug.cgi?id=10179
https://bugs.mageia.org/show_bug.cgi?id=12305
https://bugs.mageia.org/show_bug.cgi?id=12566 (only included FWIW, but this is an issue for people having Windows 8 and Mageia in parallel)
https://bugs.mageia.org/show_bug.cgi?id=12631
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 17603
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: Boot into failsafe mode

Postby gohlip » Dec 6th, '14, 04:53

doktor5000 wrote:Actually there is no relation between dracut and systemd. We had dracut before we had systemd, and such issues happened before.
.
.
And then /etc/dracut.conf.d/51-mageia-resume.conf was added to fix those bugs, but somehow now as fallout it seems to fail for others sometimes.
Mainly the UUID for the swap partition should enable dracut to enable swap when using LVM, which is not that uncommon.


What I am also hinting at (of course, I don't know but we can replicate problem to find out) is that /etc/dracut.conf.d/51-mageia-resume.conf may be cause of this problem. Not systemd, (and possibly doing dracut without changing /etc/dracut.conf.d/51-mageia-resume.conf') won't help.

To find out we need to replicate problem (change swap uuid) and
(a) if boot fails
(b) change fstab to new uuid (and grub resume=xxxx) and check if boot still fails
(c) doing dracut after the above changes and check if boot fails
(d) also remove change /etc/dracut.conf.d/51-mageia-resume.conf to new uuid or remove and check if boot still fails
(e) doing dracut after (d) and check if boot fails.

doktor5000 wrote:Still I basically fail to understand why the UUID of a swap partition should change during normal usage, when not reinstalling or installing another distro, which formats swap partition ..

Correct and agree. Installing new debian OS change swap uuid. It does not happen to other OS installations. Just debian and debian based distro's (possibly Gentoo - not sure - years ago) . Not Ubuntu or Ubuntu based distros.
Again, I state I will not be replicating this problem (I have too many OS's in my system). Sorry.

But this is an interesting issue (that should be addressed).
Why do we live? To prove not everything in nature has a purpose.
gohlip
 
Posts: 573
Joined: Jul 9th, '12, 10:50

Re: Boot into failsafe mode

Postby jiml8 » Dec 6th, '14, 06:48

Doing a "man dracut" reveals the information that mounted device info is by default taken from /proc/self/mountinfo.

However there is an option --fstab that will cause an fstab (presumably /etc/fstab) to be used instead. I wonder if this would make a difference. For instance, if the fstab refers to devices by label instead of by UUID, would the label go into the initrd? That would be easier.

There does not appear to be an entry for the swap partition in /proc/self/mountinfo, so using the default option is causing swap to be identified some other way (perhaps from /proc/swaps or from /proc/partitions?). If the fstab is used, would the swap device be referred to by device name rather than UUID?
jiml8
 
Posts: 1253
Joined: Jul 7th, '13, 18:09

Re: Boot into failsafe mode

Postby ohmysql » Dec 6th, '14, 09:23

Not sure how helpful this was as a test but I deleted the erroneous UUID in /etc/dracut.conf.d/51-mageia-resume.conf, rebooted to no effect.

I'll try the other stuff y'all suggested soon enough!
ohmysql
 
Posts: 39
Joined: Nov 8th, '12, 16:59

Re: Boot into failsafe mode

Postby gohlip » Dec 6th, '14, 13:10

@ohmysql, I assume you have fixed your fstab (no longer empty and correct uuid especially for /).
Boot into prompt (systemd.unit=multi-user.target) and do dracut.
Code: Select all
# dracut -f

If it don't work, I don't think I can help further, but try jiml8 chroot too. please let us know.

Good luck.
Why do we live? To prove not everything in nature has a purpose.
gohlip
 
Posts: 573
Joined: Jul 9th, '12, 10:50

Re: Boot into failsafe mode

Postby ohmysql » Dec 6th, '14, 20:30

FYI when I talk about fstab being empty, I mean there is no fstab in the dracut debug shell. ls /etc/ shows only the file fstab.empty.

And yes, I corrected the incorrect uuid in the normal Mageia fstab. No effect, it's still giving the incorrect uuid of the old swap partition as the error. I changed it to /dev/sda5 which should be working.

Within the context of the dracut debug shell, dracut -f does nothing, it says command not found.

I tried passing the systemd command you mentioned into grub, and that didn't work.

I'll try your other fixes, like rebuilding initd.

FYI I removed the resume line in the grub2 that's loading this mess!

Check for edits, I'll just post edit updates here as I try things, until someone else responds.

PS It'd be helpful when you're giving me suggestions y'all to please mention in what context I should try a command. For instance, I can try code in grub2, in dracut, in mint, or on a liveCD. For instance, your instructions about how to rebuild initrd, swapoff and all that, I'm not sure if I should login to a LiveCD (I only have a mint LiveCD) or if this is safe to do within a Linux Mint session off my hard disk.

Similarly, many of the commands y'all suggested don't work in dracut debut shell, so I can only assume that you want me to execute those commands from somewhere, but I'm not sure if Mint Livecd would be better than my life linux. And if I'm using linux, I'll have to specify the drive I'm using etc. FYI it's /dev/sda5 is the swap if that's helpful, I believe /dev/sda7 is Mageia.

Can I even repair dracut through the dracut setup prompt? Apparently not, I think that's kind of ridiculous.
ohmysql
 
Posts: 39
Joined: Nov 8th, '12, 16:59

Re: Boot into failsafe mode

Postby ohmysql » Dec 6th, '14, 20:45

doktor5000 wrote:
gohlip wrote:Nevertheless, there's a HOOKS line in mkinitcpio (dracut for Mageia) which is missing in dracut.conf. (not in mk2fs.conf).
There is one in /etc/dracut.conf.d/51-mageia-resume.conf and will changing that alone fix it?

Nope, as that is only taken into account when (re)generating initrd's, so you would have to run dracut after changing /etc/dracut.conf.d/51-mageia-resume.conf

Where the UUID is also used is in grub configuration for the resume= parameter, maybe it's sufficient to simply edit kernel command line before booting, removing the resume= option?

FWIW, you can see the UUIDs used in the initrd for the currently booted kernel e.g. via
Code: Select all
lsinitrd /boot/initrd-$(uname -r).img | grep -e by\-uuid


I did edit the 51-mageia file via my live Mint on the same machine, then rebooted to no effect. I'm not sure what you mean by "run dracut" but I'm in the dracut repair shell, so I assume that didn't work.

And indeed, I've removed the resume option in grub to no effect, but thanks!

PS and naturally I can't run lsinitrd from dracut debug shell! :P
ohmysql
 
Posts: 39
Joined: Nov 8th, '12, 16:59

Re: Boot into failsafe mode

Postby gohlip » Dec 6th, '14, 20:52

After reading your post, I tried systemd.unit=multi-user.target and it works, it boots to prompt. Logging in I tried "sudo dracut -f" and it works too.
Of course, I am on a functional M5.
Can you try again but you can also try with systemd.unit=rescue.target? This will boot to root prompt (you need to enter your root password). You won't have network access so don't do anything else except dracut.

Seriously on a practical note, it is far easier to reinstall, but we won't learn anything. But from a practical point for you, you should consider reinstalling.
Good luck.
Why do we live? To prove not everything in nature has a purpose.
gohlip
 
Posts: 573
Joined: Jul 9th, '12, 10:50

Re: Boot into failsafe mode

Postby ohmysql » Dec 6th, '14, 20:56

gohlip wrote:To find out we need to replicate problem (change swap uuid) and
(a) if boot fails
(b) change fstab to new uuid (and grub resume=xxxx) and check if boot still fails
(c) doing dracut after the above changes and check if boot fails
(d) also remove change /etc/dracut.conf.d/51-mageia-resume.conf to new uuid or remove and check if boot still fails
(e) doing dracut after (d) and check if boot fails.


lol hard to blame you for now wanting to replicate this mess.

I changed the swap id in both Mageia's fstab and /etc/dracut.conf/51-etc. Actually, in the latter I just removed the line... are you suggesting I put in the new UUID? In any case, I doubt that will help. The faulty UUID is clearly embedded somewhere in initrd because after changing fstab and 51-etc., it's still calling the faulty UUID and crashing.

I just removed the grub resume line but I can try to replace it with the new swap UUID?

What do you mean by "doing dracut"--and how can I do this from the dracut debug shell? I tried "dracut -f" and it said command not found, which I find worrisome, if it is the dracut debut shell ;) But then again, I don't really know what dracut is.

And lol about reinstalling. For sure, it's not a big deal--I have a function mint on this system, and I agree, reinstalling would be easy. On the other hand, I made a ton of modifications to the setup of this Mageia so I would be sad to lose them all!
ohmysql
 
Posts: 39
Joined: Nov 8th, '12, 16:59

Re: Boot into failsafe mode

Postby ohmysql » Dec 6th, '14, 21:01

gohlip wrote:After reading your post, I tried systemd.unit=multi-user.target and it works, it boots to prompt. Logging in I tried "sudo dracut -f" and it works too.
Of course, I am on a functional M5.
Can you try again but you can also try with systemd.unit=rescue.target? This will boot to root prompt (you need to enter your root password). You won't have network access so don't do anything else except dracut.

Seriously on a practical note, it is far easier to reinstall, but we won't learn anything. But from a practical point for you, you should consider reinstalling.
Good luck.


I'm adding systemd.unit=rescue.target to the linux line of my grub and still droppingi into dracut debug shell where I am unable to run dracut -f. :P

I'll post my grub commands in about a minute, by editing this, unless I hear from you first.

Here's my grub line:

menuentry 'Mageia 4 latest tip' {
insmod part_msdos
insmod ext2
search --no-floppy --fs-uuid --set=root xxxx
linux /boot/vmlinuz-desktop root=UUID=xxxx ro nokmsboot systemd.unit=multi-user
initrd /boot/initrd-desktop.img
}

The x's are my UUID.
ohmysql
 
Posts: 39
Joined: Nov 8th, '12, 16:59

Next

Return to Basic support

Who is online

Users browsing this forum: No registered users and 1 guest

cron