I was editing my disk and when i wrote the changes and exited cfdisk, no cli command worked. Thats when i realized that im f-ed up.

This what happened: I have 3 partitions, 512M efi, a 100G root partition and some free (unallocated) space. I had 84G worth data in the root patition. I totally forgot that and shrinked the root partition to 32G to extend the free space. I was using cfdisk tool for this. I wrote the changes and rebooted my machine, by long pressing power button coz no cli commands worked after writing those chrnges, to see this.

So is it possible to recover my machine now?

:_ )

SOLUTION Thanks to @dgriffith@aussie.zone. cfdisk just updates the partition table. So no worry about data damage . To fix this, live boot -> resize the partition back its original size -> fsck that partition. For more explanation, refer @dgriffith@aussie.zone comment

  • @vvv@programming.dev
    83•1 month ago

    just to add a little more explanation to what the other posters are suggesting… a hard drive, from the perspective of your OS is very very simple. it’s a series of bytes. for the sake of this example, let’s say there are 1000 of them. they are just a series of numbers.

    how do you tell apart which numbers belong to which partitions? well there’s a convention: you decide that the first 10 of those numbers can be a label to indicate where partions start. e.g. your efi starts at #11 and ends at #61. root at starts at #61 and ends at #800. the label doesn’t say anything about the bytes after that.

    how do you know which bytes in the partions make up files? similar sort of game with a file system within the bounds of that partion - you use some of the data as a label to find the file data. maybe bytes 71-78 indicate that you can find ~/.bash_histor at bytes 732-790.

    what happened when you shrunk that root partions, is you changed that label at the beginning. your root partion, it says, now starts at byte #61 and goes to #300. any bytes after that, are fair game for a new partion and filesystem to overwrite.

    the point of all this, is that so far all you’ve done is changed some labels. the bytes that make up your files are still on the disk, but perhaps not findable. however - because every process that writes to the disk will trust those labels, any operation you do to the disk, including mounting it has a chance to overwrite the data that makes up your files.

    this means:

    • most of your files are probably recoverable
    • do not boot the operating system on that drive, or any other that will attempt to mount it, because you risk overwring data
    • before you start using any data recovery tools, make a copy of the raw bytes of the disk to a different disk, so that if the tools mess up you have an option to try again

    ONLY after that is done, the first thing I’d try is setting that partion label back to what it used to say, 100gb… if you’re lucky, everything will just work. if you aren’t, tools like ‘photorec’ can crawl the raw bytes of the disk and try and output whatever files they find.

    good luck!

    • @some_guy@lemmy.sdf.org
      19•1 month ago

      While I appreciate the jokes, this is the only comment I’ll upvote because this was a call for help and this one helps.

    • @t0mriOP
      7•1 month ago

      Yeah i remember now. I have to format the partitions to complete partitioning. Thanks for info

      • oo1
        27•1 month ago

        Is it that wierd little box thing that you have to take out of your smoke alarm to stop it beeping?

        • melroy
          1•30 days ago

          I hate smoke alarms, especially since I have Tinnitus. So indeed I throw those away.

  • @zurohki@aussie.zoneEnglish
    32•1 month ago

    If there’s something really important on that disk, don’t do ANYTHING, just unplug it and hand it over to a data recovery company.

    If there isn’t anything really important on there, go ahead and try and do it yourself.

    Paying $100 to a data recovery company can save you a ton of headaches if it has the only copy of your thesis on there and you mess it up trying to fix things yourself.

    • @steersman2484@sh.itjust.works
      18•1 month ago

      If you create an image of the disk in the current state from a live boot or an other machine. You can try fixing it without having to risk making things worse

      • 7heo
        11•1 month ago

        Also, work off of the copy. Never touch the source.

    • @survivalmachine@beehaw.org
      6•1 month ago

      Where is data recovery $100? In my country, data recovery is like $1000 USD to look at your drive, and then they tell you how much they can recover and a full quote.

      • @zurohki@aussie.zoneEnglish
        0•1 month ago

        Depends on what they actually need to do. When it’s a drive that’s working and they just have to image it and run some recovery software it should be pretty cheap.

        Clean room repair of dead hard disks is a different story.

  • @ReversalHatchery@beehaw.orgEnglish
    30•1 month ago

    There’s something to know in the future, which others don’t seem to have mentioned. Resizing a partition is 2 steps: resizing the filesystem, and resizing the partition.

    When shrinking, you first resize the filesystem, and with this you make sure that the filesystem does not want to use data outside of the wanted shrinked size. If that not possible because you don’t have enough free space, the shrink operation should tell that. After shrinking is done, you can continue with changing the partition table, to actually resize the partition.

    When expanding you first expand the partition (so that the fs will have room to expand to), and then expand the filesystem.

    If you’re familiar with partitioning from the tools of microsoft windows, it’s disk manager does the 2 steps without you noticing. This is just how most graphical partition managers work.
    But it’s important to be aware that the partition and the filesystem is not one and the same object. The filesystem resides in the partition like your feet does in your shoes, and the beginning of the partition helps for the system to find the beginning of the file system, which must end at the partition’s end (or before that, but that’s not efficient).

    If you prefer graphical partition managers (I do too, it’s much easier), Linux has a few of them. I recommend you to use GParted. It’s a Linux based pendrive-bootable partition editor. They have an official live image, but I would recommend using the SystemRescue system (a live system too), which includes that and many other tools.
    In this case, that the problem had already happened, it may or may not be easier to use this.

    • SayCyberOnceMoreEnglish
      3•1 month ago

      Excellent explanation - I might use your “feet in shoes” analogy in the future

      GParted has solved so many things over the years… my data, my reputation… maybe even my job on 1 occasion.

    • @bizdelnick
      3•1 month ago

      That’s correct answer. If you did not write anything in the space you freed (i.e. did not create a partition there AND format it), your data is not damaged.

      • voxel
        1•29 days ago

        also format does not actually completely overwrite most of the data, so you’ll probably just end up with a couple corrupted blocks, which are fixable with some minor data loss

    • @t0mriOP
      3•1 month ago

      Yeah, it worked.

    • 7heo
      3•1 month ago

      Larger might be acceptable too, not sure

      It should.

  • @toni_bmw@lemmy.world
    10•1 month ago

    I always love working with partitions because of the knowledge it gives you, but it is also certainly dangerous and from time to time it is unnevitable to suffer an accident. In any case I always try to do this type of operations with parted and if possible with GUI (gparted).

    Being in the photo situation, can’t you make a fsck as the error messages tell you?

    fsck /dev/nvme0n1p2

    If not, the most practical would be, IMHO, to boot from a rescue live, e.g. https://www.system-rescue.org/Download/ Once booted, you can lift the graphical interface with startx and do with gparted the operations you need on these partitions.

    • @t0mriOP
      9•1 month ago

      For sure.

      For fsck /dev/nvme0n1p2:

      • Dave.
        30•1 month ago

        The filesystem driver knows the size of the filesystem is larger than the physical size of the partition it is on. Because of that it refuses to do anything with it until that discrepancy is sorted.

        Boot to a USB/ISO, run cfdisk, extend the partition size back to original or larger, then run fsck on the partition again.

        • @t0mriOP
          26•1 month ago

          😭😭😭🤧 THANKS!!

          im saved. My machines saved. Thanks a lot!!

          Whrt happened anyway? Why cfdisk didnt wipe the data? I thought it would everything after 32g, but all my data is un touched. What happened?

          • Dave.
            16•1 month ago

            The partition table is just a set of pointers to various places on the physical disk where partitions should be, inside those partitions are filesystems with all your data. It’s like the table of contents in a book. You can mess around with the table of contents and make the page numbers for chapters different, but all the words in the book are still there.

            Now you’re lucky that filesystem drivers are fairly smart these days. They sanity check things all the time. When you write the partition table to disk all the active filesystem drivers get notified of the changes, so they can keep track of things. When the driver noticed that the size of your filesystem exceeded the size of your partition, it basically was like “Hold it right there, I’m not touching any of this!”. At that point the filesystem would have been forcibly unmounted and disconnected, which is why none of your commands worked after running cfdisk, they were on that filesystem.

            Note that your approach was almost the right way to do it. To make your filesystem bigger you can expand the partition using cfdisk ( as long as there is physical room on the disk!) and then run a program called resize2fs , and it will expand the filesystem to suit.

            Similarly, you can shrink the filesystem in the same kind of way, except you run resize2fs first and command it to shrink the filesystem to a particular size. It will do that (assuming there’s enough free space in your filesystem to do so) then you shrink the corresponding partition with cfdisk to match.

            Of course, as you’ve learned, resizing partitions is moderately risky so backups are a good idea. Having said that I routinely expand filesystems in VMs like this without backups - I make the VMs disk larger in its settings, then run cfdisk and expand the partition, then run resize2fs.

            • @t0mriOP
              2•1 month ago

              I sincerely appreciate your consideration to help and explain

              Its funny that i tried resize partitions without knowing how to do that. I thought i should format new partitions after editing partition table coz thats what i did when installing linux, but im wrong again ig.

          • @kolorafa@lemmy.world
            9•1 month ago

            cfdisk only changes the partition table, this table like a small paper that you store at the front (or back) of drive where you put information, it’s just a list of coordinates like from this point to this point is your home, from this to this is your yard, from this to this is your neighbor. Just because you changed the values on your paper doesn’t actually make your neighbor closer or further.

            System read this list to figure out where are the “borders” between different sections that you defined to load and use them logically for multiple file systems.

          • @toni_bmw@lemmy.world
            5•1 month ago

            It’s a marvellous feeling, right?

            We thank Dave for his decisive contribution. For future occasions try to backup everything before doing operations of this type. This small script works very well for me:

            https://github.com/cleverwise/cya

            That allows you to backup even hot systems. Just mount an external disc in /home/cya and run the script with sudo…

      • @toni_bmw@lemmy.world
        3•1 month ago

        The existing file system appears to have been damaged possibly because cfdisk has not adjusted (shrinked) the existing file system before changing the partition settings. In my case, this kind of thing I only dare to do with gparted if partitions contain file systems with data.

        I would try the second option I mentioned above, as my last chance: to start a live-rescue and look that allows us to gparted, but I am not very optimistic about it

  • @30p87@feddit.de
    6•1 month ago

    Live boot and, if possible back up everything first. Everything as in the whole disk. So ``` dd if=/dev/nvme0n1 of=backup-disk

    • @t0mriOP
      3•1 month ago

      I dont think doing back up is possible. Coz i shrinked a 100g partition into 32g which had 84g of data. Is it possible?

      • @MartianSands@sh.itjust.works
        6•1 month ago

        What they’re suggesting is to back up the whole disk, rather than any single partition. Anything you do to the partition to try and recover it has the potential to make a rescuable situation hopeless. If you have a copy of the exact state of every single bit on the drive, then you can try and fix it safe in the knowledge that you can always get back to exactly where you are now if you make it worse

        • @MartianSands@sh.itjust.works
          3•1 month ago

          Also, it’s probably possible to fix the partition so that it’s as big as it used to be. It’s likely that some of your data is corrupted already, but the repartitioning won’t have erased the old data except here or there where it’s written things like new file tables in space it now considers unused

      • @colournoun@beehaw.org
        4•1 month ago

        Yes a back up is possible. Don’t back up partitions, back up the whole device. All 150+g at once.

        Whenever you try to mount the device or the filesystems, make sure to mount it read-only so that no changes are written to the device.

        Also, shrinking 84g of data into 32g is definitely not possible. Just changing the fdisk partition table doesn’t shrink or relocate the data. You need a filesystem-aware resizing tool to shrink the filesystem before shrinking the partition.

        Hopefully you can just change the partition table back to the original values and get a clean fsck.

    • oo1
      2•1 month ago

      clonezilla?
      does that still exist?

  • @hperrin@lemmy.world
    6•1 month ago

    The most important thing you should do is never boot into that disk again until you have made a full backup image of it.

  • @nialv7@lemmy.world
    0•1 month ago

    Looks like you messed up the partition table. Try scandisk, it may be able to find your partitions.

  • @Petter1@lemm.ee
    -3•1 month ago

    I’d boot on ArchISO, get all data I need to a external drive and install Arch from scratch, btw

    • @t0mriOP
      6•1 month ago

      So what should i do.

      1. Boot into arch iso
      2. Mount my disk and copy files
      3. And install arch

      But i wonder if the mounting part will work. Coz of the mess ive made. I just have to try it ig.

      • @Petter1@lemm.ee
        5•1 month ago

        I have shrunken a APFS partition (macOS) too much lately and was still able to mount it read only using Linux and back up all stuff I needed. But that depends on how corrupted this partition is now.

        Maybe you need something like Gparted live ISO in order to get to your data. Check out the Command Line Utilities on that webpage, maybe there is the savior of your data

        And about the arch installation, if you want easy mode, just type “archinstall” after ArchISO has booted and your PC is connected to the internet (phone connection via USB works to get internet connection)

      • @SturgiesYrFase
        2•1 month ago

        I believe in you. Just have the ArchWiki open. It’s really going to be your friend if you’ve not compiled Arch from scratch before.