Performed a zypper dup Tumbleweed update.
My root partition needs more space.
I rebooted into another partition with another installation LXQT and used the partition tool in YaST to expand the root.
I then used blkid to update and verify the fstab in the primary partition.
Rebooting to that install, it stalls with the Cylon red eye “working” status looking for the root partition.
OK ] Started Show Plymouth Boot Screen.
OK ] Started Forward Password Requests to Plymouth Directory Watch.
OK ] Reached target Paths.
OK ] Found device SAMSUNG_HD161GJ 2.
OK ] Reached target Initrd Root Device.
OK ] Finished dracut initqueue hook.
OK ] Reached target Remote File Systems (Pre).
OK ] Reached target Remote File Systems.
*** ] A start job is running for /dev/disk/by-uuid /9555609 … (10h 42min 52s / no limit)
the *** is the red Cylon searching eye and it never stops, stalls there.
Looks like it is not finding the target.
I assume there might be something in Grub or Boot that needs to be updated.
Looks to me that the filesystem is damaged and might be running a fsck.
What is the format? BTRFS?
You may need to just wait until the fsck completes, and presumably should repair any problems it encounters.
Yes… If your partition/filesystem is very big and your drive is slow, it can take a very, very long time.
Cross your fingers, or do anything else if you’re superstitious… and do something else while you’re waiting.
And hope that you won’t still have problems when the task completes.
If your journal is persistent, it could be gobbling a huge amount of space. If you are able to boot it, then use journalctl to manage it. If you have to boot your other installation, but it’s mountable, then you can do it manually by deleting old files from the subdirectory located in /var/log/journal/.
You can buy a little space until next dup by removing /var/log/updateTestcase*.
Check to see if purge-kernels service has been running. Two installed kernels for most people is plenty.
Inspect /tmp/ for old files, and delete if any are present.
*]Most people need only the latest version of libLLVM. If you have more than one installed, consider uninstalling the older.
When a partition gets resized the file system on that partition needs to be resized as well and that might take time.
I guess YaST will run resize2fs for you but probably in the background. So chances are that the resizing was not finished yet when you left your LXQT installation and you ended up with a (very) unclean file system and now an fsck is running.
I can have it done faster with MC than it takes to find out how using the journalctl man page or a web search for the missing examples typical of man pages, or to learn vacuum means recover wasted space. A dozen or fewer keystrokes to get there and do it is far less tedium than man page or web searching.
As a general rule, no examples, no comprende. So, while the options listing is nice to know, by itself, a list of options generally falls short enough to be a why bother.
On the rare occasions when i had to resize a partition with an ext4-filesystem on it i always did it manually (i.e. using gdisk and resize2fs). I do not know how YaST handles this.
Two problem areas come to my mind:
man resize2fs
says:“When recreating the partition, make sure you create it with the same starting disk cylinder as before! Otherwise, the resize operation will certainly not work, and you may lose your entire filesystem.”
An interrupted filesystem resize operation may result in an unusable (un-repairable?) filesystem.
Startup your LXQT-installation and try to run e2fsck. I don’t know if it is possible to restart resize2fs.
And keep in mind that depending on the size of the partition and the speed of the disk such operations can be quite lengthy.
dad-pc:/home/dad # journalctl --directory /mnt/var/log/journal/..../ -b
Failed to open /mnt/var/log/journal/..../: No such file or directory
dad-pc:/home/dad # dir /mnt/var/log
alternatives.log lightdm wpa_supplicant.log
apache2 ntp wpslog
audit nvidia-installer.log wtmp
boot.log nvidia-uninstall.log wtmp-20200311.xz
btmp pbl.log Xorg.0.log
chrony private Xorg.0.log.old
cuda-installer.log samba Xorg.1.log
cups sendfax.log Xorg.1.log.old
fax snapper.log YaST2
firewalld snapper.log-20201017.xz zypp
hp tallylog zypper.log
krb5 updateTestcase-2020-10-17-21-22-31 zypper.log-20201018.xz
lastlog updateTestcase-2020-10-18-02-55-34
dad-pc:/home/dad # journalctl --directory /mnt/var --disk-usage
No journal files were found.
Archived and active journals take up 0B in the file system.
Looking in grub.cfg I saw the following which didn’t look right? Why is it looking at two different partitions?
echo 'Loading Linux 5.6.14-1-default ...'
linux /boot/vmlinuz-5.6.14-1-default root=UUID=6dae7c25-d985-44e6-b386-23c7d3a7af64 resume=/dev/disk/by-uuid/95560983-e4b1-42a7-87b3-b2e20c8feb77 quiet
A persistent journal is optional. If not found, it isn’t configured. To configure it, use /etc/systemd/journald.conf, or simply create a /var/log/journal directory.
What is the resume= line? It is not in my fstab
It’s an optional (unnecessary) override to the resume line built into each initrd, for use by suspenders.
Looks like you system has no problem with disk space. When dealing with problems journal is a great place to start with. So you may consider enabling journal storage on disk on all your systems. Default as indicated in /etc/systemd/journald.conf is #Storage=auto. Thus creating directory /var/log/journal will move journal from memory to hard disk.
With little being known about your system giving advice to recover from the mishap is challenging.
I tried using the rescue disk, but the YaST bootloader tool errored saying it could not find the root partition.
Solution: I reinstalled from a current Tumbleweed iso.
Note the space used on that drive is now about 4 gig, vs the previous drive filled at 36 gig.
A clean install is the best answer. Running great.