Bug 4912 - bootloader step fails if /boot is too small ( less than 20Mb)
Summary: bootloader step fails if /boot is too small ( less than 20Mb)
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Pascal Terjan
QA Contact:
URL:
Whiteboard: Errata
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2012-03-12 21:57 CET by Dick Gevers
Modified: 2013-05-11 12:09 CEST (History)
4 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
bz2 tarred /root/drakx (195.80 KB, application/x-bzip)
2012-03-12 22:01 CET, Dick Gevers
Details

Description Dick Gevers 2012-03-12 21:57:00 CET
Description of problem:

Personalized desktop install: All  workstations, no servers, all Graph.Env.

A Problem occurs at the start of the bootloader section:

"An error occurred
mkinitrd failed:
(mkinitrd -v -f /boot/initrd-3.3.0-desktop-0.rc1.1.mga.img 33.0-desktop-0.rc1.1.mga2)".

Next: "Preparing bootloader"

Then the same error is printed again on screen. And again and again. Unable to continue.

I had prepared in custom partitioning one virtual drive for "/" and one for "/boot" and some for existing partitions. The "/" and "/boot" were formatted at that time.

Indeed when I look at tty2 at the contents of /mnt/boot I see the symlink initrd.desktop.img --> initrd-3.3.0-desktop-0.rc1.1.mga2.img but the latter file is not there.

I also tried manually "mkinitrd -v -f /mnt//boot/initrd-3.3.0-desktop-0.rc1.1.mga.img 33.0-desktop-0.rc1.1.mga2", but nothing happens (only: "...not found", looks like "command not found")

Started the install all over, same process in all respects. same error.
Comment 1 Dick Gevers 2012-03-12 22:01:08 CET
Created attachment 1742 [details]
bz2 tarred /root/drakx
Comment 2 Manuel Hiebel 2012-03-12 23:40:48 CET
seems your tar is not complete & this bug in strange

please next with the next iso of tomorrow

Keywords: (none) => NEEDINFO

Comment 3 Barry Jackson 2012-03-13 00:02:53 CET
It should be trying to use dracut not mkinitrd 

from your logs above:-

dracut-017-1.mga2.noarch
kernel-desktop-3.3.0-0.rc7.1.mga2-1-1.mga2.x86_64
----------------------------------------------------------------------
More information on package dracut-017-1.mga2.noarch
dracut is the default mkinitrd replacement in mageia

If you really want to use old mkinitrd instead of dracut run
update-alternatives --set mkinitrd /sbin/mkinitrd-mkinitrd

NOTE!
We only support the use of mkinitrd with initscripts.
If you use systemd (the default setup) you _must_ use dracut.

----------------------------------------------------------------------

The log shows that dracut was installed and requires on mkinitrd were provided by dracut, but just where the error is coming from I don't know. 
Others hopefully will ;)
Comment 4 Dick Gevers 2012-03-13 08:04:44 CET
To comment#2: This is all that was in /root/drakx, the tar is complete with what was available at this stage.
Comment 5 Dick Gevers 2012-03-13 23:34:36 CET
Unchanged with iso of 13/3.
Comment 6 Manuel Hiebel 2012-03-14 01:31:21 CET
I can't reproduce with your test procedure.

personally I have:

* adding /boot/vmlinuz-3.3.0-desktop-0.rc7.1.mga2
* running: mkinitrd -v -f /boot/initrd-3.3.0-desktop-0.rc7.1.mga2.img 3.3.0-desktop-0.rc7.1.mga2 with root /mnt
WARNING: Activating non-hostonly initrd due to distro upgrade.
         Your initrd will be larger than needed for compatibility.

         You can disable this by setting DRACUT_SKIP_FORCED_NON_HOSTONLY=1
D: Executing /usr/bin/dracut -v -f -o network /boot/initrd-3.3.0-desktop-0.rc7.1.mga2.img 3.3.0-desktop-0.rc7.1.mga2
I: *** Including module: dash ***
D: Installing /lib64/libc-2.14.1.so
D: Installing /lib64/ld-2.14.1.so
...
Comment 7 Dave Hodgins 2012-03-14 18:21:10 CET
(In reply to comment #0)
> Description of problem:
> 
> A Problem occurs at the start of the bootloader section:
> "An error occurred
> mkinitrd failed:
> (mkinitrd -v -f /boot/initrd-3.3.0-desktop-0.rc1.1.mga.img
> 33.0-desktop-0.rc1.1.mga2)".

> I had prepared in custom partitioning one virtual drive for "/" and one for
> "/boot" and some for existing partitions. The "/" and "/boot" were formatted at
> that time.

How much free space is in /boot?

CC: (none) => davidwhodgins

Comment 8 Dick Gevers 2012-03-14 19:43:01 CET
To comment#7

>How much free space is in /boot?

8.3M, which has been enough in many Mageia installation tests in the past, and never gave such problems (partition table hasn't changed for a long time).
Comment 9 Dick Gevers 2012-03-14 20:32:14 CET
BTW, the 8.3 is as seen with command 'df' from Current Cauldron on other partitions. When I do a new install with the 3rd iso, diskdrake shows it's size as 15MB.
Comment 10 Dick Gevers 2012-03-14 21:23:28 CET
Third iso (14/3): hit again.

tty2 shows size as 15 MB, used 6 MB, available 9MB, more than enough to fit the initrd...img which is only 6MB

On my main box the partition used for years testing installation ( /boot ) is only 13 MB and has never given this problem.
Comment 11 Manuel Hiebel 2012-03-14 21:31:09 CET
(In reply to comment #10)
> Third iso (14/3): hit again.
> 
> tty2 shows size as 15 MB, used 6 MB, available 9MB, more than enough to fit the
> initrd...img which is only 6MB
> 
> On my main box the partition used for years testing installation ( /boot ) is
> only 13 MB and has never given this problem.

can indeed be a problem.

CC: (none) => mageia, thierry.vignaud
Source RPM: Mageia-2-beta2-x86_64-DVD.iso => dracut

Comment 12 Dave Hodgins 2012-03-14 21:57:03 CET
In my beta 2 pre-release test, the initrd is 16 MB.
Comment 13 Colin Guthrie 2012-03-14 22:10:46 CET
Yes the initrd created during the installer is much more generic than a typical "hostonly" initrd. This allows for a wide range of hardware support when booting.

So a typical install-time initrd is probably ~16Mb. This will reduce to about 5-8Mb depending on setup after boot.

It could be that the installer can produce a hostonly initrd OK. The primary problem is that we definitely cannot produce a hostonly initrd on upgrades - i.e. via urpmi - as the necessary metadata is not available due to the fact that mkinird was used to boot the system that ran urpmi in the first place meaning critical metadata will not be in udev for certain setups.

See bug #4562 for more background - the non hostonly initrd is a recommended system from upstream on upgrade.

I do appreciate however that we should see if the installer can be configured to generate a hostonly system. I just need to test variations on LVM setups to make sure the necessary info is there. All that is needed to avoid this is an mkdir command in the installer - once we are certain it will work.
Comment 14 Dick Gevers 2012-03-14 22:37:45 CET
Same problem with 32 bits DVD

Hardware: x86_64 => All

Manuel Hiebel 2012-03-15 00:02:23 CET

Keywords: NEEDINFO => (none)
Summary: [beta2] bootloader step fails ("mkinitrd failed") => bootloader step fails if /boot is too small ( less than 20Mb)
Whiteboard: (none) => Errata

Comment 15 Dick Gevers 2012-03-17 18:55:37 CET
It cn be workaround by copying the initrd from current Cauldron's /boot directory to the installation's /boot directory (partition) after mkinitrd failed.

Installation is then able to continue.

Hardware: All => x86_64

Thierry Vignaud 2012-04-24 11:06:49 CEST

Assignee: bugsquad => pterjan
Source RPM: dracut => (none)

Comment 16 Colin Guthrie 2012-04-24 12:18:30 CEST
As per comment 13, the installer should now generate a non-host-only initrd and thus should be smaller again (somewhere between 6 to 8 megs depending on h/w).

A urpmi based upgrade will still have to generate the non-hostonly initrd for first boot where the user can generate a smaller one which will work from then on.

So this problem should likely be solved now, but small /boot partitions should maybe be warned about somewhere?
Comment 17 Marja Van Waes 2012-05-26 13:06:40 CEST
Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Comment 18 Dick Gevers 2012-05-28 12:47:26 CEST
It was difficult to enlarge the /boot partition intended for testing isos.

Should I try and test a smaller partition now?
Comment 19 Colin Guthrie 2012-05-28 17:51:00 CEST
A "normal" upgrade through the installer should be OK.

The only time when the upgrade may need the larger /boot is for urpmi-based upgrades which might include a chroot'ed upgrade from a live boot (I don't know how this process works or if it is even possible).

For a regular install or an upgrade via the installer, the initrd size should be suitably small.

As the ISOs are out now, I'm not sure it's worth spending too much time reproducing.
Comment 20 Dick Gevers 2012-05-28 19:06:30 CEST
Then let's close it ! Colin: Thanks for your comments

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 21 Dave Hodgins 2012-05-29 09:47:55 CEST
See bug 5872.  As this is an upgrade using mgaapplet-upgrade-helper
it should be fixable with an update.

I'm pretty sure an 18MB initrd indicates it ran out of space.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Comment 22 Marja Van Waes 2012-07-06 15:03:43 CEST
Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D
Comment 23 Dick Gevers 2013-05-10 15:04:41 CEST
David you reopened this near a year ago / Marja you commented this last:

Is there any use to keep this open?

CC: (none) => marja11

Comment 24 Marja Van Waes 2013-05-11 12:09:44 CEST
(In reply to Dick Gevers from comment #23)
> David you reopened this near a year ago / Marja you commented this last:
> 
> Is there any use to keep this open?

I'm not sure Dave saw your comment, but he might see it when I close this report :)

@ Dave

Feel free to reopen it again. Personally, I don't see the need, because

(In reply to Dave Hodgins from comment #21)
> See bug 5872.  As this is an upgrade using mgaapplet-upgrade-helper
> it should be fixable with an update.
> 
> I'm pretty sure an 18MB initrd indicates it ran out of space.


Robert Thompson from https://bugs.mageia.org/show_bug.cgi?id=5872#c5 
> Plenty of free space:
> 
> [root@jalapeno robt]# df /boot
> Filesystem      Size  Used Avail Use% Mounted on
> /dev/md1        147M   57M   84M  41% /boot

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.