| 1 |
> |
| 2 |
> And /newroot? Lets clarify: |
| 3 |
|
| 4 |
/newroot should never be visible as it's strictly in the |
| 5 |
initrd, and pivot_root will pretty much clobber that, it's |
| 6 |
something you don't need to handle. |
| 7 |
|
| 8 |
> 1) /mnt/livecd will be your zisofs image/whater |
| 9 |
|
| 10 |
It is the loopback mount location for normal or gcloop filesystems. |
| 11 |
zisofs is not a loopback device, so it won't make use of that. |
| 12 |
|
| 13 |
> 2) /mnt/cdrom will be the cdrom itself ? |
| 14 |
|
| 15 |
yes. |
| 16 |
|
| 17 |
> |
| 18 |
> So basically, the looback stuff just need to worry about /mnt/livecd, |
| 19 |
> and both for the non-critical unmount stuff? |
| 20 |
|
| 21 |
not sure what you mean by this, but yes, you should never umount |
| 22 |
/mnt/livecd. |
| 23 |
|
| 24 |
> |
| 25 |
> Also, is /newroot now totally not used anymore? And why does /mnt/cdrom |
| 26 |
> need to be mounted - i thought / was in there? I guess a quick |
| 27 |
> explanation on all the types used (zisofs, etc) and what they mount for |
| 28 |
> what will be great ... |
| 29 |
|
| 30 |
/mnt/cdrom is the cdrom |
| 31 |
/ is a tmpfs filesystem |
| 32 |
/mnt/livecd is where a loopback gets mounted |
| 33 |
/mnt/cdrom/zisofs is the zisofs location that symlinks get |
| 34 |
made to to fill in the root, but it's not a |
| 35 |
loop device, so /mnt/livecd is not used if the |
| 36 |
cd is zisofs |
| 37 |
/etc is a tmpfs filesystem |
| 38 |
/newroot is only used in the initrd, and should not be visible once |
| 39 |
/sbin/init is called on bootup. |
| 40 |
|
| 41 |
I think that about covers it. |
| 42 |
|
| 43 |
> |
| 44 |
> Hmm, not sure - that is why I asked for comments from others. I guess |
| 45 |
> the truth will still hold - the conf files tested for should not be |
| 46 |
> there if the user did not setup it ... |
| 47 |
|
| 48 |
ok, as long as that's true. .. |
| 49 |
|
| 50 |
|
| 51 |
> Tough, we all have 12 hour or close working days. As for calming down, |
| 52 |
> I _am_ calm - you have not seen me on the war path yet =) And I do not |
| 53 |
> imagine myself that the -r4 changes was not the only. |
| 54 |
> |
| 55 |
> Also, 'resigning' from the livecd project because you overstep |
| 56 |
> boundaries with no visible regard for the impact or feelings of others, |
| 57 |
> is to be frank, silly. Ask me - any change that usually cannot wait a |
| 58 |
> few hours to be verified is usually a wrong one. I did this more than |
| 59 |
> once myself - overstepping boundaries for this 'critical' fix, and the |
| 60 |
> result was worse than what the few extra hours of waiting could ever |
| 61 |
> have done. |
| 62 |
> |
| 63 |
> We do not ask your soul - we ask some sort of regard. Work with us, |
| 64 |
> and you will see that most of us will work with you. |
| 65 |
|
| 66 |
Seeing as I had already 'overstepped' my bounds as you put it and |
| 67 |
committed a -r4 in the first place (it was never anything you had |
| 68 |
committed), what was the harm at all in me updating my own ebuild? |
| 69 |
Anyhow, we use CVS for collaboration, etc, this send me a diff and I'll |
| 70 |
approve it thing is BS as long as we don't mess anything up, which I |
| 71 |
have taken steps to make sure I do not. |
| 72 |
|
| 73 |
Oh also, just as a little wood for your fire, I committed a patch to |
| 74 |
-r2,-r3,-r4, and -r5 that fixes a bug where /dev was not being created |
| 75 |
_again_. And I did view this as fairly critical, and it was simplistic. |
| 76 |
We are a team, I don't believe ONE person should hold up bug fixes, etc |
| 77 |
when things are easily fixed without disturbance. I view myself as a |
| 78 |
competant developer, if I were not, perhaps it would be a different |
| 79 |
situation. Again, I bring up the point, why do we use CVS if not to |
| 80 |
collaborate ? |
| 81 |
|
| 82 |
-Brad |
| 83 |
|
| 84 |
-- |
| 85 |
gentoo-releng@g.o mailing list |
Archives