| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <451CE3B8.70706@tls.msk.ru> Date: Fri, 29 Sep 2006 13:13:28 +0400 From: Michael Tokarev <mjt@....msk.ru> To: Jan Engelhardt <jengelh@...ux01.gwdg.de> CC: Stephan Wiebusch <stephanwib@...nline.de>, linux-kernel@...r.kernel.org Subject: Re: Initrd and ramdisk support Jan Engelhardt wrote: >> Unpacking initramfs...<0>Kernel panic - not syncing: bad gzip magic numbers >> Unpacking initramfs...<0>Kernel panic - not syncing: no cpio magic >> >> i luckily was able to determine the malefactor. There was the initrd support >> built into the kernel while the ramdisk driver was just built as a module. >> >> Is it senseful to have the possibility to built the Initramfs/Initrd-support >> without having the ramdisk driver forced to be integrated also? > > I hardly see a point in using initrd support without ramdisk. Where would you > store the initrd on instead? I build kernels without ramdisk built into, but using initramfs, for quite some time already. There was a patch somewhere around 2.6.15 or so, that removed dependency of INITRD from RAMDISK, just a small Kconfig change. Now it's in the mainline. For initramfs, there's no need for ramdisk - it reads the FS image from memory (as passed to by loader), and unpacks it into ramfs - no ramdisk is involved here. /mjt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists