id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
471	calculate EXTRA_SIZE and BOOT_SIZE values before assigning them	Manuel Carreira Silva	Bruno Cornec	"EXTRA_SPACE and BOOT_SIZE variables in /usr/sbin/mindi have fixed values.
Sometimes, in some systems, it is necessary to increment them to avoid a crash.
If mindi crashes because of this, some messages jump in to the screen,


{{{

......Failed to copy /tmp/mindi.HoaDLhll8l/initrd.img to /tmp/mindi.HoaDLhll8l/mountpoint.19653
cat: /tmp/mindi.HoaDLhll8l/mtpt.19653: No such file or directory
Please unload some of your modules and try again.
Cannot incorporate initrd.img in bootdisk (kernel / modules too big?)
FATAL ERROR. Sorry, your kernel is too big for your image
}}}



and /var/log/mindi.log would get a message like this:


{{{
copying /tmp/mindi.HoaDLhll8l/initrd.img to /tmp/mindi.HoaDLhll8l/mountpoint.19653/initrd.img...
cp: writing «/tmp/mindi.HoaDLhll8l/mountpoint.19653/initrd.img»: No space left on device
Failed to copy /tmp/mindi.HoaDLhll8l/initrd.img to /tmp/mindi.HoaDLhll8l/mountpoint.19653
Please unload some of your modules and try again.
Cannot incorporate initrd.img in bootdisk (kernel / modules too big?)
...--
Kernel size = 2000 K
Ramdisk free = 0 K
FATAL ERROR. Sorry, your kernel is too big for your image
}}}



I think this is not a bug, but for a first time user, this can be a ""horror movie"".

I think an easier approach to '''implement in a short term''', could be '''adding a message''' telling the user to try to increment values in those variables editing /usr/sbin/mindi.
This can lead to prevent users from repeating the same questions in the mailing list.

In a''' second phase''', implement an '''algorithm that could ""guess""''' which values would be assigned to the variables.
This would save the user to undesirable crashes, and would be a better solution in my opinion."	enhancement	closed	normal	3.3.0	mindi	2.2.9.5	normal	fixed	EXTRA_SPACE BOOT_SIZE initrd.img bootdisk