Jeremy Katz wrote:
On Mon, 2007-09-17 at 13:55 -0500, Douglas McClendon wrote:
Now that you're into the guts of genMinInstDelta (patch 6/7), maybe this topic is very timely-

Heh, indeed :-)  -ENEEDMORECAFFEINE first though before I finish looking
at 6 and 7.

Yeah, I'm at the end of my caffeine run, so I'll respond to further stuff much later tonight or tomorrow.


All those hard coded (117/118/119/120/121) loop devices used are very ugly.

Probably they should get replaced with dynamic choices via losetup -f, as my recent livecd-creator patch did (though it was already using dynamic via losetup -a prior, different issue).

Agreed.  Given that most people don't use loop devs explicitly, I can't
see how this would be problematic.  Too bad losetup doesn't have a "find
the first available loopdev backwards" option, though.  Because that
would be even slicker as if there _are_ things lying around with
loopdevs hard-coded, they wouldn't break.

Between that and the *nod* I'll take that as "go ahead and make the patch, and for the rare people that have broken hardcoded loop stuff that can't handle taken low-numbered loop devices, *and* want to run those broken things in a LiveOS environment, too bad"


I think I can put together a patch that does this. Will probably even look pretty slick, as they info would get conveyed via udev rules dynamically generated in mayflower-init (just like existing loop120 and loop121 rules, but based on dynamic rather than hard-coded loop devices).

*nod*
The other thing, is I seemed to notice that, at least for my test cases, the mknod-s of the /dev/loop??? devices in the mayflower-initramfs seem unnecessary, as udev seems to create them just fine. Anybody (david? jeremy?) know of why they are perhaps needed?

pre-udev version I suspect.  There shouldn't be a need for it any more
that I can see

I know you mentioned Jeremy, about merging mayflower into mkinitrd. In fact, that is one reason why I did the rewrite, as I need for it to remain runnable as non-root. You should probably get mkinitrd that way too, but...? But my point is that it's still probably good to do these cleanups to mayflower, as they will make the merge into mkinitrd that much easier/better.

FWIW, I have a branch of mkinitrd up that has the changes so that
booting a live image with an initrd generated by it "works".  The caveat
being that some things like the udev rules aren't currently there and I
sort of want to figure out a different way of conveying that.  But ran
out of time.  For anyone interested, 'git clone
http://katzj.fedorapeople.org/git/mkinitrd.git'.

And yeah, the amount of mkinitrd requiring being run as root is so small
and piddly that it really is quite annoying.  Just haven't had the round
tuits to fix them.

Is it anything that can't be handled by the fakeroot tool that Colin recently pointed me at? (and perhaps mtools?)

-dmc

--
Fedora-livecd-list mailing list
Fedora-livecd-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list

Reply via email to