Gentoo Archives: gentoo-releng

From: Brad House <brad_mssw@g.o>
To: Martin Schlemmer <azarah@g.o>
Cc: Brad House <brad_mssw@g.o>, gentoo-releng@l.g.o
Subject: Re: [gentoo-releng] x86-livecd - bugs and suggestions
Date: Mon, 02 Feb 2004 22:58:45
> > And /newroot? Lets clarify:
/newroot should never be visible as it's strictly in the initrd, and pivot_root will pretty much clobber that, it's something you don't need to handle.
> 1) /mnt/livecd will be your zisofs image/whater
It is the loopback mount location for normal or gcloop filesystems. zisofs is not a loopback device, so it won't make use of that.
> 2) /mnt/cdrom will be the cdrom itself ?
> > So basically, the looback stuff just need to worry about /mnt/livecd, > and both for the non-critical unmount stuff?
not sure what you mean by this, but yes, you should never umount /mnt/livecd.
> > Also, is /newroot now totally not used anymore? And why does /mnt/cdrom > need to be mounted - i thought / was in there? I guess a quick > explanation on all the types used (zisofs, etc) and what they mount for > what will be great ...
/mnt/cdrom is the cdrom / is a tmpfs filesystem /mnt/livecd is where a loopback gets mounted /mnt/cdrom/zisofs is the zisofs location that symlinks get made to to fill in the root, but it's not a loop device, so /mnt/livecd is not used if the cd is zisofs /etc is a tmpfs filesystem /newroot is only used in the initrd, and should not be visible once /sbin/init is called on bootup. I think that about covers it.
> > Hmm, not sure - that is why I asked for comments from others. I guess > the truth will still hold - the conf files tested for should not be > there if the user did not setup it ...
ok, as long as that's true. ..
> Tough, we all have 12 hour or close working days. As for calming down, > I _am_ calm - you have not seen me on the war path yet =) And I do not > imagine myself that the -r4 changes was not the only. > > Also, 'resigning' from the livecd project because you overstep > boundaries with no visible regard for the impact or feelings of others, > is to be frank, silly. Ask me - any change that usually cannot wait a > few hours to be verified is usually a wrong one. I did this more than > once myself - overstepping boundaries for this 'critical' fix, and the > result was worse than what the few extra hours of waiting could ever > have done. > > We do not ask your soul - we ask some sort of regard. Work with us, > and you will see that most of us will work with you.
Seeing as I had already 'overstepped' my bounds as you put it and committed a -r4 in the first place (it was never anything you had committed), what was the harm at all in me updating my own ebuild? Anyhow, we use CVS for collaboration, etc, this send me a diff and I'll approve it thing is BS as long as we don't mess anything up, which I have taken steps to make sure I do not. Oh also, just as a little wood for your fire, I committed a patch to -r2,-r3,-r4, and -r5 that fixes a bug where /dev was not being created _again_. And I did view this as fairly critical, and it was simplistic. We are a team, I don't believe ONE person should hold up bug fixes, etc when things are easily fixed without disturbance. I view myself as a competant developer, if I were not, perhaps it would be a different situation. Again, I bring up the point, why do we use CVS if not to collaborate ? -Brad -- gentoo-releng@g.o mailing list


Subject Author
Re: [gentoo-releng] x86-livecd - bugs and suggestions Martin Schlemmer <azarah@g.o>