I just installed debian and i have many problems

mariah@feddit.rocks to Linux@lemmy.ml – 37 points –

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

79

You are viewing a single comment

/usr/sbin/fsck: 1: Syntax error: "(" unexpected

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.

Sorry i was using sh. This is the output

fsck: error 2 (No such file or directory) while executing fsck.ext2 for /dev/sdd1

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?

E2fsprogs is installed already

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.

I do have it

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.

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

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.

The commands were fine but dd.

8192 bytes (8.2 kB, 8.0 KiB) copied, 21 s, 0.4 kB/s
dd: error reading '/dev/sdd1': Input/output error
16+0 records in
16+0 records out
8192 bytes (8.2 kB, 8.0 KiB) copied, 28.0116 s, 0.3 kB/s

Input/output error means the drive is just dying, irrespective of the software. Software can't do anything about failing hardware, and that's what you ran into.

Probably so, but just to be certain about the partition table not causing it, I'd maybe try running the dd command on /dev/sdd rather than /dev/sdd1. It should be able to read a little more than the attempt to read /dev/sdd1 did. I'm not absolutely certain what happens if a partition table is invalid and has a partition that includes a region extending off the end of the hard drive, and I haven't actually seen a dump of the partition table posted by OP. It might be that an attempt to read a partition that extends off the end of the drive gets exposed to an application as an I/O error.

I'm also a little surprised by the lack of kernel log messages. Maybe things have changed, but with all of IDE and SATA internal drives, I always got errors logged with the kernel if I/O failed on a drive, and they always referenced the drive's device name.

I just can't think of much higher level stuff that would cause I/O errors while trying to read at a partition level, though.

And a failing drive could also explain the freeze in Arch, the slow booting of Debian, the inability to mount the drive, and the I/O errors, so it'd explain a lot.

Great. Well, I mean, bad, but that does narrow it down. So that drive is probably failing, but it can read from some places on the drive...just not all. And it fails pretty early, just a few KB into the partition. Though I don't know why you wouldn't get a kernel log message about that.

Well, if we're really lucky, maybe it just has a bad sector at that one critical location, and everything else is fine. Well, I'm not sure I'd trust a drive once it starts getting read failures, but point is that other data there might be readable. My understanding -- which dates to rotational drives -- is that normally hard drives maintain a map of sectors and a certain limited store of spare "good" sectors on the drive. When they write, if there's an error in writing, they switch to a "good" sector, mapping the location to that "good" sector so that, internally, every time you try to touch that location on the drive, the drive is actually using a different physical location. So even writing to that spot on the disk -- though I don't know if it's something that can be regenerated -- may cause the location to be readable again, because a drive will remap the sector to different physical underlying storage.

I understand that SSDs -- which are more free to remap sectors than rotational hard drives, for which it is expensive in time to send the head careening around the drive to weird, non-sequential sectors -- use something called "wear leveling", and regularly remap what's there, as they don't care about things being physically-contiguous and one can only write so many times to a given spot on an SSD, and this spreads out the places that are getting written to many times. So if one sector on an SSD starts failing, I'd be a little concerned about others going too.

So, a couple things that we can maybe experiment with. Maybe we start reading some distance into the drive, we can get some idea of what portion of the partition isn't readable.

dd is defaulting to reading in blocks of 512 bytes at a time. It manages to read 16 512-byte-size blocks into the partition, gets 8KiB of data, and then reading the 17th block is a problem. Maybe try:

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

That'll skip over the first 1024 512-byte blocks -- that is, 512 KiB in), and start reading from that point. If the drive can't read from there, then you'll get an error, and if the drive can, then it'll read for at least a ways.

If the manual typing isn't a prohibitive problem with the CP, you can do a binary search for the end of the bad portion. So, we know that block 16 is good. We know that block 17 is bad. We don't know what extent of the partition the "bad" covers -- could be 1 block, could be the rest of the partition, could be an interspersed collection of failing and non-failing sectors. If it's just one short range, it might be possible to recover what's there.

So, I'd start at 1024. If dd can't read anything 1024 blocks in, then I'd double the "skip=" parameter to 2048, and try again. At some point, if you keep doubling the number, hopefully you'll get readable data (hopefully the rest of the partition). If it's readable, then cut in half the distance between the first-known "bad" block (currently 17) and the first-known "good" block. So, it'd look something like this, if hypothetically our bad range is 17-1500:

Furthest-known "bad" block First-known "good" block after region Trying Result Notes
N/A N/A 0 Read error after 16 blocks Our first run
17 N/A 1024 Read error immediately Trying with the skip=1024 I suggested above
17 N/A 2048 No errors Now we have our first known "good" block after the "bad" portion, at 2048
17 2048 1032 Error immediately 1032 is (17+2048)/2
1032 2048 1540 No errors 1540 is (1032+2048)/2
1032 1540 1286 Error immediately 1286 is (1032+1540)/2

The commands there would be something like:

# dd if=/dev/sdd1 status=progress of=/dev/null
# dd if=/dev/sdd1 status=progress skip=1024 of=/dev/null
# dd if=/dev/sdd1 status=progress skip=2048 of=/dev/null
# dd if=/dev/sdd1 status=progress skip=1032 of=/dev/null

...etc. At some point, the first two numbers, the furthest-known "bad" and the first-known "good" will converge to a single block -- which for our hypothetical example, would be block 1500 -- and we know the end of the "bad" region (assuming that it is a contiguous bad region...we might skip over some good data).

I'd at least try a couple commands to get an idea of whether the whole disk is hosed or just a tiny portion at the start. If a lot of it isn't readable and can't be made to be readable, then it's going to be tough to recover. If it's a tiny amount of data at the beginning of the drive, that might not be so bad.

Maybe only try to copy a limited number of blocks each time, so ...for 5MiB, that'd be count=10240, so something like:

# dd if=/dev/sdd1 status=progress count=10240 skip=1024 of=/dev/null

Then you don't have to whack Control-C to cancel it if most of the drive is "good" data.

If there isn't a whole lot of "bad" data, an option to try to pull all accessible data off the drive might be to try ddrescue. In Debian, this is in the gddrescue package package. It will attempt to read from a block device, like your /dev/sdd1 partition, and write what it can read to another file or device. It'll retry places where it gets a read error, log where errors are in a "mapfile", and then move on to try to extract as much data from a device that is seeing hardware failures as possible. It's possible to try that. Unfortunately, I don't have a device that spits out read errors handy to try it out on, so I can only give you commands looking at the man page, can't test them out here. I also haven't used it before myself to recover data from a drive, since I haven't run into your "some of the drive is readable, some isn't" scenario. I believe that it used to be more-popular in the burned CD era, where sometimes similar problems would show up.

You will also want to have a larger drive to be able to store the output from ddrescue on. While I don't know whether reads will exacerbate problems for the SSD, for all I know, the drive might, as a whole, go belly up at some point, and reads might be an input into that, so it might be a good idea to, if the aim is to try to grab what can be grabbed from the drive, not do this a huge number of times.

Another option would be to try to do the recovery directly on the problematic drive -- like, if only a small area is bad, it might be possible to write 0s or something to the bad range, hopefully make the area readable again, and hope that nothing in the bad region is critical for e2fsck to need to do the repair. If it's worth getting another drive to dump this onto first to you, though, and the existing drive doesn't have too much "bad" data, I'd probably do so and then try to repair the filesystem on that drive, as that would be less-intrusive to this drive, which I'd be inclined not to trust a whole lot. Worst case, it isn't repairable and then one has a new drive to store a new collection, I suppose.

sudo dd if=/dev/sdd1 status=progress skip=1024 of=/dev/null [sudo] password for mariah: 25847808 bytes (26 MB, 25 MiB) copied, 348 s, 74.2 kB/s dd: error reading '/dev/sdd1': Input/output error 50488+0 records in 50488+0 records out 25849856 bytes (26 MB, 25 MiB) copied, 355.279 s, 72.8 kB/s

5 more...
5 more...
5 more...
5 more...
5 more...
5 more...
6 more...
6 more...
6 more...
6 more...
6 more...
6 more...
6 more...