[SOLVED] Can't boot after shrinking root (/) to expand /home

archiedummy · 2024-03-26 18:06:44

Hello, I tried few stuff, e.g
# mount -a
mount: /home: wrong fs type, bad option, bad superblock on /dev/nvme0n1p8, missing codepage or helper program, or other error

Was running out of space after downloading/launching/messing with android studio, it even shutdown my browser instance with all my opened tabs without my consent (RAM wasn't near maxed out). So I used the disk resizer and restarted but then it always get me on the black console view "You are in emergency mode. After logging in, type "journalctl -xb" to view blabla

Used vi to change the /etc/fstab file line regarding root folder from error stuff to "defaults" but it didn't solve the issue.

Was trying couple live USB sticks, kali 2020ish didn't work, kubuntu 20 did work but couldn't move the 60 gigs unallocated (coming from root partition) past the extreme right of home partition. So I re-burnt it to mint edge 6.X kernel, couldn't boot. Then LMDE debian latest, couldn't boot on it either. Now trying latest ubuntu just to try gparted instead of common disk resizer utility, but it won't finish downloading.

Any CLI I could try in the meantime?

Last edited by archiedummy (2024-05-19 00:19:59)

ua4000 · 2024-03-27 09:55:09

Hi,
without providing more infos, e.g. complete logs, exact program names which caused the issue, exact steps done with this so called "disk resizer", it will be difficult for us to get you any advise.

To be sure: you use Arch Linux ? How did you install it ? Partition layout, used filesystems... ?

Last edited by ua4000 (2024-03-27 13:33:05)

seth · 2024-03-27 13:30:11

I used the disk resizer and restarted

Online repartitioning would be suicide - my best guess from the error message is that the you changed the partition table but didn't resize the filesystems before?
In that case, recreating the *exact* previous partiition table should help you out - as long as you didn't write around on the repartitioned devices.

archiedummy · 2024-04-21 18:17:26

EDIT 6 : here are pictures of before/after the accident : https://imgur.com/a/B2vN5yq , I can't explain why it seems that 1.82 MiB after /home partition appeared out of nowhere... Can they correspond to the missing blocks?

Sorry for disappearing I was getting all the gear and knowledge both for disk copying and future machine/partition scheme. Even though it's most probably in my (vanished) notes, I didn't have setup btrfs on LUKS on LVM yet, otherwise this accident could have been avoided and I'd have been able to hot resize. Anyways it's out of subject.
I'm back to solve this by all means!

@ua4000 yes, from what gparted live lists on the disk clone I have plugged in : (it's a dual boot)
sda1 EFI fat32 260M, sda2 microsoft reserved 16M unknown, sda3 NTFS 200G, sda4 NTFS "WinRE_DRV" 1G,
sda5 boot fat32 512M, sda6 root ext4 39G, sda7 swap 37G, 60.94G unallocated, sda8 home ext4 99.5G,
1.38TB unallocated (this new SSD is 2TB capacity, I cloned the initial 500G capacity one on it)

(Note that gparted doesn't mention an explicit mountpoint for home and root, I just know it's these, back when it was sane it does displayed / and /home as mountpoints tho)
Edit2 : Also note that before any move, I didn't have an exclamation triangle sign on gparted listing, now on the clone I get two, one for sda8 (home), one near sda2 mysterious windows 16M partition, even though on the original drive I'm still able to boot windows...

Using ddrescue for a perfect cloning, then running as written on the arch wiki :
$ sudo fsck -f /dev/sda8
fsck from util-linux 2.39.3
e2fsck 1.47.0 (5-feb-2023)
The filesystem size (according to the superblock) is 26083327 blocks
The physical size of the device is 26083072 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? no
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda8: 218302/6520832 files (1.0% non-contiguous), 23986024/26083327 blocks

Should I go ahead and use other options for fsck ?

@seth I can't remember, either I used the KDE disk utility online while system was running (which I doubt it would have allowed me to do so), either I used a kubuntu live stick to do so, which had the same KDE desktop so I admit that I'm confused...

*Exact* meaning exact GiB values ? Or exact down to the block indexing stuff? I think I just tried to boot the corrupted drive couple times, I hope that since I never was able to boot after that, that I didn't write any extra bit to it... Is there any way to read the previous allocated sizes ?
Only thing I have is a picture on my phone of the initial Gparted detection before I resized anything : / was 100GiB, /home was 99.50 GiB

Edit1 : manually resized using Gparted back to root 100GiB, using the shrinked unallocated space that didn't made it up to /home. But, with the disk clone plugged in its USB enclosure (no drive on the motherboard), it still boots in emergency mode instead of giving me my desktop environment/window manager...
Edit3 : in this mode,
root@machine:~# ls
only lists snap/chromium and snap/cups folders...
Edit4 : in this mode,
root@machine:~# cd ../home && ls
lists nothing !! :'(
Edit5 : root@machine:/# ls mnt/
lists nothing...

edit7 : from gparted live,
# fsck -f /dev/sda1
There is no label in boot sector, but there is volume label 'SYSTEM' stored in root directory
1) Copy volume label from root directory to boot sector
2) Remove volume label from root directory
[12?q]? q

edit8 : tried to give additional 20G to sda8 with gparted GUI but it returned the same error : either superblock or partition table corrupt...

edit9 : https://unix.stackexchange.com/question … t-after-pa
# resize2fs -f /dev/sda8
resize2fs 1.47.0 (5-Feb-2023)
Resizing the filesystem on /dev/sda8 to 26083072 (4k) blocks.
resize2fs: Invalid argument while trying to resize /dev/sda8
Please run 'e2fsck -fy /dev/sda8' to fix the filesystem after the aborted resize operation.
# e2fsck -fy /dev/sda8
Either the superblock or the partition table is likely tobe corrupt!
Abort? yes
Does this mean I'm in "surgery territory" as they say?

Last edited by archiedummy (2024-04-21 20:49:31)

seth · 2024-04-21 21:18:29

The filesystem size (according to the superblock) is 26083327 blocks
The physical size of the device is 26083072 blocks

The partition is 255 blocks smaller than the filesystemd.

*Exact* meaning exact GiB values ? Or exact down to the block indexing stuff?

The latter - "1 GiB" is 262144 blocks - you'll need a lot of a lot of digits after the period to get that exact…

archiedummy · 2024-04-21 23:38:40

You're right, just searched 255*4 KiB = 0.0009727478 GiB = 0.9960937 MiB = 1020 KiB ... So Gparted GUI is out of action scope, am I right? (since it can manipulate integers down to MiB only)

I played a bit with this answer that uses fdisk : https://unix.stackexchange.com/a/566822 without luck. Entered the return key to press the default 2048 sector start and default value end, even though there were other choices. Does it seem the good route to try hard?

Also for some reason sda8 had dos partition table so I changed it to gpt, idk if it could have caused the result fail...

edit : tried to manually +1 MiB from gparted GUI but it won't apply changes without throwing the same error (superblock/partition table corrupt)

edit 2 : https://access.redhat.com/solutions/55010 didn't help in my case
# mount /dev/sda8 /mnt/media
mount: /mnt/media: wrong fs type, bad option, bad superblock on /dev/sda8, missing codepage or helper program, or other error. dmesg(1) may have more information after failed mount system call.
# dumpe2fs /dev/sda8 |grep "Block count"
Block count: 26083327
# lvs -ao +devices
it outputs nothing

edit 3 : tried 8th answer from https://ubuntuforums.org/showthread.php … st13401300
# mke2fs -S -b 4k -t ext4 -v /dev/sda8
fs_types for mke2fs.conf resolution: 'ext4'
/dev/sda8 contains a ext4 file system
last mounted on /home on Tue Mar 26 2024
Proceed anyway? y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=8191 blocks
6520832 inodes, 26083072 blocks
1304153 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2174746624
796 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Filesystem UUID: 6def9f..
Superblock backups stored on blocks : 32768, ..., 23887872
Allocating group tables: done
Found a gpt partition table in /dev/sda8
/dev/sda8 may be further corrupted by superblock rewrite
Proceed anyway? y
Skipping journal creation in superonly mode
Writing superblocks and filesystem accounting info: done
# mount /dev/sda8 /mnt/media
mount: /mnt/media: mount(2) system call failed: Structure needs cleaning.
# e2fsck -f -C 0 /dev/sda8
e2fsck: Inode checksum does not match inode while checking journal for /dev/sda8
e2fsck: Cannot proceed with file system check
/dev/sda8 : *** WARNING: Filesystem still has errors ***
(Note that I didn't make use of the extended option -E resize= ( https://www.man7.org/linux/man-pages/man8/mke2fs.8.html ), I don't know if I should have...)
Seems like I fucked up, redumping the drive clone1 (of the original drive) onto clone2 (on which I'm working so far) using ddrescue for the following of the thread.

edit 4 : tried the 14th (which solved that other thread) https://ubuntuforums.org/showthread.php … st13401815
# mke2fs -n /dev/sda8
# e2fsck -b 32768 /dev/sda8
I didn't abord and proceeded anyway (n), then spammed the 'y' key, cause I had a bunch of :
Free inodes count wrong for group #NNN. Fix<y>?
Rebooted to gparted live,
# fsck -a /dev/sda8
/dev/sda8: The filesystem size (according to the superblock) is 26083327 blocks
The physical size of the device is 26083072 blocks
Either the superblock of the partition table is likely to be corrupt!
/dev/sda8: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options)
# fsck /dev/sda8
(same error) Abort<y>? no
Pass 1:
...
Pass 5:
/dev/sda8: 218302/6520832 files (1.0% non-contiguous), 23986024/26083327 blocks
# mount /dev/sda8 /mnt/media
wrong fs type, bad option, bad superblock, or other error. dmesg(1) may have blabla

Last edited by archiedummy (2024-04-22 14:44:16)

seth · 2024-04-22 06:42:05

some reason sda8 had dos partition table so I changed it to gpt

sda8 is a partition and partitions are typically not supposed to hold partition tables themselves.

Testdisk can find and restore likely partition tables for you:
https://wiki.archlinux.org/title/File_r … d_PhotoRec

archiedummy · 2024-04-22 16:47:00

Used this : https://linuxconfig.org/how-to-recover- … e-in-linux
Stopped the Analyse at ~67% as the clone drive is 2TB instead of the original 500GB capacity, thinking it would have probed nothing but void from now on.

When trying booting on the clone drive, I do experience some new form of TTY : this time, I get "GNU GRUB version 2.06" as centered title, and
"Minimal BASH-like line editing is supported. [...]"
grub> ls
(proc) (memdisk) (hd0) (hd0,gpt2) (hd0, gpt1)

Should I stay in here, or boot a livestick and try mounting sda8 ? If latter, how to clean shutdown using a CLI from within that grub shell ?

edit : using https://askubuntu.com/questions/883992/ … mmand-line
grub> ls (hd0,gpt2)/
error: unknown filesystem.
grub> ls (hd0,gpt1)/
efi/ System Volume Information/
grub> boot
error: you need to load the kernel first.
grub> exit
(didn't work)
grub> set root=(hd0,gpt1)
grub> linux /vml
(tab completion finds nothing )
grub> insmod all_video
grub> insmod linux
grub> linux /boot/vmlinuz root=/dev/sda6
error: file `/boot/vmlinuz' not found.

edit 2 : exited and went to bios' boot options, placed USB HDD realtek on top of the OS. But now it boot loops : after OEM splash screen, there's written "Reset System" on top left corner...
edit 3 : relocated main OS on top of bios' boot options, tried the comment about exiting twice, still doesn't boot.

edit 4 : rebooted on the livestick, testdisk only left efi partition and the partition of interest (now called sda2 99.5G), that's why I wasn't able to boot.
# mount /dev/sda2 /mnt/media
mount.nilfs2: Error while mounting /dev/sda2 on /mnt/media: Invalid argument

What's strange is that gparted GUI now lists /dev/sda1 as name EFI, fs fat32, label SYSTEM -> all right,
then 347.38 GiB unallocated,
but /dev/sda2 still has an exclamation sign, no name, fs unknown, no label. Only size has value 99.50 GiB, no value for the "used" field, nor unused, nor flags field...

edit 5 : in contrast to /dev/sda1 (efi),
# blkid
/dev/sda2 only has a PARTUUID. No UUID, no LABEL, no BLOCK_SIZE, no TYPE, no PARTLABEL
# mkfs.ext4 /dev/sda2
Creating filesystem with 26083072 4k blocks and 6520832 inodes
Filesystem UUID : 53b9d...
Superblocks backups stored on...
Allocating group tables: done
Writing inode tables: done
Creating journal (131072 blocks): done
Writing superblocks and filesystem accounting information: done
# fsck /dev/sda2
/dev/sda2: clean, 11/6520832 files, 555792/26083072 blocks
# mkdir -p /mnt/tmp && mount -t ext4 /dev/sda2 /mnt/tmp
# cd /mnt/tmp
#ls
lost+found
There's nothing did I mess up something?!

Edit 6 : apparently nilfs2 partitions can be mounted : https://man.archlinux.org/man/core/nilf … ilfs2.8.en -> did I screw up by formatting to ext4 and have to start again (cloning and testdisk) ?

Edit 7 : I just remembered this thread I posted a month ago, after the accident : may be useful for more context, idk : https://ubuntuforums.org/showthread.php … st14184958

Last edited by archiedummy (2024-04-22 19:48:13)

seth · 2024-04-22 20:35:28

Did you do anything to the disk but writing the partition table?
Generall please don't follow some click-along tutorial here. Testdisk can find filesystems/partition patterns and recover them for you but you still have to pay attention what you're doing there and what you're restoring. The nilfs detection is most likely a false positive.

If you haven't written anything else to the disk, restoring the original partition table is still your best shot.
You (most likely) have the proper partition size in blocks reported by fsck - use that w/ fdisk if testdisk fails to accurately detect the partition layout - it is a tool, not a magical fix.

Edit: if it's the relevant system/disk then there's a complete partition table recorded in https://ubuntuforums.org/showthread.php … st14184978

Last edited by seth (2024-04-22 20:37:08)

archiedummy · 2024-04-22 22:11:37

I'm not sure, I tried to write everything I did through all the edits I appended to my posts (sorry for the overwhelming amount, I really care about my data and rather prefer the recovery process to be fully transparent than hiding dumb steps I could have done)

You're right, in the meantime I found a more complete tutorial in the docs of the program itself : https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step
From there I let quick detection fully complete till 100%. Final results were quite not on track with the tutorial though, as I didn't have any duplicate or missing stuff (I recorded a brief video of me exploring the outcomes). Outcome was listing
P EFI System
D MS Data
D MS Data
D Linux filesys. data (size in sectors 208666616), which, upon hitting P (to list files), displayed No file found, filesystem may be damaged.
D Linux filesys. data (size in sectors 12400 only), which, upon hitting P (to list files), only had etc, javalib, priv-app, apex_manifest.pb
So I pressed q to get back to the list, and from there, as there was nothing to get further back, I naively pressed escape.

It brought me back to the main screen (kinda partition selection), but from there I had access to the buttons Type/Superblock (lists nothing)/List/Image Creation/Quit.
LIST button over the 8th line (start 729034752, end 937699327, size 208664576) DOES LET ME ACCESS the me (=user) directory !! With its childs .bashrc , .local (all my custom scripts), Desktop, Documents, my repository packages where I store my sourcecodes, .git, and so on !!!

From this point what should I do ? Currently keeping alive the console running testdisk on the live iso that spins into RAM. Only the SSD USB enclosure is connected. Interactive prompt allows me to press a to select all files, C to copy the selected files. But since it's an ISO living in RAM, I guess it's read only. Can I plug a thumbdrive and manage to get testdisk copying on it ??? Or will I have to relaunch testdisk and the quicksearch ?!

Yes the ubuntuforums link lists some commands I applied to the clone drive I'm working on can I do something from these values?

Edit ; if I dare go getting few hours of sleep,
- is it wise to let the SSD enclosure and its pricy 2TB SSD plugged into the system alive (in my experience live gparted never suspends), risking to fry SSD and/or not get reproducible quicksearch results from testdisk ?
- or is it 100% reproducible and I can quit and unplug enclosure ? (I don't have 100G thumbdrive on hands yet anyway to proceed to the rescue :$)

Last edited by archiedummy (2024-05-16 14:39:31)

seth · 2024-04-22 22:38:28

LIST button over the 8th ligne (start 729034752, end 937699327, size 208664576) DOES LET ME ACCESS the me (=user) directory !! With its childs .bashrc , .local (all my custom scripts), Desktop, Documents, my repository packages where I store my sourcecodes, .git, and so on !!!

Which is in line with

/dev/sdd8 729034752 937699327 208664576 99.5G Linux filesystem

from your ubuntu threa, but looking at that, it's actually the same situation, you just registered here for more attention? So the partition table in that thread is actually the corrupted one?
An also a lot of the information that was "generated" here had actually long existed over there?

archiedummy · 2024-04-22 22:50:58

Yes, apologies, maybe I saw that nobody from the ubuntu community was eager to solve my issue.
I guess these values are for the currently corrupted one yes, I typed these commands after the accident, at this time I was already unable to boot to my OS.

Now the more I dig into the files, the more I see red filenames / file lines, does this mean these are files longtime deleted (by me), or files that are currently corrupted and need to be retrieved from the testdisk prompt asap ?

So first step is to make a copy from the testdisk prompt, and then is there a hope to bring back the OS to its working state ?
I'd prefer not having to go through an arch install from scratch again, also I wasn't able to find a YT tutorial to set up btrfs on (LUKS on) two LVs (one for @ and all its subs @var @tmp @qemu stuff etc., and one for @home) with snapper properly integrated for my dailydriver renovation yet..

edit : ok so according to this https://www.howtogeek.com/700310/how-to … -testdisk/ I'm screwed up as I fired up :
# testdisk
off of the live iso living in RAM, instead of off from some mounted drive, to be able to paste on it, right ?
Is there some .map or stuff I should save to RAM regarding the quicksearch, before leaving testdisk to relaunch it off of a proper location?

edit2 : nevermind I'll mount the stick when I have it on hands from a 2nd terminal and check whether testdisk probed the new stick presence, no need to answer anymore (except maybe about system restoration, i.e should I use write testdisk's button after I managed to backup files), I'll keep you all updated, thank you @Seth !

Last edited by archiedummy (2024-04-22 23:51:36)

seth · 2024-04-23 07:31:02

go through an arch install from scratch again

But:

ubuntu thread wrote:

I do still have the grub screen with ubuntu and windows choice, but when proceeding to default (ubuntu) I land on a black console screen. I can still boot on windows

I wasn't able to find a YT tutorial to set up btrfs on (LUKS on) two LVs (one for @ and all its subs @var @tmp @qemu stuff etc., and one for @home)

Don't blindly follow youtube tutorials for crying out loud.

ubuntu thread wrote:

I was running out of space in /home, so I fired up gparted to shrink /root (on the left side of /home on the physical drive),
moved the allocated space up to the right of home, expand.
I clicked the tick icon to proceed to operations, but somehow when coming back I was left with /root shrinked to 40G (ok),
but : unallocated 60G on left side of /home, and unallocated 1.86 MiB on right side of /home (which I believe weren't there beforehand, not sure tho

Status quo post:

Disk /dev/sdd: 1.82 TiB (this is a clone of the original 500GB corrupted disk, used clonezilla to clone the most part, then dd on corrupted partition as it was flagged with exclamation sign on gparted GUI, after using dd it was appearing without the sign, as when I plugged the og 500GB disk and looked at it with gparted GUI)
2000398934016 bytes, 3907029169 sectors
Disk model: PCIe
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
IO size (minimum/optimal): 4096/4096 bytes
Disklabel type : gpt
Disk identifier: 44EB1DBE-...

Device Start End Sectors Size Type
/dev/sdd1  2048       534527     532480     260M    EFI System      
/dev/sdd2  534528     567295     32768      16M     Microsoft reserved    
/dev/sdd3  567296     438628351  438061056  208.9G  Microsoft  basic data
/dev/sdd4  438628352  440676351  2048000                                   
/dev/sdd5  440676352  441724926  1048575    512M    EFI System      
/dev/sdd6  441724928  523644927  81920000   39.1G   Linux filesystem  
/dev/sdd7  523644928  601237503  77592576   37G     swap                   
/dev/sdd8  729034752  937699327  208664576  99.5G   Linux filesystem

Did you post this anywhere?

ubuntu thread wrote:

also I found a picture of the gparted display right BEFORE the accident happened, / was weighing 100.00 GiB with 26.18 GiB used, /home was 99.50 GiB with 91.55 GiB used

From the explanations and symptoms you managed to shorten the /home partition which was at the tail of the disk by 255 blocks - just regrow that.
You also managed to add a second EFI system, which is a abig nono.
Then there's a 1000M gap at sdd4 and 37GB swap after the 39.1GB sdd6 - but that still doesn't add up (sdd4+5+6+7) to the claimed 100GB root partition.

This was not a good idea:

sudo e2fsck -B 4096 -f -y -v /dev/loop1

I'm screwed up as I fired up :
# testdisk
off of the live iso living in RAM, instead of off from some mounted drive, to be able to paste on it, right ?

What?
It does absolutely not matter where you run testdisk from, you just need some location (mounted filesystem on nonvolatime memory) to restore files to.

Do you still have the master, ie. the disk you originally fucked up, w/o any efforts to fix it?
Clone that again and post the image reflecting the status quo ante and stop flailing around.

archiedummy · 2024-04-25 22:42:51

But:

(I thought that since ubuntu is backed up by canonical, their forum employees wouldn't bother helping people who aren't using their distro)

I wasn't able to find a YT tutorial to set up btrfs on (LUKS on) two LVs (one for @ and all its subs @var @tmp @qemu stuff etc., and one for @home)

Good mentality lol I agree, I just can't play with VMs at the moment, so I watch those who had already

Did you post this anywhere?

Yes here is the link of the pictures https://imgur.com/a/B2vN5yq

255 blocks - just regrow that.

Is there a cli to deal with blocks ? All I was thinking about was gparted GUI which can only deal with as little as 1 MiB, those 255 blocks are inferior to 1 MiB unfortunately

You also managed to add a second EFI system, which is a abig nono

Thank you, how to tell which one to delete ? Can I delete the wrong one safely ? No checks to ensure before doing so?

that still doesn't add up

Nice observation, there's indeed 60.94 GiB unallocated between sdc7 and sdc8 (freed from root, I wanted to get them onto home but somehow gparted didn't succeed in making it to the end...)

It does absolutely not matter where you run testdisk from, you just need some location (mounted filesystem on nonvolatime memory) to restore files to.

Thanks! (I'm currently copying testdisk findings on /home/user to a drive btw 2086 fails out of 205k "ok" atm. I don't know which controller freezes but it takes like forever (hours) to move 100GiB on a USB3.0 stick, the file counter often stops for a while, I wonder if it's testdisk related or hardware related, anyway i just cross my fingers) Ok I think it's actually the stick. Dove into its reviews and it's 1MB/s only when it comes to 4k writes, so 100G/0.001=100k seconds/3600= it should finish in 28 hours fuck my life I should have gone with an m.2 )

Do you still have the master

Yes, sorry for the wait but I'll have to let testdisk copy over,
will edit this post with
# fdisk -l
as soon as it's done!

seth · 2024-04-25 23:51:26

Is there a cli to deal with blocks ?

Using the correct sector counts w/ fdisk or cfdisk should do.

Thank you, how to tell which one to delete

It's already on the picture from before the change, so I'd ignore that for now.

Nice observation, there's indeed 60.94 GiB unallocated between sdc7 and sdc8 (freed from root, I wanted to get them onto home but somehow gparted didn't succeed in making it to the end...)

Ah, you shortened the root partition and moved the swap - have you ever activated that swap on the master?

Right now it looks like p8 partition is at the proper location (otherwise you'd not even get the fsck warning) but just too short and expanding it to the end of the disk should suffice.
If you've never activated the new swap partition you may also be able to restore the former root partition.

What has likely happened is that you tried to repartition the drive while some FS were mounted, what's not possible (w/ ext4) and what we recently figured the KDE partitioning tool will not prevent your from doing.
So resizing the filesystems failed, moving the partitions failed and you somehow ended up with a badly restored p8 (too short)

archiedummy · 2024-05-07 18:25:01

Back at it,

fdisk should do.

working on the slave drive / master drive clone, from gparted livestick,
# fdisk /dev/sda8
The device contains 'ext4' signature and it will be removed by a write command.
Device does not contain a recognized partition table.
Created a new DOS (MBR) disklabel with disk identifier 0x6f...

From there, I just wanted to somehow input +255 sectors, as in here https://www.redhat.com/sysadmin/partitions-fdisk . However this guy is creating a partition, whereas I just want to resize the boundaries. I guess using `n` would delete p8 content ? So I looked elsewhere..this french webpage https://doc.ubuntu-fr.org/fdisk#reparer … partitions advertises that entering expert mode with `x`, there would be some `z` command (resize a partition and its file system). However I don't have this option :

Command (m for help): x
Expert command (m for help): m
DOS (MBR)
b move beginning of data in a partition
F fix partitions C/H/S values
i change the disk identifier
Geometry (for the current label)
c change number of cylinders
h change number of heads
s change number of sectors/track
Generic
p print the partition table
v vertify the table
d print the raw data of the first sector
D of the last sector
f fix partitions order
m print this menu
Save & Exit
q quit without saving
r return to main menu

Expert command (m for help): s
Number of sectors (1-63, default 63): (enter)

Expert command (m for help): c
Number of cylinders (1-1048576, default 12988): (enter)

Expert command (m for help): h
Number of heads (1-255, default 255): (enter)

Expert command (m for help): F
Nothing to do. C/H/S values are correct already.

So I don't know how I could input grow it from 255 blocks...

[EFI] It's already on the picture from before the change, so I'd ignore that for now.

Wise decision, I agree, thanks

Ah, you shortened the root partition and moved the swap

Yes I don't remember but I believe I had to, gparted needs donor and receiver partitions to be near each other with only unallocated space in between. Does this teach me for future installs to always create swap at the very end ? (first efi, then root, then home, then swap?)

have you ever activated that swap on the master?

I don't think so (not sure tho), as I never was able to boot the corrupted drive after that. I assume swap only activates if I were to boot again, and exceed RAM capabilities / asking for hibernation.

What has likely happened is that you tried to repartition the drive while some FS were mounted, what's not possible (w/ ext4) and what we recently figured the KDE partitioning tool will not prevent your from doing.
So resizing the filesystems failed, moving the partitions failed and you somehow ended up with a badly restored p8 (too short)

Dang I didn't know there was a flaw After I read your message I removed KDE partition manager from the potential successor KDE install (in case I fail to restore this system) and replaced it with gnome gparted. This convinced me too https://www.reddit.com/r/kde/comments/n … stable_as/ , it says gparted is more battle tested. However I figured out it still integrates very poorly within KDE desktop (in terms of theme) : somehow the whole ribon of action icons appears white on white, so a connoisseur would have to click blindly, but a newbie would be lost I guess. Anyway that's not the point of this thread.

archiedummy · 2024-05-07 18:47:16

As for

Do you still have the master, ie. the disk you originally fucked up, w/o any efforts to fix it?

From gparted livestick loaded in RAM, on master drive
# fdisk -l
Disk /dev/loop0: 460.37 MiB, 482734080 bytes, 942840 sectors
sectors of 512 bytes

Disk /dev/sda: 447.13 GiB, 480103981056 bytes, 937703088 sectors
sectors of 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 44E...

Device Start End Sectors Size Type
/dev/sda1 2 048 534 527 532 480 260M EFI System
/dev/sda2 534 528 567 295 32 768 16M Microsoft reserved
/dev/sda3 567 296 438 628 351 438 061 056 208.9G Micrsoft basic data
/dev/sda4 438 628 352 440 676 351 2 048 000 1000M Windows recovery environment
/dev/sda5 440 676 352 441 724 926 1 048 575 512M EFI System
/dev/sda6 441 724 928 523 644 927 81 920 000 39.1G Linux filesystem
/dev/sda7 523 644 928 601 237 503 77 592 576 37G Linux swap
/dev/sda8 729 034 752 937 699 327 208 664 576 99.5G Linux filesystem

-----
edit : I then unplugged master drive to store it safely, and am now working back on a drive clone. I didn't manage to grow the clone from 255 blocks using fdisk or parted CLI. Upon trying cfdisk prompt as you recommended,
# cfdisk /dev/sda8
Device already contains a ext4 signature; it will be removed by a write command. Press a key to continue.
Device does not contain a recognized partition table. Select a type (among gpt, dos, sgi, sun. I choose gpt)
Disk: /dev/sda8
Size: 99.5 GiB, 106 836 262 912 bytes, 208 664 576 sectors
Label: gpt, identifier: B8E...
Device Start End Sectors Size Type
Free space 2048 208 664 542 208 662 495 99.5G
-> I choose [New]
-> I input 208664576 S (can be followed by M for MiB, G, T, or S for sectors)
But it doesn't apply and displays in red : "Maximum size is 106 835 197 440 bytes."

edit2 : what's super strange is that using # fdisk -l , with the clone attached, I get the exact same layout as with when I checked master drive. Same ends and same sector numbers. But you'll notice that the 208 664 576 sectors value from the fdisk command is different from the 208 662 495 sectors from cfdisk.....

edit3 : upon agreeing on the default 99.5G value, it proceeds and now lists /dev/sda8p1 as type Linux filesystem, start 2048, end 208 662 527, sectors 208 660 480. <- Yet again a third different value
I do am able to resize it now. I have to input New Size (default is 99.5G still). It accepts only MiB/GiB/TiB/Sectors.
Thanks to the error above, I know that 99.5G eqv 106 835 197 440 bytes. I want to add 255 blocks. *4096 bytes = wanna add 1 044 480 bytes. 1 sector being 512 bytes, I wanna add 1044480/512=2040 S. So I can add 2040 S to either one of the three above reported sector values. In doubt, I choose the highest to get me the largest boundaries over the territory to recover. 2040 + 208 664 576 = 208 666 616 S.
Still get the error : "Maximum size is 106 834 165 760 bytes." ...

edit4 : in comparison to querying fdisk -l on master drive, doing it on drive clone (which is 2TB capacity instead of 500G), throws me a red line :
"GPT PMBR size mismatch (937703087 != 3907029167) will be corrected by write.
The backup GPT table is not on the end of the device."
I guess it's not important, but just in case some end table might be useful in this issue, I note it there.

Last edited by archiedummy (2024-05-07 21:09:51)

seth · 2024-05-07 21:02:57

From gparted livestick loaded in RAM

I asked that because it's likely a good idea to make a fresh copy of that and operate on that copy - not the one you've already fumbled around with.

In fdisk just delete the last partition (sda8) and create a new (sda8) partition that covers the entire free space to the end of the drive (there're currently 3761 unused sectors at the end)
You can also use cfdisk if you're mor comfortable w/ that.

archiedummy · 2024-05-07 21:37:06

In fdisk just delete the last partition (sda8) and create a new (sda8) partition that covers the entire free space to the end of the drive (there're currently 3761 unused sectors at the end)
You can also use cfdisk if you're more comfortable w/ that.

# cfdisk /dev/sda8
can only create new partition on the detected "free space" 99.5G partition, it can't delete nothing, so it's out of my options.
# fdisk /dev/sda8
d
No partition is defined yet! (in red)
n
partition number : 8
first sector : 2048
last sector (2048-208664542, default 208 662527) : 208 664 542
(since I cannot input 208 666 616 (= 208 664 576 + 2040))
w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Invalid argument (in red)
The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe

# partprobe
# fdisk -l
still list 208 664 576 sectors for sda8...
# reboot
I can reach the grub ...... distro logo ...... black screen ......... mouse pointer o-o ...... LOGIN PAGE o-o I type my credentials ....... but it takes incredible amount of time to check the password (like 3 real minutes), and ends up not letting me access my desktop, despite the pw being the right one. After the 3 minutes it goes black screen and brings me back on the login page, without the usual highlighted dots if password was mistyped... What could explain this behavior ?

Edit : I think I know, root is ok so it can boots without issue, but home is screwed up so it won't let me land on my desktop. What's strange then is that master drive couldn't even manage to boot...

(In the meantime I'm following your advice of re-dumping spare fresh 1TB clone of 500G master, onto the 2TB clone2 I'm working on.)

Last edited by archiedummy (2024-05-07 21:43:26)

seth · 2024-05-07 21:41:23

"cfdisk /dev/sda", NOT "cfdisk /dev/sda8"

archiedummy · 2024-05-07 23:43:14

thanks, I re-dumped clone1 onto clone2. working with clone2,
# fdisk -l
GPT PMBR size mismatch (937703087 != 3907029167) willl be corrected by write. The backup GPT table is not on the end of the device.
Disk /dev/sda: 1.82 TiB, 2 000 398 934 016 bytes, 3 907 029 168 sectors
Sectors of 512 bytes
I/O size (minimum/optimal): 512 / 33 553 920 bytes
Disklabel type: gpt
Disk identifier: 44E...
/dev/sda8 start 729 034 752, end 937 699 327, sectors 208 664 576, size 99.5G, type Linux filesystem

# fdisk /dev/sda8
d
No partition is defined yet! (in red)
n
primary
Partition number (1-4, default 1): ^C (i quit, as there's no 8 option)
extended
Partition number (1-4, default 1): ^C (i quit, as there's no 8 option)
n
primary
Partition number (1-4, default 1): i choose 3
2048
Last sector (2048-208 664 575, default 208 664 575) : enter
Created a new partition 3 of type 'Linux' and of size 99.5 GiB.
w
# partprobe
# reboot
grub, distro splashscreen, black screen, mouse pointer, login screen, again a hell of a long time to check the password, and brings me back to login screen endlessly
Tried using the KDE virtual keyboard even, doesn't solve the problem...

Am I screwed up at this point?

seth · 2024-05-08 07:04:54

You're still operating on the wrong device.
Don't try to use fdisk/cfdisk on the partition (sda8) but the drive (sda)!

archiedummy · 2024-05-08 11:46:38

You're still operating on the wrong device.

In the sense block device because I was targeting partition instead of disk, or you mean the wrong physical drive/pcb ?

redumped,
$ sudo su
# fdisk /dev/sdc
m
p
208 664 576 sectors for sdc8 Linux filesystem
d
partition number : 8
p
n
Partition number : 8
Last sector (601 237 504 - 3 907 029 134) : 208 666 616
Value out of range. (in red)
Last sector (601 237 504 - 3 907 029 134) : +208 666 616
Created a new partition 8 of type 'Linux filesystem' and of size 99.5 GiB.
Partition #8 contains a ext4 signature. (in red)
Do you want to remove the signature ? : No
w
Altered, syncing disks.
# reboot
grub, black screen....... TTY back to after the accident :
"You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.
Press enter for maintenance (or press Control-D to continue):
[10....] Bluetooth hci0: command 0xfc09 tx timeout
[13...] ucsi_acpi USBC000:00: con1: failed to register alternate modes
[18...] Bluetooth: hci0: Failed to send firmware data (-110)
[18...] ucsi_acpi USBC000:00: con2: failed to register alt modes
[23...] ucsi_acpi USBC000:00: con2: failed to register alternate modes
"

pressing enter key then typing exit brings me back to TTY endlessly

Should I have removed the ext4 signature stuff?

Last edited by archiedummy (2024-05-08 11:52:50)

seth · 2024-05-08 12:40:22

Should I have removed the ext4 signature stuff?

NO!

"+208 666 616" why don't you just go w/ the default value (which should be the end of the drive)?

archiedummy · 2024-05-08 13:23:17

I don't know, you suggested regrowing the last partition from 255 blocks, due to the errors that were thrown about superblocks and stuff. According to my calculus it's equal to 2040 sectors. I thought getting the system exactly how it was before the accident would allow me to restore it.

(Trying default ending rn, will report the outcome here asap)

edit :
rewrote clone2
# fdisk /dev/sdc
p
d
8
n
8
Last sector (default 3 907 028 991) : enter
Do you want to remove the signature? N
w
partition table altered, syncing disks
# reboot
grub, brieve distro logo, TTY emergency mode

edit2 :
rebooted on gparted stick
# fdisk /dev/sda
d8
n8
last sector: +208 666 616
Do you want to remove ext4 signatuer? Yes this time
w
#reboot
grub, distro logo, login screen, checks for forever and brings me back on login screen, as if pw was wrong despite it being the right one

Is the next step trying to somehow offload my userhome testdisk backup stick onto a new home partition living on diskclone, and try booting, since root partition seems ok ? Or am I missing on steps that can still be tried ?

Last edited by archiedummy (2024-05-08 13:41:53)

Arch Linux

#1 2024-03-26 18:06:44

[SOLVED] Can't boot after shrinking root (/) to expand /home

#2 2024-03-27 09:55:09

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#3 2024-03-27 13:30:11

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#4 2024-04-21 18:17:26

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#5 2024-04-21 21:18:29

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#6 2024-04-21 23:38:40

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#7 2024-04-22 06:42:05

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#8 2024-04-22 16:47:00

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#9 2024-04-22 20:35:28

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#10 2024-04-22 22:11:37

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#11 2024-04-22 22:38:28

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#12 2024-04-22 22:50:58

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#13 2024-04-23 07:31:02

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#14 2024-04-25 22:42:51

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#15 2024-04-25 23:51:26

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#16 2024-05-07 18:25:01

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#17 2024-05-07 18:47:16

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#18 2024-05-07 21:02:57

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#19 2024-05-07 21:37:06

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#20 2024-05-07 21:41:23

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#21 2024-05-07 23:43:14

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#22 2024-05-08 07:04:54

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#23 2024-05-08 11:46:38

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#24 2024-05-08 12:40:22

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

#25 2024-05-08 13:23:17

Re: [SOLVED] Can't boot after shrinking root (/) to expand /home

Board footer