I decided to give tumbleweed a try, this time around.
So today, there were updates. And there was a failure in the middle.
Apparently, tumbleweed is keeping both old and new kernel. And there is not quite enough space for that in my 100M “/boot”.
I recovered. I took the “abort” choice from zypper, deleted the “initrd” file for the old kernel to make some space, went into Yast software management and deleted the old kernel. I then ran “mkinitrd” to complete the step that had failed. And finally, I ran “zypper dup” again to pick up the packages that I had missed by aborting.
I guess this is going to happen for every kernel update.
Question: If I delete “plymouth” will it stay deleted, or will it come back on the next “zypper dup”?
I ask, because “plymouth” is what causes “initrd” to be huge, and that in turn is why space is tight for “/boot”.
[Note that I use an encrypted LVM, which is why I need a separate “/boot”]
I remember a discussion of that, but didn’t pay much attention. I had thought I would have enough space, but I had not noticed how bloated the “initrd” files have become with “plymouth.”
On 04/12/2013 10:06 PM, nrickert wrote:
> Question: If I delete “plymouth” will it stay deleted, or will it come
> back on the next “zypper dup”?
i would think if you delete it with YaST Software Management and then
right click on it (in the list in YaST Software Management) and
select “Taboo – Never install” it would not…
but i’m not sure about “zypper dup”…so, [read my caveat, and] try
it and see…
And also now the default kernel behaviour on 12.3 standard. My main system (still on 12.2) always has a partitioned /boot of 100MB, space is not tight and always been enough for a couple of kernels if needed. I’ve forgotten the original reason why I have a separate /boot (not using LVM or encryption), but it did once avoid a problem suffered by others on openSUSE. So your comment raises an issue possibly affecting 12.3 with separate /boot generally, and a question:
Did you mean that initrd expansion is due to plymouth with the use of encrypted LVM, or will it just happen with plymouth anyway without encryption or LVM?
I have always believed that using the multiple kernel facility has been an essential precaution to configure when using Tumbleweed with its kernel updates, and the reason why I never used a separate /boot partition, or for any other “testing” version. All my linux partitions are logical ones, and resizing /boot for expansion would be a tedious process.
The currently running system (“/boot” is from there) does not have an encrypted LVM. It does have randomly encrypted swap, but that was setup more recently than the “initrd” was built, so could not affect the “initrd” size. The system whose partition is mounted as “/mnt” does use an encrypted LVM. As I recall, the “initrd” for the 3.1.10 kernel on that system was similar in size to the one you see there.
Incidentally, the error message (when I still had both kernels) said that around 860K of additional space was required for that partition, so there is almost space for a second kernel.
I’m pretty sure that “initrd” was far smaller in opensuse 12.1 (before Plymouth).
So, with a 100M “/boot” you might run into problems on the next kernel update. Anyone with a separate “/boot” needs to check whether there’s enough space.
I never really liked “plymouth” anyway. In pre-plymouth times, I always changed the booting to be noisy. I like to see all of those startup messages rolling down the screen, and I feel blinded by the effect of plymouth.
At present, plymouth is prompting for the encrypted LVM key. But I’m pretty sure that there will still be a prompt without it.
That’s around 1/3 the former size (see comment #7 above).
I rebooted. The reboot went fine, the prompting for encryption key was fine. And the boot screen is now more informative about what is going on.
After rebooting, I tried:
# zypper refresh
# zypper dup -D
It told me that there was nothing to do. So it looks as if it won’t try to reinstall plymouth. Note that I did not blacklist plymouth.
Details:
To delete plymouth, I opened Yast software management. I searched for “plymouth”. The first line was one of the plymouth libraries. I marked that for deletion. The “conflict” prompt appeared, and one of its choices amounted to deleting the rest of plymouth. It also deleted something called “suspend” which seems to depend on plymouth libraries.
Thanks for the detailed explanation. I removed Tumbleweed (12.1), so only have 11.4 (before Plymouth). Here are some numbers for initrd from my systems all fully updated, you may find interesting.
openSUSE 11.4 (Evergreen) installl to root partition only, contains initrd of 10.7MiB.
openSUSE 12.2 with /boot partition (ext2) size: 101.9MiB contains initrd of 15.4MiB. A recent partclone image of /boot is 41.2MiB [used space].
openSUSE 12.3 recent clean install to root partition only, contains initrd of 30.9MiB.
There should be room for another 12.3 kernel in my /boot partition, even with the increased space taken up by replacing 12.2’s /boot with 12.3’s. However it could be tight, initrd being the largest increase, but other files increased also.
PS. Hadn’t seen your #10 when I posted this, but it looks as if my initrd sizes confirms yours.
That’s a computer purchased in 2007. At that time, 100M looked plenty big enough. I seem to remember having both default and pae kernel installed, with less than half the partition used.
In practice, the computer came with Windows and a 100M Dell partition. I converted the Dell partition to “/boot” and used the reinstall disk to reinstall Windows to a smaller partition, so that I would have plenty of space for linux. Alas, new computers come with no reinstall disk.
I didn’t turn on verbose. The amount that I see is less than the old days, but I think that’s systemd compared to SysvInit. I think I already noticed that change in 12.1.
I now see the “fsck” output before mounting file systems. No more mushroom treatment (“keep them in the dark and feed them horse manure”).
On 2013-04-14 08:37, dd wrote:
> On 04/14/2013 01:46 AM, nrickert wrote:
>> Yes, and I like it that way.
>
> me too…and, not knowing if/how to murder plymouth was on my list of
> reasons to not move to 12.3
But I see two hurdles. He said:
> The “conflict” prompt appeared, and one of its
> choices amounted to deleting the rest of plymouth. It also deleted
> something called “suspend” which seems to depend on plymouth libraries.
The deletion of “suspend” worries me. I don’t know what it does exactly,
but as I do use suspend to ram and/or hibernation, that could be an issue.
The other issue is passphrase request for those using encrypted partitions.
An alternative is using:
plymouth.enable=0
on the kernel line. There is a thread at the openSUSE mail list named
“Re: [opensuse] mkinitrd - disable features?” where they are talking
about this issue.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
At the moment, I am running Yast Software Management on my main desktop, where I still have Plymouth though I am thinking about whether to remove.
I search for “suspend”. It lists two packages: “pm-utils” and “suspend”. Based on the description, the important one seems to be “pm-utils”. The description for “suspend” says:
“A set of tools to support suspending notebooks, working around the specific problems each machine has.”
On the box where I deleted Plymouth, I am using an encrypted LVM. I was still prompted for the encryption key, though it was not that GUI prompt screen. It was just prompting at the command line.
The one thing I am not sure of, is what happens if there are two or more encrypted partitions, using the same encryption key. Plymouth remembers the key and uses it for both. My guess is that I would be prompted twice and have to enter the key twice.
Before "“plymouth”, I could enter “initrd” in the options column of “/etc/crypttab”, and run “mkinitrd”. Thereafter, the encryption key prompting (still at the command line) would be done in the “initrd” which did remember the key and re-use for other partitions. The information about that seems to have disappeared from the man page for “crypttab” so I am not sure whether that still works.