My user account doesnt have sudo despite being in sudoers. I cant run new commands i have to execute the binary. Grub takes very long to load with "welcome to grub" message. I just wanted a stable distro as arch broke and currupted my external ssd

  • tal@lemmy.today
    2·
    1 year ago

    looks puzzled

    /usr/sbin/fsck should be an executable. On my Debian Trixie system, it is. That sounds like it's a script, and whatever interpreter is specified to run it by the shebang line at the top of the file doesn't like the file's syntax. I wouldn't think that any Linux distro would replace that binary with a script, as it's something that has to run when almost everything else is broken.

    On my system, I get:

    $ file /usr/sbin/fsck
/usr/sbin/fsck: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked,   terpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=9d35c49423757582c9a21347eebe2c0f9dfdfdc4, for GNU/Linux 3.2.0, stripped
$ strings -n3 /usr/sbin/fsck|head -n5
ELF
/lib64/ld-linux-x86-64.so.2
GNU
GNU
#uu

    Do you get anything like that?

    EDIT: Oh, wait, wait, wait. /usr/sbin/fsck might be printing that message itself. I was gonna say that fsck shouldn't be looking at any files, but the man page lists /etc/fstab as a file that it looks at. Looking at strace -e openat fsck on my system, it does indeed look at /etc/fstab. Maybe the contents of your /etc/fstab are invalid, have a parenthesis in it. Can you also try grep '(' /etc/fstab and see what that gives?

    EDIT2: I don't think that it's an fsck error message. When I replace the first line of my fstab with left parens, I get "fsck: /etc/fstab: parse error at line 1 – ignored", which is a lot more reasonable.

    • mariah@feddit.rocksOP
      21·
      1 year ago

      Sorry i was using sh. This is the output

      fsck: error 2 (No such file or directory) while executing fsck.ext2 for /dev/sdd1
      • tal@lemmy.today
        2·
        1 year ago

        Sorry i was using sh.

        Ah, okay, that makes more sense.

        On my system, looks like fsck.ext2 is a symlink to e2fsck, which is provided by the e2fsprogs package:

        $ type fsck.ext2
fsck.ext2 is /sbin/fsck.ext2
$ dpkg -S /sbin/fsck.ext2
e2fsprogs: /sbin/fsck.ext2

        Can you try:

        # apt install e2fsprogs

        And then run:

        # fsck /dev/sdd1

        Again?

          • tal@lemmy.today
            2·
            1 year ago

            rubs chin

            Okay. "error 2 (No such file or directory)" is the error code that perror() will print when it gets ENOENT.

            checks

            One way you can get that is if you attempt to execute a file that isn't there, or execute or open a symlink that has a target that's missing. Could be that fsck.ext2 is missing or is a symlink, and that the e2fsck binary that it points to isn't there.

            On my system, I get this:

            $ ls -l /sbin/fsck.ext2 /sbin/e2fsck
-rwxr-xr-x 1 root root 356624 Sep  8 00:47 /sbin/e2fsck
lrwxrwxrwx 1 root root      6 Sep  8 00:47 /sbin/fsck.ext2 -> e2fsck

            Do you get something like that as well?

            If they aren't there, you can force reinstallation of e2fsprogs with # apt install --reinstall e2fsprogs and if the files are missing, that should add them, but I don't know how one could wind up in a situation where the package database thinks that the package is installed but that the binaries aren't present on a fresh Debian install.

              • tal@lemmy.today
                2·
                1 year ago

                Okay, though I had an idea as to what should cause that, but no, not it. I deleted my response shortly after posting it, if you already saw it.

                Hmm. Well, how about this. It should be possible to run e2fsck directly, and you say that the binary is present. Try:

                # /sbin/e2fsck /dev/sdd1

                If it says something about /dev/sdd1 being mounted, then don't go ahead with the scan; you've got the wrong partition in that case.

                • mariah@feddit.rocksOP
                  2·
                  1 year ago

                  Attempt to read block from filesystem resulted in short read while trying to open /dev/sdd1 Could this be a zero-length partition?

                  • tal@lemmy.today
                    2·
                    1 year ago

                    fsck is probably wrong in guessing that it's a zero-length partition; I would be more-inclined to guess that a read error caused it not to be able to read anything.

                    # parted /dev/sdd print

                    That should display the partition table on the drive, as well as the lengths of the partition. My guess is that it'll just show that you have a 4.5TB partition. Probably starts at something like 1MB and ends at something like 4500GB.

                    Linux was able to read from the drive enough to get at the partition table on it, or the lsblk output you had above in that image wouldn't be able to show the partition.

                    But I'd guess that it's hitting read errors in trying to read from the drive, and that the way that this is percolating up to fsck is fsck asking for N bytes and getting back only the bytes that it could read before it hit the error.

                    It's maybe not impossible that an invalid partition table could produce that error. And maybe e2fsck is trying to read off the end of the device or something because the filesystem on the partition is messed up, but I'm biased towards to thinking that it's more-likely that the drive is failing.

                    The first option I'm normally going to take when maybe a hard drive is dying is:

                    # smartctl -a /dev/sdd

                    As long as the drive supports SMART, that'll tell you whether the drive thinks that it's failing. That won't catch everything, but if the drive doesn't give itself a clean bill of health, then I wouldn't either.

                    If the kernel is trying to read data from a drive and seeing errors, it'll probably show up in the kernel log.

                    # dmesg | grep sdd

                    Should show you errors in the kernel log from the current boot relating to that drive.

                    If you don't see any errors there, then I'd be inclined to see whether it's possible to read the contents of the partition and whether that can do so. Something like – and be very careful not to reverse the "if" (input file) and "of" (output file) parameters here, because dd can write to a drive and if typed incorrectly, this can overwrite your drive's contents:

                    # dd if=/dev/sdd1 status=progress of=/dev/null

                    That'll just try reading from the beginning of the partition, giving you updates as it goes to let you know how much it's read, and then just dump the data into /dev/null. If it fails to read data at some point, it should bail out way before 4.5TB. Probably don't want to wait for the whole partition to be read, though, because 4.5TB is gonna take a while.

                    If dd can read the contents of the partition, then I assume that e2fsck should be able to as well.

                    If dd can read the data, then I'd assume that something is wrong with the filesystem, or at least the data on the partition, and it'd make sense to look at that.

                    If dd can't read the data, then I'd be inclined to blame hardware (or maybe the partition table), since nothing inside the partition itself, including the filesystem, should be able to make dd fail to read the contents of the partition; dd doesn't actually pay any attention to the data that it's reading.