| 1 |
>>>>> "Ed" == Ed W <lists@××××××××××.com> writes: |
| 2 |
|
| 3 |
>> When all packages have been stacked, hook scripts that come with the |
| 4 |
>> packages are run in a chroot. For example, packages can add their own |
| 5 |
>> init scripts by calling rc-update, or add users, or whatnot. |
| 6 |
>> |
| 7 |
|
| 8 |
Ed> I assume you run these hook scripts each time you boot then? This |
| 9 |
Ed> seems like a good idea, I had been thinking about putting that on the |
| 10 |
Ed> writable partition and dreaming up some way to ensure that the scripts |
| 11 |
Ed> were only run once - I think your design is cleaner (although need to |
| 12 |
Ed> watch boot speeds) |
| 13 |
|
| 14 |
You definitely have to. Although our platform is "embedded" in a sense |
| 15 |
that it has no keyboard and mouse, and that it has to "just work", it |
| 16 |
has a dual core 2GHz Intel. This is not to say that boot is slow |
| 17 |
(rc-update does not crunch numbers), it's just that it is fast enough |
| 18 |
and we didn't invest much to speed it up. |
| 19 |
|
| 20 |
Ed> I would be very interested to pick over your implementation details if |
| 21 |
Ed> you were willing to share (offlist if you don't think it's sensible to |
| 22 |
Ed> post publically?). I'm quite interested in how you picked the package |
| 23 |
Ed> list and ordered them and exactly how you implemented the hook scripts |
| 24 |
Ed> and failure conditions? |
| 25 |
|
| 26 |
Unfortunately I did the work for my employer, so I cannot share it |
| 27 |
with you, at least not character by character. |
| 28 |
|
| 29 |
One package (one ISO) contains several directories which become aufs |
| 30 |
branches during boot, and a dedicated single directory that contains |
| 31 |
links like |
| 32 |
|
| 33 |
00base-os -> ../base-os |
| 34 |
10core-modules -> ../blah |
| 35 |
|
| 36 |
It's these links that give the order of the stack, and it's actually |
| 37 |
the links that are being stacked. You need this order because (at |
| 38 |
least) the base OS install has to come first. Other packages may |
| 39 |
overlay files from there, for example /etc/X11/xorg.conf or |
| 40 |
/etc/conf.d/net. |
| 41 |
|
| 42 |
>> What I am extremely excited about is that everything worked right out |
| 43 |
>> of the box. Not even one single problem. I expected aufs to fail with |
| 44 |
>> many branches (currently we have some 50 of them), busybox to be not |
| 45 |
>> compatible enough with the shell, initramfs to impose too many |
| 46 |
>> restrictions ... - nothing. |
| 47 |
>> |
| 48 |
|
| 49 |
Ed> That's really good to hear! I am currently only planning about 3-4 |
| 50 |
Ed> packages, but based on what you say I might look to split my packages |
| 51 |
Ed> more granually... |
| 52 |
|
| 53 |
Definitely. What I did was to keep things separate when they are not |
| 54 |
related to each other. Some of the directories have a tree structure |
| 55 |
that hosts only one single file. I don't have 50 ISO files around |
| 56 |
though - I aggregate many directories into one ISO. |
| 57 |
|
| 58 |
Cheers, |
| 59 |
Joerg |
Archives