How to check integrity of the root file system?
/etc/fstab says it's ext4, and /etc/mtab says it's lxfs.
Is there fsck for lxfs to run on the unmounted root from outside?
Or chkdsk in windows is sufficient for WSL files?
Related
Due to increasing space consumption of WSL I was forced to move my WSL distros to another disk.
Ubuntu
docker-desktop
docker-desktop-data
I used these commands.
wsl --shutdown
wsl --export (on all three of those distros)
wsl --import (already on another disk)
Now my environment is running fine but the ext4.vhdx in AppData\Local\Docker\wsl\data is still present and I can't remove it due to it still being used.
When I look at process hadnles
Its still being used by system which is not telling much.
If I run WSL --shutdown all virtual disks present on disk E: lose their handles and the one on disk C: is still being used.
Would you know how to find out what part of WSL or if it even is WSL is using?
Since shutting down WSL does not remove that handle it might be used by something else.
Its not docker-for-desktop that one uses different disk.
Thanks for your suggestions.
Docker Desktop for Windows, which uses WSL2, stores all image and container files in a separate virtual volume (vhdx). This virtual hard disk file can automatically grow when it needs more space (to a certain limit). Unfortunately, if you reclaim some space, i.e. by removing unused images, vhdx doesn't shrink automatically. Luckily, you can reduce its size manually by calling this command in PowerShell (as Administrator):
Optimize-VHD -Path $Env:LOCALAPPDATA\Docker\wsl\data\ext4.vhdx -Mode Full
If the above command fails with
The system failed to compact 'C:\Users\Maxx\AppData\Local\Docker\wsl\data\ext4.vhdx':
The process cannot access the file because it is being used by another process. (0x80070020).
exit form Docker Desktop or stop services and tasks using that file:
net stop com.docker.service
taskkill /IM "docker.exe" /F
taskkill /IM "Docker Desktop.exe" /F
wsl --shutdown
I reclaimed 15Gb of 40Gb.
Origin of the solution.
You can just clean data from interface. Troubleshooting -> Clean/Purge data
Upgrading from WSL1 to WSL2 made it a bit messy, but resetting docker-desktop to its default setting and then purging data from WSL (using docker-desktop troublesshot) cleared it for me.
I recently moved my wsl directory to another drive due to low storage in C: drive. As per the answer provided in this StackOverflow post, I used lxrunoffline tool and moved my Ubuntu distribution to another drive (E:\wsl in my case). As soon as the distribution was moved successfully, I ran wsl to test and it worked like a charm.
Everything went fine until one day I accidentally renamed the E:\wsl folder to something else. Well, as expected, wsl didn't work. Then, I reverted back to the name wsl and expected it to work but to my surprise, it didn't find any installed distribution after that even though it's installed... 😕
E:> wsl
Windows Subsystem for Linux has no installed distributions.
Distributions can be installed by visiting the Microsoft Store:
https://aka.ms/wslstore
Is there any way to revert back to the old directory or make wsl point to a manual location?
EDIT: I don't want to reset Ubuntu as I want to retain the installed packages and preferences...
Well, I finally found a solution to this problem. 😊
This is as simple as registering the distribution using lxrunoffline tool using the rg or register command.
E:\LxRunOffline\LxRunOffline-v3.3.3>lxrunoffline rg
[ERROR] the option '-d' is required but missing
Options:
-n arg Name of the distribution
-d arg The directory containing the distribution.
-c arg The config file to use. This argument is optional.
After running the register command, I was able to start wsl as usual. But that would log you in as a "root" user and would thus start in "/root" directory. I ran the following command to start wsl as different user (this is for Ubuntu):
ubuntu config --default-user <user-name>
I'm trying to automate the installation process of CentOS7 minimal in VirtualBox. Kickstart file is the solution. I find putting ks.cfg file into OEMDRV.vhdm disk and mounting it to VM memory the easiest way to give the VM access to the configuration file.
Anaconda reads ks.cfg file, as it pointed out mistake in spelling, but once the file is properly written the VM runs an error, same happens if the ks.cfg file is empty:
The I/O cache encountered an error while updating data in medium "ahci-
0-1" (rc=VERR_ACCESS_DENIED). Make sure there is enough free space on the
disk and that the disk is working properly. Operation can be resumed
afterwards.
The host is Windows 10, below is my ks.cfg file. The file is taken of already existing centOS7 minimal VM.
#version=DEVEL
# System authorization information
auth --enableshadow --passalgo=sha512
# Use CDROM installation media
cdrom
# Use cmdline/text/graphical install
graphical
# Run the Setup Agent on first boot
firstboot --enable
ignoredisk --only-use=sda
# Keyboard layouts
keyboard --vckeymap=us --xlayouts='us'
# System language
lang en_US.UTF-8
# Network information
network --bootproto=dhcp --device=enp0s3 --ipv6=auto --activate
network --hostname=localhost.localdomain
# Root password #working on --isctrypted rootpw
rootpw --iscrypted $6$6eqrvzKwp2ST4PMi$VUqUy8G/AsbaZK9XbtqlQcSIZjZ7QQk5yFqe5h/91YwM3GI3PjxEASc062EFPgGjvsmMxcLuKvx8d69KLplYJ1
# System services
services --disabled="chronyd"
# System timezone
timezone Europe/Warsaw --isUtc --nontp
# User
user --groups=wheel --name=secutest --password=$6$Ct923BcyZG.13TR2$jEUcu5tlvncoejaWa9eof.5GL1oU3wLVe0zEWLDrpKY6oXJhGeV4CRvoiYfFeC1IpkPeaXc1z912E3HdvOS/t/ --iscrypted --gecos="secutest"
# System bootloader configuration
bootloader --append=" crashkernel=auto" --location=mbr --boot-drive=sda
%packages
#^minimal
#core
kexec-tools
%end
%addon com_redhat_kdump --enable --reserve-mb='auto'
%end
%anaconda
pwpolicy root --minlen=6 --minquality=1 --notstrict --nochanges --notempty
pwpolicy user --minlen=6 --minquality=1 --notstrict --nochanges --emptyok
pwpolicy luks --minlen=6 --minquality=1 --notstrict --nochanges --notempty
%end
reboot
The solution is to use OEMDRV.iso, ISO disk type. Next OEMDRV disk has to be mounted to VM's SATA controller.
This command creates OEMDV.iso file with volume labeled 'OEMDRV' out of folder, which is exactly what we need.
$ mkisofs -V OEMDRV -o OEMDRV.iso path/to/directory
I have modified ”SELINUX=enforcing“ in /etc/selinux/config.But after restarting the machine,I can't ssh to my machine.
Prompt that
/bin/bash: Permission denied
When you edited the SELINUX for the first time or when switching between different types of policy, you need to relabel the filesystem. The below steps will do the relabel process automatically as shown in the procedures:
Restart server
reboot
On the GRUB display, press “e” to start editing the selected menu item.
Perform a break at an early stage of the boot process by typing 「rd.break」 at the end of the line starting
with kernel=.
kernel=... UTF-8 rd.break
Once ready press CTRL+X to start the boot process.
Check write access on the /sysroot mount point. By default this mount point is mounted only with the read-only (ro) access
mount | grep sysroot
=/dev/mapper/rhel-root on /sysroot type xfs (ro,relatime,attr2,inode64,noquota)
Remount the sysroot directory with read & write access.
mount -o remount,rw /sysroot
mount | grep sysroot
=/dev/mapper/rhel-root on /sysroot type xfs (rw,relatime,attr2,inode64,noquota)
Enter chroot system
chroot /sysroot
(new prompt) sh-4.4#
Force file-system relabeling. Next time when you will reboot the system, it will relabel the filesystem for
SElinux automatically.This usually occurs when labeling a file system for SELinux for the first time, or when
switching between different types of policy, such as changing from the targeted to the strict policy.
touch /.autorelabel
Exit the chroot. Reboot the machine
exit
logout or reboot (it will take time)
Now you should be able to login with ssh.
Recently I changed the permissions of the file system and gave myself all the rights. I logged out of the system and I couldn't log back in. I got the error message
Could not update ICEauthority file /home/marundu/.ICEauthority</>
I did a live boot with a Fed 17 disc and replaced my .ICEauthority file with the live-user version and it worked for a time, until I logged out again. Now, the login progress screen is all that shows. I can log into command mode (Ctrl-Alt-F2) but I can't sudo - I get the error messages:
sudo:/usr/libexec/sudoers.so must be only writable by owner and sudo: fatal error. Unable to load plugins.
I just found a good link on Ubuntu:
Ask Ubuntu: ICEauthority permissions problem
Some things to note:
I tried the obvious things like changing file permissions, but found my whole home directory was somehow owned by root. I believe this was due to a failed package update.
I used a recovery disk (Knoppix ISO) for ease of use: Better UI
When mounting the bad home partition, I used the most common Linux file type (Ext4)
I used 'sudo mount -o r,w -t ext4 /dev/sda1 /mnt'
When changing ownership, I used the numeric user:group specification, since the recovery disk doesn't have the symbolic users and groups: 'sudo chown -R 1000:1000 /mnt/home/userdir'
I verified that /home/userdir had rwx for owner, r-x for group / other. This is noted as a valid set of permissions for ICEauthority; others can work. See the linked discussion.
Hope that helps someone...
I got the “Could not update ICEauthority file” error and found that my home partition was in "Read-Only" mode. Thus, this error made sense.
The real question was what caused the "Read-Only" attribute on the partition. I ran "dmesg | read-only" and found that there were serious errors with the file system on my home partition which the kernel had set to "read-only during the boot process.
I then booted from a USB key (CDROM would do as well) and ran "sudo fsck /dev/sdXY" where /dev/sdXY is the partition containing my home directory. fsck corrected a number of file system errors on my home partition.
I then reboot after removing the USB key/CDROM and the problem went away.
Bottom line: Check if your home partition has file system errors. They might be the cause of this error. If so, run fsck from an external device on the partition containing your home directory.