[opensuse] New kernel and Dracut
OK, I compiled a new kernel for the 13.2 release and was installing it. I have to manually copy bzImage and System.map because I do not use the make install which requires the perl-Bootloader to be available. Before I just did mkinitrd -B and the initrd file was made. Now that is part of dracut and I can't create a new initrd file. The message log states that many modules are not supported - like "Module "raid1.ko" is not supported......". This is true because I did not compiled this as a module, but as a build-in. My system is not booting because it is waiting for my drives to appear. The exact same config is used under 12.3 and of course working. Now with dracut I run into problems. Any suggestions? Regards, Frans -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Frans de Boer wrote:
OK, I compiled a new kernel for the 13.2 release and was installing it. I have to manually copy bzImage and System.map because I do not use the make install which requires the perl-Bootloader to be available.
Before I just did mkinitrd -B and the initrd file was made. Now that is part of dracut and I can't create a new initrd file. The message log states that many modules are not supported - like "Module "raid1.ko" is not supported......". This is true because I did not compiled this as a module, but as a build-in.
You say "I can't create a new initrd", but below:
My system is not booting because it is waiting for my drives to appear. The exact same config is used under 12.3 and of course working. Now with dracut I run into problems.
you're booting your system so I guess you do have an initrd? It sounds like you need to look at the config of the initrd & the kernel - when raid support is built in, your array should become available without extra effort. After reviewing the config, the next step is probably to attach a serial console and capture the console output so you can see what's going on. -- Per Jessen, Zürich (17.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/05/2015 08:00 AM, Per Jessen wrote:
Frans de Boer wrote:
OK, I compiled a new kernel for the 13.2 release and was installing it. I have to manually copy bzImage and System.map because I do not use the make install which requires the perl-Bootloader to be available.
Before I just did mkinitrd -B and the initrd file was made. Now that is part of dracut and I can't create a new initrd file. The message log states that many modules are not supported - like "Module "raid1.ko" is not supported......". This is true because I did not compiled this as a module, but as a build-in.
You say "I can't create a new initrd", but below:
My system is not booting because it is waiting for my drives to appear. The exact same config is used under 12.3 and of course working. Now with dracut I run into problems.
you're booting your system so I guess you do have an initrd?
It sounds like you need to look at the config of the initrd & the kernel - when raid support is built in, your array should become available without extra effort. After reviewing the config, the next step is probably to attach a serial console and capture the console output so you can see what's going on.
Sorry, I had to say "it seems I can't create a working initrd". I used the exact same config as under 12.3, and still the machine hangs by counting "[x of 3] start jobs....". I now use the "make install" command for the kernel as it seems to work, It does not complain about the absence of perl-BootLoader anymore. I use a construct of a mastergrub partition with chainings to the relevant openSuSE distributions/partitions. Anyhow, whatever I do, nothing seems to work for creating an initrd gets me booted. Back in the days when mkinitrd was not hijacked by dracut, things did work always. Has there to be anything special within the compiled kernel? If no answer, I will install perl-bootloader in the hope that this will solve the problem - hoping that starting the mastergrub code does not get nuked. I will also remove the initrd as provided by the distribution and recreate it again. Let's see if the same problem occurs. Frans. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/05/2015 04:21 PM, Frans de Boer wrote:
On 05/05/2015 08:00 AM, Per Jessen wrote:
Frans de Boer wrote:
OK, I compiled a new kernel for the 13.2 release and was installing it. I have to manually copy bzImage and System.map because I do not use the make install which requires the perl-Bootloader to be available.
Before I just did mkinitrd -B and the initrd file was made. Now that is part of dracut and I can't create a new initrd file. The message log states that many modules are not supported - like "Module "raid1.ko" is not supported......". This is true because I did not compiled this as a module, but as a build-in.
You say "I can't create a new initrd", but below:
My system is not booting because it is waiting for my drives to appear. The exact same config is used under 12.3 and of course working. Now with dracut I run into problems.
you're booting your system so I guess you do have an initrd?
It sounds like you need to look at the config of the initrd & the kernel - when raid support is built in, your array should become available without extra effort. After reviewing the config, the next step is probably to attach a serial console and capture the console output so you can see what's going on.
Sorry, I had to say "it seems I can't create a working initrd". I used the exact same config as under 12.3, and still the machine hangs by counting "[x of 3] start jobs....". I now use the "make install" command for the kernel as it seems to work, It does not complain about the absence of perl-BootLoader anymore.
I used mkinitcpio based on a preset -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/05/2015 10:21 PM, Frans de Boer wrote:
On 05/05/2015 08:00 AM, Per Jessen wrote:
Frans de Boer wrote:
OK, I compiled a new kernel for the 13.2 release and was installing it. I have to manually copy bzImage and System.map because I do not use the make install which requires the perl-Bootloader to be available.
Before I just did mkinitrd -B and the initrd file was made. Now that is part of dracut and I can't create a new initrd file. The message log states that many modules are not supported - like "Module "raid1.ko" is not supported......". This is true because I did not compiled this as a module, but as a build-in.
You say "I can't create a new initrd", but below:
My system is not booting because it is waiting for my drives to appear. The exact same config is used under 12.3 and of course working. Now with dracut I run into problems.
you're booting your system so I guess you do have an initrd?
It sounds like you need to look at the config of the initrd & the kernel - when raid support is built in, your array should become available without extra effort. After reviewing the config, the next step is probably to attach a serial console and capture the console output so you can see what's going on.
Sorry, I had to say "it seems I can't create a working initrd". I used the exact same config as under 12.3, and still the machine hangs by counting "[x of 3] start jobs....". I now use the "make install" command for the kernel as it seems to work, It does not complain about the absence of perl-BootLoader anymore.
I use a construct of a mastergrub partition with chainings to the relevant openSuSE distributions/partitions. Anyhow, whatever I do, nothing seems to work for creating an initrd gets me booted. Back in the days when mkinitrd was not hijacked by dracut, things did work always.
Has there to be anything special within the compiled kernel? If no answer, I will install perl-bootloader in the hope that this will solve the problem - hoping that starting the mastergrub code does not get nuked.
I will also remove the initrd as provided by the distribution and recreate it again. Let's see if the same problem occurs.
Frans. And No, I recreated the initrd for the stock kernel and everything worked...:\ So, maybe not the initrd creation is at fault, maybe something in the kernel itself? If so, what has changed between 12.3 and 13.2 that the kernels compiled do not proceed with the boot process but seem to wait for disks. my guess is the dracut modules?
Regards, Frans. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Frans de Boer wrote:
I recreated the initrd for the stock kernel and everything worked...:\ So, maybe not the initrd creation is at fault, maybe something in the kernel itself? If so, what has changed between 12.3 and 13.2 that the kernels compiled do not proceed with the boot process but seem to wait for disks. my guess is the dracut modules?
Hi Frans Apart from the dracut initrd being bigger and less easy to handle, I have not noticed any issues with it. If anything is waiting for disks, it's probably not the kernel but maybe systemd? /Per -- Per Jessen, Zürich (11.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/06/2015 08:01 AM, Per Jessen wrote:
Frans de Boer wrote:
I recreated the initrd for the stock kernel and everything worked...:\ So, maybe not the initrd creation is at fault, maybe something in the kernel itself? If so, what has changed between 12.3 and 13.2 that the kernels compiled do not proceed with the boot process but seem to wait for disks. my guess is the dracut modules?
Hi Frans
Apart from the dracut initrd being bigger and less easy to handle, I have not noticed any issues with it. If anything is waiting for disks, it's probably not the kernel but maybe systemd?
/Per The message where the boot process hangs is:
[ ] (x of 3) A start job running for dev-disk-by\x2duuid-<....> This appears also sometimes when closing the distribution provided kernel. I dislike the cumbersome uuid notion and rather use label, but beside that, has anybody seen this in conjunction of systemd? It does not matter if some or all modules are compiled into the kernel, the result is always the same. Again, any suggestion? Frans -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Frans de Boer wrote:
On 05/06/2015 08:01 AM, Per Jessen wrote:
Frans de Boer wrote:
I recreated the initrd for the stock kernel and everything worked...:\ So, maybe not the initrd creation is at fault, maybe something in the kernel itself? If so, what has changed between 12.3 and 13.2 that the kernels compiled do not proceed with the boot process but seem to wait for disks. my guess is the dracut modules?
Hi Frans
Apart from the dracut initrd being bigger and less easy to handle, I have not noticed any issues with it. If anything is waiting for disks, it's probably not the kernel but maybe systemd?
/Per The message where the boot process hangs is:
[ ] (x of 3) A start job running for dev-disk-by\x2duuid-<....>
This appears also sometimes when closing the distribution provided kernel.
This is from systemd. It's waiting for that disk to become available.
I dislike the cumbersome uuid notion and rather use label, but beside that, has anybody seen this in conjunction of systemd?
Yep.
It does not matter if some or all modules are compiled into the kernel, the result is always the same.
Again, any suggestion?
So it doesn't work with a vanilla openSUSE kernel either? -- Per Jessen, Zürich (17.0°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/06/2015 02:13 PM, Per Jessen wrote:
Frans de Boer wrote:
On 05/06/2015 08:01 AM, Per Jessen wrote:
Frans de Boer wrote:
I recreated the initrd for the stock kernel and everything worked...:\ So, maybe not the initrd creation is at fault, maybe something in the kernel itself? If so, what has changed between 12.3 and 13.2 that the kernels compiled do not proceed with the boot process but seem to wait for disks. my guess is the dracut modules?
Hi Frans
Apart from the dracut initrd being bigger and less easy to handle, I have not noticed any issues with it. If anything is waiting for disks, it's probably not the kernel but maybe systemd?
/Per The message where the boot process hangs is:
[ ] (x of 3) A start job running for dev-disk-by\x2duuid-<....>
This appears also sometimes when closing the distribution provided kernel.
This is from systemd. It's waiting for that disk to become available.
I dislike the cumbersome uuid notion and rather use label, but beside that, has anybody seen this in conjunction of systemd?
Yep.
It does not matter if some or all modules are compiled into the kernel, the result is always the same.
Again, any suggestion?
So it doesn't work with a vanilla openSUSE kernel either?
It does work with the standard distribution specific kernel. As the same compiled configuration is normally working under 12.3, why not under 13.2? Maybe compile the distribution kernel and tailor from there might be an approach, albeit a time consuming one? Frans. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Frans de Boer wrote:
On 05/06/2015 02:13 PM, Per Jessen wrote:
It does not matter if some or all modules are compiled into the kernel, the result is always the same.
Again, any suggestion?
So it doesn't work with a vanilla openSUSE kernel either?
It does work with the standard distribution specific kernel. As the same compiled configuration is normally working under 12.3, why not under 13.2?
Quite different kernels, presumably. Also, the systemd setup changed quite a bit.
Maybe compile the distribution kernel and tailor from there might be an approach, albeit a time consuming one?
I would start with the openSUSE kernel-sources anyway, but for a big jump in kernel version, I wouldn't expect an old config to work right a way. Anyway, you've no doubt got good reasons to want to build your own, so you'll have to make the extra effort and compare the two kernel/configs. -- Per Jessen, Zürich (16.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/06/2015 08:29 PM, Per Jessen wrote:
Frans de Boer wrote:
On 05/06/2015 02:13 PM, Per Jessen wrote:
It does not matter if some or all modules are compiled into the kernel, the result is always the same.
Again, any suggestion?
So it doesn't work with a vanilla openSUSE kernel either?
It does work with the standard distribution specific kernel. As the same compiled configuration is normally working under 12.3, why not under 13.2?
Quite different kernels, presumably. Also, the systemd setup changed quite a bit.
Maybe compile the distribution kernel and tailor from there might be an approach, albeit a time consuming one?
I would start with the openSUSE kernel-sources anyway, but for a big jump in kernel version, I wouldn't expect an old config to work right a way. Anyway, you've no doubt got good reasons to want to build you own, so you'll have to make the extra effort and compare the two kernel/configs.
Nope, of course same kernel and config under 12.3 and 13.2. My reason, I don't want to load all kind of stuff which my machine supports but where I have no need for in my server system. Also, I compile to a higher optimization including choice of CPU. Maybe the suggestion of Andrei is valid. I always cut this out - no need for. But maybe with the change to Dracut it is needed? Again, I'll explore this too.... to be continued..... Frans. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Wed, 06 May 2015 16:35:29 +0200 Frans de Boer <frans@fransdb.nl> пишет:
It does work with the standard distribution specific kernel. As the same compiled configuration is normally working under 12.3, why not under 13.2?
Please read systemd README for the least of kernel options that need to be enabled (or disabled). Common reason for "missing" devices is lack of CONFIG_FHANDLE.
Maybe compile the distribution kernel and tailor from there might be an approach, albeit a time consuming one?
Frans.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Andrei Borzenkov -
Frans de Boer -
Per Jessen -
Ruben