related to 6/7, mayflower loop device cleanup proposal

[Douglas McClendon]

Jeremy,

Now that you're into the guts of genMinInstDelta (patch 6/7), maybe this 
topic is very timely-

I've recently (like finished this morning) done a personal rewrite of 
the functionality of mayflower.  Setting asside why I did that, here is 
a proposal/notation relating that 6/7 patch.


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).

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).

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?

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.

Just an idea...  And I will post that rewrite soon enough, in case other 
parts of it are useful idea fodder...

-dmc

[Jeremy Katz]

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.

>  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.

>  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.

>  Just an idea...  And I will post that rewrite soon enough, in case
> other 
>  parts of it are useful idea fodder... 
Sure, sounds good.

Jeremy

[Douglas McClendon]

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

[Jeremy Katz]

On Mon, 2007-09-17 at 14:37 -0500, Douglas McClendon wrote:
>  Jeremy Katz wrote:
>  > On Mon, 2007-09-17 at 13:55 -0500, Douglas McClendon wrote:
>  >> 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" 
Yeah, I think that's pretty much where I sit :)

>  > 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?) 
To be honest, the only things that are there are a few mknods.  And I
can't see any good reason why those have to be done at initrd creation
rather than at run-time

Jeremy