Bug 3856

Hi, thanks for reporting this bug.

As it's maybe more in the drakxtools or kernel conf, added also these maintainer.

(Please set the status to 'assigned' if you are working on it)

Keywords: (none) => Triaged
CC: (none) => thierry.vignaud, tmb

Yeah ... You're absolutely right. It has nothing to do with grub itself. I was a bit tired yesterday.

If You need any additional info, don't hesitate to ask.

I just tested that by calling the bootloader-config script directly and the same happened again. I then booted the newly created entry with two 'init' parameters and called the script again, but there were still only two 'init' parameters generated in the new bootloader entry.

Indeed it's more that.

Guys, was init=/bin/systemd hard-coded somewhere ?

Keywords: Triaged => (none)
CC: (none) => dmorganec, mageia
Source RPM: drakxtools-13.72.1-2.mga2.src.rpm => bootloader-utils

Yeah it used to be in some thing or other. I wasn't aware of it, but Blino kindly removed it recently.

From what Blino said on the ML:

"Well, init=/bin/systemd is forced by drakxtools on each kernel install,
if /bin/systemd exists (which means always, since systemd is required by
basesystem). See /usr/lib/libDrakX/bootloader.pm"

So this has now been removed and now systemd-sysvinit is in the vendor prefer list such that it should get selected by default at install time.

Maybe it wasn't removed cleanly, so it adds 2 init now?

I'll go check svn

Yes ... it adds 2 inits now.

The following part of the add_kernel subroutine adds just one ...

    if (-e "$::prefix/bin/systemd") {
       log::l("defaulting to systemd");
       #@$dict = grep { $_->[0] ne 'devfs' } @$dict;
       $v->{append} .= " init=/bin/systemd";
    }

... so, there must be a deeper magic. 

-OR-

I just got on my mind, that the upgrade from Mandriva was a bit painful (I had to repeat the process 20 times and solve many conflicts manually) ... moreover, there was a problem with the automatic repository selection and many packages were taken from the i586 repo instead of x86_64 ... so ... it might be caused by the current untrusted system state.

It would be nice if somebody's able to reproduce the issue.

I changed the code a bit:

       print $v->{append}."\n";
       $v->{append} .= " init=/bin/systemd";
       print $v->{append}."\n";

And the result is:

rdblacklist=nouveau nouveau.modeset=0 init=/bin/systemd
rdblacklist=nouveau nouveau.modeset=0 init=/bin/systemd init=/bin/systemd


So the first init comes in the add_kernel subroutine already filled-in.

Ah, I see now...

We haven't pushed any new drakxtools to the mirrors since we removed that code, so it's still in use.

Thierry, do you have anything more you want to add to drakxtools before I push a new tarball ?

Created attachment 1285 [details]
bootloader-duplicate-init.patch

I was not sure if the code removal is the right solution and therefore I replaced that concatenation with check if the init= is present. The concatenation is done only if init= is missing ... 

But if You plan to change the whole init solution in the future releases, then there would be probably no need for specifying any init parameter.

Thanks for the patch, but in this case it's not needed.

The correct way for sysvinit and systemd to coexist is to not force anything through drakx tools, but instead to install systemd-sysvinit wich we now do,
so that whole code has been removed as you can see here:

http://svnweb.mageia.org/soft/drakx/trunk/perl-install/bootloader.pm?r1=1962&r2=2419

Ok then :] I'll be happy to test the updated package ... 

Thanks.

BR, J.

Fixed drakxtools-13.73-1.mga2 pushed to the mirrors

Status: NEW => RESOLVED
Resolution: (none) => FIXED
Source RPM: bootloader-utils => drakxtools