[opensuse] lack of space on /boot for new kernel

Fr David Ousley

16 Jan 2014 16 Jan '14

02:21

In doing a regular "zypper up" there is a new kernal update for 12.3 64 bit to be installed (kernel-desktop-3.7.10-1.24.1). The installation failed with the message (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: installing package kernel-desktop-3.7.10-1.24.1.x86_64 needs 8MB on the /boot filesystem Is there a file on the /boot filesystem which I can move or delete to conveniently make room (without having to repartition)? The large files currently are the 3.7.10-1.16 initrd, System.map, vmlinuz, and config. Also symvers-3.7.10-1.16-desktop.gz and vmlinux-3.7.10-1.16-desktop.gz. I can give a complete list if that will help. I have not been keeping copies of the old kernels. Just wondering whether there is an easy way to get the new kernel installed. Thanks. -- Fr David Ousley Church of St Michael the Archangel 6611 Ardleigh Street Philadelphia, PA 19119 215-247-1092 davidousley@verizon.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Show replies by date

Ken Schneider - openSUSE

16 Jan 16 Jan

03:19

On 01/15/2014 09:21 PM, Fr David Ousley pecked at the keyboard and wrote:

...

In doing a regular "zypper up" there is a new kernal update for 12.3 64 bit to be installed (kernel-desktop-3.7.10-1.24.1). The installation failed with the message

(with --nodeps --force) Error: Subprocess failed. Error: RPM failed: installing package kernel-desktop-3.7.10-1.24.1.x86_64 needs 8MB on the /boot filesystem

Is there a file on the /boot filesystem which I can move or delete to conveniently make room (without having to repartition)? The large files currently are the 3.7.10-1.16 initrd, System.map, vmlinuz, and config. Also symvers-3.7.10-1.16-desktop.gz and vmlinux-3.7.10-1.16-desktop.gz. I can give a complete list if that will help. I have not been keeping copies of the old kernels. Just wondering whether there is an easy way to get the new kernel installed.

Thanks.

If you are not using LVM I'm afraid you will need to repartition. What filesystem types are you using? Some can be resized easier than others. I have used UBCD in the past to boot to so a partitioning tool could be used to resize the partitions. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott

03:24

Ken Schneider - openSUSE wrote:

...

If you are not using LVM I'm afraid you will need to repartition.

/boot can't be on LVM. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov

05:29

On Thu, Jan 16, 2014 at 7:24 AM, James Knott wrote:

...

Ken Schneider - openSUSE wrote:

...
If you are not using LVM I'm afraid you will need to repartition.

/boot can't be on LVM.

It can with grub2. Whether YaST supports it, is another question. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez

03:41

El 15/01/14 23:21, Fr David Ousley escribió:

...

In doing a regular "zypper up" there is a new kernal update for 12.3 64 bit to be installed (kernel-desktop-3.7.10-1.24.1). The installation failed with the message

(with --nodeps --force) Error: Subprocess failed. Error: RPM failed: installing package kernel-desktop-3.7.10-1.24.1.x86_64 needs 8MB on the /boot filesystem

Is there a file on the /boot filesystem which I can move or delete to conveniently make room (without having to repartition)? The large files currently are the 3.7.10-1.16 initrd, System.map, vmlinuz, and config. Also symvers-3.7.10-1.16-desktop.gz and vmlinux-3.7.10-1.16-desktop.gz. I can give a complete list if that will help. I have not been keeping copies of the old kernels. Just wondering whether there is an easy way to get the new kernel installed.

Thanks.

what's the size of /boot ? this is a separate partition I guess, otherwise you are running out of space in the root filesystem as well.. what does tune2fs -l /dev/partion/that/contains/boot returns ? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

12:14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-01-16 04:41, Cristian Rodríguez wrote:

...

what's the size of /boot ? this is a separate partition I guess, otherwise you are running out of space in the root filesystem as well..

When you install openSUSE on a situation that needs a separate /boot, like having raid or lvm or encrypted system, YaST makes an absurdly small recommendation for nowdays. I have seen this situation more than once recently. Causes: more than one kernel (the default now), plymouth... - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLXzQoACgkQtTMYHG2NR9WnowCfdyu5Cp+n5JA7yxOgGn+hjP1y RNUAniVxMN8+3IljIGYIeN5jV2RnLWlD =J1QI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Lars Müller

12:52

On Thu, Jan 16, 2014 at 01:14:02PM +0100, Carlos E. R. wrote: [ 8< ]

...

When you install openSUSE on a situation that needs a separate /boot, like having raid or lvm or encrypted system, YaST makes an absurdly small recommendation for nowdays. I have seen this situation more than once recently.

And the bug ID is? I bet there is none. And I also bet there is no bug regardin /boot and it's size at all. Marcus gave an advice: enable the purge-kernels service. This service comes with the mkinitrd package. It checks on boot if /boot/do_purge_kernels exists and if that's the case executes /sbin/purge-kernels Either use YaST or the systemctl to check if the purge-kernels.service is enabled. His other advice was to check how many kernel packages are installed at all. Please call: rpm -qa kernel-\* If you have more than two either reboot after you enabled the purge-kernels.service or call systemctl start purge-kernels.service This issue might be worth being added to http://en.opensuse.org/openSUSE:Most_annoying_bugs_12.3 Please reference bnc#818317 Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

Fr David Ousley

17:11

...

...
In doing a regular "zypper up" there is a new kernal update for 12.3 64 bit to be installed (kernel-desktop-3.7.10-1.24.1). The installation failed with the message

...

...
(with --nodeps --force) Error: Subprocess failed. Error: RPM failed: installing package kernel-desktop-3.7.10-1.24.1.x86_64 needs 8MB on the /boot filesystem

...

what's the size of /boot ? this is a separate partition I guess, otherwise you are running out of space in the root filesystem as well..

/boot is a separate partition: I accepted the size suggested when I installed openSuse. It seemed small, but I asssumed that the installer knew better than I did. df tells me that /boot is 68 MB. It is ext4.

...

what does tune2fs -l /dev/partion/that/contains/boot returns ?

I suspect I have the syntax wrong here: linux2:/boot # tune2fs -l /dev/mapper/pdc_djiegecc-part-5 tune2fs 1.42.6 (21-Sep-2012) tune2fs: No such file or directory while trying to open /dev/mapper/pdc_djiegecc-part-5 Couldn't find valid filesystem superblock. Marcus suggested running: linux2:/boot # rpm -qa|grep kernel-desktop kernel-desktop-devel-3.7.10-1.16.1.x86_64 kernel-desktop-3.7.10-1.16.1.x86_64 so it appears that these are the only kernels installed. Lars asked for: linux2:/boot # rpm -qa|grep kernel* kernel-desktop-devel-3.7.10-1.16.1.x86_64 texlive-l3kernel-2012.67.svn_3570svn26111-4.5.2.noarch kernel-firmware-20130714git-1.9.1.noarch kernel-devel-3.7.10-1.16.1.noarch nfs-kernel-server-1.2.7-2.18.1.x86_64 kernel-desktop-3.7.10-1.16.1.x86_64 The system has hardware RAID -- two mirrored disks. Here is the listing of /boot: drwxr-xr-x 5 root root 1024 Jan 15 19:43 ./ drwxr-xr-x 26 root root 4096 Jan 15 18:56 ../ -rw------- 1 root root 512 Jan 16 2012 backup_mbr lrwxrwxrwx 1 root root 1 Nov 26 13:35 boot -> ./ -rw-r--r-- 1 root root 136018 Jun 7 2013 config-3.7.10-1.16-desktop drwxr-xr-x 2 root root 1024 Nov 27 13:47 grub/ drwxr-xr-x 4 root root 1024 Nov 26 20:15 grub2/ lrwxrwxrwx 1 root root 5 Nov 26 07:48 grub2-efi -> grub2/ lrwxrwxrwx 1 root root 26 Nov 27 11:54 initrd -> initrd-3.7.10-1.16-desktop -rw------- 1 root root 32591624 Nov 27 11:54 initrd-3.7.10-1.16-desktop drwx------ 2 root root 12288 Jan 16 2012 lost+found/ -rw-r--r-- 1 root root 241451 Jun 7 2013 symvers-3.7.10-1.16-desktop.gz -rw-r--r-- 1 root root 516 Jun 7 2013 sysctl.conf-3.7.10-1.16-desktop -rw-r--r-- 1 root root 2531845 Jun 7 2013 System.map-3.7.10-1.16-desktop -rw-r--r-- 1 root root 5813683 Jun 7 2013 vmlinux-3.7.10-1.16-desktop.gz lrwxrwxrwx 1 root root 27 Nov 27 11:54 vmlinuz -> vmlinuz-3.7.10-1.16-desktop -rw-r--r-- 1 root root 4998200 Jun 7 2013 vmlinuz-3.7.10-1.16-desktop Thanks for all the responses. I think this supplies the additional information asked. Other than repartioning, any quick fixes? Thanks. dao -- Fr David Ousley Church of St Michael the Archangel 6611 Ardleigh Street Philadelphia, PA 19119 215-247-1092 davidousley@verizon.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

18:08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-01-16 18:11, Fr David Ousley wrote:

...

Here is the listing of /boot:

...

-rw------- 1 root root 32591624 Nov 27 11:54 initrd-3.7.10-1.16-desktop -rw-r--r-- 1 root root 2531845 Jun 7 2013 System.map-3.7.10-1.16-desktop -rw-r--r-- 1 root root 5813683 Jun 7 2013 vmlinux-3.7.10-1.16-desktop.gz -rw-r--r-- 1 root root 4998200 Jun 7 2013 vmlinuz-3.7.10-1.16-desktop

Those are the big files.

...

Thanks for all the responses. I think this supplies the additional information asked. Other than repartioning, any quick fixes?

As I said, uninstall plymouth. Maybe half of the initrd is due to it. And some one from the yast team should take notice and increase the default size for boot. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLYIB8ACgkQtTMYHG2NR9UJ1ACcCRvIU9F2mXBjkVW7A9th2dYj b6IAn2xpNpHzOPmhgnTKQanuxwv+Dy/r =wKpr -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Fr David Ousley

18:23

On Thu, 16 Jan 2014 13:08:31 -0500, Carlos E. R. wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2014-01-16 18:11, Fr David Ousley wrote:

...
Here is the listing of /boot:

...
-rw------- 1 root root 32591624 Nov 27 11:54 initrd-3.7.10-1.16-desktop -rw-r--r-- 1 root root 2531845 Jun 7 2013 System.map-3.7.10-1.16-desktop -rw-r--r-- 1 root root 5813683 Jun 7 2013 vmlinux-3.7.10-1.16-desktop.gz -rw-r--r-- 1 root root 4998200 Jun 7 2013 vmlinuz-3.7.10-1.16-desktop

Those are the big files.

As I said, uninstall plymouth. Maybe half of the initrd is due to it.

I uninstalled plymouth and rebooted. No change to the size of the files in /boot, including the large initrd. Did I miss something? Thanks -- Fr David Ousley Church of St Michael the Archangel 6611 Ardleigh Street Philadelphia, PA 19119 215-247-1092 davidousley@verizon.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

jdd

18:25

Le 16/01/2014 19:23, Fr David Ousley a écrit :

...

I uninstalled plymouth and rebooted. No change to the size of the files in /boot, including the large initrd. Did I miss something? Thanks

mkinitrd? I suppose you can't install /boot on an other partition? 64Mb is ridiculous - may be it was the windows boot partition? jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov

18:29

В Thu, 16 Jan 2014 13:23:55 -0500 "Fr David Ousley" пишет:

...

On Thu, 16 Jan 2014 13:08:31 -0500, Carlos E. R. wrote:

...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2014-01-16 18:11, Fr David Ousley wrote:

...
Here is the listing of /boot:

...
-rw------- 1 root root 32591624 Nov 27 11:54 initrd-3.7.10-1.16-desktop -rw-r--r-- 1 root root 2531845 Jun 7 2013 System.map-3.7.10-1.16-desktop -rw-r--r-- 1 root root 5813683 Jun 7 2013 vmlinux-3.7.10-1.16-desktop.gz -rw-r--r-- 1 root root 4998200 Jun 7 2013 vmlinuz-3.7.10-1.16-desktop

Those are the big files.

As I said, uninstall plymouth. Maybe half of the initrd is due to it.

I uninstalled plymouth and rebooted. No change to the size of the files in /boot, including the large initrd. Did I miss something? Thanks

You need to recreate initrds (run mkinitrd manually). It is not performed during plymouth (de-)installation. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Fr David Ousley

19:18

...

...
I uninstalled plymouth and rebooted. No change to the size of the files in /boot, including the large initrd. Did I miss something? Thanks

You need to recreate initrds (run mkinitrd manually). It is not performed during plymouth (de-)installation.

Thanks -- this did the trick. initrd is half the size it was, leaving almost half of /boot free. Thanks to all who helped! Thecommunity is wonderful. dao -- Fr David Ousley Church of St Michael the Archangel 6611 Ardleigh Street Philadelphia, PA 19119 215-247-1092 davidousley@verizon.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

19:22

On 2014-01-16 20:18, Fr David Ousley wrote:

...

...
...
I uninstalled plymouth and rebooted. No change to the size of the files in /boot, including the large initrd. Did I miss something? Thanks

You need to recreate initrds (run mkinitrd manually). It is not performed during plymouth (de-)installation.

Thanks -- this did the trick. initrd is half the size it was, leaving almost half of /boot free.

Thanks to all who helped! Thecommunity is wonderful.

Yep. I forgot to mention that you had to run mkinitrd. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

John Andersen

20:21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/16/2014 11:22 AM, Carlos E. R. wrote:

...

On 2014-01-16 20:18, Fr David Ousley wrote:

...
...
...
I uninstalled plymouth and rebooted. No change to the size of the files in /boot, including the large initrd. Did I miss something? Thanks

You need to recreate initrds (run mkinitrd manually). It is not performed during plymouth (de-)installation.

Thanks -- this did the trick. initrd is half the size it was, leaving almost half of /boot free.

Thanks to all who helped! Thecommunity is wonderful.

Yep. I forgot to mention that you had to run mkinitrd.

Some questions if I may: 1) So what functionality (besides eye-candy) does Plymouth supply such that we can simply un-install it and everything runs just fine? 2) Also, my /boot has only (one kernel at this time) but it has several symtype-[kernel]-default-gz, -desktop-gz, -xen-gz, -desktop-gz. - ---Why so many. Why not manage these such that only one is installed to match the current vmlinuz-[kernel] Side Note that none of these issued affect me, because my /boot is located on / (root) rather than it's own partition. This apparently was a choice I made at installation some long time ago and totally forgot about. It too was probably a Yast recommendation. - -- _____________________________________ - ---This space for rent--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAlLYP1MACgkQv7M3G5+2DLJSXwCfb/h1byt7CBbtoV6otToNVWLs Sh8AnRmxIFa4LDyExan3/gaiUVfRm+0V =jDKf -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

20:35

On 2014-01-16 21:21, John Andersen wrote:

...

Some questions if I may:

1) So what functionality (besides eye-candy) does Plymouth supply such that we can simply un-install it and everything runs just fine?

eye-candy. Of course, it has features that allow entering the password for an encrypted filesystem. Also, as boot messages are not displayed, it captures them into a file (/var/log/boot.msg). Maybe it displays them on request, I'm not sure because I always remove plymouth. I remove it mostly because I want to see the plain text messages of boot flowing by, and because it can sometimes interfere with the graphical X session and other things. I also have separate boot partitions, which were ample enough some years ago but now are too small. It has problems (I have seen many reports), fortunately not hitting everybody - but I will not risk it. I do not want to have to find out if some weird problem I have is related to plymouth, so I remove it. Clear field. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

Robin Klitscher

21:02

On 01/17/2014 09:35 AM, Carlos E. R. wrote:

...

On 2014-01-16 21:21, John Andersen wrote:

...
Some questions if I may:

1) So what functionality (besides eye-candy) does Plymouth supply such that we can simply un-install it and everything runs just fine?

eye-candy.

Of course, it has features that allow entering the password for an encrypted filesystem. Also, as boot messages are not displayed, it captures them into a file (/var/log/boot.msg). Maybe it displays them on request, I'm not sure because I always remove plymouth.

I remove it mostly because I want to see the plain text messages of boot flowing by, and because it can sometimes interfere with the graphical X session and other things. I also have separate boot partitions, which were ample enough some years ago but now are too small. It has problems (I have seen many reports), fortunately not hitting everybody - but I will not risk it. I do not want to have to find out if some weird problem I have is related to plymouth, so I remove it. Clear field.

For what it may be worth, as a mere ignorant user I just have splash=verbose on the kernel line in grub.cfg (or menu.lst). This gives me the plain text messages flowing by (too fast to read, actually) in place of the eye-candy while leaving Plymouth running (or at least that's what the boot log reports). -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

21:12

On 2014-01-16 22:02, Robin Klitscher wrote:

...

For what it may be worth, as a mere ignorant user I just have splash=verbose on the kernel line in grub.cfg (or menu.lst). This gives me the plain text messages flowing by (too fast to read, actually) in place of the eye-candy while leaving Plymouth running (or at least that's what the boot log reports).

Yep. You can also disable plymouth with a boot parameter. But I have to remove it because it takes space in the /boot partition that I need, disabling it is not enough for me. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

Felix Miata

20:52

On 2014-01-16 12:21 (GMT-0800) John Andersen composed:

...

1) So what functionality (besides eye-candy) does Plymouth supply such that we can simply un-install it and everything runs just fine?

What Carlos wrote +1. Without it, there is usually a KMS mode switch that causes a visual glitch somewhere in each boot process that bothers some people who know how to code. They attributed their bother to everyone and provided Plymouth as a combined solution to that and unrelated issues. I don't call Plymouth eye candy, because I think of candy as something pleasant. I think of bling as fancy showoff for the sake of play pretty without regarding utility as anything more than nice to have. To me utility is being able to see what's happening, which Plymouth themes I've seen do their level best to inhibit, through dark colors, low text to background contrast, and paint areas half or less of the available screen space. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

21:19

On 2014-01-16 21:52, Felix Miata wrote:

...

On 2014-01-16 12:21 (GMT-0800) John Andersen composed:

...
1) So what functionality (besides eye-candy) does Plymouth supply such that we can simply un-install it and everything runs just fine?

What Carlos wrote +1.

Without it, there is usually a KMS mode switch that causes a visual glitch somewhere in each boot process that bothers some people who know how to code. They attributed their bother to everyone and provided Plymouth as a combined solution to that and unrelated issues.

I have seen that glitch. Yes, it bothers me a bit, on some machines it may cause the screen to be reset and messages erased. It happens, I think, when grub uses a different video mode than the kernel.

...

I don't call Plymouth eye candy, because I think of candy as something pleasant. I think of bling as fancy showoff for the sake of play pretty without regarding utility as anything more than nice to have. To me utility is being able to see what's happening, which Plymouth themes I've seen do their level best to inhibit, through dark colors, low text to background contrast, and paint areas half or less of the available screen space.

I have not experienced it. I got it installed first on the virtual machines I use for testing factory releases, and there those graphics got automatically disabled, I don't know why. Soon I hit problems, so in the 'postit' note where I wrote what to do during installs, plymouth is on the remove list so that I never forget. Thus I never installed it on real hardware and I have never _seen_ it in action. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

Felix Miata

21:30

On 2014-01-16 22:19 (GMT+0100) Carlos E. R. composed:

...

plymouth is on the remove list so that I never forget. Thus I never installed it on real hardware and I have never _seen_ it in action.

I've seen it on systems I did not install, and on distros that make crucial system components depend on plymouth being installed to remain installed themselves (e.g. Mageia). -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Felix Miata

19:39

On 2014-01-16 12:11 (GMT-0500) Fr David Ousley composed:

...

...
what's the size of /boot ? this is a separate partition I guess, otherwise you are running out of space in the root filesystem as well..

...

/boot is a separate partition: I accepted the size suggested when I installed openSuse. It seemed small, but I asssumed that the installer knew better than I did. df tells me that /boot is 68 MB. It is ext4.

68MB is too small for an installation that includes GFXboot, Plymouth, Grub and Grub2. What were the other partition sizes you accepted? A bug probably needs to be filed about this, but it needs facts to back it up. Simply saying too small without context won't be good enough. It looks like similar too small for LVM was fixed 6 months ago: https://bugzilla.novell.com/show_bug.cgi?id=826981 Maybe it should be cloned. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Fr David Ousley

20:50

On Thu, 16 Jan 2014 14:39:41 -0500, Felix Miata wrote:

...

On 2014-01-16 12:11 (GMT-0500) Fr David Ousley composed:

...
...
what's the size of /boot ? this is a separate partition I guess, otherwise you are running out of space in the root filesystem as well..

...
/boot is a separate partition: I accepted the size suggested when I installed openSuse. It seemed small, but I asssumed that the installer knew better than I did. df tells me that /boot is 68 MB. It is ext4.

68MB is too small for an installation that includes GFXboot, Plymouth, Grub and Grub2. What were the other partition sizes you accepted? A bug probably needs to be filed about this, but it needs facts to back it up. Simply saying too small without context won't be good enough.

FWIW, on the system here, I accepted the installation suggestions which were (omitting the remaining Windows partitions): /boot 68 MB /swap 2 GB /root 20GB /home 894 GB -- Fr David Ousley Church of St Michael the Archangel 6611 Ardleigh Street Philadelphia, PA 19119 215-247-1092 davidousley@verizon.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen

21:03

On 1/16/2014 12:50 PM, Fr David Ousley wrote:

...

On Thu, 16 Jan 2014 14:39:41 -0500, Felix Miata wrote:

...
On 2014-01-16 12:11 (GMT-0500) Fr David Ousley composed:

...
...
what's the size of /boot ? this is a separate partition I guess, otherwise you are running out of space in the root filesystem as well..

...
/boot is a separate partition: I accepted the size suggested when I installed openSuse. It seemed small, but I asssumed that the installer knew better than I did. df tells me that /boot is 68 MB. It is ext4.

68MB is too small for an installation that includes GFXboot, Plymouth, Grub and Grub2. What were the other partition sizes you accepted? A bug probably needs to be filed about this, but it needs facts to back it up. Simply saying too small without context won't be good enough.

FWIW, on the system here, I accepted the installation suggestions which were (omitting the remaining Windows partitions):

/boot 68 MB /swap 2 GB /root 20GB /home 894 GB

Same as me, other than /boot being located on / And a word of warning about that recommendation too..... Root being only 20 gig can cause some problems, because that is where /tmp is by default. On my machine that leaves only some 8Gig free on root partition. And some things, like K3B can use a boatload of temp space. While copying some DVDs recently the machine ran out of room on / due to multiple 4Gig iso images laying around in /tmp. I had to configure k3b to use temp space in a directory in my /home/[user] directory. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

21:21

On 2014-01-16 22:03, John Andersen wrote:

...

And some things, like K3B can use a boatload of temp space. While copying some DVDs recently the machine ran out of room on / due to multiple 4Gig iso images laying around in /tmp. I had to configure k3b to use temp space in a directory in my /home/[user] directory.

Same here. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

Felix Miata

21:26

On 2014-01-16 13:03 (GMT-0800) John Andersen composed:

...

Fr David Ousley wrote:

...

...
On Thu, 16 Jan 2014 14:39:41 -0500, Felix Miata wrote:

...

...
...
68MB is too small for an installation that includes GFXboot, Plymouth, Grub and Grub2. What were the other partition sizes you accepted? A bug probably needs to be filed about this, but it needs facts to back it up. Simply saying too small without context won't be good enough.

...

...
FWIW, on the system here, I accepted the installation suggestions which were (omitting the remaining Windows partitions):

...

...
/boot 68 MB /swap 2 GB /root 20GB /home 894 GB

Did that originate from a 12.3 installation, or was that updated from something older still, or 13.1?

...

Same as me, other than /boot being located on /

...

And a word of warning about that recommendation too.....

...

Root being only 20 gig can cause some problems, because that is where /tmp is by default. On my machine that leaves only some 8Gig free on root partition.

Most of mine, mostly for testing, are 4800MB / with no separate tmp partition, with anywhere between 5% and 60+% free. This one running 24/7 among others has these: Filesystem 1K-blocks Used Available Use% Mounted on /dev/md2 10566060 5849834 4183678 59% / /dev/md0 9345494 6538145 2336249 74% /tmp Note that my /tmp is home for the temp dirs for 9 Gecko profiles using 873,524,939 bytes in about 30k files.

...

And some things, like K3B can use a boatload of temp space. While copying some DVDs recently the machine ran out of room on / due to multiple 4Gig iso images laying around in /tmp. I had to configure k3b to use temp space in a directory in my /home/[user] directory.

I do that anyway, as I don't necessarily want the iso written to be removed when I do a copy. Some deserve being archived somewhere. What needs to be determined is whether the fix for too small /boot for LVM installations last summer fixed this for 13.1+ for RAID as well as for LVM. Did either David's or John's installation originate with 13.1, or were they prior to the fix? https://bugzilla.novell.com/show_bug.cgi?id=826981 Has anyone tried letting the installer choose the size of /boot in 13.1 and been stuck with less than the 400MB suggested according to the bug? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen

21:37

On 1/16/2014 1:26 PM, Felix Miata wrote:

...

Did either David's or John's installation originate with 13.1, or were they prior to the fix? https://bugzilla.novell.com/show_bug.cgi?id=826981

In my case, it was a fresh install of 12.3 on a brand new hard-drive and I opted for boot NOT being a separate partition, but merely a sub-directory of /. (I chose this option having previously fought 11.4 having a too small /boot partition through several kernel updates). I haven't done an LVM install yet. (Foolish Fear of the Unknown). -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Fr David Ousley

21:18

On Thu, 16 Jan 2014 14:16:42 -0500, Felix Miata wrote:

...

Those installation tools lie about need. They report gross need, not how much available space is short of the actual need for you to use to

...
calculate how much needs to be freed up.

Not sure what to do with this: zypper gags, claiming not enough space. So even if there is actually enough, I don't know how to get from here to there.

...

If there is a /boot/grub/stage2.old or stage2.bak, delete it to gain ~200k.

Checked, and no old files of that sort.

...

Another way to gain space is ensure only one Grub is installed if both Grub Legacy and Grub2 are installed. Grub2 uses more space on /boot

...
than does Grub Legacy. Legacy rpm is 331k vs Grub2 rpm's 1.9M. And, you only need one or the other, even though the installer normally >gives you both.

Both are installed, so that is one way I can free up space for the future.

...

If your system is using dracut instead of mkinitrd, you might find the latter wants to build a smaller initrd by default. Or vice versa, especially >if the hostonly switch is used.

Uses mkinitrd.

...

If your /boot uses a journaling filesystem it is doing so for virtually no reason and wasting space in the process. Most of /boot's infrequent

...
accesses are only reading. Writing rarely happens except at new kernel installation or old kernel removal times. All my /boot partitions are ext2.

Mine is ext4, which I guess is unnecessary, from what you say. ext4 is journalling, right?

...

You could unmount your /boot before installing the kernel, and it would install to the root filesystem instead. To do that, after unmounting

...
and before updating the kernel, mount it somewhere else to copy its current content to the new /boot, update fstab, and update /etc/>grub.conf. If Grub is on MBR you may be good to go already just by updating, but I'd ensure booting is possible before trying a reboot according to what is currently installed where. Grub probably isn't already installed to your root filesystem and may need to be.

This suggests the best long-term solution (someone else suggested moving /boot to the root file system). Let me see if I've got it: unmount /boot (I'm on a running system now) mount boot somewhere on the root filesystem update fstab to point to where /boot now is edit /etc/grub.conf to do the same then install the new kernel. Did I miss anything? Is a reboot needed before installing the new kernel? I don't know how to "ensure booting is possible" other than by trying to reboot -- can you help me with that one? Many thanks! While I've been using linux (and unix and xenix) for 25 years, I'm an end user and not really expert in all this. dao -- Fr David Ousley Church of St Michael the Archangel 6611 Ardleigh Street Philadelphia, PA 19119 215-247-1092 davidousley@verizon.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

21:24

On 2014-01-16 22:18, Fr David Ousley wrote:

...

On Thu, 16 Jan 2014 14:16:42 -0500, Felix Miata <> wrote:

...

...
If your /boot uses a journaling filesystem it is doing so for virtually no reason and wasting space in the process. Most of /boot's infrequent >accesses are only reading. Writing rarely happens except at new kernel installation or old kernel removal times. All my /boot partitions are >ext2.

Mine is ext4, which I guess is unnecessary, from what you say. ext4 is journalling, right?

Yes. I concur on the recommendation to use ext2 for /boot.

...

This suggests the best long-term solution (someone else suggested moving /boot to the root file system). Let me see if I've got it:

You can not do this is your "/" is on LVM or some raid types. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

Fr David Ousley

22:19

...

...
This suggests the best long-term solution (someone else suggested moving /boot to the root file system). Let me see if I've got it:

You can not do this is your "/" is on LVM or some raid types.

The raid is set in the motherboard BIOS. Listed in the Yast partitioner as DM Raid. Does that preclude moving /boot to root? -- Fr David Ousley Church of St Michael the Archangel 6611 Ardleigh Street Philadelphia, PA 19119 215-247-1092 davidousley@verizon.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

22:29

On 2014-01-16 23:19, Fr David Ousley wrote:

...

...
...
This suggests the best long-term solution (someone else suggested moving /boot to the root file system). Let me see if I've got it:

You can not do this is your "/" is on LVM or some raid types.

The raid is set in the motherboard BIOS. Listed in the Yast partitioner as DM Raid. Does that preclude moving /boot to root?

As it that is a "fake" raid, you would still need a separate /boot. However, I understand that on some cases you can go without. It depends on whether grub is capable of still loading the kernel, I guess. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

Andrey Borzenkov

17 Jan 17 Jan

04:51

On Fri, Jan 17, 2014 at 2:29 AM, Carlos E. R. wrote:

...

On 2014-01-16 23:19, Fr David Ousley wrote:

...
...
...
This suggests the best long-term solution (someone else suggested moving /boot to the root file system). Let me see if I've got it:

You can not do this is your "/" is on LVM or some raid types.

The raid is set in the motherboard BIOS. Listed in the Yast partitioner as DM Raid. Does that preclude moving /boot to root?

As it that is a "fake" raid, you would still need a separate /boot.

Fake raid is seen as a single drive in BIOS. So you must have your /boot on raid to be usable.

...

However, I understand that on some cases you can go without.

It depends on whether grub is capable of still loading the kernel, I guess.

-- Cheers / Saludos,

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

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

08:36

On 2014-01-17 05:51, Andrey Borzenkov wrote:

...

On Fri, Jan 17, 2014 at 2:29 AM, Carlos E. R. wrote:

...
On 2014-01-16 23:19, Fr David Ousley wrote:

...
...
...
This suggests the best long-term solution (someone else suggested moving /boot to the root file system). Let me see if I've got it:

You can not do this is your "/" is on LVM or some raid types.

The raid is set in the motherboard BIOS. Listed in the Yast partitioner as DM Raid. Does that preclude moving /boot to root?

As it that is a "fake" raid, you would still need a separate /boot.

Fake raid is seen as a single drive in BIOS. So you must have your /boot on raid to be usable.

Are you sure of that? In that case, you don't need a separate boot partition for fake raid. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

Andrey Borzenkov

16:48

В Fri, 17 Jan 2014 09:36:00 +0100 "Carlos E. R." пишет:

...

On 2014-01-17 05:51, Andrey Borzenkov wrote:

...
On Fri, Jan 17, 2014 at 2:29 AM, Carlos E. R. wrote:

...
On 2014-01-16 23:19, Fr David Ousley wrote:

...
...
...
This suggests the best long-term solution (someone else suggested moving /boot to the root file system). Let me see if I've got it:

You can not do this is your "/" is on LVM or some raid types.

The raid is set in the motherboard BIOS. Listed in the Yast partitioner as DM Raid. Does that preclude moving /boot to root?

As it that is a "fake" raid, you would still need a separate /boot.

Fake raid is seen as a single drive in BIOS. So you must have your /boot on raid to be usable.

Are you sure of that?

Of single drive? Of course - this is the whole point of having RAID (fake or not).

...

In that case, you don't need a separate boot partition for fake raid.

You can *not* have separate boot partition on one of drives comprising fake raid. And yes, you would normally not need separate boot partition on different drive.

John Andersen

16 Jan 16 Jan

21:24

On 1/16/2014 1:18 PM, Fr David Ousley wrote:

...

This suggests the best long-term solution (someone else suggested moving /boot to the root file system). Let me see if I've got it:

unmount /boot (I'm on a running system now) mount boot somewhere on the root filesystem update fstab to point to where /boot now is edit /etc/grub.conf to do the same

Not sure that is what anyone recommended, but I might have missed a few posts. My machine was set up with no /boot partition, and /boot is just another normal directory in / (root). (It was a fresh install). Not sure you can just do it that easy. Don't know how it affects things like your MBR etc. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Felix Miata

22:02

On 2014-01-16 16:18 (GMT-0500) Fr David Ousley composed:

...

On Thu, 16 Jan 2014 14:16:42 -0500, Felix Miata wrote:

...

...
Those installation tools lie about need. They report gross need, not how much available space is short of the actual need for you to use to

...
calculate how much needs to be freed up.

...

Not sure what to do with this: zypper gags, claiming not enough space. So even if there is actually enough, I don't know how to get from here to there.

df would tell you how much is used and available, which you can compare to what zypper said was required.

...

...
If your /boot uses a journaling filesystem it is doing so for virtually no reason and wasting space in the process. Most of /boot's infrequent

...
accesses are only reading. Writing rarely happens except at new kernel installation or old kernel removal times. All my /boot partitions are ext2.

...

Mine is ext4, which I guess is unnecessary, from what you say. ext4 is journalling, right?

Right. I don't know if there is any way to convert to non-journaled without backup->format->restore->reinstall Grub. Might be something better reserved for some other time now that smaller initrds have solved your problem.

...

...
You could unmount your /boot before installing the kernel, and it would install to the root filesystem instead. To do that, after unmounting

...
and before updating the kernel, mount it somewhere else to copy its current content to the new /boot, update fstab, and update /etc/>grub.conf. If Grub is on MBR you may be good to go already just by updating, but I'd ensure booting is possible before trying a reboot according to what is currently installed where. Grub probably isn't already installed to your root filesystem and may need to be.

...

This suggests the best long-term solution (someone else suggested moving /boot to the root file system).

That used to not work with RAID if it needs to be home to Grub. IIRC it's supposed to be OK with Grub2.

...

Let me see if I've got it:

...

unmount /boot (I'm on a running system now) mount boot somewhere on the root filesystem update fstab to point to where /boot now is edit /etc/grub.conf to do the same

...

then install the new kernel.

...

Did I miss anything? Is a reboot needed before installing the new kernel?

Grub2 specifies root= via UUID by default. If you were using Grub2 to reboot before installing the new kernel, Grub2's menu config file would be using the old UUID, which may or may not be appropriate to the relocated arrangement. Installing the new kernel after the moves should fix it up automatically. There ought to be a howto available somewhere from Google for this kind of move. I've only ever done it involving ext2 & ext3 without RAID or LVM. It's actually something I commonly do for the first installation to a new or wiped HD.

...

I don't know how to "ensure booting is possible" other than by trying to reboot -- can you help me with that one?

That's more a do you know how to and are you ready to boot rescue media to fix it if it fails comment. First, think about the boot process itself and decide how many bases there are and how many were touched. Maybe my unfamiliarity with with Grub2 and you not telling us whether you are booting from Grub or Grub2 is causing me to miscount. It should be instructive to have complete fdisk -l output, plus the content from /etc/grub.conf, in order to confirm your count of the bases.

...

Many thanks! While I've been using linux (and unix and xenix) for 25 years, I'm an end user and not really expert in all this.

I too used Xenix (and before that DOS) long before OS/2, Windows and Linux, but since close to 30 years ago. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Michael Hamilton

04:38

Could you move boot into root? Or could you move boot to some other larger unused partition? You could do this from a live CD/DVD/usb-stick and reconfigure grub2. There are also live-disks with non-destructive re-partitioning tools such as gpartd which is part of my openSUSE system (not sure if it's on the live DVD system). On Thu, 16 Jan 2014, Fr David Ousley wrote:

...

In doing a regular "zypper up" there is a new kernal update for 12.3 64 bit to be installed (kernel-desktop-3.7.10-1.24.1). The installation failed with the message

(with --nodeps --force) Error: Subprocess failed. Error: RPM failed: installing package kernel-desktop-3.7.10-1.24.1.x86_64 needs 8MB on the /boot filesystem

Is there a file on the /boot filesystem which I can move or delete to conveniently make room (without having to repartition)? The large files currently are the 3.7.10-1.16 initrd, System.map, vmlinuz, and config. Also symvers-3.7.10-1.16-desktop.gz and vmlinux-3.7.10-1.16-desktop.gz. I can give a complete list if that will help. I have not been keeping copies of the old kernels. Just wondering whether there is an easy way to get the new kernel installed.

Thanks.

-- Fr David Ousley Church of St Michael the Archangel 6611 Ardleigh Street Philadelphia, PA 19119 215-247-1092 davidousley@verizon.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Felix Miata

04:51

On 2014-01-15 21:21 (GMT-0500) Fr David Ousley composed:

...

In doing a regular "zypper up" there is a new kernal update for 12.3 64 bit to be installed (kernel-desktop-3.7.10-1.24.1). The installation failed with the message

...

(with --nodeps --force) Error: Subprocess failed. Error: RPM failed: installing package kernel-desktop-3.7.10-1.24.1.x86_64 needs 8MB on the /boot filesystem

...

Is there a file on the /boot filesystem which I can move or delete to conveniently make room (without having to repartition)? The large files currently are the 3.7.10-1.16 initrd, System.map, vmlinuz, and config. Also symvers-3.7.10-1.16-desktop.gz and vmlinux-3.7.10-1.16-desktop.gz. I can give a complete list if that will help. I have not been keeping copies of the old kernels. Just wondering whether there is an easy way to get the new kernel installed.

Those installation tools lie about need. They report gross need, not how much available space is short of the actual need for you to use to calculate how much needs to be freed up. Is there really only one kernel installed now? If 2 (or more) are already installed and just hiding from your particular view, zypper rm the oldest. If there is a /boot/grub/stage2.old or stage2.bak, delete it to gain ~200k. Another way to gain space is ensure only one Grub is installed if both Grub Legacy and Grub2 are installed. Grub2 uses more space on /boot than does Grub Legacy. Legacy rpm is 331k vs Grub2 rpm's 1.9M. And, you only need one or the other, even though the installer normally gives you both. If your system is using dracut instead of mkinitrd, you might find the latter wants to build a smaller initrd by default. Or vice versa, especially if the hostonly switch is used. If your /boot uses a journaling filesystem it is doing so for virtually no reason and wasting space in the process. Most of /boot's infrequent accesses are only reading. Writing rarely happens except at new kernel installation or old kernel removal times. All my /boot partitions are ext2. You could unmount your /boot before installing the kernel, and it would install to the root filesystem instead. To do that, after unmounting and before updating the kernel, mount it somewhere else to copy its current content to the new /boot, update fstab, and update /etc/grub.conf. If Grub is on MBR you may be good to go already just by updating, but I'd ensure booting is possible before trying a reboot according to what is currently installed where. Grub probably isn't already installed to your root filesystem and may need to be. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Marcus Meissner

08:02

On Wed, Jan 15, 2014 at 09:21:02PM -0500, Fr David Ousley wrote:

...

In doing a regular "zypper up" there is a new kernal update for 12.3 64 bit to be installed (kernel-desktop-3.7.10-1.24.1). The installation failed with the message

(with --nodeps --force) Error: Subprocess failed. Error: RPM failed: installing package kernel-desktop-3.7.10-1.24.1.x86_64 needs 8MB on the /boot filesystem

Is there a file on the /boot filesystem which I can move or delete to conveniently make room (without having to repartition)? The large files currently are the 3.7.10-1.16 initrd, System.map, vmlinuz, and config. Also symvers-3.7.10-1.16-desktop.gz and vmlinux-3.7.10-1.16-desktop.gz. I can give a complete list if that will help. I have not been keeping copies of the old kernels. Just wondering whether there is an easy way to get the new kernel installed.

rpm -qa|grep kernel-desktop See if there are multiple instances of kernel-desktop installed. If there are multiple, there is a purge kernels service running on every boot, which is however not enabled by default in 12.3. Under root: systemctl enable purge-kernels.service and then on reboot all but two kernel revisions will be deinstalled. Ciao, MArcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

12:20

On 2014-01-16 03:21, Fr David Ousley wrote:

...

Is there a file on the /boot filesystem which I can move or delete to conveniently make room (without having to repartition)? The large files currently are the 3.7.10-1.16 initrd, System.map, vmlinuz, and config. Also symvers-3.7.10-1.16-desktop.gz and vmlinux-3.7.10-1.16-desktop.gz. I can give a complete list if that will help. I have not been keeping copies of the old kernels. Just wondering whether there is an easy way to get the new kernel installed.

A listing would be nice, yes. You probably have at least two kernels; if you have more, delete one with rpm. Possibly, your initrd files are large: you can reduce their sizes drastically by uninstalling plymouth. Boot screen will not be so nice, of course. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

3758

Age (days ago)

3759

Last active (days ago)

List overview

Download

39 comments

14 participants

participants (14)

Andrey Borzenkov
Carlos E. R.
Carlos E. R.
Cristian Rodríguez
Felix Miata
Fr David Ousley
James Knott
jdd
John Andersen
Ken Schneider - openSUSE
Lars Müller
Marcus Meissner
Michael Hamilton
Robin Klitscher