Replying to myself again... --- Jane Dogalt <jdogalt@xxxxxxxxx> wrote: > > --- Jesse Keating <jkeating@xxxxxxxxxx> wrote: > > > On Thursday 25 January 2007 17:38, Jane Dogalt wrote: > > > I guess I should go read the rest of that thread to figure out > > where > > > the work remains to get a pungi/mock build that doesn't require > any > > > root priveleges... > > > > A way for users to create and mount loopback filesystems for the > > anaconda > > stage1/2 images. > > > How's this: > > I've been deep in the initrd created by pilgrim for livecds... > > I've recently read someones post on this list suggesting that an > initrd > could be fleshed out into a fully functional rescue system... > > I've been in the initrd pursuing my rebootless installer idea, which > actually looks pretty trivial... (I'm confident it will be done by > fudcon).... > > I've been upset at how much time I've spent on various hacks to > provide > input to qemu, when it appears the --append, --kernel, and --initrd > probably will get me what I need in a cleaner way... > > AND NOW... > > I think I can solve the problem you just stated- > > make an initrd as fat or a bit fatter even than the pilgrim livecd, > then use qemu with no system image other than a specified > kernel/initrd > that come from the running system. Of course, since we no longer need loop/mount/mkfs for initramfs, you of course just build a custom initramfs based on existing ones, but adding the tools you need, i.e. mkfs.<whatever> (and libs, as par pilgrim script) Or, if you really wanted to be sick, you could just pass the host root filesystem as a read only device to qemu, then have your custom initramfs mount it, chroot to it, and work from it mounted read only, writing data either to /dev/hdb as mentioned, or via qemu's emulated samba server. But certainly for pungi, this would be overkill, since all you would need is the short script qmkfs -t <filesystem type> -o <mkfs opts> -r <src root dir> [-s transmogrifyscript.sh] <output_filesystem_image> So it grabs mkfs.<filesystem type> from the host filesystem, copies it to the new initramfs along with the transmogrifyscript (for changing ownership/permissions of files and any other arbitrary stuff). Then it runs qemu with the new initramfs as described, eventually extracting the output to the file specified. I suppose if nobody else writes the above shell script first, I'll get around to it sooner or later... (I'm actually using a much more convoluted system currently which uses an entire fedora core installation that was just generated. Until I was digging deep into the very flexible initramfs in pilgrim (maybe not much different from core, I haven't looked), I didn't realize I could practically do everything I needed to do as root in just the initramfs environment. I want to give credit to Jason https://www.redhat.com/archives/fedora-devel-list/2007-January/msg01191.html who combined with my own sick adventures of creating md-raid1 mirrors underneath dm-snapshots by hand using DavidZ's pilgrim's initramfs eshell, inspired this design of qmkfs. -dmc/jdog ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
