(In reply to Frank Griffin from comment #0)
> Switching to tty2 from the graphical install gives a busybox prompt that
> does not accept most of the usual commands, e. g. ls, df, bug.

and that's with the same stage 2 as in bug 21886:

[marja@localhost ~]$ xzcat Downloads/21886ddebug.log.xz | grep DrakX
* second stage install running (DrakX v17.91)
[marja@localhost ~]$ 


Busybox-1.27.2 works fine, afaict, in an installed system here, but that's a newer version than we had when stage2 was last built.

Assignee: bugsquad => mageiatools
Source RPM: (none) => drakx-installer.stage2-17.91, busybox
CC: (none) => marja11

This has a familiar ring to it (except I think last time it was that boot-nonfree wasn't being rebuilt when boot-free was).  Why doesn't stage2 get rebuilt when its components change ?

(In reply to Frank Griffin from comment #2)
> This has a familiar ring to it (except I think last time it was that
> boot-nonfree wasn't being rebuilt when boot-free was).  Why doesn't stage2
> get rebuilt when its components change ?

For some important changes, schedbot prepares the rebuild by bumping the release and adding a message about why it's needed.
http://svnweb.mageia.org/packages/cauldron/drakx-installer-stage2/current/SPECS/drakx-installer-stage2.spec?view=log

(The newest entry is for rpm-4.14.0-4.mga7 that was pushed to cauldron core/updates_testing last Friday)

However, someone still needs to push stage2 to the build server after schedbot did its work.

For changes that schedbot doesn't detect, someone has to remember that stage2 needs to get its release bumped and be rebuilt.

We need more packagers and developers with *time*

Would you have time to become a Mageia packager and help make sure stage2 gets rebuilt when needed?

Probably not to be a full packager, but if there's some sort of ping that indicates stage2 activity is needed, I can certainly sign up for it and submit whatever's needed if no one objects.  Someday I hope to have the leisure to grok all of the rpm macros and the rules for their use in MGA, but I think I'd try to weigh in on the development side first.

Same behavior with the Nov 3 stage2.

We actually dont rebuild stage2 & rescue for every package change that could affect it sometimes breaks more than it fixes... 

However I've now submitted them both to the BS

CC: (none) => tmb

Thanks, Thomas, I'll give it a try.

The rebuild changed the characteristics of the error in bug#21886, but this problem is still the same.

(In reply to Frank Griffin from comment #8)
> The rebuild changed the characteristics of the error in bug#21886, but this
> problem is still the same.

Since mdkinst.sqfs is corrupted, as Dave Hodgins found, it might have the same cause.

Summary: Busybox cannot identify the usual commands => Busybox in installer cannot identify the usual commands
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=21886

As detailed in bug#21886 Pascal has fixed this.

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