Unable to start Manjaro after stealing hard drive space

Support
1

Hi all, I’m pretty new to all of this so sorry in advance for my limited knowledge.

I dual boot with Manjaro KDE and Windows 10. My problem is that I decided I needed more space on Windows and I tried using both KDE and Windows default partition managers to take some space from Manjaro, neither worked so I used my Manjaro live iso to try, it kinda worked but now I’m unable to load into Manjaro, when I try this error pops up for a few seconds

error: attempt to read or write outside of partition
Press any key to continue. . .

(Sorry I can’t post images so I hope I am formatting this correctly)

After waiting a few seconds or pressing any key I will be shown this

Manjaro_Linux: The filesystem size (according to the superblock) is 291740672 blocks
The physical size of the device is 196608000 blocks
Either the superblock or the partition table is likely to be corrupt!
Manjaro_Linux: UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY.
(i.e., without -a or -p options)
ERROR: Bailing out. Run ‘fsck /dev/sda4’ manually
FILESYSTEM CHECK FAILED
Please run fsck manually. After leaving this maintenance shell, the system will reboot automatically.
sh: can’t access tty: job control turned off
[rootfs ]#

I tried following the directions that it shows me to manually run fsck but it took me almost 2 hours without the screen changing to just quit out of it, when I tried looking up similar cases I found one that took an hour to work but apparently that much time is abnormal? But now that I’m looking at it I also ran the command with using a instead of y for each so I’m not sure if that would affect it.

I can load into Windows 10 fine but with a similar looking error that appears beforehand

error: attempt to read or write outside of partition.
/EndEntire
file path: /ACPI(a0341d0,0)/PCI(3,1)/PCI(1,0)/Sata(4,ffff,0)HD(1,000m32000,3aea1b0cb5797f49,2,2)/File(\efi\Microsoft\Boot )/File(bootmgfw.efi)/EndEntire
Press any key to continue. . .

I tried to restore using timeshift since that worked for me previously with an unrelated partition issue but it didn’t help and this is what that looked like in case it provides any information

[manjaro@manjaro ~] timeshift --restore
Application needs admin access.
Please run the application as admin (using ‘sudo’ or ‘su’)
[manjaro@manjaro ~] sudo timeshift --restore
First run mode (config file not found)
Selected default snapshot type: RSYNC
E: Failed to mount device ’ /dev/sda4’ at mount point ’ /run/timeshift/backup’
E: mount: /run/timeshift/backup: wrong fs type, bad option, bad superblock on /dev/sda4, missing codepage or helper program, or other error.
Selected default snapshot device: /dev/sda4
Select backup device:
Num Device Size Type Label
0 > /dev/sda4 805.3 GB ext4 Manjaro Linux
Enter device name or number (a=Abort): 0
E: Failed to mount device ’ /dev/sda4’ at mount point ’ /run/timeshift/backup’
E: mount: /run/timeshift/backup: wrong fs type, bad option, bad superblock on /dev/sda4, missing codepage or helper program, or other error.
E: No snapshots found on device ’ /dev/sda4’

I’m still able to use Windows 10 ok aside from the error at the start, I’m likely going to start from scratch and reinstall both OS but I had some documents I forgot to back up that I would really like to recover, not sure if there’s a way to fix what I’ve got now but I would at least like to get those back if possible, I don’t know if I can recover them somehow with the timeshift file on a new install or something? I only have the one on the manjaro partition though.

Edit: I forgot to post what happens when I input the commands, this is what I’m getting every time I try any fsck variation.

[rootfs ]# fsck -v /dev/sda4
fsck from util-linux 2.37.2
e2fsck 1.46.4 (18-Aug-2021)
The filesystem size (according to the superblock) is 291740672 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort(y)? no
Manjaro_Linux contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Error reading block 196600032 (Invalid argument) while getting next inode from scan. Ignore error(y)? yes
Force rewrite(y)? yes

Everything then halts at this point, I can still type stuff so it didn’t freeze but no other lines pop up and the longest I’ve waited just in case was a bit more than 2 hours, not sure if it keeps working either since reboot and exit don’t work while in that state. If I abort or don’t ignore the error nothing happens and if I don’t force rewrite then the last 2 lines loop.

To clarify: I used KDE partition manager on a live iso and after the fact when I realized something was wrong I tried to give the space back to the original partition the same way but it kept giving an error, not sure if that is relevant.

2

should be the right thing to do. You can use fsck -V /dev/sda4 (verbose) which might show you what it is currently doing.

Timeshift won’t help you for the immediate filesystem problem (maybe later if you have to restore files).

Using gparted or KDE partitionmanager should have resized the filesystem together with the partition as those are pretty failsafe nowadays, … but something must have gone wrong.

  • EDIT: using Windows’ partitioning tools does not take Linux filesystems into acount, though! It just cuts the partiton to whatever you select - data loss included. I don’t know which one you used now.
1 Like
3

So you know:

  • You can’t edit your system partition from within the system. That’s like trying to change the seat of your chair while sitting on it. :face_with_head_bandage:
  • AFAIK you can’t edit Linux oriented partitions from the Windows partition manager as it doesn’t know how to handle those – even though they’re open-source… :unamused:
1 Like
4

Thank you for the info, I’ll try it out again later tonight when I have more time since the first time took a while. I also forgot to mention that I used KDE partition manager on a live iso and after the fact when I realized something was wrong I tried to give the space back to the original partition the same way but it kept giving an error, not sure if that is relevent.

5

KDE partition manager on a Live ISO sounds good :slight_smile: - that will have reduced the filesystem size first.

What filesystem type do you use? ext4 or something :cough:, exotic?

I have good hopes that fsck will get you up and running again.

6

I do use ext4 and I tried earlier to let fsck work for a couple hours but I still didn’t notice anything different. I could try again overnight to see if just leaving it for a long enough time works since I’m not in a rush.

I tried to do a little more research to see if I missed something before and I found a couple more commands and variations but none of them showed any difference

fsck -V /dev/sda4
fsck -f /dev/sda4
fsck /dev/sda4
e2fsck /dev/sda4

Not sure if there are others but there was no notable difference, I tried in both the live iso and the shell (I think that’s what it’s called the black screen white text area I get when I try booting).

Also I just realized I never posted what happens when I input the commands, this is what I’m getting every time I try any variation of fsck.

[rootfs ]# fsck -v /dev/sda4
fsck from util-linux 2.37.2
e2fsck 1.46.4 (18-Aug-2021)
The filesystem size (according to the superblock) is 291740672 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort(y)? no
Manjaro_Linux contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Error reading block 196600032 (Invalid argument) while getting next inode from scan. Ignore error(y)? yes
Force rewrite(y)? yes

Everything then halts at this point, I can still type stuff so it didn’t freeze but no other lines pop up and the longest I’ve waited just in case was a bit more than 2 hours, not sure if it keeps working either since reboot and exit don’t work while in that state. If I abort or don’t ignore the error nothing happens and if I don’t force rewrite then the last 2 lines loop.

Not sure how helpful the info is but I can’t think of anything else to include

7

Remember to make a backup before resizing partitions. :wink:

Tip: When pasting terminal output on Discourse forums, one can either…

  • Use the Preformatted text </> toolbar button–NOT the Quote " button.

  • Add three backticks ` above and below the text (Markdown):

    ```
    type or paste code here
    ```

  • Use HTML:

    <pre><code>
    type or paste code here
    </pre></code>

Please edit your posts accordingly.

8

To do what you want, what needs to happen is this:

  • the filesystem on the Manjaro partition needs to be shrunk
    (a lot of stuff needs to be relocated/rewritten - all that is on there needs to now be crammed into less space)
  • only then the partition containing that filesystem can be shrunk down as well
  • then the other partition can be extended
  • then the filesystem on it needs to be informed about having more space available

Somewhere in the first stage your procedure failed - perhaps Windows resized the partition disregarding the filesystem on it? Because it does not recognize the Linux filesystems, can’t natively work with it?
But this is pure speculation at this point.

Right now, the partition is smaller than the filesystem on it.
A lot of data got “chopped off” - was not relocated to fit the smaller space.
And this new available space was assigned to the Windows partition and claimed by the Windows filesystem already by now.

Some stuff is quite definitely lost.
You also ran fsck and had it making changes in attempt to “repair” the filesystem - which doesn’t do any good either.

You could try to restore the original state of the partitions - but now both of your systems are at risk.
I’d only try that if I had a backup.

9

I agree unfortunately. The errors fsck show are pretty catastrophic.

A last ditch effort might be to shrink the Windows partition and grow the partition containing the ext4 filesystem again so that the physical place where the ext4 filesystem was is again part of that partition. Depending on how much has changed during it being used in Windows fsck might be able to recover something. But some files will be gone for sure.

10