Creating new and bigger /boot partition

Support
,
21

Holy crap, i didnt know that BIOS/GPT isnt even possible… atleast for Windows its not, so for Linux that it works is pretty new info for me, thanks.

It worked and i just installed Kernel 6.6 (logs):

The following packages will be installed:

linux66

linux66-nvidia

Starting

resolving dependencies...

looking for conflicting packages...

Packages (2) linux66-6.6.16-2 linux66-nvidia-545.29.06-36

Total Installed Size: 187,87 MiB

:: Proceed with installation? [Y/n]

checking keyring...

checking package integrity...

loading package files...

checking for file conflicts...

checking available disk space...

:: Processing package changes...

installing linux66...

Optional dependencies for linux66

wireless-regdb: to set the correct wireless channels of your country [installed]

installing linux66-nvidia...

:: Running post-transaction hooks...

(1/5) Arming ConditionNeedsUpdate...

(2/5) Updating module dependencies...

(3/5) Updating linux initcpios...

==> Building image from preset: /etc/mkinitcpio.d/linux66.preset: 'default'

==> Using default configuration file: '/etc/mkinitcpio.conf'

-> -k /boot/vmlinuz-6.6-x86_64 -g /boot/initramfs-6.6-x86_64.img --microcode /boot/intel-ucode.img

==> Starting build: '6.6.16-2-MANJARO'

-> Running build hook: [base]

-> Running build hook: [udev]

-> Running build hook: [autodetect]

-> Running build hook: [modconf]

-> Running build hook: [kms]

-> Running build hook: [keyboard]

==> WARNING: Possibly missing firmware for module: 'xhci_pci'

-> Running build hook: [keymap]

-> Running build hook: [block]

-> Running build hook: [filesystems]

-> Running build hook: [fsck]

==> Generating module dependencies

==> Creating gzip-compressed initcpio image: '/boot/initramfs-6.6-x86_64.img'

==> Image generation successful

==> Building image from preset: /etc/mkinitcpio.d/linux66.preset: 'fallback'

==> Using default configuration file: '/etc/mkinitcpio.conf'

-> -k /boot/vmlinuz-6.6-x86_64 -g /boot/initramfs-6.6-x86_64-fallback.img -S autodetect --microcode /boot/intel-ucode.img

==> Starting build: '6.6.16-2-MANJARO'

-> Running build hook: [base]

-> Running build hook: [udev]

-> Running build hook: [modconf]

-> Running build hook: [kms]

==> WARNING: Possibly missing firmware for module: 'ast'

-> Running build hook: [keyboard]

==> WARNING: Possibly missing firmware for module: 'xhci_pci'

-> Running build hook: [keymap]

-> Running build hook: [block]

==> WARNING: Possibly missing firmware for module: 'qed'

==> WARNING: Possibly missing firmware for module: 'qla2xxx'

==> WARNING: Possibly missing firmware for module: 'qla1280'

==> WARNING: Possibly missing firmware for module: 'bfa'

-> Running build hook: [filesystems]

-> Running build hook: [fsck]

==> Generating module dependencies

==> Creating gzip-compressed initcpio image: '/boot/initramfs-6.6-x86_64-fallback.img'

==> Image generation successful

(4/5) Updating Kernel initcpios for Nvidia-DRM...

(5/5) Updating Grub-Bootmenu

Generating grub configuration file ...

Found theme: /usr/share/grub/themes/manjaro/theme.txt

Found linux image: /boot/vmlinuz-6.6-x86_64

Found initrd image: /boot/intel-ucode.img /boot/initramfs-6.6-x86_64.img

Found initrd fallback image: /boot/initramfs-6.6-x86_64-fallback.img

Found linux image: /boot/vmlinuz-6.1-x86_64

Found initrd image: /boot/intel-ucode.img /boot/initramfs-6.1-x86_64.img

Found initrd fallback image: /boot/initramfs-6.1-x86_64-fallback.img

Warning: os-prober will not be executed to detect other bootable partitions.

Systems on them will not be added to the GRUB boot configuration.

Check GRUB_DISABLE_OS_PROBER documentation entry.

Found memtest86+ image: /boot/memtest86+/memtest.bin

done

Done ...

Finally no abort message because of not enough space. You see 187MB, as i said.

Now i could delete the /boot Partition?

EDIT: Problem, after restart the new Kernel 6.6 wasn’t running, I was checking Manjaro Settings manager and it still told me its installed but 6.1 is running and 6.6 only installed.

I restarted again and openend Grub and under Advanced option, i only see 6.1 Kernel x2 duplicated.

Something is wrong :frowning:

22

You should be able to. I would keep your backup of the boot partition around until you’ve deleted the old boot partition and rebooted the system successfully, just in case. And if you haven’t already, check your running kernel version with uname -r after the reboot to verify your actually running the new kernel.

23 
$ uname -r
6.1.77-2-MANJARO

@Nachlese
I restarted several times now and it doesn’t made a difference if i decided to choose the upper or lower 6.1 entry… still 6.1 running and 6.6 is ignored :face_with_thermometer:

boot]$ ls
grub                               initramfs-6.6-x86_64-fallback.img  linux61-x86_64.kver  memtest86+
initramfs-6.1-x86_64-fallback.img  initramfs-6.6-x86_64.img           linux66-x86_64.kver  vmlinuz-6.1-x86_64
initramfs-6.1-x86_64.img           intel-ucode.img                    lost+found           vmlinuz-6.6-x86_64
24

Does the old /boot partition still exist? If so, grub will still boot from that, in which case the 6.1 kernel on that partition will be loaded.

Make sure you have the backup of the old boot partition, delete the old boot partition, then try to reboot again.

If it still doesn’t work, you can use the live usb to recreate the old boot partition and restore the files from backup. Then uncomment the line in /etc/fstab.

25

Yeah the old /boot partition are still present, anyways 6.1 is booting now too…

But i can’t install the new Kernel… Well i can install, but it won’t get detected from GRUB… or something like that.

Any idea why Kernel 6.6 not showing up in Grub Menue?

Do i have to make adjustments in fstab or somewhere else that showed a path to the new boot location in Root… with the new Boot folder?

26

The physical partition needs to be removed from the disks partition table using a partition manager. Whether it is enabled in /etc/fstab doesn’t matter to grub.

Once that is gone, grub will look for boot files in your rootfs and you should see an option for 6.6. The menus are stored in the boot partition or /boot directory, so it sounds like you’re seeing the old one.

27

I removed the partition and restarted my system, but its no longer booting and saying Error there is no such partition and Grub rescue command line shows up.

Im coming to the idea, that root>boot was probably never in used while booting now after several restarts.

Maybe i should try my way with a bigger/boot partition as i mentioned it in first place and copy there my stored backup boot files?

Or should i set a Boot Marker on my Root again, does this solved my problem maybe?
But i have no clue how i can do this.

EDIT: I just set a boot flag to my Root Partition but still error and grub rescue command line.

28

So, from my understanding, grub (generally) on BIOS/MBR has a first-stage bootloader in the MBR, which then loads a second-stage bootloader that is located after the MBR, but before the first partition. This then scans each partition looking for grub config files and the kernel/initramfs images, then loads & hands execution to the kernel.

What I think is happening, is that grub was loading the old menu and the old kernels from the old boot partition. Once the old 6.1 kernel is started and your logged in, your seeing the new /boot directory that has the 6.6 kernel.

If grub still doesn’t boot, you may need to re-install grub or regenerate the config file /boot/grub/grub.cfg. That second-stage bootloader needs to be able to read the filesystem. If the old boot partition was a fat32, the second-stage might’ve been installed to only support that.

It’s possible that running grub-install will install the second-stage with support for ext4 and regenerate the config. However, this needs to be done either on a running system, or in a chroot environment using a live usb. There should be lots of examples on here showing how to use the manjaro-chroot command.

Also, lots of info on the ArchWiki GRUB page.

Definitely worth a try, you can do that from the Live USB too.

Edit

Try this,

Boot up with a live USB and mount your rootfs partition (assuming /dev/sdxN) to /mnt.

Note: Replace ‘/dev/{sdx|sdxN}’ with your disk/partition respectively.

$ sudo mount /dev/sdxN /mnt

Then chroot into the rootfs.

$ sudo manjaro-chroot /mnt

This should drop you into a root shell inside your rootfs.

From here, re-install grub and regenerate the config file.

# grub-install --recheck --target=i386-pc /dev/sdx
# grub-mkconfig -o /boot/grub/grub.cfg

Then leave the chroot and reboot.

1 Like
29

I think i found the solution already:

I created the bigger partition SDC3 (3GByte) and copy my newest /boot backup files,
after that i edited fstab and inserted the new UUID from SDC3.
And now i have Kernel 6.6 instant running again.

But what i don’t understand, that i have dupplicated my Boot files now, both in Rootfilesystem and in /Boot together, without dupplication the system won’t boot now.

Also my older rootbackup files are no longer working (where i had 6.1 running) but i guess, since i installed 6.6 and the installation used update-grub after i created this backup files. This lead to this broken boot with version 6.1 backup, which probably became outdated.

I need still do a little bid testing, im not really trusting the situation… im better use update-grub again.

Update: I removed Kernel 6.1 and system still is booting now. Both 6.1 Kernel files in from Bootpartition and in Rootfs was removed in sync. I think thats a good sign… still thanks for the support.

Pleople who reading this information, need to know that they wouldn’t run into this issues, if they would going straight to a bigger partition (and not download newer Kernel, like i did) or if they resize their /boot partition only had to edit fstab and adjust the new UUID. All you have to do just sudo cp -arv /boot/. TARGETLOCATION and or additional backup your systemfiles with timeshift.

30

Glad you got it working!

Just make sure to re-enable the boot partition in /etc/fstab if you are using a separate boot partition again (ie. /dev/sdc3), otherwise things might break after a kernel update.

1 Like
31

Oh i forgot to mention that i did this already, im better edit that in my posting above :wink:

32

what a mess :wink:
Viele Köche verderben den Brei.
and it was very late (3:30 am here)

You eventually did it - although in a different way than what you initially wanted.

Just for the record:
I just did what I was describing to you - twice.
(first I added a /boot partition - to get to where you started,
then I removed it again)

Worked in both cases - no problem at all.

Anyway, I’m glad it’s solved for you now!

33

Maybe exactly this was the reason why it was working for you but not for me… because you initially started with boot in the rootfs, while i initially had it vise versa but i try to archive a goal in a way it was never intented to be working?

Maybe additional configuration which we forgot?

I first was fooled, i though it was working for me too, only after installing differend Kernel showed me about a problem, even the Kernel 6.6 install logs inside rootfs showed a greenlight. :man_shrugging:

34

That is a definite “No”.
I took special care to actually move the contents of /boot each time.
They where either in /boot on / or they where on the extra partition - not in both at the same time.
All I had to do that was not mentioned was to recreate the initrd
and I also reinstalled Grub and ran update-grub on top of it - to be sure.
Anyway - it’s behind us now. :wink:

35

Well, im just intrested what you think, what i did possible wrong?

Why it is no longer booting after deleting the boot partition?
I only get real experience, when i know what i did wrong and where was the failure.

36

Part of the problem is, that we don’t know what you did.
Commands given and the response that you got.

I can tell you what I did:

Part of the job can be done without the live USB - but I’d just use it all the way.

You had a separate /boot partition (as did I …)

lsblk -f
to find out which partition is which

I created directories below /mnt

mkdir /mnt/root
mkdir /mnt/boot

mount the /boot partition to /mnt/boot
mount the / partition to /mnt/root

Now you can copy the contents of /boot to the /boot directory on the root partition
cp -a /mnt/boot/* /mnt/root/boot

Then, edit /etc/fstab - comment out the line that references your /boot partition (put a # in front of the line)
nano /mnt/etc/fstab

then you can unmount the two partitions:

umount /mnt/boot
umount /mnt/root

then you can chroot - I did it like this:
I mounted the root partition (now the only one needed) to /mnt
mount /dev/sdXy /mnt
and then
manjaro-chroot /mnt /bin/bash

(I did it like this because I’m in a VM and to avoid the heuristic picking up the old /boot partition)

In chroot I recreated the initrd
mkinitcpio -P
and ran
grub-install /dev/sdX
and
update-grub

exit

I then checked the “boot” on partition using
parted -l

Can’t remember whether I changed it or not.

That’s it - I hope I didn’t miss a step because of the classic short term memory loss. :wink:

1 Like
37

Huh? I thought i explained every step about it.

38

Well, the thread is very long and I’m not going through it again - you started with a picture of what you did in your file manager.
I prefer command line - it is more clear and definitive.

1 Like
39

I didn’t used this grub reinstallation, after the install from Kernel 6.6. Maybe this was the case
why the old partition still was in function and why i run into a non booting state.

Anyways, i dont see that you deleted your Boot Partition either.

Your way to archive this goal, looks also very complicated… i did the most with KDE partition Manager and used Dolphin with Root Access to copy/pasted the files or to open terminal from this pathdirection, all this additional mounting looks hardcore, after i couldn’t archive my goal on the first try, i didn’t wanted to waste more time to navigate in Terminal.

Sometimes a simple filebrowser gives me just more overview. The drawback is to show transparency to explain in details every little step with code pasting :frowning:

I don’t wanted to spamm this Forum with Screenshots… but probably it would help alot Windows Users who run into issues without using hardcore Terminal commands.

Should this command not looked like this for MBR?

grub-install --force --target=i386-pc --recheck --boot-directory=/boot /dev/sdy

and for EFI like that?

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck

Isn’t this outdated and very complicated also? Download the maintainer and execute install-grub should do this job far more easy or did i miss something here?

For me is also a big question, how to compare this situations when someone using a VM versus native installation and if there is some distortion possible. (Sorry i have no real experience with VM’s)

Anyways, thanks for your additional explanation. Even when i barely understand the half of the commands that you used :sweat_smile:

40

But I did - you’ll have to believe me. :wink:

Looks can be deceiving - this is just my preference.
I’m used to it - I almost never use the graphical tools.

When you have a separate partition and want to move it’s contents to the same place where this partition is mounted,
you have to unmount it in order to do that.
Like always, there are many ways to skin a cat.

Including yours - which in turn to me looks overly complicated and messy :wink:

That is rarely the case for me.

perhaps
If you think that mine didn’t work, then that means: it wasn’t necessary in the first place.
The disk Grub is installed to does not change, is still the same - and the /boot directory is … the /boot directory - no need to explicitly mention it.

Well, nothing can be done about that - there is no way that I’m doing this on real hardware for fun and edification. :wink:

The key step you and I was missing on the first try was likely the regeneration of the initrd.

Cheers!

2 Likes