You are not logged in.
Pages: 1
I was an idiot messing with gparted. I wanted to increase the size of my boot partition because upgrading the kernel to 5.7.10 said I didn't have enough space. I should have done this on the livecd, not in arch itself. I unmounted my boot partition, forgot to mount it again and then ran pacman -Syu. Turned my pc off, went to bed and didn't think about it. I booted it up today, and it refused to boot saying "unable to mount /boot". After researching I'm sure it's because of my oopsy and the kernel versions not matching with my pacman version of linux.
Looking into the systemctl logs I found this line
mount: /boot: unknown filesystem type 'vfat'.
Here's what I attempted: I booted to a gparted live USB and properly did the resizing. Booted into the arch iso, made sure the partitions are right with fdisk -l
(Please be patient with me I'm having an awful day right now and ssh is refusing to work so I'm typing these out by hand)
Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Seagate BarraCud
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1E8748D5-4144-4616-A34D-C5978205D224
Device Start End Sectors Size Type
/dev/sda1 2048 1023999 1021952 499M Windows recovery environment
/dev/sda2 1024000 2277375 1253376 612M EFI System
/dev/sda3 2277376 2310143 32768 16M Microsoft reserved
/dev/sda4 2310144 208707583 206397440 98.4G Microsoft basic data
/dev/sda5 975622144 976773119 1150976 562M Windows recovery environment
/dev/sda6 831043894 975620632 144576739 68.9G Linux filesystem
/dev/sda7 208707584 271622143 62914560 30G Linux filesystem
/dev/sda8 271622144 831043893 559421750 266.8G Linux filesystem
Partition table entries are not in disk order
My sda6 is my Manjaro partition, since I'm not completely done distroswapping here
My sda7 is my home partition
My sda8 is my root partition
I mounted my root, home, and boot partitions
Since it all looked good to me, I tried reinstalling the latest linux kernel with pacman -S linux linux-headers while chrooted. It does it's thing but ultimate fails at the
Creating gzip-compressed initcpio image: bootnitramfs-linux.fallback.img
with an error
gzip: stdout: No space left on device
Confused, I ran df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda7 30G 13G 16G 46% /
/dev/sda8 262G 19G 230G 8% /home
udev 3.9G 0 3.9G 0% /dev
shm 3.9G 0 3.9G 0% /dev/shm
run 3.9G 109M 3.8G 3% /run
tmp 3.9G 0 3.9G 0% /tmp
/dev/sda2 96M 96M 0 100% /boot
It's still showing 96M (Which I assumed rounded up to 100M previously) When fdisk shows the partition having 612M previously. I've tried unmounting and remounting and nothing. I'm not that new to Linux, but doing stuff manually like this I'm still learning. I'm just so confused and agitated rn and I just wanna boot back into arch again. Am I approaching this wrong or is this something I messed up?
Thank you for your help.
Last edited by krosis (2020-07-25 02:46:19)
Offline
My "shot in the dark":
You might have resized the partition itself, but not the filesystem in it.
Make sure it's unmounted:
umount /dev/sda2
I'm not sure that archiso comes with it, but you need to have the package "fatresize" installed. It's in the community repo.
Run:
fatresize -s max /dev/sda2
Mount /dev/sda2 and do df -h again to check the filesystem size.
Maybe that will do it?
Offline
I had no idea I would need to resize the filing system. It makes sense. I installed the package and ran it and got an error:
# fatresize -s max /dev/sda2
Error: /dev/sda2 is not valid FAT16/FAT32 partition.
I did unmount beforehand
Last edited by krosis (2020-07-25 02:05:10)
Offline
What? Is /boot your ESP? What is your bootloader? What did you do to your /boot partition?
If you have access to another os, flash archiso to an USB and then we can start fixing what happened, or if you have one, boot into archiso...it will be much better if you can get your outputs to ix.io as the wiki shows...
And be sure to have a backup hard drive in the case you need to backup something.
Also, this whole partition scheme is just asking for trouble...
You seem to be using another os? What is your computer current state? If you can boot into an archiso you can fix the kernel difference, but first you need to fix the issue with the partition.
If you are in archiso run ‘fsck.vfat’ on your ESP, lets hope you haven’t nuked it...
Yep, nuked it is...follow the instructions that @Thiago H gave you.
Last edited by GaKu999 (2020-07-25 02:18:16)
Offline
It's saying something is definitely wrong with /dev/sda2.
Something might have gone wrong while you were resizing and it doesn't recognize a FAT32 filesystem anymore.
At this point, I'd simply reformat the partition from the live iso.
If you can mount it, mount it and backup your /boot.
Then format /dev/sda2:
mkfs.vfat -F32 /dev/sda2
Then remount it and restore from backup. Check the filesystem size at this point with df -h.
If it looks good, chroot (make sure the / partition is mounted into /mnt and /dev/sda2 is mounted into /mnt/boot, before you chroot).
Triple-check your /etc/fstab from inside the chroot - the partition UUID will need to be updated if it's being used.
Finally, use pacman to reinstall the kernel, the microcode, and grub, and re-run:
mkinicpio -P
grub-install <get your parameters from the wiki for this one>
grub-mkconfig -o /boot/grub/grub.cfg
If we didn't forget anything, it should be bootable at this point.
Offline
I'm very happy to say that your solution worked perfectly. I followed everything to the letter and I was so happy to see lightdm on my screen. Windows and Manjaro also boot just fine thankfully. I can't thank you enough!
Offline
YAY! Thank you for the feedback and I'm glad we could sort this out.
Also thanks to @GaKu999 for stepping in to assist
Offline
Pages: 1