[gentoo-dev] Libreoffice without sane?
Hello. Today I discovered that libreoffice wants to install a dozen new dependencies. I understand that this is probably due to some modularization effort but I don't have a scanner and I don't plan to, so I am trying to hack the ebuild so sane can be enabled and disabled via an USE flag, but having no luck for now. Is there a way to completely disable sane in the LO build or is it a mandatory dependency? I found --with-system-sane-headers, which I guess is the way I'll have to go if there's no way to completely disable sane. At least I will save one dependency there. I am not saying it's a big win but it's a feature I'll never use. -- Jesús Guerrero Botella
Re: [gentoo-dev] /usr vs. initramfs redux
* Robin H. Johnson schrieb am 05.08.11 um 02:46 Uhr: [...] That leaves the only reasonable solution as #2. In terms of minimal impact, I propose that we offer users with a static system an absolutely minimal initramfs, that _just_ mounts the required directories. No modules, no LVM, no MD, no crypto etc - if you want that functionality, go and use genkernel or dracut. If your fstab contains a line like: /dev/sdXN /usr ... Then this initramfs is for you. The minimal initramfs would do the following. 1. Mount devtmpfs/sysfs/procfs as needed to access devices. 2. Mount real_root to /newroot 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab 4.1. If /newroot/etc/initramfs.mount does not exist Assume it contains only: /usr /var 5. Mount the combined items from said files 6. pivot_root. That sounds like a good compromise to me! Another thing to consider: /etc/init.d/localmount should check whats already mounted and leave that out. But it will act as fallback if the minimal initramfs fails to mount /usr or /var for any reason. That way anybody migrating to that minitramfs will not risc an unbootable system. -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgpm0QBMwgCgh.pgp Description: PGP signature
Re: [gentoo-dev] /usr vs. initramfs redux
On Fri, Aug 5, 2011 at 6:16 AM, Marc Schiffbauer msch...@gentoo.org wrote: * Robin H. Johnson schrieb am 05.08.11 um 02:46 Uhr: [...] That leaves the only reasonable solution as #2. In terms of minimal impact, I propose that we offer users with a static system an absolutely minimal initramfs, that _just_ mounts the required directories. No modules, no LVM, no MD, no crypto etc - if you want that functionality, go and use genkernel or dracut. If your fstab contains a line like: /dev/sdXN /usr ... Then this initramfs is for you. The minimal initramfs would do the following. 1. Mount devtmpfs/sysfs/procfs as needed to access devices. 2. Mount real_root to /newroot 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab 4.1. If /newroot/etc/initramfs.mount does not exist Assume it contains only: /usr /var 5. Mount the combined items from said files 6. pivot_root. That sounds like a good compromise to me! Why would we build yet another initramfs vs just making dracut work reliably? You can already build dracut without support for lvm+raid+luks/etc. If we're going to require an initramfs then we should make sure that ALL gentoo-provided solutions work before we expand the need for a mounted /usr. The genkernel team already mentioned that they plan to switch to dracut, so we really just need to get dracut working properly. That said, nobody is preventing anybody from re-inventing the wheel if they wish to do so. I just wouldn't just offer it up as an example of a perfectly acceptable migration strategy, when we've had a lvm+raid howto for years that wouldn't be compatible with it. Rich
Re: [gentoo-dev] /usr vs. initramfs redux
* Rich Freeman schrieb am 05.08.11 um 14:42 Uhr: On Fri, Aug 5, 2011 at 6:16 AM, Marc Schiffbauer msch...@gentoo.org wrote: * Robin H. Johnson schrieb am 05.08.11 um 02:46 Uhr: [...] That leaves the only reasonable solution as #2. In terms of minimal impact, I propose that we offer users with a static system an absolutely minimal initramfs, that _just_ mounts the required directories. No modules, no LVM, no MD, no crypto etc - if you want that functionality, go and use genkernel or dracut. If your fstab contains a line like: /dev/sdXN /usr ... Then this initramfs is for you. The minimal initramfs would do the following. 1. Mount devtmpfs/sysfs/procfs as needed to access devices. 2. Mount real_root to /newroot 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab 4.1. If /newroot/etc/initramfs.mount does not exist Assume it contains only: /usr /var 5. Mount the combined items from said files 6. pivot_root. That sounds like a good compromise to me! Why would we build yet another initramfs vs just making dracut work reliably? You can already build dracut without support for lvm+raid+luks/etc. If dracut will have some sort of minimalistic mode where it would generate such an initrd that would be ok IMO. OTOH the initrd that Robin described would be a very static solution with almost no dependencies, so if genkernel had a USE flag like dracut it would be possible to build it without dracut dependency and thus would allow for smaller systems. -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgpOneX3Jhj27.pgp Description: PGP signature
Re: [gentoo-dev] /usr vs. initramfs redux
On Fri, Aug 5, 2011 at 7:42 AM, Rich Freeman ri...@gentoo.org wrote: On Fri, Aug 5, 2011 at 6:16 AM, Marc Schiffbauer msch...@gentoo.org wrote: * Robin H. Johnson schrieb am 05.08.11 um 02:46 Uhr: [...] That leaves the only reasonable solution as #2. In terms of minimal impact, I propose that we offer users with a static system an absolutely minimal initramfs, that _just_ mounts the required directories. No modules, no LVM, no MD, no crypto etc - if you want that functionality, go and use genkernel or dracut. If your fstab contains a line like: /dev/sdXN /usr ... Then this initramfs is for you. The minimal initramfs would do the following. 1. Mount devtmpfs/sysfs/procfs as needed to access devices. 2. Mount real_root to /newroot 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab 4.1. If /newroot/etc/initramfs.mount does not exist Assume it contains only: /usr /var 5. Mount the combined items from said files 6. pivot_root. That sounds like a good compromise to me! Why would we build yet another initramfs vs just making dracut work reliably? You can already build dracut without support for lvm+raid+luks/etc. If we're going to require an initramfs then we should make sure that ALL gentoo-provided solutions work before we expand the need for a mounted /usr. The genkernel team already mentioned that they plan to switch to dracut, so we really just need to get dracut working properly. That said, nobody is preventing anybody from re-inventing the wheel if they wish to do so. I just wouldn't just offer it up as an example of a perfectly acceptable migration strategy, when we've had a lvm+raid howto for years that wouldn't be compatible with it. Rich In point of fact all modern Linux kernels have an initramfs built in now, that when empty is effectively bypassed, so there is no wheel reinvention. To quote the docs [1] All 2.6 Linux kernels contain a gzipped cpio format archive, which is extracted into rootfs when the kernel boots up. After extracting, the kernel checks to see if rootfs contains a file init, and if so it executes it as PID 1. If found, this init process is responsible for bringing the system the rest of the way up, including locating and mounting the real root device (if any). If rootfs does not contain an init program after the embedded cpio archive is extracted into it, the kernel will fall through to the older code to locate and mount a root partition, then exec some variant of /sbin/init out of that. [1] /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt While dracut may help with the process of creating the initramfs, its really not a terribly complicated endeavor, and from further reading (specifically as related to the desired removal of md autodetection), it is the full intention of the kernel upstream that initramfs be the new path forward in handling things such as separate /usr, raid volumes, and so on. Further, dracut will introduce yet another dep in base-system (I am guessing here), that is not more than perhaps a convenience. I note here, that I have not used dracut as the well documented method of creating an initramfs is straight forward enough that I did not require anything too fancy to handle mounting raid1 volumes, and providing a recovery environment with networking and ssh. This, at least to me, seems like an excellent opportunity to nicely document what can be done with an initramfs (in basic and advanced forms, as there are some really fancy things one can do with initramfs's), and how Gentoo is recommending their usage in the cases outlined by Robin and others. So, I am +1 on robbat2's solution and -1 on dracut. That said, I am fully willing to alter my position when presented with a better argument. Lastly, I do have a few minor concerns about how this default initramfs will be dealt with, however those can wait. Mainly, I simply desire the flexibility to replace the Gentoo-shipped version with a custom version easily. Thanks and kind regards, Matt -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] /usr vs. initramfs redux
On 08/05/2011 04:12 PM, Marc Schiffbauer wrote: * Rich Freeman schrieb am 05.08.11 um 14:42 Uhr: On Fri, Aug 5, 2011 at 6:16 AM, Marc Schiffbauer msch...@gentoo.org wrote: * Robin H. Johnson schrieb am 05.08.11 um 02:46 Uhr: [...] That leaves the only reasonable solution as #2. In terms of minimal impact, I propose that we offer users with a static system an absolutely minimal initramfs, that _just_ mounts the required directories. No modules, no LVM, no MD, no crypto etc - if you want that functionality, go and use genkernel or dracut. If your fstab contains a line like: /dev/sdXN /usr ... Then this initramfs is for you. The minimal initramfs would do the following. 1. Mount devtmpfs/sysfs/procfs as needed to access devices. 2. Mount real_root to /newroot 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab 4.1. If /newroot/etc/initramfs.mount does not exist Assume it contains only: /usr /var 5. Mount the combined items from said files 6. pivot_root. That sounds like a good compromise to me! Why would we build yet another initramfs vs just making dracut work reliably? You can already build dracut without support for lvm+raid+luks/etc. If dracut will have some sort of minimalistic mode where it would generate such an initrd that would be ok IMO. OTOH the initrd that Robin described would be a very static solution with almost no dependencies, so if genkernel had a USE flag like dracut it would be possible to build it without dracut dependency and thus would allow for smaller systems. -Marc To clarify, By dependencies in dracut you mean udev? And by smaller systems you mean systems without udev? Then yes, such minimal initramfs should propably be covered in the embedded's documentation, but otherwise trying to avoid dracut is reinventing the wheel...
Re: [gentoo-dev] /usr vs. initramfs redux
On Fri, Aug 5, 2011 at 9:25 AM, Matthew Summers quantumsumm...@gentoo.org wrote: In point of fact all modern Linux kernels have an initramfs built in now, that when empty is effectively bypassed, so there is no wheel reinvention. To quote the docs [1] Yes, but that embedded initramfs doesn't actually do much of anything right now. It may exist from an architecture standpoint, but it doesn't mean that there isn't a lot of work to be done which would be redundant with work already done elsewhere. I can see where you might want a simpler solution than dracut as an alternative for more embedded setups/etc. It probably would be cleaner to just create a new solution than modify dracut to get rid of udev/etc. In any case, as long as a solution exists for md+lvm+luks+/usr before we start breaking more stuff than is already broken, then we should be fine. Having more than one optional solution is fine. While I don't think that gentoo needs to be another Ubuntu, having reasonable out-of-the-box support for one of the major desktop environments running on md+lvm+luks seems pretty useful. Rich
Re: [gentoo-dev] /usr vs. initramfs redux
On Fri, Aug 05, 2011 at 08:25:19AM -0500, Matthew Summers wrote: This, at least to me, seems like an excellent opportunity to nicely document what can be done with an initramfs (in basic and advanced forms, as there are some really fancy things one can do with initramfs's), and how Gentoo is recommending their usage in the cases outlined by Robin and others. I'm all in favor of documenting what an initramfs does (or at least what it is supposed to do), how it works, how to create one, how to debug issues while booting with one, etc. That said, I'm a bit hesitant to describing that we recommend it regardless of the situation. What is wrong with describing when? At least inform our users that the udev rules have evolved to more than just detect and mknod scripts and that they are now relying on files and binaries available in other locations, like /usr and /var. How does the tool that creates an initramfs know which files to copy from /usr and /var anyhow? Also, how well does this play with all our profiles (so not only the popular architectures)? What about SELinux and/or grSecurity's RBAC model? Are these supported throughout the initramfs? Wkr, Sven Vermeulen
Re: [gentoo-dev] /usr vs. initramfs redux
On Fri, Aug 05, 2011 at 09:57:08AM -0400, Rich Freeman wrote:
In any case, as long as a solution exists for md+lvm+luks+/usr before
we start breaking more stuff than is already broken, then we should be
fine. Having more than one optional solution is fine. While I don't
think that gentoo needs to be another Ubuntu, having reasonable
out-of-the-box support for one of the major desktop environments
running on md+lvm+luks seems pretty useful.
My proposed minimal initramfs is an alternative to dracut for users with
trivial systems. For _ALL_ of the other cases, genkernel/dracut should
be used. Patches to add any of that other support to the minimal
initramfs will be rejected.
Definition of a trivial system:
/, /usr, /var are contained on or within device nodes available in
devtmpfs at the time the kernel invokes the initramfs.
Examples of non-trivial systems:
- {/, /usr, /var} on any of LVM, LUKS, NFS, iSCSI
- {/, /usr, /var} on MD that is not auto-assembled by the kernel [1].
- etc.
The initramfs would be rebuilt extremely infrequently, since it doesn't
contain any kernel modules, and reads the actual configuration from the
real root fs.
[1]: Upstream MD kernel folk have said everybody wanting to do MD
detection should migrate to initramfs for detection, as there at lot of
corner cases in detection where userspace is needed to make a sane
decision. Also if you use non-msdos partition tables, or large MDs.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] /usr vs. initramfs redux
Hi, my knowledge of booting from an initramfs is limited right now, so keep that in mind. However, I will attempt to answer some of your questions. On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote: I'm all in favor of documenting what an initramfs does (or at least what it is supposed to do), how it works, how to create one, how to debug issues while booting with one, etc. That said, I'm a bit hesitant to describing that we recommend it regardless of the situation. What is wrong with describing when? At least inform our users that the udev rules have evolved to more than just detect and mknod scripts and that they are now relying on files and binaries available in other locations, like /usr and /var. It looks like the situation where we will have to have one is if /usr and /var are not on the same file system as /, because of how udev has evolved. How does the tool that creates an initramfs know which files to copy from /usr and /var anyhow? My understanding is that nothing gets copied from /usr and /var, and it doesn't have to. Here is my basic understanding of how the boot sequence works: 1) rootfs is mounted on /. Rootfs contains the contents of the initramfs. 2) the init program inside the initramfs is run. 3) This init program will mount the real /usr and /var. 4) This init program will then mount the real root on top of rootfs. (there is a call that does this, but I'll need to look that up again). I vaguely remember reading that you don't mount the real root on /newroot then pivet_root as mentioned earlier in this thread; I think that is part of the old initrd method. 5) This init program will now run /sbin/init or which ever init program the user wants to run. Also, how well does this play with all our profiles (so not only the popular architectures)? What about SELinux and/or grSecurity's RBAC model? Are these supported throughout the initramfs? This one I can't answer. Regards, William pgpt5o4tlOXOe.pgp Description: PGP signature
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
Historically those DIRs contained all utils/tools to manage the system and fix problems etc. when you are unable to get /usr up, i.e. when it's remote. The rootfs basically contained all the core system-tools minus all the apps, which usually were managed centrally. With bbox of course one could mimic this to a certain point easily within an initramfs though. Regards -Sven On Mon, 2011-08-01 at 15:45 +0300, Samuli Suominen wrote: Historically /bin, /sbin, /lib had the purpose to contain the utilities to mount /usr. This role can now be taken by the initramfs. Because the initramfs knows, where to find the root partition (which includes /etc), it can parse /etc/fstab and other configuration files and mount /usr before it finally switches the root partition and executes /usr/bin/init. From this point on init mounts the remaining partitions in /etc/fstab and the system starts as usual. Cheers, Kacper
Re: [gentoo-dev] /usr vs. initramfs redux
On Fri, Aug 5, 2011 at 8:42 PM, William Hubbs willi...@gentoo.org wrote: On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote: How does the tool that creates an initramfs know which files to copy from /usr and /var anyhow? My understanding is that nothing gets copied from /usr and /var, and it doesn't have to. Here is my basic understanding of how the boot sequence works: 1) rootfs is mounted on /. Rootfs contains the contents of the initramfs. Ok, so the initfs is typically in /boot, though it need not be. It needs to be someplace the bootloader can find it, and with grub legacy that typically means on a bare hard drive partition, or one using md raid-1 with older metadata. The initramfs doesn't need to find itself - the bootloader loads it into ram and passes its address to the kernel when executing it. 2) the init program inside the initramfs is run. 3) This init program will mount the real /usr and /var. So, this is the chicken and egg bit that led to the question about how the tool that creates initramfs knows what to copy from /usr, etc. If /usr can be mounted without any files from /usr, then clearly booting without /usr mounted shouldn't be a problem (just mount it early). If it does need files from /usr, then the initramfs has to contain those files since /usr isn't mounted yet. The answer isn't that complicated - the tool just knows what files are needed from a hardcoded list/etc. It might also use some static linked tools. It might also use a subset of the regular udev/etc tools - it doesn't need to configure your video capture card and mouse - it just needs to find anything that could contain the root filesystem (and now /usr as well). Keep in mind the initramfs does not need to fully initialize the system, and it doesn't need to do it in a way compatible with anything that will subsequently load. It doesn't need to populate /dev the way the rest of the stuff in the distro expects it to be, since the /dev it is populating will get unmounted/wiped/etc before switching roots. Initramfs just has to quickly operate in a scratch filesystem, mount the real filesystems, then wipe itself out and chroot. It doesn't need to be compatible with the latest version of dbus/hal/X11/openrc/etc - it just needs to be internally self-consistent. For whatever reason it still isn't working for me (using dracut) - for some bizarre reason it can't auto-detect my raid, even though running mdadm --assemble --scan and exiting the dash shell allows it to boot. Oh well - I'm sure I'll work it out. Then of course somebody needs to patch it to mount /usr as well, or grab a copy of whatever Fedora is doing if it is open source. And as previously stated I'm fine with a more minimal initramfs being provided as well, although my feeling is that if the dracut solution works reliably it seems redundant. In fact, dracut -H creates a host-only solution that should only have minimal drivers installed, and once it finishes running it should free any RAM it is using and not leave any processes around. Rich
[gentoo-dev] Re: /usr vs. initramfs redux
Rich Freeman posted on Fri, 05 Aug 2011 21:04:50 -0400 as excerpted: On Fri, Aug 5, 2011 at 8:42 PM, William Hubbs willi...@gentoo.org wrote: On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote: How does the tool that creates an initramfs know which files to copy from /usr and /var anyhow? My understanding is that nothing gets copied from /usr and /var, and it doesn't have to. Here is my basic understanding of how the boot sequence works: 1) rootfs is mounted on /. Rootfs contains the contents of the initramfs. Ok, so the initfs is typically in /boot, though it need not be. It needs to be someplace the bootloader can find it, and with grub legacy that typically means on a bare hard drive partition, or one using md raid-1 with older metadata. The initramfs doesn't need to find itself - the bootloader loads it into ram and passes its address to the kernel when executing it. With a personal knowledge caveat similar to that of williamh's, I believe tha above to be incorrect. AFAIK, the distinction between initrd and initramfs is the following: initrd: An initrd is a file separate from the kernel, so yes, the bootloader needs to know about and pass its information to the kernel. initramfs: An initramfs, as alluded to in the quote from the documentation in an earlier post, is a cpio archive appended to the kernel image itself -- no separate initrd file, and the kernel knows to look for the compressed image as loaded into memory after the end of the kernel code itself. At kernel build time, if this feature is configured the kernel make process will check to see if a suitable prebuild cpio archive is available and append it to the kernel image if so. If the cpio archive is not available yet but there's a configuration for building it, it'll be built, then appended to the kernel image. As such, the bootloader doesn't need to point the kernel at the initramfs since the kernel already knows where to find it as loaded into memory as part of the kernel image file, and certain kernel commandline options (AFAIK root=, init=) that would normally apply to the initrd if one was used, apply to the final realroot instead. An initramfs thus has less to go wrong, since it's appended to the kernel image as part of the same file at build time, so the two are always kept together. While it's still possible that the kernel fails to update its initramfs image at build-time, once that's correct, the boot loader can't accidentally be pointed at the wrong initrd, since an initramfs becomes part of the same kernel file as the kernel image itself. (I've read that it's possible to have both an initramfs as appended to the kernel image, and an initrd as configured on the kernel command line by the boot loader, thus effectively creating a three-stage boot, initramfs, initrd, realroot. I've no idea whether that's true or not, but the idea of trying to keep track of what belongs in one vs. the other strikes me as way more complex than it'd be worth for most gentoo users, altho I can see that it might be useful for users of binary distros with prebuilt kernel images, who wish to do additional stuff in an initrd, without messing with the prebuilt and presumably supported kernel image as distributed by their distro, with its own prebuilt initramfs appended. It could also be useful for certain gentoo users, for instance those doing remote-boot kernels with the basics applying to most instances found in the initramfs, while any necessary configuration specific to only a subset could be loaded as an initrd.) 2) the init program inside the initramfs is run. 3) This init program will mount the real /usr and /var. So, this is the chicken and egg bit that led to the question about how the tool that creates initramfs knows what to copy from /usr, etc. If /usr can be mounted without any files from /usr, then clearly booting without /usr mounted shouldn't be a problem (just mount it early). If it does need files from /usr, then the initramfs has to contain those files since /usr isn't mounted yet. The answer isn't that complicated - the tool just knows what files are needed from a hardcoded list/etc. No quibbles with this or the rest of what you wrote, and indeed, I agree that the question needed asked/answered. (It still hasn't been answered in any detail, but I'm not sure if that was the intent of asking the question. The general it's hardcoded answer is sufficient at a suitably high level.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] /usr vs. initramfs redux
Hi Rich, On Fri, Aug 05, 2011 at 09:04:50PM -0400, Rich Freeman wrote: On Fri, Aug 5, 2011 at 8:42 PM, William Hubbs willi...@gentoo.org wrote: On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote: How does the tool that creates an initramfs know which files to copy from /usr and /var anyhow? My understanding is that nothing gets copied from /usr and /var, and it doesn't have to. Here is my basic understanding of how the boot sequence works: 1) rootfs is mounted on /. Rootfs contains the contents of the initramfs. Ok, so the initfs is typically in /boot, though it need not be. It needs to be someplace the bootloader can find it, and with grub legacy that typically means on a bare hard drive partition, or one using md raid-1 with older metadata. The initramfs doesn't need to find itself - the bootloader loads it into ram and passes its address to the kernel when executing it. Not quite. It is actually inside the kernel binary. You are thinking of an initrd. Look at these files: /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt. /usr/src/linux/Documentation/early-userspace/README 2) the init program inside the initramfs is run. 3) This init program will mount the real /usr and /var. So, this is the chicken and egg bit that led to the question about how the tool that creates initramfs knows what to copy from /usr, etc. If /usr can be mounted without any files from /usr, then clearly booting without /usr mounted shouldn't be a problem (just mount it early). If it does need files from /usr, then the initramfs has to contain those files since /usr isn't mounted yet. All we are trying to do is get /usr and /var mounted before running udev. All you really need in the initramfs is whatever is necessary to get the file systems mounted. Keep in mind the initramfs does not need to fully initialize the system, and it doesn't need to do it in a way compatible with anything that will subsequently load. It doesn't need to populate /dev the way the rest of the stuff in the distro expects it to be, since the /dev it is populating will get unmounted/wiped/etc before switching roots. Actually the /dev in the initramfs will not be wiped; it will become /dev in the running system. The other thing we will need is to have CONFIG_DEVTMPFS set to y in the kernel config. This will create a tmpfs containing all devices that the kernel knows about, which should be mounted on /dev. This CONFIG_DEVTMPFS=y setting is also preferred by upstream udev. Initramfs just has to quickly operate in a scratch filesystem, mount the real filesystems, then wipe itself out and chroot. It doesn't need to be compatible with the latest version of dbus/hal/X11/openrc/etc - it just needs to be internally self-consistent. My understanding is it doesn't do anything like a chroot. Instead, it mounts the real root directly on top of itself. For whatever reason it still isn't working for me (using dracut) - for some bizarre reason it can't auto-detect my raid, even though running mdadm --assemble --scan and exiting the dash shell allows it to boot. Oh well - I'm sure I'll work it out. Then of course somebody needs to patch it to mount /usr as well, or grab a copy of whatever Fedora is doing if it is open source. I think it is more simple than this; I will be looking into the steps to make a trivial initramfs soon. William pgpbEMn5q04l0.pgp Description: PGP signature
Re: [gentoo-dev] /usr vs. initramfs redux
On Fri, Aug 5, 2011 at 10:37 PM, William Hubbs willi...@gentoo.org wrote: Hi Rich, On Fri, Aug 05, 2011 at 09:04:50PM -0400, Rich Freeman wrote: On Fri, Aug 5, 2011 at 8:42 PM, William Hubbs willi...@gentoo.org wrote: On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote: How does the tool that creates an initramfs know which files to copy from /usr and /var anyhow? My understanding is that nothing gets copied from /usr and /var, and it doesn't have to. Here is my basic understanding of how the boot sequence works: 1) rootfs is mounted on /. Rootfs contains the contents of the initramfs. Ok, so the initfs is typically in /boot, though it need not be. It needs to be someplace the bootloader can find it, and with grub legacy that typically means on a bare hard drive partition, or one using md raid-1 with older metadata. The initramfs doesn't need to find itself - the bootloader loads it into ram and passes its address to the kernel when executing it. Not quite. It is actually inside the kernel binary. You are thinking of an initrd. Look at these files: /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt. /usr/src/linux/Documentation/early-userspace/README The initramfs cpio archive does not HAVE to be inside the kernel binary. It may be assembled as a separate file (perhaps in /boot), and passed to the kernel by the bootloader, just as Rich describes. See the section External initramfs images in ramfs-rootfs-initramfs.txt.
