I need to resize /boot (complicated setup, experts only)

English Install/Boot/Login
#1

So, /boot which used to be very small, apparently now has to be quite large (similar to a Red Hat install). Anyhow… my 100M /boot is no longer sufficient for maintaining openSUSE. In order to resize I need to push the extended partition out… so I move everything… well… everything but /usr. Why? Because it WON’T move. In the olden days, things like /usr were optional, but apparently systemd makes that the effective new “root” in importance (sigh). Anyway, it means that the system effectively ignores whatever you have /etc/fstab for where /usr is mounted… since /usr is needed at boot now. My guess is that I have to somehow get grub2 to do something, but I have no idea what to do. I tried editing grub.cfg, but apparently under openSUSE it’s a generated file (and quite complex btw). I think I might be able to force the grub.cfg using low level commands to move the /usr area the LVM area where it now resides, but again, I just don’t know how.

Anybody done this? You know, all of this used to be a whole lot easier. I figure it’s easier to just blow everything away start over now (which will be painful). Sure wish this was easier…

opensuse 12.3

#2

cjcox, it’s sure nice to see you again.

I can think of a few options, as to how well they’ll work or what you’ll think, that I don’t know. I avoid doing a seperate partition for /boot / and/usr and others for just this reason. I keep mine simple. swap, /, and /home. That’s it for me. Now as to how to remedy yours. I would grab a live image of parted magic. From here, you could shrink / and then enlarge /boot (basically just moving cylinders around). Another option would be to dump the /boot partition and let it reside under /. Of course starting over is also an option, in which a simpler partition scheme may be what works best. All I can do is give you ideas/options. Ultimately, you make the call.

#3

I “solved” this problem by uninstalling plymouth. That reduces the size of the “initrd” file enough so that 100M is sufficient space to have two kernel versions. Another option would be to comment out the multiversion line in “/etc/zypp/zypp.conf”.

I’ll postpone enlarging “/boot” until 13.1 is released.

#4

On 07/06/2013 04:16 PM, Jonathan R wrote:
>
> cjcox, it’s sure nice to see you again.
>
> I can think of a few options, as to how well they’ll work or what
> you’ll think, that I don’t know. I avoid doing a seperate partition for
> /boot / and/usr and others for just this reason. I keep mine simple.
> swap, /, and /home. That’s it for me. Now as to how to remedy yours. I
> would grab a live image of parted magic. From here, you could shrink /
> and then enlarge /boot (basically just moving cylinders around). Another
> option would be to dump the /boot partition and let it reside under /.
> Of course starting over is also an option, in which a simpler partition
> scheme may be what works best. All I can do is give you ideas/options.
> Ultimately, you make the call.
>
>
Resizing is child’s play… the problem is pointing to a new /usr.

In order to resize, I need blow away an extended partition area. To do that
safely, I just want to point at my new /usr area. Again, just moving in
/etc/fstab doesn’t work anymore because this is all done via grub2 boot loader
apparently now.

Again, this isn’t the typical “mom and pop” style destkop/laptop install. It’s
more complex (multiple drives etc… where partitioning is very useful from a
performance perspective and for flexibility).

Not need for “parted magic”… just saying…

#5

On 07/06/2013 04:26 PM, nrickert wrote:
>
> cjcox;2569914 Wrote:
>> Anyhow… my 100M /boot is no longer sufficient for maintaining
>> openSUSE.
>
> I “solved” this problem by uninstalling plymouth. That reduces the
> size of the “initrd” file enough so that 100M is sufficient space to
> have two kernel versions. Another option would be to comment out the
> multiversion line in “/etc/zypp/zypp.conf”.
>
> I’ll postpone enlarging “/boot” until 13.1 is released.
>
>
Awesome. Deleting plymouth… will that break anything startup wise? I’m
guessing no (sounds like you did it post install)… .right?

(nrickert, sorry about the private reply… hit the wrong button)

#6

Only the fancy graphics. Instead, you will see the old style text-based boot screen. Yes, I removed Plymouth
after install. If you remove only “plymouth” and “plymouth-branding-openSUSE”, that does not cause any problems that I am aware of. It reduces the size of the “initrd” files by around 20M, which makes a big difference.

I didn’t see any private reply. You are using “nntp”. I’m guessing that the sender email address is setup so that private replies go to the bit bucket (or “/dev/null”).

#7

Removing Plymouth might be possible, but it’s like a canary for graphics issues that might occur starting when Plymouth normally loads. If you experience any graphics problems, you should be certain to mention this customization.

IIRC parted magic is proprietary software, I’ve been using the GNU equaivalent (GParted Live) without issue for many years now to resize, shift, create and delete partitions.

TSU

#8

On 2013-07-06 22:56, cjcox wrote:
>
> So, /boot which used to be very small, apparently now has to be quite
> large (similar to a Red Hat install). Anyhow… my 100M /boot is no
> longer sufficient for maintaining openSUSE. In order to resize I need
> to push the extended partition out… so I move everything… well…
> everything but /usr. Why? Because it WON’T move. In the olden days,
> things like /usr were optional, but apparently systemd makes that the
> effective new “root” in importance (sigh). Anyway, it means that the
> system effectively ignores whatever you have /etc/fstab for where /usr
> is mounted… since /usr is needed at boot now.

Er… no, that is not so.

Indeed you can move /usr, and fstab is not ignore. Yes, several things
are needed during boot from /usr, but the solution to solve that problem
is that all that is needed is copied to initrd, which is stored on
/boot, increasing its size.

> My guess is that I have
> to somehow get grub2 to do something, but I have no idea what to do. I
> tried editing grub.cfg, but apparently under openSUSE it’s a generated
> file (and quite complex btw). I think I might be able to force the
> grub.cfg using low level commands to move the /usr area the LVM area
> where it now resides, but again, I just don’t know how.

Guess what? To move /usr you… just move it :slight_smile:

It is when you move /boot when you need to do things with grub.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#9

On 2013-07-07 00:12, Chris Cox wrote:
> On 07/06/2013 04:26 PM, nrickert wrote:

> Awesome. Deleting plymouth… will that break anything startup wise? I’m
> guessing no (sounds like you did it post install)… .right?

I also remove plymouth. Beware of dependencies: you have to leave some
of plymouth libs, or by dependencies suspend will also be removed.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#10

On 2013-07-07 00:11, Chris Cox wrote:
> Resizing is child’s play… the problem is pointing to a new /usr.

You only need to point to a new /usr (and root, and home, and all) if
the UUID changes. That is, if the identificators used by fstab and grub
changes.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#11

On 2013-07-07 00:46, nrickert wrote:
> I didn’t see any private reply. You are using “nntp”. I’m guessing
> that the sender email address is setup so that private replies go to the
> bit bucket (or “/dev/null”).

Using nntp a “private reply” would be a plain email sent to the faked
address we use at ...@no-mx.forums.opensuse.org, which does not exist.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#12

You recall incorrectly. Parted Magic is a Linux distribution. start – Parted Magic

You were thinking of PartitionMagic; PartitionMagic - Wikipedia, the free encyclopedia

#13

I doubt that. As far as I know, plymouth has to get out of the way before other graphic software can load.

I deleted plymouth and libraries on several boxes, without a problem. However, others have reported that this interferes with hibernation. So I deleted just plymouth (and its branding) on another box, but kept the libraries. I have not run into any problems.

The one issue that is affected, is the use of crypto. Plymouth normally handles the prompting for encryption keys. Without plymouth, that is done with command line scripts running from the “initrd”. The effect is that if you have two or more encrypted partitions with the same encryption key, then you will be prompted more than once for the key. You can fix that by putting “initrd” in the options column of “/etc/crypttab” and running “mkinitrd”.

I’ll note that after removing plymouth, I did do “mkinitrd”. I’m not sure what happens if you are using an old “initrd” that has plymouth inside, but you have actually removed plymouth.

#14

On 07/06/2013 05:53 PM, Carlos E. R. wrote:
> On 2013-07-07 00:11, Chris Cox wrote:
>> Resizing is child’s play… the problem is pointing to a new /usr.
>
> You only need to point to a new /usr (and root, and home, and all) if
> the UUID changes. That is, if the identificators used by fstab and grub
> changes.
>

Ok… I guess I’m not being clear. Picture two drives. One drive is the where
/usr currently resides but really it’s a PV that’s part of a VG.

I have another VG (different drives) where I’ve established a copy of that same
/usr.

And I want to switch to it. The UUID in this case is different but really
associated with a dev mapper entry (I don’t think that matters). the first LV
was dm-1 and the new one is dm-11 (and each have their own unique UUID).

So… I want to switch /usr out… I want the new LV to be used instead, that way
I don’t have to depend on the old one anymore and I can reorganize the drive easily.

#15

On 07/06/2013 05:46 PM, nrickert wrote:
…snip…
> I didn’t see any private reply. You are using “nntp”. I’m guessing
> that the sender email address is setup so that private replies go to the
> bit bucket (or “/dev/null”).
>
>

Sorry… they do go to @no-mx.forums.opensuse.org… that wasn’t always the case.
My bad.

#16

On 07/06/2013 05:48 PM, Carlos E. R. wrote:
> On 2013-07-06 22:56, cjcox wrote:
>>
>> So, /boot which used to be very small, apparently now has to be quite
>> large (similar to a Red Hat install). Anyhow… my 100M /boot is no
>> longer sufficient for maintaining openSUSE. In order to resize I need
>> to push the extended partition out… so I move everything… well…
>> everything but /usr. Why? Because it WON’T move. In the olden days,
>> things like /usr were optional, but apparently systemd makes that the
>> effective new “root” in importance (sigh). Anyway, it means that the
>> system effectively ignores whatever you have /etc/fstab for where /usr
>> is mounted… since /usr is needed at boot now.
>
> Er… no, that is not so.

Really?
>
> Indeed you can move /usr, and fstab is not ignore. Yes, several things
> are needed during boot from /usr, but the solution to solve that problem
> is that all that is needed is copied to initrd, which is stored on
> /boot, increasing its size.

When I edit /etc/fstab and move /usr… the old user is mounted on reboot.
The only thing I can see that mentions it is grub2… but indeed, we are talking
about booting… so maybe there’s something passed into mkinitrd (??).

I guess I’m not used to having to mention /usr in mkinitrd. Is this documented
anywhere?

>
>> My guess is that I have
>> to somehow get grub2 to do something, but I have no idea what to do. I
>> tried editing grub.cfg, but apparently under openSUSE it’s a generated
>> file (and quite complex btw). I think I might be able to force the
>> grub.cfg using low level commands to move the /usr area the LVM area
>> where it now resides, but again, I just don’t know how.
>
> Guess what? To move /usr you… just move it :slight_smile:

Nope… it’s not that simple I’m afraid. I have moved(copied it and tried to
point to it just using fstab, eg. how things used to work) it. Old one is
always used.

>
> It is when you move /boot when you need to do things with grub.
>

My other post explains things in a bit more detail (well, not full detail, but
enough to show the problem).

#17

On 2013-07-07 01:30, Chris Cox wrote:
> On 07/06/2013 05:53 PM, Carlos E. R. wrote:
>> On 2013-07-07 00:11, Chris Cox wrote:
>>> Resizing is child’s play… the problem is pointing to a new /usr.
>>
>> You only need to point to a new /usr (and root, and home, and all) if
>> the UUID changes. That is, if the identificators used by fstab and grub
>> changes.
>>
>
> Ok… I guess I’m not being clear. Picture two drives. One drive is the where
> /usr currently resides but really it’s a PV that’s part of a VG.

Ok, you did not say this first. Moving /usr about in the same disk where
the uuid does not change is a trifle. Moving to a different disk is
different because the uuid changes. But not that different: you just
change the references to it in fstab and grub, and rebuild the initrd.

In you case, you can leave the old usr around till you get the new one
working.

I have moved from one computer to another, with separate boot, user,
opt, home, and more. It is not that difficult.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#18

On 2013-07-07 01:36, nrickert wrote:
>
> tsu2;2569949 Wrote:
>> Removing Plymouth might be possible, but it’s like a canary for graphics
>> issues that might occur starting when Plymouth normally loads.
>
> I doubt that. As far as I know, plymouth has to get out of the way
> before other graphic software can load.

Not quite… plymouth is also run after boot to do some graphical thing
on tty7 before X really starts, on tty8. I don’t know why or what it
does, but I know that it is there and causes some problems

> I deleted plymouth and libraries on several boxes, without a problem.
> However, others have reported that this interferes with hibernation.

It does. I reported :slight_smile:

> The one issue that is affected, is the use of crypto. Plymouth
> normally handles the prompting for encryption keys. Without plymouth,
> that is done with command line scripts running from the “initrd”. The
> effect is that if you have two or more encrypted partitions with the
> same encryption key, then you will be prompted more than once for the
> key. You can fix that by putting “initrd” in the options column of
> “/etc/crypttab” and running “mkinitrd”.

Ah… noted.

>
> I’ll note that after removing plymouth, I did do “mkinitrd”. I’m not
> sure what happens if you are using an old “initrd” that has plymouth
> inside, but you have actually removed plymouth.

That it “runs” - or its phantom does :slight_smile:

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#19

On 2013-07-07 01:36, Chris Cox wrote:
> On 07/06/2013 05:48 PM, Carlos E. R. wrote:

>>> effective new “root” in importance (sigh). Anyway, it means that the
>>> system effectively ignores whatever you have /etc/fstab for where /usr
>>> is mounted… since /usr is needed at boot now.
>>
>> Er… no, that is not so.
>
> Really?

Yep :slight_smile:

>> Indeed you can move /usr, and fstab is not ignore. Yes, several things
>> are needed during boot from /usr, but the solution to solve that problem
>> is that all that is needed is copied to initrd, which is stored on
>> /boot, increasing its size.
>
> When I edit /etc/fstab and move /usr… the old user is mounted on reboot.
> The only thing I can see that mentions it is grub2… but indeed, we are talking
> about booting… so maybe there’s something passed into mkinitrd (??).

Yep.

Not only passed, but actual libraries and applications that reside in
/usr, are copied inside initrd so that they run from there. I have that
from the horse mouth, so to speak.

The initrd file is a cpio archive. You can open it and see what is
inside; it is a tree of directories with lots of binaries, config files,
and scripts. Apps, libraries, and kernel modules. A lot.

> I guess I’m not used to having to mention /usr in mkinitrd. Is this documented
> anywhere?

Maybe, dunno. The developers doing it commented on this on the factory
mail list time ago, there were a lot of discussions about that at the
time. That’s how I know.

>> Guess what? To move /usr you… just move it :slight_smile:
>
> Nope… it’s not that simple I’m afraid. I have moved(copied it and tried to
> point to it just using fstab, eg. how things used to work) it. Old one is
> always used.

Because there may be references to it in initrd. You have at least to
rebuild initrd, there is a copy of fstab inside. AFAIK grub does not change.

>> It is when you move /boot when you need to do things with grub.
>>
>
> My other post explains things in a bit more detail (well, not full detail, but
> enough to show the problem).

Yes, already answered there.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#20

On 07/06/2013 07:00 PM, Carlos E. R. wrote:
> On 2013-07-07 01:36, Chris Cox wrote:
>> On 07/06/2013 05:48 PM, Carlos E. R. wrote:
>
>
>>>> effective new “root” in importance (sigh). Anyway, it means that the
>>>> system effectively ignores whatever you have /etc/fstab for where /usr
>>>> is mounted… since /usr is needed at boot now.
>>>
>>> Er… no, that is not so.
>>
>> Really?
>
> Yep :slight_smile:
>
>>> Indeed you can move /usr, and fstab is not ignore. Yes, several things
>>> are needed during boot from /usr, but the solution to solve that problem
>>> is that all that is needed is copied to initrd, which is stored on
>>> /boot, increasing its size.
>>
>> When I edit /etc/fstab and move /usr… the old user is mounted on reboot.
>> The only thing I can see that mentions it is grub2… but indeed, we are talking
>> about booting… so maybe there’s something passed into mkinitrd (??).
>
> Yep.
>
> Not only passed, but actual libraries and applications that reside in
> /usr, are copied inside initrd so that they run from there. I have that
> from the horse mouth, so to speak.
>
> The initrd file is a cpio archive. You can open it and see what is
> inside; it is a tree of directories with lots of binaries, config files,
> and scripts. Apps, libraries, and kernel modules. A lot.
>
>> I guess I’m not used to having to mention /usr in mkinitrd. Is this documented
>> anywhere?
>
> Maybe, dunno. The developers doing it commented on this on the factory
> mail list time ago, there were a lot of discussions about that at the
> time. That’s how I know.
>
>>> Guess what? To move /usr you… just move it :slight_smile:
>>
>> Nope… it’s not that simple I’m afraid. I have moved(copied it and tried to
>> point to it just using fstab, eg. how things used to work) it. Old one is
>> always used.
>
> Because there may be references to it in initrd. You have at least to
> rebuild initrd, there is a copy of fstab inside. AFAIK grub does not change.
>
>>> It is when you move /boot when you need to do things with grub.
>>>
>>
>> My other post explains things in a bit more detail (well, not full detail, but
>> enough to show the problem).
>
> Yes, already answered there.
>

I tried to rebuild initrd. I ended up with an unbootable system. So…
ultimately, I did the rebuild from scratch. Created a “fat” root single
filesystem (just to avoid future difficulties… do wish things were as easy as
they used to be though).