Red Hat Bugzilla – Bug 1015629
fedora becomes unbootable after installing debian
Last modified: 2015-02-17 12:30:53 EST
Created attachment 807774 [details] /run/initramfs/sosreport.txt i have installed fedora 19 from the xfce spin recently. i was able to boot into it for several days. i then installed a debian 7.0 system on the same disk. since then fedora will not boot (but fedora-rescue does boot). i am assuming the debian install is the cause of the problem. note that both systems were installed on the same set of partitions, with fedora root in one partition and debian root in another. the two linux systems share ext4 /home, other rw ext4 partitions, including each others root, and swap. before the debian install no changes were made to the partition table. during the debian install no changes were made to the partition table, except some labelling was done. also some empty ext4 partitions were formatted. also, i did not install the bootloader for debian system, so the bootloader remains grub installed by fedora. booting into the fedora-rescue system, running this command: dracut --force --regenerate-all does not work to correct the problem. /run/initramfs/sosreport.txt is attached. various other data asked for in https://fedoraproject.org/wiki/How_to_debug_Dracut_problems were collected in fedora-rescue and are given below. the serial console setup procedure given in that document does not attempt to boot the system, it goes to grub shell. also that document refers to /etc/grub.conf, but there is no such file. the grub configuration file is named /boot/grub2/grub.cfg. here is screen dialog on boot: [ok] started show plymouth boot screen. [ok] reached target paths. [ok] reached target basic system. [ok] found device WDC_WD5001AALS-00L3B2. dracut_initqueue[104]: warning: could not boot. dracut_initqueue[104]: warning: /dev/disk/by-uuid/79dd9c77-ec15-4395-b91e-d0b6120d4cec does not exist. starting dracut emergency shell. warning: generating /run/initramfs/sosreport.txt entering emergency mode. exit the shell to continue. type "journalctl" to view system logs. you might want to save /run/initramfs/sosreport.txt to a USB stick or /boot after mounting them and attach it to a bug report. dracut:/# here is /etc/fstab: # # /etc/fstab # Created by anaconda on Sat Sep 14 21:02:37 2013 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID=a38cad09-76ec-4670-ad16-019647d7091e / ext4 defaults 1 1 UUID=43cb5165-0353-4f9c-937e-3c0d62b72e38 /data ext4 defaults 1 2 UUID=135ec9e1-e4da-4ea3-8fe7-ce4d0334a88b /debian ext4 defaults 1 2 UUID=93faed0a-796c-4400-b81c-50d021791e28 /home ext4 defaults 1 2 UUID=79dd9c77-ec15-4395-b91e-d0b6120d4cec swap swap defaults 0 0 here is output of dmseteup ls --tree: No devices found here is output of blkid: /dev/sda1: UUID="55bc7e06-1e43-4f10-bcc1-5816ca9129ca" TYPE="ext4" /dev/sda2: LABEL="xpc" UUID="D2D4DCE8D4DCCFB9" TYPE="ntfs" /dev/sda3: LABEL="xp0" UUID="E2B8F857B8F82BA3" TYPE="ntfs" /dev/sda5: LABEL="xpd" UUID="362460B024607531" TYPE="ntfs" /dev/sda6: LABEL="xpe" UUID="9AC8C4AAC8C485CB" TYPE="ntfs" /dev/sda7: LABEL="xpf" UUID="5858D8A358D88164" TYPE="ntfs" /dev/sda8: LABEL="xpg" UUID="4A88AFF888AFE0A5" TYPE="ntfs" /dev/sda9: LABEL="lxhome" UUID="567fbac2-625a-4ba6-96ac-7d7316055f82" TYPE="ext4" /dev/sda10: UUID="a38cad09-76ec-4670-ad16-019647d7091e" TYPE="ext4" /dev/sda11: UUID="288ab0c1-37c5-40c0-ab35-36f878490f9e" TYPE="ext4" /dev/sda12: UUID="6d72fe4d-4a4c-4d8e-ab2b-91ae62b280b6" TYPE="swap" here is output of blkid -o udev: ID_FS_UUID=55bc7e06-1e43-4f10-bcc1-5816ca9129ca ID_FS_UUID_ENC=55bc7e06-1e43-4f10-bcc1-5816ca9129ca ID_FS_TYPE=ext4 ID_FS_LABEL=xpc ID_FS_LABEL_ENC=xpc ID_FS_UUID=D2D4DCE8D4DCCFB9 ID_FS_UUID_ENC=D2D4DCE8D4DCCFB9 ID_FS_TYPE=ntfs ID_FS_LABEL=xp0 ID_FS_LABEL_ENC=xp0 ID_FS_UUID=E2B8F857B8F82BA3 ID_FS_UUID_ENC=E2B8F857B8F82BA3 ID_FS_TYPE=ntfs ID_FS_LABEL=xpd ID_FS_LABEL_ENC=xpd ID_FS_UUID=362460B024607531 ID_FS_UUID_ENC=362460B024607531 ID_FS_TYPE=ntfs ID_FS_LABEL=xpe ID_FS_LABEL_ENC=xpe ID_FS_UUID=9AC8C4AAC8C485CB ID_FS_UUID_ENC=9AC8C4AAC8C485CB ID_FS_TYPE=ntfs ID_FS_LABEL=xpf ID_FS_LABEL_ENC=xpf ID_FS_UUID=5858D8A358D88164 ID_FS_UUID_ENC=5858D8A358D88164 ID_FS_TYPE=ntfs ID_FS_LABEL=xpg ID_FS_LABEL_ENC=xpg ID_FS_UUID=4A88AFF888AFE0A5 ID_FS_UUID_ENC=4A88AFF888AFE0A5 ID_FS_TYPE=ntfs ID_FS_LABEL=lxhome ID_FS_LABEL_ENC=lxhome ID_FS_UUID=567fbac2-625a-4ba6-96ac-7d7316055f82 ID_FS_UUID_ENC=567fbac2-625a-4ba6-96ac-7d7316055f82 ID_FS_TYPE=ext4 ID_FS_UUID=a38cad09-76ec-4670-ad16-019647d7091e ID_FS_UUID_ENC=a38cad09-76ec-4670-ad16-019647d7091e ID_FS_TYPE=ext4 ID_FS_UUID=288ab0c1-37c5-40c0-ab35-36f878490f9e ID_FS_UUID_ENC=288ab0c1-37c5-40c0-ab35-36f878490f9e ID_FS_TYPE=ext4 ID_FS_UUID=6d72fe4d-4a4c-4d8e-ab2b-91ae62b280b6 ID_FS_UUID_ENC=6d72fe4d-4a4c-4d8e-ab2b-91ae62b280b6 ID_FS_TYPE=swap here is output of dmesg | grep -e dracut: [ 2.118984] systemd[1]: Starting dracut cmdline hook... here is /etc/dracut.conf: # PUT YOUR CONFIG HERE OR IN separate files named *.conf # in /etc/dracut.conf.d # SEE man dracut.conf(5) # Sample dracut config file #logfile=/var/log/dracut.log #fileloglvl=6 # Exact list of dracut modules to use. Modules not listed here are not going # to be included. If you only want to add some optional modules use # add_dracutmodules option instead. #dracutmodules+="" # dracut modules to omit #omit_dracutmodules+="" # dracut modules to add to the default #add_dracutmodules+="" # additional kernel modules to the default #add_drivers+="" # list of kernel filesystem modules to be included in the generic initramfs #filesystems+="" # build initrd only to boot current hardware #hostonly="yes" # # install local /etc/mdadm.conf #mdadmconf="no" # install local /etc/lvm/lvm.conf #lvmconf="no" # A list of fsck tools to install. If it's not specified, module's hardcoded # default is used, currently: "umount mount /sbin/fsck* xfs_db xfs_check # xfs_repair e2fsck jfs_fsck reiserfsck btrfsck". The installation is # opportunistic, so non-existing tools are just ignored. #fscks="" # inhibit installation of any fsck tools #nofscks="yes" # mount / and /usr read-only by default #ro_mnt="no" # set the directory for temporary files # default: /var/tmp #tmpdir=/tmp
I noticed this bug report, and have experienced the same problem myself. I did not save sosreport.txt however. In recent weeks, I have been setting up multiple boots on desktop computers: this one boots into Fedora 19, Windows 7, Debian 7.1 and FreeBSD 9.1. I found that Debian installs made Fedora unbootable (under the normal boot), and took note that I should install Fedora last. I think I have found part of the reason for the problem. Partitions are identified in /etc/fstab by their UUIDs. The Debian installation does not touch the ext3 partitions, but the Debian installer reformats the Linux swap partition and gives it a new UUID. Of course this makes the Fedora fstab file incorrect. As in the above report, I found that the normal Fedora boot crashed in the Dracut phase, whereas the rescue boot succeeded. Once I realized that the UUID of the swap partition had been changed by the Debian installation, I booted into Debian, mounted the Fedora root partition, and hand-edited /etc/fstab. I assumed that this would solve the problem. However correcting /etc/fstab did not solve the problem. The Fedora boot crashed on trying to access the swap partition under its old UUID in /dev/disk/by-uuid I used find to grep for the previous UUID on all files in /etc/, and concluded that the replaced UUID of the swap partition was not to be found in plain text in any file in /etc, apart from my backup copies of the installed /etc/fstab I concluded from this that the Fedora boot process must archive the UUIDs of the partitions to be mounted outside /etc, and probably uses the archived ids to do things like file system checks before mounting the root partition. But I am no expert on Linux, or on the Fedora boot process. === On doing a web search, I found that someone else had apparently recovered the boot by re-synchronizing files with a yum repository, and that gave me an idea. I used yum to erase the most recent kernel, then updated with yum to force the machine to reinstall that kernel, and I found that the machine then rebooted normally. === Apologies for not keeping error reports and log files and forwarding them on, but I am adding these comments in the hope that they might be helpful.
boot with the rescue entry, then do: # dracut --regenerate-all --force
i tried dracut --force --regenerate-all before i filed this bug, as i stated. this command still does not work. but i have found part of the problem: dracut leaves /etc/fstab in unworkable state. when i edited /etc/fstab to use the current uuids, the system booted. but there is still a problem: the user password has been trashed and i can not log in.
(In reply to mordred from comment #3) > but i have found part of the problem: dracut leaves /etc/fstab in unworkable > state. > > when i edited /etc/fstab to use the current uuids, the system booted. Well, dracut does not modify /etc/fstab.
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.
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.