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?

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 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 !!!

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-04-22 22:28:16)

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)

Arch Linux

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Board footer