The pictures indicate the problem to first appear on screen around “starting cleaning up and shutting down daemons” & “stopped target Network” (although this does not mean that the origin is at this point). But at least for me, it is not sufficient to determine why the targets get stopped when the system is intended to boot.
The logs of the damaged system would be very helpful:
Based upon the way you used the command, we would need the content of journalctl.0 .
Be aware: This does only work if you did the chrootI explained abovein advance to the journalctl commands.
Also, what is the relation between the two pictures?
liveuser@localhost-live /]$ mkdir /mnt/root
mkdir: cannot create directory ‘/mnt/root’: Permission denied
[liveuser@localhost-live /]$ sudo mkdir /mnt/root
[liveuser@localhost-live /]$ mount UUID=E7A7-ECAE /mnt/root
mount: /mnt/root: must be superuser to use mount.
[liveuser@localhost-live /]$ sudo mount UUID=E7A7-ECAE /mnt/root
[liveuser@localhost-live /]$ sudo chroot /mnt/root
chroot: failed to run command ‘/bin/bash’: No such file or directory
[liveuser@localhost-live /]$
I expect this is the wrong partition. E7A7-ECAE sounds like a FAT16 or FAT32 partition or something like that. It is unlikely that this is the root partition of your damaged system. Because of that, chroot is not able to find the “bash” on this device. Because chroot did not work, journalctl also does not output the content we need. You need to use your root partition for chroot, which is one of the other partitions.
Given the pictures you posted initially, I assume that maybe your root partition is the one that begins with 6fec64c0… … ?
If you get the output chroot: failed to run command ‘/bin/bash’: No such file or directory, it did not work.
Given your picture above (the second in this post), only the BTRFS partition seems big enough for the root partition. I am wondering that chroot to this partition is not possible. And of course I am also considering that this behavior belongs to the problem we have to tackle.
May I ask for the output of sudo umount /mnt/root; sudo mount UUID=6fec64c0-a806-464e-9e7e-a72a403ba06e /mnt/root; sudo ls /mnt/root; sudo ls /mnt/root/bin/bash ?
liveuser@localhost-live /]$ sudo umount /mnt/root
[liveuser@localhost-live /]$ sudo mount UUID=6fec64c0-a806-464e-9e7e-a72a403ba06e /mnt/root
[liveuser@localhost-live /]$ sudo ls /mnt/root
home root timeshift
[liveuser@localhost-live /]$ sudo ls /mnt/root/bin/bash
ls: cannot access ‘/mnt/root/bin/bash’: No such file or directory
[liveuser@localhost-live /]$
I suspect the btrfs partition has subvolumes for / and /home as per the default config.
Mounting the entire btrfs volume like that probably will not work, but instead needs the option to mount the / (root) subvolume. I do not use btrfs so cannot give you the entire command syntax but do understand what is needed there.
Since the OP has sda1 as FAT, sda2 as EXT4, and sda3 as BTRFS then the mount structure likely should be (and mounted in that order)
the root subvolume of sda3 mounted at /mnt sudo mount /dev/sda2 /mnt/boot sudo mount /dev/sda1 /mnt/boot/efi
then for i in /proc /sys /run /dev ; do sudo mount -o bind "$i" "/mnt/$i"; done
Once all this is done then a chroot /mnt will put him chrooted into the installed system so the problem can be fixed.
I think the /bin/ and /var/ should be sufficient. For the moment, it is just to get the logs. So we don’t need all partitions. But that root is a subvolume within BTRFS makes sense. I just tried it in a VM: if @perryt has a default BTRFS, another “root” folder has to be added to identify the subvolume.
So, @perryt , if you have used the commands as above, you need to add another root to the chroot command (you mount it on the root directory, and within the volume, there is another “folder” also called root). Therefore, just change the chroot command: chroot /mnt/root/
→ chroot /mnt/root/root/. Hope that works to get journalctl working.
e.g.,
[root@localhost-live liveuser]# mount UUID=6fec64c0........... /mnt/root/
[root@localhost-live liveuser]# ls /mnt/root/
home root
[root@localhost-live liveuser]# chroot /mnt/root/root/
Hello @perryt ,
Welcome to the community!
I don’t want to jump in on support since too many cooks, etc… but have you tried the live image rescue (if it is still avail) option. At one time I used it and it restored my system for me, more or less, but I haven’t used it since and this was many releases ago. Just a thought.
[liveuser@localhost-live mnt]$ sudo mkdir /mnt/boot
[liveuser@localhost-live mnt]$ sudo mkdir /mnt/boot/efi
[liveuser@localhost-live mnt]$ for i in /proc /sys /run /dev ; do sudo mount -o bind “$i” “/mnt/$i”; done
mount: /mnt//proc: mount point does not exist.
mount: /mnt//sys: mount point does not exist.
mount: /mnt//run: mount point does not exist.
mount: /mnt//dev: mount point does not exist.
[liveuser@localhost-live mnt]$ sudo chroot /mnt
chroot: failed to run command ‘/bin/bash’: No such file or directory
[liveuser@localhost-live mnt]$
[liveuser@localhost-live mnt]$ ls /mnt/root
[liveuser@localhost-live mnt]$ sudo mount UUID=6fec64c0-a806-464e-9e7e-a72a403ba06e /mnt/root
[liveuser@localhost-live mnt]$ ls /mnt/root
home root timeshift
[liveuser@localhost-live mnt]$ ls /mnt/root/root
bin dev home lib64 media ‘New Folder’ proc root sbin srv tmp var
boot etc lib lost+found mnt opt robots.txt run snap sys usr
[liveuser@localhost-live mnt]$ sudo chroot /mnt/root/root
cat: /proc/21022/comm: No such file or directory
[root@localhost-live /]#
Not an issue. Can be ignored. I had this, too. journalctl can still work with this.
At least, we are one step closer to get the logs of the damaged system. I’ll check how to solve this (or maybe Jeff knows that off the top of his head? ).
NO NO NO
Once the proper / subvolume is mounted then it will have the /mnt/boot directory.
Once the partition /dev/sda2 is mounted at /mnt/boot then it will have the .mnt/boot/efi directory.
It is not necessary and is counterproductive to create those directories since the steps I showed will mount things properly for you.
First make sure the main / file system in the btrfs subvolume is properly mounted at /mnt. Then and only then should you mount the other filesystems as noted.
Things must be done in the order noted, and be done successfully in each step before you can proceed to the next step.
Despite the error with account validation failure, did you get any output of journalctl --boot=0 ?
If so, we need the output.
If it does not work at all, do you have “sudo” disabled on your system? In this case, do suafter the chroot, and thenjournalctl --boot=0 …-1 …-2after the su command. su will need the root password from the damaged system if the root account is enabled on that system.
Okay, so the Live USB image does not have the rescue option but the workstation installation media does. If you have the ability to write the installation media then it will have the rescue option available at boot.
Also a bit of text on creating your own rescue USB from one of the maintainers of Fedora …
First need a pen with FAT16
fdisk -l /dev/sdb
Disk /dev/sdb: 1,9 GiB, 1992294400 bytes, 3891200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x844f3a44
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 1 3891199 3891199 1,9G 6 FAT16
with gparted (fat16 + flag bootable)
Than we can put boot.iso on a usb stick (now also copied and ranamed as Network
Installers),
for example:
https://alt.fedoraproject.org/
wget https://download.fedoraproject.org/pub/fedora/linux/releases/25/Workstation/x86_64/iso/Fedora-Workstation-netinst-x86_64-25-1.3.iso
As root usb must be formated or else format usb with:
# mkfs.vfat /dev/sdb1.
# /usr/bin/livecd-iso-to-disk --reset-mbr Fedora-Workstation-netinst-x86_64-25-1.3.iso /dev/sdb1
(just need add --reset-mbr if pen are bootable before run livecd-iso-to-disk)
and check if boots:
qemu-system-x86_64 -drive format=raw,file=/dev/sdb
Info deprecated:
Answer the question, Where is diskboot.img
( http://www.redhat.com/archives/rhl-beta-list/2008-April/msg01563.html )
boot.iso is the replacement, and we can boot on USB like explain above.
Ok, so, I think we should focus on one thing, and not many at the time. First, feel free to try the approach of @jakfrost . Maybe the rescue option can solve the issue and makes the logs obsolete.
If the rescue option approach does not work, then, shutdown your machine and boot a newlive system. Ignore everything above. If the new live system is on, then open a terminal and do the following in the live system’s terminal:
sudo mkdir /mnt/root
sudo mount UUID=6fec64c0-a806-464e-9e7e-a72a403ba06e /mnt/root
sudo chroot /mnt/root/root
su
journalctl --boot=0
journalctl --boot=-1
journalctl --boot=-2
We need to know the content of all the journalctl commands!
Note: in the commands, it is not 1 but -1 and not 2 but -2 , so each with a minus.
@computersavvy I think we should focus on getting the logs first. And then let’s see what to do next.
).