Red Hat Bugzilla – Bug 17030
Installer dies with traceback if list of pkgs to be installed is customized
Last modified: 2008-05-01 11:37:58 EDT
Expert mode install, english language, customized list of packages: dies with a traceback when running mkdosfs.
(quoting from memory) I have sda1 as /dosc, sda5 as /dosd (NTFS), sda6 as /, sda7 as /usr, sdb1 as /dose, sdb5 as /var, sdb6 as /home
and sdb7 as swap.
I had selected about 840MB of packages, then the installer formatted /, /usr and died.
It does not happen without expert mode enabled.
Created attachment 3060 [details]
Oh, and "no filesystems were harmed in the making of this traceback" ;-)
Meaning that DOS and NTFS partitions appear to be fine.
My previous report was slightly off the mark: expert mode/mkdosfs is not the problem, customizing the list is!
To reproduce (maybe you don't need to do exactly as I did, but you never know): cd install, select 105keys ita kdb
with dead keys, logitech mouseman, custom system, disk druid (sda1->/dosc, sda5->/dosd NTFS, sda6->/,
sda7->/usr, sdb5->/home, sdb6->/var, sdb7->swap, sdb8->/dose), format all linux partitions, no bootdisk,
use linear, default to dos, Europe/Rome, UTC+2, use DST,
no changes: ok
some changes: traceback
I hadn't noticed it before because the schedule was so tight that other bugs took precedence and never spent
any time customizing the list... I select the subsystems and let it go.
Brock please reproduce.
hmmm ... I could not reproduce this problem in test with the steps above ... :(
* tried italian & english GUI
* tried partitions as described above
* tried expert & non-expert modes
* tried lilo config as above
Have you tried it with RC2 or with a newer cut? Please test RC2, also, because I managed to reproduce it on a differen system:
hda1->/dosc, hda5->/dosd, hda6->/, hda7->swap; italian GUI (other was TUI), customized list... traceback.
Here it comes...
Created attachment 3084 [details]
Sorry, I meant "Italian TUI (other was GUI)".
verified this problem using the RC2 CDs (my fault for not using them in the
first place... :( )
this issue is verified fixed in internal builds (RC-4 & above)... thanks for