#[SOLVED] Dependency failed for /home
340 messages · Page 1 of 1 (latest)
@dry nexus do you still have the usb flashed?
yes
does it matter if the iso is old
yes done
now chroot
do i chroot into the home partition?
you can't chroot in the home partition
ohh, they can't run a service through chroot
can you just exit from chroot, umount the partitions and run fsck on the home partition
you should still be able to log in even tho ur in emergency mode you’ll only have the cli iirc
journalctl -xb
yup, that's the other way but they are already in the iso
¯_(ツ)_/¯ i’ll brb
do i run this and check if it works?
do i need to pass any arguments
should be something like :-
fsck -f /dev/home-par
yes, but you have to umount your partitions first
did it showed some corrupted inodes
what's the output
yup
you have to press y for all the optimization it asks
or maybe you can run fsck -fy /dev/sda3 for automatically considering yes for all the optimizations
i did yes to all
there was a prompt for it
just try rebooting now
is this normal
I don't thinks that's normal
running fsck on the home partition shouldn't affect your system this way
do i ctrl c?
I don't think ctrl c will work
that can happen due to loose display connection too
what do i do
irrc arch iso has some memory test build it, you can boot in that through the grub menu
have you tried rebooting again?
hard poweroff
do you see some memtest option
BIOS may have memtest too
ohh, if you can boot in your iso you should be able to boot in your system
yes
maybe try running that, just in case.
first can you try booting in your system.
as it might have occurred due to some kernel panic or something
running memtest
I don't think the problem is with the memory
you are booting in your archiso fine
@dry nexus update?
i let memtest run
I'm hard rebooting rn
roger that
please journalctl -xb
yes
run fsck -p /dev/sda3
and try rebooting again, if this doesn't work will chroot in the system through arch iso and see the pacman logs first
.
you can also use fsck -fy /dev/sda3
i did fsck -f -y /dev/sda3
it led to demonic possession

again?
fsck service exec might be jacked
is it normal for arch to break like this
don't put that y and manually press y for all the conformation
No, it might have occurred due to some broken update and maybe some corruption
/dev/sda3 was unmounted right?
yes i did it from iso
oh ok
have you tried this?
it might be the issue with some systemd-libs or something
can we get a cat /etc/fstab to see fsck order? it might be worth running fsck on another sda partition to see if it produces the same result if we cant get any pertinent information from manually y paging through this next fsck -f /dev/sda3 that he's ab to run.
am i making sense here
i did not have to put y once
and the random numbers start appearing
you mean demon mode lol
can you show the output once
you have to put in y multiple times depending on the corruption level
it's just asking for clearing the corrupted inodes
do you mounted /home exterally
just type y for every prompt fsck -f /dev/sda3 shows
after this demon attacks
daemonic possession ha
what
ohh so you are in the arch system itself
let's just check the pacman log
doesn't matter
even if i do it through the installer it's the same
I don't think they need to reformat the drive
ca we do force fsck
it might be some other hardware issue
already done
they are having daemonic possession when they do fsck
oh
let's check the pacman logs
less /var/log/pacman.log
press shift-g and starts scrolling up.
check for some errors
you don't have to scroll too up, just scroll for 1 update
umm
you can try grep -C 3 -i 'fsck' /var/log/pacman.log | egrep 'error|fail|warning'
if you dont want to pan through like 1000 lines of a log
yea i had like 600 packages updated
I think there is corrupt metadata on that filesystem, why not backup and recreate filesystem
that's what i'm leaning to tbh but idk
do you have a backup of your home directory?
fsck.ext4 -f -b 8193 /dev/sda3 - this will tries an alternative superblock backup location.
all errors are from 2023 june
there are no recent errors
roger that.
-B or -b?
-b
-b 8193, tells fsck to use the superblock backup located at offset 8193, instead of the primary superblock at offset 0
Instead of using the normal superblock, use an alternative superblock specified by superblock. This option is normally used when the primary superblock has been corrupted. The location of the backup superblock is dependent on the filesystem's blocksize. For filesystems with 1k blocksizes, a backup superblock can be found at block 8193; for filesystems with 2k blocksizes, at block 16384; and for 4k blocksizes, at block 32768. ```
from [fsck.ext4](https://linux.die.net/man/8/fsck.ext4)
its like 1:45am here so i'm runnin on fumes lol
what do i do now ")
fsck.ext4 -f -b 8193 /dev/sda3
will it delete my files?
no its just running fsck again
have you checked the pacman log
yes lol it didn't return anything
yes the errors are from 2023
he's running e2fsck against the backup superblock
no he ran grep
i had scrollable view no errors there
^
@dry nexus
less /var/log/pacman.log
press shift-g
bro haha leave the pacman logs lie
i did
there are no errors
are you sure, there were no errors or something like that?
@dry nexus dumpe2fs /dev/sda3 | grep -i superblock
i am still in the arch system btw
because goofy ah ext4 might not have a superblock at 8193
have you tried running fsck via arch-iso without mounting any partition?
their system was running fine till the update, I seriously don't know what's exactly wrong
Gyat
i tried running just by mounting root partition
can you try running without mounting any partition
on it
boot through the iso don't mount any partition and run fsck on the home partition
i thought he already ran fsck from iso
i ran but mounting / partition
i didn't think it'd make any difference
oh
well typically only that specific partition needs to be unmounted to run fsck but its worth a shot
yeah, but we have to try something.
welp
incredible
can we try ^ now
I'll try from iso
on it right now
roger
the numbers mason
what do they mean
i'm so lost in the sauce rn i dont even know what to think ab this
just don't try this yet
only linus can help me now
-S
Write superblock and group descriptors only. This is useful if all of the superblock and backup superblocks are corrupted, and a last-ditch recovery method is desired. It causes mke2fs to reinitialize the superblock and group descriptors, while not touching the inode table and the block and inode bitmaps. The e2fsck program should be run immediately after this option is used, and there is no guarantee that any data will be salvageable. It is critical to specify the correct filesystem blocksize when using this option, or there is no chance of recovery. ```
from [mkfs.ext4](https://linux.die.net/man/8/mkfs.ext4)
i would try it
mkfs.ext4 -S /dev/sda3 && fsck.ext4 -f /dev/sda3
i saw in the manjaro forums that fsck -f -y [home partition] fixed their issue
yes
my computer booted even after the update yesterday
it's just today it's being a bitch
let us know how this goes
will it erase my data
not if you run it with the -S flag
what does mkfs cmmd do
@bronze eagle ^
yeah I read it
he ran fsck.ext4 -f -b 8193 /dev/sda3 and it still threw a fit so I had him run dumpe2fs /dev/sda3 | grep -i superblock to see where the superblocks were
he posted this, so we reran fsck at superblock 32768
same error
then @heady wind posted about the -S flag for mkfs which rewrites superblock and group descriptors only. if its corrupted metadata this should hopefully fix it.
If he still unable to recover it then I think he should use ddrescue or photorec tools to recover home partition data, and then format it and then mount it again
we're getting there, I want to see if mkfs is going to do anything for him first
ok
Don't run that command yet
which one
this i think
The one I sent image of
It can
that cmmd will wipe out his data and then create a superblock to all over entire partition. Isn't this is Irrelevant now
if superblocks are missaligned with the inodes if i'm reading correctly
if he's going to run it he should actually run dumpe2fs /dev/sda3 | grep -i "Block size" first, then specify the block size in the mkfs.ext4 command. so it should actually be mkfs.ext4 -S -b { block size } && fsck.ext4 -f /dev/sda3
Specify the size of blocks in bytes. Valid block-size values are 1024, 2048 and 4096 bytes per block. If omitted, block-size is heuristically determined by the filesystem size and the expected usage of the filesystem (see the -T option). If block-size is negative, then mke2fs will use heuristics to determine the appropriate block size, with the constraint that the block size will be at least block-size bytes. This is useful for certain hardware devices which require that the blocksize be a multiple of 2k. ```
from [mkfs.ext4](https://linux.die.net/man/8/mkfs.ext4)
Higher one is for handling larger files smaller is for handling small size files
is there no way without wiping out my data
i got too much important stuff
why not use tools like ddrescue or phtorec to recover data
probably best to just run disk recovery software on your drive tbh
Data recovery tool
PhotoRec is file data recovery software designed to recover lost files including video, documents and archives from hard disks (Mechanical Hard drives, Solid State Drives...), CD-ROMs, and lost pictures (thus the Photo Recovery name) from digital camera memory. PhotoRec ignores the file system and goes after the underlying data, so it will still...
good ni8
so i tried mounting /home manually and there are some things
3 error messages
ext4_check_descriptors: Block bitmap for group 2666 not in group (block 10444675469559614510)
216.324314) EXT4-fs (sda3): group descriptors corrupted!
mount: /home: fsconfig system call failed: Structure needs cleaning.
you can't mount that, it has corrupted descriptors
@dry nexus can you add TLDR about your issue and what you've tried so that a new person may easily comprehend the issue?
when i tried to boot
/home partition could not mount apparently for corrupted descriptors
and running fsck -f -y on the partition would lead to infinite scroll of numbers
TLDR of the issue
Troubleshooting Steps Taken
- ran
fsck -f /dev/sda3from archiso :: inode scrolling issue occurs - ran memtest :: no fault
- checked
/var/log/pacman.logforfsckerrors, fails, and warnings :: no recent logs - ran
fsck.ext4 -f -b 8193 /dev/sda3:: bad magic number, superblock could not be read - ran
dumpe2fs /dev/sda3 | grep -i superblock:: first backup superblock begins at32769 - ran
fsck.ext4 -f -b 32769 /dev/sda3:: inode scrolling issue still occurs - attempted
mount /dev/sda3::block bitmap for group 2666 not in group; group descriptors corrupted
@dry nexus when you get the inode scrolling issue, do you let it run or do you stop it?
good morning
i stopped it
by force rebooting
good morning lol. I've never seen fsck behave this way, but you may want to just try letting it run, despite the scrolling nonsense. I'm pretty sure those are inode numbers. You could try to let it run for like 5-10 minutes or so and see if it stops on its own. If you don't want to try that, then like we were talking about last night you should probably run ddrescue like @bronze eagle suggested.
I'll run fsck for some time to see if it stops automatically
then I'll have to run ddrescue ig
okay, I'm not sure exactly what the implications of letting run are, and you may decide to let it run longer than 10 minutes if its taking that long. This is beyond the scope of what I'm familiar with so, just a suggestion
Yup, I have seen a similar issue where the author has to run the fsck for 30mins
i even dm'd @dry nexus about this
I'm sorry i did not get the notification
I'll run fsck from iso and let it run
sounds good, keep us updated.
so i will not mount any partitions
just plain fsck -f -y /dev/sda3
that'll work
sounds good
I'll send a message here which will be the starting time
started
demonic possession is on
i forced shutdown
been more than an hour
I'll try again tomorrow ")
with ddrescue ig
👍🏻
@restive crater what exactly do i do with ddrescue
also fsck.ext4 -f -b 32769 /dev/sda3 returns
To be perfectly honest with you I’ve never personally used ddrescue but I’ve seen good things and I think that’s the direction you should head. ddrescue tutorial I found. maybe give that a watch or wait for @bronze eagle or @heady wind to see if they can help you further. I gotta go to bed lol I have a full day tomorrow.
Homepage: https://www.data-medics.com
Original ddrescue written guide: https://www.data-medics.com/forum/threads/how-to-clone-a-hard-drive-with-bad-sectors-using-ddrescue.133/
ddrescue triggers & documentation: https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html
In this part 2 of the series on how to clone a hard drive with bad se...
@bronze eagle
i have not started using ddrescue yet
I'll free tomorrow, will talk further on this
yes please
guys @heady wind @bronze eagle @restive crater
there is update
so i read somewhere that fsck might have a bug
which is why i flashed a new version of the iso just to have the closure (and honestly i don't know if it's anyhow relevant)
so i tried running fsck -f /dev/sda3 and let it run as long as it takes
and after a good amount of time ..
it took 2 hours and 14 minutes
lmao
mout it
today was my semster last paper, and it's done
I'll just have a lunch then will look at it
it's solved
i'm in my system now
you using waybar
[SOLVED] Dependency failed for /home
i want to use ags but i still haven't got time to sit around with javascript
also i have my sems coming up
I use somone config for ags, I also didn't have much time. I invested a month in customising hyprland + waybar setup
i tried using end_04's config for ags
they made a material 3 themed bar and widgets
but it's for laptop
and the config is very big
I used it too It's messy but looks great.
and I get too many error during installation, that dotfile uses plasma ags together
yeah same
so i thought i'll write my own ags and take components from others
it would be great, take pieces and build at your preferences
easiest way to build configs
The problem got solved by letting fsck -f [partition] run for as long as it takes
Great
So glad to hear this. Great Job @dry nexus !