Bug 995843 - Cannot boot after replacing swap partition for a new one
Cannot boot after replacing swap partition for a new one
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: dracut (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: dracut-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-11 09:04 EDT by Nelson Benitez
Modified: 2016-05-11 15:40 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-18 06:04:42 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nelson Benitez 2013-08-11 09:04:23 EDT
I was using Fedora 19 fine, having /home in a separate partition, then I was running out of space in my root partition, so then I rebooted with a gparted live usb[1] and resized my home partition to move space to my root partition, I also had to move my swap partition.

But I took care to not move my root partition (I only enlarged it) so the start of the partition did not changed and so to avoid any problem for grub to locate it (gparted warned me about that). And as that is the case, when I booted, grub loads fine, but launching into the fedora partition it stops at this message:

[ OK ] Reached target Paths
[ OK ] Reached Basic System
dracut-initqueue[94]: Warning: Could not boot
dracut-initqueue[94]: Warning: /dev/disk/by-uuid/$SOME_LONG_ID does not exist

It seems fedora/grub is confused about the new locations of my /home or / partitions.. I thought that by taking care to not move the start of the root partition (as gparted warned me) I would not have any problem.. but here it is.. how can I fix that? editing grub info? is there a better way to enlarge your root or home partitions from within fedora? 

Note: My partitions are plain primary partitions, not using LVM nor extended partitions.

Thanks for any help,
Comment 1 Nelson Benitez 2013-08-11 09:07:10 EDT
[forgot to add the foot note]

> I rebooted with a gparted live usb[1]

[1] As I tought that was not possible from within fedora itself
Comment 2 Nelson Benitez 2013-08-12 03:35:09 EDT
I've managed to finally boot! yay :-), by doing the following when in the dracut emergency shell:

cd /usr/lib/dracut/hooks/initqueue/finished/
rm devexists-\x2fdev\x2fby-uuid\x2f$OLD_PARTITION_UUID.sh
#      exits dracut emergency shell
exit # now it continues to boot fine after removing above sh file

The content of above sh file is just the following line:

[ -e "/dev/disk/by-uuid/$OLD_PARTITION_UUID" ]



So it seems the boot halted due to that shell script that tests for the existence of my partition old uuid, because it seems after enlarging it in gparted the partition got a new uuid.

The problem is now that whenever I reboot I have to repeat above steps, as the devexists sh file appears again on every boot, so now I have to find out what in my fedora system is causing that file to regenerate, and the culprit is likely to be an entry in my /etc/fstab that refers to the old uuid for my partition, but I need to confirm it when I get to my linux box this afternoon.
Comment 3 Nelson Benitez 2013-08-13 05:38:44 EDT
(In reply to Nelson Benitez from comment #2)
> I've managed to finally boot! yay :-), by doing the following when in the
> ..
> ..
> So it seems the boot halted due to that shell script that tests for the
> existence of my partition old uuid, because it seems after enlarging it in
> gparted the partition got a new uuid.

In fact, the *problematic uuid is that of my old swap partition*, I had to delete my old swap partition and create another one because of my relocation of partitions to gather more space and because I expanded the ram of my computer from 1GB to 3GB so I needed to aument the swap to match the ram size.

So I am changing the bug title to state that is the *delete swap partition and create a new one* that caused the problem.

> 
> The problem is now that whenever I reboot I have to repeat above steps, as
> the devexists sh file appears again on every boot, so now I have to find out
> what in my fedora system is causing that file to regenerate, and the culprit
> is likely to be an entry in my /etc/fstab that refers to the old uuid for my
> partition, but I need to confirm it when I get to my linux box this
> afternoon.

I've changed the /etc/fstab and replace the old swap uuid for the uuid of the new swap partition, but the change is not being picked up, on reboot I've been thrown again at the dracut emergency shell because it doesn't find my old swap partition.

I think I've traced the problem to the following dracut commandline options:

 --add-fstab _<filename>_ 
    Add entries of <filename> to the initramfs /etc/fstab. 

--mount "<device> <mountpoint> <filesystem type> <filesystem options>"
    Mount <device> on <mountpoint> with <filesystem type> 
    and <filesystem options> in the initramfs  

So when systemd calls dracut binary to create the initramfs image, it's probably passing my old partition uuid as part of those options.

So, where is the systemd code that calls dracut binary?  how often does it call it? how can I trigger systemd to call it again? so it generates a new initramfs with my updated /etc/fstab changes..
Comment 4 Harald Hoyer 2013-08-14 06:51:54 EDT
If you do HW changes or disk layout changes and cannot boot anymore, use the "rescue" boot entry and do:

# dracut --force --regenerate-all
Comment 5 Nelson Benitez 2013-08-14 15:01:20 EDT
(In reply to Harald Hoyer from comment #4)
> If you do HW changes or disk layout changes and cannot boot anymore, use the
> "rescue" boot entry and do:
> 
> # dracut --force --regenerate-all

Thanks for the tip! but I had already solved it by re-installing the kernel rpm package, as follows:

rpm -e --nodeps kernel-3.10.5-201.fc19.i686
yum install kernel-3.10.5-201.fc19.i686

The remove kernel command above would remove my current initramfs image, and then when installing it again, it makes dracut to create a new one, this time taken into account my fstab changes.
Comment 6 Nelson Benitez 2013-08-15 01:46:53 EDT
So after my specific boot problem is solved, I think it's time to think about the big picture so this not happens again..

It's legitimate for a user to want to re-organize his disk layout outside of fedora, for example creating a bigger swap partition after having expanded physical ram. 

Based on my experience in this bug, the UUID of a partition does not change when you move, enlarge or shrink it, that's cool (very clever for systemd to use UUID's instead of /dev/sda? numbers) but obviously if you delete and create a new partition, then when you boot again into fedora, dracut will throw you at the emergency shell because it cannot find the now *non-existent UUID* of your old partition.

I think that should change, dracut should only enforced the existence of the root partition, the other ones should be optional[1], if they are not present then print a warning with maybe some instructions about how to regenerate the initramfs so the warning goes away next time, but anyway when the user happens to install a new kernel update, the warning will go away because the initramfs image is regenerated.

[1] Is it possible this is implemented yet via this patch http://goo.gl/aQWzef ? I don't think so as when I was at the emergency shell my /sysroot/ was empty, but maybe that has changed in recent versions?
Comment 7 Harald Hoyer 2013-08-15 02:59:23 EDT
(In reply to Nelson Benitez from comment #6)
> So after my specific boot problem is solved, I think it's time to think
> about the big picture so this not happens again..
> 
> It's legitimate for a user to want to re-organize his disk layout outside of
> fedora, for example creating a bigger swap partition after having expanded
> physical ram. 
> 
> Based on my experience in this bug, the UUID of a partition does not change
> when you move, enlarge or shrink it, that's cool (very clever for systemd to
> use UUID's instead of /dev/sda? numbers) but obviously if you delete and
> create a new partition, then when you boot again into fedora, dracut will
> throw you at the emergency shell because it cannot find the now
> *non-existent UUID* of your old partition.
> 
> I think that should change, dracut should only enforced the existence of the
> root partition, the other ones should be optional[1], if they are not
> present then print a warning with maybe some instructions about how to
> regenerate the initramfs so the warning goes away next time, but anyway when
> the user happens to install a new kernel update, the warning will go away
> because the initramfs image is regenerated.
> 
> [1] Is it possible this is implemented yet via this patch
> http://goo.gl/aQWzef ? I don't think so as when I was at the emergency shell
> my /sysroot/ was empty, but maybe that has changed in recent versions?

This patch was not yet backported to F19, but should be.

The problem is, that if you want to have resume from hibernation working, you have to wait until all swap partitions show up, before you mount the root partition.

I will have to revise my strategy and exploit more of the systemd features.
Comment 8 Harald Hoyer 2013-08-15 03:00:13 EDT
commit 226e3710b4236c69a8f821b6a5c53a264fe4892a
Comment 9 Nelson Benitez 2013-08-17 05:04:04 EDT
(In reply to Harald Hoyer from comment #8)
> commit 226e3710b4236c69a8f821b6a5c53a264fe4892a

Thank you, I've tested this commit and worked fine for me!, I applied it and regenerate initramfs by installing a new kernel update, then I rebooted with gparted live cd and selected the option "Generate new UUID" for my swap partition, then booted again in Fedora and dracut won't halt, yay! but.. 

..now systemd is waiting for my old uuid in a 90sec timeout.. but that is a systemd bug so I've filed it as bug 998094 in case you're interested in subscribing or proposing fixes :-)
Comment 10 Harald Hoyer 2013-08-19 04:04:03 EDT
beware... in commit 226e3710b4236c69a8f821b6a5c53a264fe4892a, there is missing a "then"

http://pkgs.fedoraproject.org/cgit/dracut.git/tree/0028-systemd-dracut-initqueue.sh-added-missing-then.patch
Comment 11 Athos Ribeiro 2013-10-18 13:46:04 EDT
Had the same problem yesterday in fedora 19 after formating mw swap partition during another distro installation in another partition.

Just followed the steps mentioned above and it worked fine:

cd /usr/lib/dracut/hooks/initqueue/finished/
rm devexists-\x2fdev\x2fby-uuid\x2f$OLD_PARTITION_UUID.sh
exit

#finally:

dracut --force --regenerate-all

And that shall be enough to solve the problem.

Thank you!

ps: is it a dup of 'bug 991692' ?
Comment 12 Fedora End Of Life 2015-01-09 17:27:18 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 13 Fedora End Of Life 2015-02-18 06:04:42 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 14 Kodiak Firesmith 2016-05-11 15:40:25 EDT
Thanks Harald and Nelson for the clues toward solving my RHEL 7 problem.

It is kind of a nightmare that something innocuous like relocating swap to a different VG would completely ruin my afternoon. :)

Looking forward to this fix in RHEL 8 I guess...

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