Filing here for Fedora based on the last comment from the original bug/ +++ This bug was initially created as a clone of Bug #1267887 +++ Description of problem: Anaconda can't find previously installed Atomic host in rescue mode. This is both anaconda from Atomic ISO media and anaconda from RHEL iso media. This renders rescue mode for Atomic completely broken. I've tried both default LVM and Btrfs layout for Atomic. Same result: OTOH anaconda finds and mounts standard LVM layout from previous RHEL install. Starting installer, one moment... anaconda 21.48.22.53-1 for RHEL Atomic Host 7 started. * installation log files are stored in /tmp during the installation * shell is available on TTY2 * when reporting a bug add logs from /tmp as separate text/plain attachments ================================================================================ ================================================================================ Rescue The rescue environment will now attempt to find your Linux installation and moun t it under the directory : /mnt/sysimage. You can then make any changes require d to your system. Choose '1' to proceed with this step. You can choose to mount your file systems read-only instead of read-write by cho osing '2'. If for some reason this process does not work choose '3' to skip directly to a s hell. 1) Continue 2) Read-only mount 3) Skip to shell 4) Quit (Reboot) Please make a selection from the above: 1 ================================================================================ ================================================================================ Rescue Mount You don't have any Linux partitions. The system will reboot automatically when y ou exit from the shell. Please press <return> to get a shell. When finished, please exit from the shell and your system will reboot. sh-4.2# blkid /run/install/repo//LiveOS/squashfs.img: TYPE="squashfs" /dev/sr0: UUID="2015-09-30-15-19-52-00" LABEL="RHEL Atomic Host 7 x86_64" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="7a837437-dd7c-4ef3-9abe-cb78f150b1dd" TYPE="ext4" /dev/vda2: UUID="2DBcV3-IbxU-dr95-id9h-pIWQ-dgIq-PxryPM" TYPE="LVM2_member" /dev/loop0: TYPE="squashfs" /dev/loop1: LABEL="Anaconda" UUID="521399b3-a1a4-4460-b99d-1e1bfa97a8bf" TYPE="ext4" /dev/loop2: TYPE="DM_snapshot_cow" /dev/mapper/live-rw: LABEL="Anaconda" UUID="521399b3-a1a4-4460-b99d-1e1bfa97a8bf" TYPE="ext4" /dev/mapper/live-base: LABEL="Anaconda" UUID="521399b3-a1a4-4460-b99d-1e1bfa97a8bf" TYPE="ext4" /dev/zram0: UUID="b3ec35ed-e6a9-4589-9737-6d9a98af5b55" TYPE="swap" --- Additional comment from Chris Lumens on 2015-10-01 17:24:35 EEST --- We don't think rescue mode works with atomic anywhere, including in Fedora. I can't really find any commits that would have added support. So I think this is basically an RFE that we need to deal with in Fedora first, and then backport one it's working.
well, Atomic Host is no more, but we still have Silverblue, and CoreOS is coming. I don't think this is fixed, because, well, basically we're in pyanaconda.storage.root _find_existing_installations() here, and a key check in that is this: if not os.access(sysroot + "/etc/fstab", os.R_OK): so it looks at the mounted device and expects to find /etc/fstab . On an ostree install that won't be there, because everything's under like /ostree/deploy/fedora/deploy/(something) . So, pretty sure this is still not fixed, and we probably still ought to fix it. CCing Dusty.
I do think it would be nice to have rescue functionality. Maybe less so for Fedora CoreOS because we're trying to enforce people automate provisioning of those machines (i.e. they should be able to throw them away and start over easily), but absolutely for Silverblue.
Likely dup: https://bugzilla.redhat.com/show_bug.cgi?id=1873886
*** Bug 1873886 has been marked as a duplicate of this bug. ***