[resending to the lists and Cc, sorry I initially replied only to Askar] On Sat, Sep 20, 2025 at 5:55 AM Askar Safin <safinaskar@xxxxxxxxx> wrote: > On Fri, Sep 19, 2025 at 6:25 PM Nicolas Schichan <nschichan@xxxxxxxxxx> wrote: > > Considering that the deprecation message didn't get displayed in some > > configurations, maybe it's a bit early at the very least. > > I changed my opinion. > Breaking users, who did not see a deprecation message at all, > is unfair. > I will send a patchset soon, which will remove initrd codepath, > which currently contains deprecation notice. And I will put > deprecation notice to > other codepath. Thanks > Then in September 2026 I will fully remove initrd. Is there a way to find some kind of middle ground here ? I'm lead to believe that the main issue with the current code is that it needs to parse the superblocks of the ramdisk image in order to get the amount to data to copy into /dev/ram0. It looks like it is partly because of the ramdisk_start= kernel command line parameter which looks to be a remnant of the time it was possible to boot on floppy disk on x86. This kernel command line allows to look for a rootfs image at an offset into the initrd data. If we assume now that the rootfs image data starts at the beginning of the initrd image and is the only part of the initrd image this would indeed remove a lot of complexity. Maybe it would be possible to remove the identify_ramdisk_image() function and just copy the actual size of /initrd.image into /dev/ram0. This would allow any file system to be used in an initrd image (no just romfs, cramfs, minixfs, ext2fs and squashfs), and this would simplify the code in init/do_mounts_rd.c greatly, with just the function rd_load_image() and nr_blocks() remaining in this file. I can send a patch for that but first I need to sort out my SMTP issues from the other day. Regards, -- Nicolas Schichan
