Commit?73fb321a5d56b ("lua: make initramfs structures full userdata objects with methods") broke my boot script, requiring a workaround along the lines of the patch below: Is this an intentional user-visible change? I note the documentation at https://www.syslinux.org/wiki/index.php?title=Lua.c32#Example:_Print_kernel.2Finitramfs_information_and_load_them hasn't been updated and still shows what to do for 6.03 without any hint that it won't be compatible with 6.04. Also... if we are doing this, then why do we need to pass the first 'initramfs' argument into the initramfs.load() function? Surely it should have access to 'self' without the caller having to explicitly pass it in? Isn't that kind of the point? --- a/boot/syslinux.lua +++ b/boot/syslinux.lua @@ -87,8 +87,14 @@ ?-- Booting the kernel ? ?local kernel = sl.loadfile("/BZIMAGE") -local initramfs = sl.initramfs_init() -sl.initramfs_load_archive(initramfs, "/INITRD") +local initramfs +if sl.initramfs_init ~= nil then +??initramfs = sl.initramfs_init() +??sl.initramfs_load_archive(initramfs, "/INITRD") +else +??initramfs = sl.initramfs() +??initramfs.load(initramfs, "/INITRD") +end ? ?local cmdline =??get_content("/CMDLINE") -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5213 bytes Desc: not available URL: <http://www.zytor.com/pipermail/syslinux/attachments/20180802/030ad700/attachment.bin>
David Woodhouse <dwmw2 at infradead.org> writes:> Commit?73fb321a5d56b ("lua: make initramfs structures full userdata > objects with methods") broke my boot script, requiring a workaround > along the lines of the patch below: > > Is this an intentional user-visible change? I note the documentation at > https://www.syslinux.org/wiki/index.php?title=Lua.c32#Example:_Print_kernel.2Finitramfs_information_and_load_them > hasn't been updated and still shows what to do for 6.03 without any > hint that it won't be compatible with 6.04.Hi! Please accept my apologies. This was an intentional API change, but it wasn't intended to be user visible on the basis that nobody used it yet. Frankly, I didn't expect anybody come after me almost four years after I committed it...> Also... if we are doing this, then why do we need to pass the first > 'initramfs' argument into the initramfs.load() function? Surely it > should have access to 'self' without the caller having to explicitly > pass it in? Isn't that kind of the point?Yes it is. You have to use the Lua method syntax to achieve that as shown in com32/lua/doc/syslinux.asc: local sl = require "syslinux" kernel = sl.loadfile "/SuSE-11.1/x86_64/linux" print("File name: " .. kernel:name() .. " size: " .. kernel:size()) initrd1 = "/SuSE-11.1/x86_64/initrd" initrd = sl.initramfs() initrd:load(initrd1) print ("File name: " .. initrd1 .. " size: " .. initrd:size()) sl.boot_it(kernel, initrd, "init=/bin/bash") Please refer to the in-tree documentation in preference to the online one. -- Regards, Feri
Seemingly Similar Threads
- Building a http query string including SMBIOS Serial Number to load a specific kernel
- [PATCH][git-pull] lua: make kernel and initrd progress output match in sl_boot_linux
- boot 32 or 64 kernel depending on cpu
- [PATCH][git-pull] lua: make kernel and initrd progress output match in sl_boot_linux
- [PATCH][git-pull] lua: fix broken bindings, switch to using methods, document things