|Summary:||Cannot boot after replacing swap partition for a new one|
|Product:||[Fedora] Fedora||Reporter:||Nelson Benitez <nbenitezl>|
|Status:||CLOSED EOL||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||19||CC:||athoscribeiro, bojan, dracut-maint, harald, jonathan, kfiresmith, mszpak, tadej.j|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-02-18 11:04:42 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Nelson Benitez 2013-08-11 13:04:23 UTC
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 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: Warning: Could not boot dracut-initqueue: 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 13:07:10 UTC
[forgot to add the foot note] > I rebooted with a gparted live usb  As I tought that was not possible from within fedora itself
Comment 2 Nelson Benitez 2013-08-12 07:35:09 UTC
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 09:38:44 UTC
(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 10:51:54 UTC
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 19:01:20 UTC
(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 05:46:53 UTC
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, 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.  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 06:59:23 UTC
(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, 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. > >  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 07:00:13 UTC
Comment 9 Nelson Benitez 2013-08-17 09:04:04 UTC
(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 08:04:03 UTC
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 17:46:04 UTC
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 22:27:18 UTC
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 11:04:42 UTC
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 19:40:25 UTC
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...