[gentoo-user] resizing EFI partition, btrfs context

[gentoo-user] resizing EFI partition, btrfs context

[Stefan G. Weichinger]

Hello, gentoo-users,

today I wanted to resize my EFI-partition sda1.

It was on my SSD which had roughly this layout:

sda1	300M	EFI System
sda2	~460G 	linux fs -> btrfs
sda3	~4G	swap

This is a dualboot setup with Gentoo and Fedora (in fact triple-boot as
there's some MS Windows 10 Pro on another disk, but anyway) and both
distros have their root-filesystems and stuff within the btrfs on sda2.

They even share stuff by mounting the same subvols here and there ...
nice, by the way.

My issue was and is: 300M gets tight when 2 distros install multiple
kernels into /boot ... so I would like to have around 500 megs to avoid
having to always manually clean up some kernel before upgrades run
through. comfort.

I ddrescued sda to a HDD for backups, then rebooted with gparted etc etc

long story short: it failed.
Right now I boot and run from that HDD with still 300M for EFI.

sidenote: how slow such a harddisk is ...

I'd like to move the full btrfs-structure to a slightly smaller
partition on the SSD (which should have that larger EFI-boot-partition)
and I would love to get some pointers on how to do that without having
any fs-UUIDs changed, and gummiboot complaining etc etc

For now I am tired and leave it like that for today (late here).

Thanks, Stefan

Re: [gentoo-user] resizing EFI partition, btrfs context

[Jc García]

2015-10-05 15:36 GMT-06:00 Stefan G. Weichinger <lists@xunil.at>:
>
> Hello, gentoo-users,
>
> today I wanted to resize my EFI-partition sda1.
>
> It was on my SSD which had roughly this layout:
>
> sda1    300M    EFI System
> sda2    ~460G   linux fs -> btrfs
> sda3    ~4G     swap
>
> This is a dualboot setup with Gentoo and Fedora (in fact triple-boot as
> there's some MS Windows 10 Pro on another disk, but anyway) and both
> distros have their root-filesystems and stuff within the btrfs on sda2.
>
> They even share stuff by mounting the same subvols here and there ...
> nice, by the way.
>
> My issue was and is: 300M gets tight when 2 distros install multiple
> kernels into /boot ... so I would like to have around 500 megs to avoid
> having to always manually clean up some kernel before upgrades run
> through. comfort.
>
> I ddrescued sda to a HDD for backups, then rebooted with gparted etc etc
>
> long story short: it failed.
>

I tried to do this (getting more space for kernels in the EFI
partitions) some days ago, and failed on my first try also, I went the
easy way backing up what I had and deleting, remaking the partition
using gparted, put the stuff in there(and finally change from
gummiboot to bootctl), reboot and failed, after sratching my head and
2 more fails trying FAT16 and going back to FAT32 booting, I noticed I
had not set the partition type only the label, and didn't found how to
do that using gparted, so went to the basic: gdisk, and set the
partition type to EF00 and I it worked. Didn't you miss this sort of
details?

Re: [gentoo-user] resizing EFI partition, btrfs context

[Stefan G. Weichinger]

Am 2015-10-06 um 02:47 schrieb Jc García:

>> long story short: it failed.
> 
> I tried to do this (getting more space for kernels in the EFI
> partitions) some days ago, and failed on my first try also, I went the
> easy way backing up what I had and deleting, remaking the partition
> using gparted, put the stuff in there(and finally change from
> gummiboot to bootctl), reboot and failed, after sratching my head and
> 2 more fails trying FAT16 and going back to FAT32 booting, I noticed I
> had not set the partition type only the label, and didn't found how to
> do that using gparted, so went to the basic: gdisk, and set the
> partition type to EF00 and I it worked. Didn't you miss this sort of
> details?

Well, if I knew ;-)
I thought of having missed the boot flag as well although gparted should
have taken care of that, right? And gparted finished successfully but
the boot failed after that.

Right now I just have to retry: clone the hdd to the ssd then restart
the gparted-steps.

Or is there a clever way to copy the whole btrfs over into a fresh and
slightly smaller partition while keeping its UUID intact?

Re: [gentoo-user] resizing EFI partition, btrfs context

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

On Tue, 6 Oct 2015 09:16:31 +0200, Stefan G. Weichinger wrote:

> I thought of having missed the boot flag as well although gparted should
> have taken care of that, right? And gparted finished successfully but
> the boot failed after that.

I did have a problem enlarging the ESP when I tried a while ago, it just
wouldn't boot so I ended up deleting and recreating it.
 
> Right now I just have to retry: clone the hdd to the ssd then restart
> the gparted-steps.
> 
> Or is there a clever way to copy the whole btrfs over into a fresh and
> slightly smaller partition while keeping its UUID intact?

How about btrfs send/receive? I've never used them but used the equivalent
with ZFS and it was simple to do.

When you do repartition the disk, I'd suggest putting swap immediately
after the ESP. That way, if you want to fiddle with the size of the ESP
again, you only have to touch swap, not your main btrfs volume.


-- 
Neil Bothwick

ASCII stupid question... get a stupid ANSI!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] resizing EFI partition, btrfs context

[Stefan G. Weichinger]

Am 2015-10-06 um 09:28 schrieb Neil Bothwick:

> I did have a problem enlarging the ESP when I tried a while ago, it
> just wouldn't boot so I ended up deleting and recreating it.

I will do that on the SSD, yes.

>> Right now I just have to retry: clone the hdd to the ssd then
>> restart the gparted-steps.
>> 
>> Or is there a clever way to copy the whole btrfs over into a
>> fresh and slightly smaller partition while keeping its UUID
>> intact?
> 
> How about btrfs send/receive? I've never used them but used the
> equivalent with ZFS and it was simple to do.

I think "btrfs-replace" is my friend. Will try that later.

> When you do repartition the disk, I'd suggest putting swap
> immediately after the ESP. That way, if you want to fiddle with the
> size of the ESP again, you only have to touch swap, not your main
> btrfs volume.

Good advice, will follow that, thanks.

Re: [gentoo-user] resizing EFI partition, btrfs context

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

On Tue, 6 Oct 2015 09:35:40 +0200, Stefan G. Weichinger wrote:

> > How about btrfs send/receive? I've never used them but used the
> > equivalent with ZFS and it was simple to do.  
> 
> I think "btrfs-replace" is my friend. Will try that later.

If you want to keep the system live, replace will do the trick, but when I
tried it to replace a drive that was showing SMART errors it was VERY
slow. btrfs send serialises your whole filesystem to a file so it should
be much faster.


-- 
Neil Bothwick

Hard work has a future payoff. Laziness pays off now.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] resizing EFI partition, btrfs context

[Stefan G. Weichinger]

Am 2015-10-06 um 09:45 schrieb Neil Bothwick:
> On Tue, 6 Oct 2015 09:35:40 +0200, Stefan G. Weichinger wrote:
> 
>>> How about btrfs send/receive? I've never used them but used
>>> the equivalent with ZFS and it was simple to do.
>> 
>> I think "btrfs-replace" is my friend. Will try that later.
> 
> If you want to keep the system live, replace will do the trick, but
> when I tried it to replace a drive that was showing SMART errors it
> was VERY slow. btrfs send serialises your whole filesystem to a
> file so it should be much faster.

btrfs send would also have the benefit that I won't lose the
source-dev in the process. btrfs-replace would "empty" my hdd, if then
things fail I don't have that backup again to start from.

I just have to find out how to keep the UUID to keep the copy booting etc

I will try that later this day, after some job work.

Re: [gentoo-user] resizing EFI partition, btrfs context

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

On Tue, 6 Oct 2015 09:52:18 +0200, Stefan G. Weichinger wrote:

> > If you want to keep the system live, replace will do the trick, but
> > when I tried it to replace a drive that was showing SMART errors it
> > was VERY slow. btrfs send serialises your whole filesystem to a
> > file so it should be much faster.  
> 
> btrfs send would also have the benefit that I won't lose the
> source-dev in the process. btrfs-replace would "empty" my hdd, if then
> things fail I don't have that backup again to start from.

Good point.
 
> I just have to find out how to keep the UUID to keep the copy booting
> etc

Just run bootctl/gummiboot install after repartitioning to pick up the
new UUID.


-- 
Neil Bothwick

Das Internet is nicht fuer gefingerclicken und giffengrabben. Ist easy
droppenpacket der routers und overloaden der backbone mit der spammen
und der me-tooen. Ist nicht fuer gewerken bei das dumpkopfen. Das
mausklicken sichtseeren keepen das bandwit-spewin hans in das pockets
muss; relaxen und watchen das cursorblinken.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] resizing EFI partition, btrfs context

[Stefan G. Weichinger]

Am 2015-10-06 um 10:05 schrieb Neil Bothwick:

>> I just have to find out how to keep the UUID to keep the copy
>> booting etc
> 
> Just run bootctl/gummiboot install after repartitioning to pick up
> the new UUID.

fstab has to be edited as well (in my case for 2 distros), I wanted to
avoid all that.

I assume I have to btrfs-send the root-subvol to fully clone all my
subvolumes.

Re: [gentoo-user] resizing EFI partition, btrfs context

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

On Tue, 6 Oct 2015 10:09:37 +0200, Stefan G. Weichinger wrote:

> >> booting etc  
> > 
> > Just run bootctl/gummiboot install after repartitioning to pick up
> > the new UUID.  
> 
> fstab has to be edited as well (in my case for 2 distros), I wanted to
> avoid all that.

Come on, sed's not that hard! :P

> I assume I have to btrfs-send the root-subvol to fully clone all my
> subvolumes.

I'm not sure, looking at the man page it appears you pass it a list of
subvolumes and it dumps them all to one file, then you restore them all
from the same file. It would be worth testing with unimportant data
first. 


-- 
Neil Bothwick

This man is depriving a village somewhere of an idiot

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] resizing EFI partition, btrfs context

[Rich Freeman]

On Tue, Oct 6, 2015 at 3:52 AM, Stefan G. Weichinger <lists@xunil.at> wrote:
> Am 2015-10-06 um 09:45 schrieb Neil Bothwick:
>> On Tue, 6 Oct 2015 09:35:40 +0200, Stefan G. Weichinger wrote:
>>
>>>> How about btrfs send/receive? I've never used them but used
>>>> the equivalent with ZFS and it was simple to do.
>>>
>>> I think "btrfs-replace" is my friend. Will try that later.
>>
>> If you want to keep the system live, replace will do the trick, but
>> when I tried it to replace a drive that was showing SMART errors it
>> was VERY slow. btrfs send serialises your whole filesystem to a
>> file so it should be much faster.
>
> btrfs send would also have the benefit that I won't lose the
> source-dev in the process. btrfs-replace would "empty" my hdd, if then
> things fail I don't have that backup again to start from.
>
> I just have to find out how to keep the UUID to keep the copy booting etc
>
> I will try that later this day, after some job work.
>

I doubt send/receive would preserve the UUID.

I'd probably use btrfs-replace.

If you do want to keep the same UUID via any mechanism make sure the
original drive isn't visible or btrfs may try to use it instead of the
new one.  That is more of a concern in raid configs, but it might
apply to single volume.  Btrfs can't tell the difference between the
active volume you unmounted yesterday and the lvm snapshot of it from
six months ago, and will potentially try to mix-and-match them
resulting in carnage.

Btrfs does support resizing if you just want to shrink the filesystem
and then dd it over to the new partition.  Just make sure the old one
isn't attached when you try to mount it.  Just shrink your btrfs
partition down to a size smaller than where it is going, use dd to
copy it, then you can run btrfs resize to expand it back to the full
size.  The syntax is slightly different but it works the same as
resize2fs, and I believe it works either online or offline.

However, if you're able to figure out how to use btrfs and migrate it
from one drive to another, you could probably just edit the UUID in
your grub config if necessary.  It just takes a text editor, and maybe
a run of grub2-mkconfig if you're using that.  You'll also want to
update your fstab, and if you're using dracut you should update that
as well (as long as it gets a decent UUID from the command line I
think it will figure things out on its own though - dracut saves a
copy of your fstab to help find things when you build it but then it
will remount filesystems using the real fstab before it finishes).

-- 
Rich

Re: [gentoo-user] resizing EFI partition, btrfs context

[Stefan G. Weichinger]

Am 2015-10-06 um 14:32 schrieb Rich Freeman:
> On Tue, Oct 6, 2015 at 3:52 AM, Stefan G. Weichinger <lists@xunil.at> wrote:
>> Am 2015-10-06 um 09:45 schrieb Neil Bothwick:
>>> On Tue, 6 Oct 2015 09:35:40 +0200, Stefan G. Weichinger wrote:
>>>
>>>>> How about btrfs send/receive? I've never used them but used
>>>>> the equivalent with ZFS and it was simple to do.
>>>>
>>>> I think "btrfs-replace" is my friend. Will try that later.
>>>
>>> If you want to keep the system live, replace will do the trick, but
>>> when I tried it to replace a drive that was showing SMART errors it
>>> was VERY slow. btrfs send serialises your whole filesystem to a
>>> file so it should be much faster.
>>
>> btrfs send would also have the benefit that I won't lose the
>> source-dev in the process. btrfs-replace would "empty" my hdd, if then
>> things fail I don't have that backup again to start from.
>>
>> I just have to find out how to keep the UUID to keep the copy booting etc
>>
>> I will try that later this day, after some job work.
>>
> 
> I doubt send/receive would preserve the UUID.
> 
> I'd probably use btrfs-replace.
> 
> If you do want to keep the same UUID via any mechanism make sure the
> original drive isn't visible or btrfs may try to use it instead of the
> new one.  That is more of a concern in raid configs, but it might
> apply to single volume.  Btrfs can't tell the difference between the
> active volume you unmounted yesterday and the lvm snapshot of it from
> six months ago, and will potentially try to mix-and-match them
> resulting in carnage.
> 
> Btrfs does support resizing if you just want to shrink the filesystem
> and then dd it over to the new partition.  Just make sure the old one
> isn't attached when you try to mount it.  Just shrink your btrfs
> partition down to a size smaller than where it is going, use dd to
> copy it, then you can run btrfs resize to expand it back to the full
> size.  The syntax is slightly different but it works the same as
> resize2fs, and I believe it works either online or offline.
> 
> However, if you're able to figure out how to use btrfs and migrate it
> from one drive to another, you could probably just edit the UUID in
> your grub config if necessary.  It just takes a text editor, and maybe
> a run of grub2-mkconfig if you're using that.  You'll also want to
> update your fstab, and if you're using dracut you should update that
> as well (as long as it gets a decent UUID from the command line I
> think it will figure things out on its own though - dracut saves a
> copy of your fstab to help find things when you build it but then it
> will remount filesystems using the real fstab before it finishes).

I do a plain rsync into a new btrfs on the ssd now and edited the UUID
within copied gummiboat loader entries .... some GBs left to sync before
I can test booting!

;)

I don't use grub2 anymore, just gummiboot .. and even this might be
replaced by bootctl soon. step by step, you know.

Re: [gentoo-user] resizing EFI partition, btrfs context

[Stefan G. Weichinger]

Am 2015-10-06 um 14:50 schrieb Stefan G. Weichinger:

> I do a plain rsync into a new btrfs on the ssd now

stupid me. this does NOT copy the subvols over as I assumed.

I tried to rsync the root-subvol ... but there are no subvols created by
rsync.

Re: [gentoo-user] [solved] resizing EFI partition, btrfs context

[Stefan G. Weichinger]

On 06.10.2015 15:00, Stefan G. Weichinger wrote:

> stupid me. this does NOT copy the subvols over as I assumed.
> 
> I tried to rsync the root-subvol ... but there are no subvols created by
> rsync.

Ok, done so far.
I took the btrfs-replace road with the risk ... I had to use "btrfs
filesystem resize" to shrink the source filesystem a bit. Tricky syntax,
btw ...

The UUID of the btrfs-pool stayed the same, I recreated the ESP and did
some fiddling from a chroot to get gummiboot reinstalled.

Is the step from gummiboot to bootctl problematic?
Just because I am at it right now ...

Thanks, Stefan (now back to work ;) )

Re: [gentoo-user] [solved] resizing EFI partition, btrfs context

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

On Tue, 6 Oct 2015 19:33:26 +0200, Stefan G. Weichinger wrote:

> Is the step from gummiboot to bootctl problematic?

sed s/gummiboot/bootctl everywhere

It's the same program with a different name, so just run bootctl install
instead then you can unmerge gummiboot. I don't recall any problems
making the switch, so it was either trouble-free or so traumatic I've
blotted it out!


-- 
Neil Bothwick

Mac screen message: "Like, dude, something went wrong."

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] [solved] resizing EFI partition, btrfs context

[Stefan G. Weichinger]

Am 2015-10-06 um 19:51 schrieb Neil Bothwick:
> On Tue, 6 Oct 2015 19:33:26 +0200, Stefan G. Weichinger wrote:
> 
>> Is the step from gummiboot to bootctl problematic?
> 
> sed s/gummiboot/bootctl everywhere
> 
> It's the same program with a different name, so just run bootctl
> install instead then you can unmerge gummiboot. I don't recall any
> problems making the switch, so it was either trouble-free or so
> traumatic I've blotted it out!

Already did the step, thanks.
A bit cleanup to do now, but nothing problematic.

So no need to patch Canek's kerninst script at all, just use

BOOT_MANAGER="gummiboot"

as before, as far as I understand from a quick check.

Did you unmerge gummiboot as well?
(os-prober has to leave as well .. left over from grub)

Re: [gentoo-user] [solved] resizing EFI partition, btrfs context

[Stefan G. Weichinger]

On 06.10.2015 19:59, Stefan G. Weichinger wrote:

> Did you unmerge gummiboot as well?
> (os-prober has to leave as well .. left over from grub)

ok. removed gummiboot from ESP via efibootmgr and cleaned up messy entries.

Now the box boots 3 OSes via UEFI ... with bootctl coming from the
systemd in gentoo. Nice.

phew, all that work to resize the ESP from 300M -> 500M.
I could have cleaned up old kernels from ESP manually for years instead
with that energy/time ;-)

thanks all, Stefan

Re: [gentoo-user] [solved] resizing EFI partition, btrfs context

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

On Tue, 6 Oct 2015 20:15:49 +0200, Stefan G. Weichinger wrote:

> phew, all that work to resize the ESP from 300M -> 500M.
> I could have cleaned up old kernels from ESP manually for years instead
> with that energy/time ;-)

Time to invoke one of my favourite Douglas Adams quotes:

"I ... am rarely happier than when spending an entire day programming my
computer to perform automatically a task that would otherwise take me a
good ten seconds to do by hand.”


-- 
Neil Bothwick

By the time you can make ends meet, they move the ends.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] [solved] resizing EFI partition, btrfs context

[Stefan G. Weichinger]

Am 2015-10-06 um 22:40 schrieb Neil Bothwick:
> On Tue, 6 Oct 2015 20:15:49 +0200, Stefan G. Weichinger wrote:
> 
>> phew, all that work to resize the ESP from 300M -> 500M. I could
>> have cleaned up old kernels from ESP manually for years instead 
>> with that energy/time ;-)
> 
> Time to invoke one of my favourite Douglas Adams quotes:
> 
> "I ... am rarely happier than when spending an entire day
> programming my computer to perform automatically a task that would
> otherwise take me a good ten seconds to do by hand.”

well said, exactly like that

Re: [gentoo-user] [solved] resizing EFI partition, btrfs context

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

On Tue, 6 Oct 2015 19:59:04 +0200, Stefan G. Weichinger wrote:

> Did you unmerge gummiboot as well?

Yes.

> (os-prober has to leave as well .. left over from grub)

I don't bother with that, even with GRUB.


-- 
Neil Bothwick

"I laugh in the face of danger, then I hide until it goes away"

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]