![]() ![]() ![]() Typically you would just download the full source for the kernel. Keep in mind while looking at this that the key to the difference between 2GB and other modules is a combination of device tree and kernel configuration…the source itself is meaningless unless it is configured to match your running system. Consider what follows to be a superset of headers, and more extensive than what the 2GB model source would provide. I use this sort of method because full source is almost always better than just headers (only it takes a lot more disk space…but not too much if you don’t build an actual kernel Image). Possible but fairly complicated.What follows is just one long alternative way to obtain and configure the “equivalent” of headers. Of course being able to load the kernel from the disk image would be preferable but I would imagine this is somewhat more difficult without reasonably sophisticated boot infrastructure to first boot an initrd to mount the rootfs, parse the local bootloader configuration, get the guest kernel, push this to somewhere that you can get on the next reboot and cycle the machine. ![]() I tried to do it using the builtin make deb-pkg, but sadly it will only work for Debian/Ubuntu, so I'm not 100% satisfied and I'm looking for another solution that may work everywhere, if you have any idea That's exactly what I understood yesterday, I will try to add a script that sync everything needed to build new modules easily using DKMS, so I can add ZFS to fix this issue, but also improve the ease of customisation for every other usages We are working on solutions to bypass this limitation so you can just boot using your local kernel In short: we are attaching your volumes (disks) using NBD which is not handled by the boot loaders (u-boot for C1, ipxe for VPS and C2*), so we can't get your kernel from your /boot folder and that's why we created bootscript to give you ability to use different kernels. Possible but fairly there a reason a non-vanilla kernel needs to be used? I imagine something in your netboot/remote disk infrastructure needs to be compiled in rather than loaded from initrd? Ofcourse being able to load the kernel from the disk image would be preferable but I would imagine this is somewhat more difficult without reasonably sophisticated boot infrastructure to first boot an initrd to mount the rootfs, parse the local bootloader configuration, get the guest kernel, push this to somewhere that you can get on the next reboot and cycle the machine. If you were able to use vanilla kernels you could then just use the headers available in the distro packages to build DKMS modules like ZFS.įailing that you should probably just also package your kernels for the distros so that people are able to install them to the local disk even if they won't be used so that kernel modules not required to boot the server can be built against them and stored on the network disk and modprobed after system startup. ![]() I'm not familar with Scaleway so apologies if this something already discussed elsewhere. Is there a reason a non-vanilla kernel needs to be used? I imagine something in your netboot/remote disk infrastructure needs to be compiled in rather than loaded from initrd? ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |