How to Fix Ubuntu Emergency Mode: systemd-fsck-root Failed on LVM Root

Symptom: your Ubuntu machine boots to a black screen that says "Entering emergency mode. Exit the shell to continue.", followed by red errors about the system bus and /bin/bash. This guide explains what those messages actually mean, how to find the real cause, and how to repair the most common one: a failed root filesystem check on an LVM volume.

Tested scenario: Ubuntu 26.04 LTS, ext4 root on LVM (/dev/mapper/ubuntu--vg-ubuntu--lv). The same steps apply to Ubuntu 25.10 and other dracut-based distributions such as Fedora.

Contents

1. Quick fix (TL;DR)
2. The error messages
3. Why the red errors are not the real problem
4. Finding the real cause
5. Step-by-step fix: repair the root filesystem
6. If fsck.ext4 is not found
7. After you boot: checks you should not skip
8. FAQ

Quick fix (TL;DR)

If your boot log shows [FAILED] Failed to start systemd-fsck-root.service, the root filesystem check failed and Ubuntu refused to mount it. At the # prompt:

journalctl -u systemd-fsck-root.service --no-pager | tail -40
blkid /dev/mapper/ubuntu--vg-ubuntu--lv
fsck.ext4 -f /dev/mapper/ubuntu--vg-ubuntu--lv
reboot

Back up first if the data matters. If the disk is physically failing, running a repair can make things worse. Details below.

The error messages

On screen you will typically see some combination of these lines:

Failed to connect to system scope bus via local transport: No such file or directory
Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
Press Enter for system maintenance
(or press Control-D to continue):
sulogin: failed to execute /bin/bash: No such file or directory
#

Scrolling further up (or rebooting and watching closely) reveals the line that matters:

[FAILED] Failed to start systemd-fsck-root.service - File System Check on /dev/mapper/ubuntu--vg-ubuntu--lv
[DEPEND] Dependency failed for sysroot.mount - /sysroot.
[DEPEND] Dependency failed for initrd-root-fs.target - Initrd Root File System.
[DEPEND] Dependency failed for initrd-parse-etc.service - Mountpoints Configured in the Real Root.

Why the red errors are not the real problem

You are not in your installed Ubuntu system yet. You are inside the initramfs, a tiny temporary system that loads before your real root filesystem. Since Ubuntu 25.10, Ubuntu desktop builds this initramfs with dracut instead of initramfs-tools (OMG! Ubuntu). The rdsosreport.txt message is dracut's signature.

That minimal environment does not include D-Bus or Bash, so:

• "Failed to connect to system scope bus" just means there is no D-Bus in the initramfs. It is a side effect, not the cause.
• "sulogin: failed to execute /bin/bash" means Bash is not in the initramfs. The emergency shell falls back to a basic sh, which is the # prompt you see. It works fine for repairs.

Pressing Ctrl+D will only retry the same boot and land you back here. The fix is to deal with whatever stopped the root filesystem from mounting.

Finding the real cause

Emergency mode means the root filesystem could not be mounted. The usual causes are:

What the log shows	Likely cause
Failed to start systemd-fsck-root.service	Filesystem errors (often after a power cut or forced shutdown), or a failing disk
Timed out waiting for device	Disk not detected, missing storage driver in initramfs, or wrong UUID in GRUB/fstab
No password prompt on an encrypted disk	Missing LUKS/cryptsetup support in the initramfs

This guide covers the first row, which is the one shown in the screenshots above.

Step-by-step fix: repair the root filesystem

Step 1: Read the actual fsck error

The emergency shell may not include less, so pipe through tail instead:

journalctl -u systemd-fsck-root.service --no-pager | tail -40

Messages such as "UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY" confirm filesystem corruption. I/O errors or "Buffer I/O error on device" suggest the disk itself is failing. If you see I/O errors, skip ahead to the backup warning in Step 3.

Step 2: Confirm the LVM volume is active and check its filesystem type

lvm lvscan
blkid /dev/mapper/ubuntu--vg-ubuntu--lv

lvscan should list the volume as ACTIVE. If it shows inactive, activate it with lvm vgchange -ay. The blkid output includes TYPE="ext4" (Ubuntu's default), xfs, or btrfs.

The double hyphens in ubuntu--vg-ubuntu--lv are not a typo. Device-mapper escapes a hyphen inside a name by doubling it. The same volume is also reachable as /dev/ubuntu-vg/ubuntu-lv.

Step 3: Back up before repairing, if you can

fsck changes the filesystem in place. On a healthy disk with minor corruption it is safe and routine. On a physically failing disk, the extra reads and writes can turn a recoverable situation into lost data. If anything on the machine is not backed up, boot from an Ubuntu live USB first and copy your important files off. For badly damaged disks, clone the drive with ddrescue first.

Step 4: Run the repair

For ext4, the volume is not mounted at this point, so it is safe to check:

fsck.ext4 -f /dev/mapper/ubuntu--vg-ubuntu--lv

Answer y to the proposed fixes. If there are hundreds of prompts, re-run with -y to accept them all:

fsck.ext4 -fy /dev/mapper/ubuntu--vg-ubuntu--lv

Run it again until it reports the filesystem as clean with no further changes. fsck's exit code tells you the outcome:

• 0: no errors.
• 1: errors were corrected.
• 4 or higher: errors remain uncorrected. Do not reboot and hope; investigate further.

You can check the code with echo $? right after fsck finishes.

Step 5: Reboot

reboot

If the filesystem is now clean, Ubuntu should boot normally.

If fsck.ext4 is not found

If the shell replies fsck.ext4: not found, the initramfs was built without the filesystem checker. That is why the automatic check failed, and your disk may be perfectly healthy. Repair from a live USB instead:

1. Boot an Ubuntu 26.04 live USB and choose Try Ubuntu.
2. Open a terminal and activate LVM, then run the check:

   sudo vgchange -ay
   sudo fsck.ext4 -f /dev/mapper/ubuntu--vg-ubuntu--lv

3. Reboot into your installed system and regenerate the initramfs so the checker is included next time:

   sudo dracut --force --regenerate-all

After you boot: checks you should not skip

Getting back to the desktop does not mean the problem is solved. Find out why the filesystem broke.

Check disk health

sudo apt install smartmontools
lsblk -d -o NAME,MODEL,SIZE
sudo smartctl -a /dev/nvme0n1   # or /dev/sda for SATA disks

Warning signs include reallocated sectors, pending sectors, media errors, or a health assessment other than PASSED. If you see any of these, replace the drive soon and keep backups current.

Review errors from the failed boot

journalctl --list-boots
journalctl -b -1 -p err --no-pager

Logs from inside the initramfs are not always kept in the persistent journal, so the previous boot may show little.

Prevent it happening again

• Avoid holding the power button to shut down, especially during updates.
• On desktops in areas with unreliable power, a small UPS is cheap insurance.
• Keep regular backups. deja-dup or restic are both fine starting points.

FAQ

Is "sulogin: failed to execute /bin/bash" a sign that Bash was deleted?

No. It refers to the initramfs, which does not ship Bash. Your installed system's /bin/bash is untouched.

Will fsck delete my files?

fsck fixes filesystem structures. Fragments of files it cannot reattach are placed in /lost+found. On mild corruption you typically lose nothing, but there is no guarantee on a damaged disk, hence the backup advice.

My root filesystem is XFS or Btrfs. What do I run?

For XFS, use xfs_repair on the unmounted device. For Btrfs, start with the read-only btrfs check. Do not use btrfs check --repair without a backup; the Btrfs developers themselves warn it can cause further damage.

Can I just boot an older kernel from GRUB?

That helps when a kernel or initramfs update is the cause. It does not help with filesystem corruption, because every kernel mounts the same broken filesystem.

Summary: in a dracut emergency shell, ignore the D-Bus and Bash messages and look for the first [FAILED] line. For a failed systemd-fsck-root.service, read the fsck error, back up if the disk looks unhealthy, run fsck on the unmounted root volume until it is clean, then check the drive's SMART health once you are back in.

Does RHEL 7 support online resize of disk partitions?

Environment

• Red Hat Enterprise Linux 7

Issue

• Both Xen and KVM support online resize of the virtual block devices that the virtual machines use.
• Unfortunately, since the partitions in the boot virtual block device are already in use, those can't be modified online and the virtual machine won't pick up the changes on the boot virtual block device without a reboot.
• We are looking for ability to dynamically increase a partitioned volume, is it possible to resize the disk partitions online in RHEL 7?
• We are unable to dynamically increase a SAN attached volume without taking the volume offline. When will this feature to Support online resize of disk partitions be available?

Resolution

The ability to resize a Logical Volume and filesystem has long been provided by Logical Volume Manager (LVM) by simply using the entire block device (/dev/sdx for example) as a Physical Volume in the LVM Volume Group. There is no need for the old style of partition. This would allow the Logical Volume and filesystem to easily be expanded.

As to older style partitions, this feature has been added in RHEL 7 current release with a feature request (RFE has been filed to add support for online resize of disk partitions to RHEL 7 in private Red Hat Bugzilla 853105). With this feature, it's possible to resize the disk partitions online in RHEL 7.

---

Warning: Online partition table resizing is not a recommended process mostly because the underlying layer of an active logical volume or filesystem that relies on that information is being modified. While it is possible to perform online partition resize operation, it is not recommended simply from a data integrity standpoint and not because it's not possible.

---

• In order to resize online a partition which is in use please observe the following steps:

Raw

# fdisk -l /dev/vda

Disk /dev/vda: 32.2 GB, 32212254720 bytes, 62914560 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
Disk label type: dos
Disk identifier: 0x000db7e6

   Device Boot      Start         End      Blocks   Id  System
/dev/vda1   *        2048     1026047      512000   83  Linux
/dev/vda2         1026048    28289023    13631488   8e  Linux LVM

# cat /proc/partitions 
major minor  #blocks  name

 252        0   31457280 vda
 252        1     512000 vda1
 252        2   13631488 vda2
  11        0    1048575 sr0
 253        0   10240000 dm-0
 253        1    2129920 dm-1

# pvs
  PV         VG          Fmt  Attr PSize  PFree
  /dev/vda2  rhel_vm-205 lvm2 a--  13.00g 1.20g

• Modify the on-disk partition table as usual (e.g. by using fdisk command).
  • Delete the partition:
    Raw

    Command (m for help): d
    Partition number (1,2, default 2): 2
    Partition 2 is deleted
    

  • Re-create the partition with the new size:
    Raw

    Command (m for help): n
    Partition type:
       p   primary (1 primary, 0 extended, 3 free)
       e   extended
    Select (default p): p
    Partition number (2-4, default 2): 2
    First sector (1026048-62914559, default 1026048): 
    Using default value 1026048
    Last sector, +sectors or +size{K,M,G} (1026048-62914559, default 62914559): +18G
    Partition 2 of type Linux and of size 18 GiB is set
    
    Command (m for help): t
    Partition number (1,2, default 2): 2
    Hex code (type L to list all codes): 8e
    Changed type of partition 'Linux' to 'Linux LVM'
    
    Command (m for help): p
    
    Disk /dev/vda: 32.2 GB, 32212254720 bytes, 62914560 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
    Disk label type: dos
    Disk identifier: 0x000db7e6
    
       Device Boot      Start         End      Blocks   Id  System
    /dev/vda1   *        2048     1026047      512000   83  Linux
    /dev/vda2         1026048    38774783    18874368   8e  Linux LVM
    

  • Commit changes to on-disk partition table:
    Raw

    Command (m for help): w
    The partition table has been altered!
    
    Calling ioctl() to re-read partition table.
    
    WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
    The kernel still uses the old table. The new table will be used at
    the next reboot or after you run partprobe(8) or kpartx(8)
    Syncing disks.
    

  • While on-disk partition table has been updated, observe that on-memory kernel partition table has not:
    Raw

    # partprobe 
    Error: Partition(s) 2 on /dev/vda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.
    
    # cat /proc/partitions | grep vd
     252        0   31457280 vda
     252        1     512000 vda1
     252        2   13631488 vda2
    

• Execute partx (provided by util-linux package) with --update option on the block device to update the in-memory kernel partition table from the on-disk partition table:
  Raw

  # partx -u /dev/vda
  

• Verify that in-memory kernel partition table has been updated with the new size:
  Raw

  # cat /proc/partitions | grep vd
   252        0   31457280 vda
   252        1     512000 vda1
   252        2   18874368 vda2
  

• Proceed with any further steps, in this example by extending the PV on the partition:
  Raw

  # pvresize /dev/vda2
    Physical volume "/dev/vda2" changed
    1 physical volume(s) resized / 0 physical volume(s) not resized
  
  # pvs
    PV         VG          Fmt  Attr PSize  PFree
    /dev/vda2  rhel_vm-205 lvm2 a--  18.00g 6.20g
  

Root Cause

• Changes to allow online resizing of in-use partitions are required in both kernel and userland.
  • RHEL7 kernels include the required changes to BLKPG ioctl from block: add partition resize function to blkpg ioctl to support BLKPG_RESIZE_PARTITION operation.
  • RHEL7 util-linux package includes partx and resizepart binaries, currently the only userland commands that support BLKPG_RESIZE_PARTITION operation of BLKPG ioctl.

Reset Your Forgotten Ubuntu Password in 2 Minutes or Less

If you’ve ever forgotten your password, you aren’t alone… it’s probably one of the most common tech support problems I’ve encountered over the years. Luckily if you are using Ubuntu they made it incredibly easy to reset your password.

All it takes is adjusting the boot parameters slightly and typing a command or two, but we’ll walk you through it.

Reset Your Ubuntu Password

Reboot your computer, and then as soon as you see the GRUB Loading screen, make sure to hit the ESC key so that you can get to the menu.

Root Shell – Easy Method

If you have the option, you can choose the “recovery mode” item on the menu, usually found right below your default kernel option.

Then choose “Drop to root shell prompt” from this menu.

This should give you a root shell prompt.

Alternate Root Shell Method

If you don’t have the recovery mode option, this is the alternate way to manually edit the grub options to allow for a root shell.

First you’ll want to make sure to choose the regular boot kernel that you use (typically just the default one), and then use the “e” key to choose to edit that boot option.

Now just hit the down arrow key over to the “kernel” option, and then use the “e” key to switch to edit mode for the kernel option.

You’ll first be presented with a screen that looks very similar to this one:

You’ll want to remove the “ro quiet splash” part with the backspace key, and then add this onto the end:

rw init=/bin/bash

Once you hit enter after adjusting the kernel line, you’ll need to use the B key to choose to boot with that option.

At this point the system should boot up very quickly to a command prompt.

Changing the Actual Password

You can use the following command to reset your password:

passwd <username>

For example my username being geek I used this command:

passwd geek

After changing your password, use the following commands to reboot your system. (The sync command makes sure to write out data to the disk before rebooting)

sync
reboot –f

I found that the –f parameter was necessary to get the reboot command to work for some reason. You could always hardware reset instead, but make sure to use the sync command first.

And now you should be able to login without any issues.

Manually uninstalling VMware Workstation from Linux hosts

Manually uninstalling VMware Workstation from Linux

VMWare Workstation doesn't ship in a deb, so it isn't registered in dpkg (which is why you can't find it in the software center). It does have an install and uninstall utility though.

To uninstall VMWare Workstation, you will need to run

#vmware-installer --uninstall-product vmware-workstation

Details

This article provides steps for manually removing VMware Workstation when the uninstaller script or RPM package fails to remove the product automatically.

Solution

Note: Log into the host using the root account to execute the terminal commands in this article. If running Ubuntu, the root account is not available by default. Prepend all commands with sudo,or switch to root using this command:

sudo su -

Warning: This command provides unrestricted access to the operating system. It is possible to cause damage to the system when using this access level.

1. Open a command prompt. For more information, see Opening a command or shell prompt (1003892). Type the commands as indicated in the steps of this procedure.
   
2. Shut down all VMware applications and services.
   
   /etc/init.d/vmware stop
   
   
3. Verify that all processes have stopped:
   
   lsmod | grep vm
   
   Note: A zero must be listed beside VMware related modules to indicate that they are no longer running.
   
   
4. Move the VMware libraries to the /tmp directory:
   
   cd /lib/modules/kernel_version/misc
mv vm* /tmp
   
   Note: If the kernel has ever been updated, you must check and move the files from multiple paths. Substitute the kernel version where indicated above.
   
   
5. Unload the kernel modules:
   
   rmmod vmnet.o
rmmod vmmon.o
rmmod vmci.o
rmmod vmblock.o
rmmod vmppuser.o
   
   
6. Remove the VMware startup scripts:
   
   RedHat and Most Distributions:
   rm /etc/rc.d/init.d/rc2.d/*vmware*
rm /etc/rc.d/init.d/rc3.d/*vmware*
rm /etc/rc.d/init.d/rc5.d/*vmware*
rm /etc/rc.d/init.d/rc6.d/*vmware*
   
   Ubuntu:
   
   rm /etc/rc2.d/*vmware*
rm /etc/rc3.d/*vmware*
rm /etc/rc5.d/*vmware*
rm /etc/rc6.d/*vmware*
   
   Note: If you are using a different Linux distribution, substitute the correct path in the commands.
   
   
7. Remove the remaining VMware files and directories:
   
   rm -rf /etc/vmware*
rm /usr/bin/vmware-usbarbitrator
rm /usr/bin/vmnet*
rm -r /usr/lib/vmware*
rm -r /usr/share/doc/vmware*
   
   
8. If an RPM package was used to install the VMware product, complete these steps to delete the RPM database entry:
   
   rpm -qa | grep VMware
   
   A list of VMware packages is presented. Copy the exact package name for the next step and paste it into the command where indicated.
   
   
9. Remove the VMware packages:
   
   rpm --erase --nodeps VMware_Package_Name

Update script working with Backtrack 5

I could not find an update script working with Backtrack 5 so I decided to make a quick one.

Updated version: 2.0

Changelog Version 2.0

Code:

* Reviewed all tools.
* Compatible with Backtrack 5 R2/R3.
* Removed the menu.

Code:

git clone git://github.com/sickn3ss/backtrack_update.git
cd backtrack_update
chmod a+x backtrack5_update.py
./backtrack5_update.py

Screenshot:



If you know more tools I could add to the script in order to update them please feel free to post them here.
Also if you find any bugs or have any feedback feel free to contact me in this thread. I will update the thread with each update to the script.

NOTE: Please make sure you understand what the script does before running it.

Enjoy!

Got files separed from norm HTML

After meet up with team members we decide to migrate the site from norm HTML to PHP, the all projetc will take quite a while to finish, but so far the foundations, of the project are already laid down.. Quite interesting to see how this process is unfolding down ...

• Cut all the code and past in a separated document
• Save the new document with a different header name with .php file extension.
• Then import the content of the heading document into the main html document using the include* function - [ include is part of php library ]

Seems like all gone as we were expecting, but bear in mind that we faced some bugs when we tried to apply this approach the first time  ... Here it goes the output still getting the original content but keeping all the information rendered on server..

Here follows a screen shoot of the file the way it was before it been changed .. All the HTML markup in just one page ..

Using Virtual Ethernet Adapters in Promiscuous Mode on a Linux Host

VMware Workstation does not allow the virtual Ethernet adapter to go into promiscuous mode unless the user running VMware Workstation has permission to make that setting. This follows the standard Linux practice that only root can put a network interface into promiscuous mode.

When you install and configure VMware Workstation, you must run the installation as root. VMware Workstation creates the VMnet devices with root ownership and root group ownership, which means that only root has read and write permissions to the devices.

To set the virtual machine's Ethernet adapter to promiscuous mode, you must launch VMware Workstation as root because you must have read and write access to the VMnet device. For example, if you are using bridged networking, you must have access to /dev/vmnet0.

To grant selected other users read and write access to the VMnet device, you can create a new group, add the appropriate users to the group and grant that group read and write access to the appropriate device. You must make these changes on the host operating system as root (su -). For example, you can enter the following commands:

chgrp <newgroup> /dev/vmnet0

chmod g+rw /dev/vmnet0

<newgroup> is the group that should have the ability to set vmnet0 to promiscuous mode.

The command to run vmware workstations ads root is simple: user@user#:~$ sudo vmware start

If you want all users to be able to set the virtual Ethernet adapter (/dev/vmnet0 in our example) to promiscuous mode, run the following command on the host operating system as root:

chmod a+rw /dev/vmnet0

This is another posting showing "how to do computing" for everyday computer usages... For a general public

VMware on Linux : Running in Permiscuous Mode

 VMware on Linux: Promiscuous Mode

When VMware Workstation is hosted under Linux, by default it doesn't allow VM Guests to access the network in Promiscuous mode.  There's an easy fix for this...

If you run something like Wireshark from a VM Guest, you'll see VMware display an error message.

The problem lies with the permissions on the Host.  When VMware is started without root privileges, it doesn't have the permissions necessary to access the /dev/vmnet0 device.

A quick temporary bodge is to use chgrp and chmod on the Host, to tweak the permissions on /dev/vmnet* until the next reboot (where yourgroup is a group that your user account is in - typically admin on my Ubuntu machines):
   chgrp yourgroup /dev/vmnet*
   chmod g+rw /dev/vmnet*

A more permanent fix is to edit /etc/init.d/vmware on the Host, and tweak the ownership and permissions when the device is created, by adding the lines in red:
  # Start the virtual ethernet kernel service
   vmwareStartVmnet() {
      vmwareLoadModule $vnet
      "$BINDIR"/vmware-networks --start >> $VNETLIB_LOG 2>&1
      chgrp yourgroup  /dev/vmnet*
      chmod g+rw /dev/vmnet*

After you restart the Host's VMware daemon ...

   /etc/init.d/vmware stop
   /etc/init.d/vmware start

you'll be able to boot your Guest VM, and use Wireshark or whatever in the Guest.  Just Remember!   Your VM Guest's Network Adapter must be set to BRIDGED (connected directly to the physical network), not NAT (used to share the host's IP address).

Aside: I did think it ought be possible to achieve the same effect a little more cleanly, by creating a file in /etc/udev/rules.d to set the desired ownership and permission modes for /dev/vmnet*.  But nothing I've tried has worked.  Anyone?

md5sum.exe introduction

After you download all the Shorten (.shn) files for a particular disc or show, you want to verify that the files are not corrupted or otherwise unusable before you burn them to disc or host them on your file server. We do this by checking the downloaded Shorten (.shn) files against an .md5 file. An .md5 is a simple text file that contains a "fingerprint" of each Shorten file.

When you perform an md5 check, you are comparing the fingerprint from the files you downloaded to the fingerprint of the files on the server you downloaded from. If the md5's (fingerprints) match, you have an uncorrupted Shorten file.

 md5sum.exe - 48KB         88170 Downloads since 9/29/00

Windows 95/98/Me: Download md5sum.exe to c:\windows\command

Windows NT/2000: Download md5sum.exe to your c:\winnt\system32

 

Open an MS-DOS window and go to the directory of the show you want to check. When you are in that directory, type:

md5sum -c [filename].md5
 

You must insert the name of the .md5 file [without the brackets]. Below is an example of a successful md5sum check:

   

On the other hand, if a track does not pass the md5check, you will see the following:

If any Shorten files do not pass the .md5 check, you should delete the offending file(s), and try re-downloading. Then run the .md5 check again. The file(s) should now pass the .md5 check.

If the same files fail an .md5 check more than twice, you should contact the FTP Siteop you downloaded the files from and let them know what tracks are giving you a problem. They may be hosting a corrupted track without knowing it.

Open an MS-DOS window and go to the directory of the show you want to create an .md5 file for. When you are in that directory, type:

md5sum *.shn > [filename].md5
 

NOTE: You must insert the name of the .md5 file [without the brackets]. Example:
 

md5sum *.shn > ph94-06-26d1.md5

An .md5 file will be created and placed in that directory. Please remember to adhere the etree.org naming scheme when naming .md5 files!

Please remember to always .md5 check your Shorten files before burning!

  
Special thanks to bruce@gridpoint.com and the PCP community for compiling this special version of md5sum. Documentation and graphics by Mike Wren.