Bug 613714

(In reply to comment #0)
> my full list of issues with dracut from Mandriva, and they suggested I report
> upstream:
> 
> https://qa.mandriva.com/show_bug.cgi?id=60097
> 
> In short,
> 
> dracut seems not to be thinking of chrooted builds of a initrd img.
> 
> alot of checks are checked against /proc and /sys and in a chroot, those are
> the same as the host running it, if you're planning on building it for other
> hardware, that doesn't work.
> 
> eg: some checks are based on /proc/mounts instead of /etc/fstab
> 
> also, the network and nfs modules are way too big: eg: if you're not using
> dhcp, you shouldn't need dhclient and stuff, same with DNS and bridge stuff
> 
> if you're doing hostonly, it should be minimal, and if you're chrooting, it
> should check how it will be, after you've booted the machine using PXE, and not
> how it is with the host machine.
> 
> also, when using nfs, but not doing hostonly, one should have ALL network
> drivers included, and maybe even wireless as well, isn't PXE over wireless also
> possible?    

hostonly is only for the host it currently runs on.. just don't do the "hostonly" mode, if you want to build for another machine or want to be generic :-)

like the name says: hostonly IS ONLY FOR THE HOST!

(In reply to comment #0)
> also, the network and nfs modules are way too big: eg: if you're not using
> dhcp, you shouldn't need dhclient and stuff, same with DNS and bridge stuff

You can exclude any dracut module on the command line or in the config file. Read the manpage.

(In reply to comment #2)
> (In reply to comment #0)
> > also, the network and nfs modules are way too big: eg: if you're not using
> > dhcp, you shouldn't need dhclient and stuff, same with DNS and bridge stuff
> 
> You can exclude any dracut module on the command line or in the config file.
> Read the manpage.    

ok, sry, I see your problem. You might want to copy&paste the module and rip out all you don't need.

I do see your point, but i'm not trying to make a generic one, i'm trying to make a specific one for that particular machine.

(also the network drivers are ALWAYS looked upon at the host, nevermind if you're not specifying hostonly.)


the thing is, if you want a machine to boot from PXE and from an NFS share; the only way to make a initrd image, is through a chrooted install, you make the nfs mount point, you set up your packaging manager and your packages, and then you chroot in it and try to make a initrd for it.

if i'd make a generic initrd, it's huge, getting that through PXE is very very slow. so that's what i want to make a hostonly one.

and the thing is, when you've chrooted, you have all the info to make a hostonly one. (except network driver; which should be able to be specified by dracut arguments, because the generic one should have ALL network drivers and not only the one currently in use on that host (as it is now))

instead of using /proc/mounts, use /etc/fstab; and stuff like that.

And that is my point. if you agree with me, it'd be happy to send you some patches.

I mean, if you want to make a mkinitrd replacement, it should replace all of it.

The thing is, if i patch stuff to make it work in chroots with hostonly, only to have the dracut devs or contributers add more work based on /proc ... it makes my life more difficult.

also the network module could be split to allow smaller initrds

eg: network-bridge, network-dhcp, network-dns, ...

also, why does plymouth depend on crypt? is that absolutely necessary?

(In reply to comment #5)
> also the network module could be split to allow smaller initrds
> 
> eg: network-bridge, network-dhcp, network-dns, ...

agreed

> 
> also, why does plymouth depend on crypt? is that absolutely necessary?    

already fixed in git

(In reply to comment #4)
> the thing is, if you want a machine to boot from PXE and from an NFS share; the
> only way to make a initrd image, is through a chrooted install, you make the
> nfs mount point, you set up your packaging manager and your packages, and then
> you chroot in it and try to make a initrd for it.
> 
> if i'd make a generic initrd, it's huge, getting that through PXE is very very
> slow. so that's what i want to make a hostonly one.

Ok, then make a generic one, boot the machine with it, then create the host-only image on the target machine and you are set and done!

(In reply to comment #4)
> instead of using /proc/mounts, use /etc/fstab; and stuff like that.

Seems like the multipath module violated the mantra and checks the root device even in the generic mode.

(In reply to comment #4)
> And that is my point. if you agree with me, it'd be happy to send you some
> patches.

https://apps.sourceforge.net/trac/dracut/wiki
git://dracut.git.sourceforge.net/gitroot/dracut/dracut

Patches are always welcome. Best to send them to the mailing list.

i send 3 patches to the mailing list

This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

(In reply to comment #7)
> (In reply to comment #4)
> > the thing is, if you want a machine to boot from PXE and from an NFS share; the
> > only way to make a initrd image, is through a chrooted install, you make the
> > nfs mount point, you set up your packaging manager and your packages, and then
> > you chroot in it and try to make a initrd for it.
> > 
> > if i'd make a generic initrd, it's huge, getting that through PXE is very very
> > slow. so that's what i want to make a hostonly one.
> 
> Ok, then make a generic one, boot the machine with it, then create the
> host-only image on the target machine and you are set and done!

Very late update to this comment, but: I tried your approach of making a host-only image from the host, but on Fedora 16 this does not work, new bug created under number 817158.

This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping