1 |
On 16:01 Thu 07 Jul , Paul Smith wrote: |
2 |
> %% Chris Gianelloni <wolf31o2@g.o> writes: |
3 |
> |
4 |
> cg> Actually, what rocket means in that catalyst has no built-in |
5 |
> cg> support for unionfs. To get unionfs, you need to use gk_mainargs |
6 |
> cg> (or gk_kernargs) --unionfs. |
7 |
> |
8 |
> Oh, OK. Yeah, I already found this in the new genkernel, and did do it |
9 |
> in livecd.conf (I thought I mentioned that in one of my mails). |
10 |
> |
11 |
> cg> You will also probably want livecd/bootargs: unionfs... unless |
12 |
> cg> you know the device you want, in which case you can do |
13 |
> cg> livecd/bootargs: unionfs=/dev/sda1 (or whatever). |
14 |
> |
15 |
> I'm actually using GNAP to create the ISO, so I override the kernel boot |
16 |
> params there and don't need this. |
17 |
> |
18 |
> cg> Yeah, livecd/bootargs is new in the _pre series. I even documented it |
19 |
> cg> in the template spec files... ;] |
20 |
> |
21 |
> That's a good enhancement though! :-). |
22 |
> |
23 |
> >> 0) mkdir -p /newroot |
24 |
> >> |
25 |
> >> 1) Create a tmpfs at /memory |
26 |
> >> |
27 |
> >> 2) Create a unionfs at /union, where the only item in the union is |
28 |
> >> /memory (mounted RW) |
29 |
> >> |
30 |
> >> 3) Init /newroot (make directories, copy over /dev/null and /dev/console) |
31 |
> >> |
32 |
> >> 4) Find the cdrom and mount it as /newroot/mnt/cdrom |
33 |
> >> |
34 |
> >> 5) Mount the squashfs as /newroot/mnt/livecd (read-only) |
35 |
> >> |
36 |
> >> 6) Add /newroot/mnt/livecd to the unionfs after the tmpfs (/memory) |
37 |
> >> |
38 |
> >> 7) Create /union/proc and /union/sys |
39 |
> >> |
40 |
> >> 8) Pivot_root to make /union the new /. |
41 |
> >> |
42 |
> >> 9) Clean up the old root (in /tmp/.initrd) |
43 |
> >> |
44 |
> >> 10) chroot . 'exec /sbin/init' (basically). |
45 |
> |
46 |
> Hold on a second... I just discovered something that I don't understand |
47 |
> at all. The behavior above, in particular steps #8 & 9, is not actually |
48 |
> what happens. |
49 |
Initramfs's are special as in they eliminate many of the workarounds |
50 |
that are present in an initrd. You no longer need to specify init= on |
51 |
the command line. In fact the kernel ignores it when an initramfs is |
52 |
detected. Also the kernel expects the initial script to be called init. |
53 |
So genkernel renames the linuxrc file to init inside the initramfs. |
54 |
Because the script is called init the value of $0 is set to /init. |
55 |
|
56 |
Initramfs are also different in that they no longer pivot_root and then |
57 |
chroot. You can just chroot directly. The differing code is to handle |
58 |
this behavior difference. Ultimately its much simpler than worrying |
59 |
about the pivot root. |
60 |
|
61 |
> |
62 |
> If you look in the linuxrc you'll see it has an option to be invoked one |
63 |
> of two ways: where $0 is "/init", and where $0 is "/linuxrc". Depending |
64 |
> on which one is used the script exhibits different behavior... very |
65 |
> different, in some cases. Like, the "/init" branch doesn't use |
66 |
> pivot_root at all; it just does a chroot. The whole end cleanup is very |
67 |
> different. |
68 |
> |
69 |
> I've been thinking that the livecd is booting with $0 == "/linuxrc", but |
70 |
> in fact it's not: $0 == "/init". |
71 |
> |
72 |
> Can someone give me an idea of where this ($0) is set up (it's not init= |
73 |
> on the boot line because my boot line says init=/linuxrc--but it must be |
74 |
> the kernel somehow because it execs the shell so it would set argv[0]), |
75 |
> and what the purpose is between the different behaviors, and why you'd |
76 |
> choose one over the other? |
77 |
> |
78 |
> cg> AFIAK, /mnt/cdrom would need to be done before the pivot_root, |
79 |
> cg> too. So you can't move that to later. |
80 |
> |
81 |
> True, but you could do one of two things: |
82 |
> |
83 |
> a) Mount it in /unionfs/mnt/cdrom in the first place, not in |
84 |
> /newroot/mnt/cdrom. By the time we mount the cdrom we already have |
85 |
> a /union filesystem created and working. |
86 |
> |
87 |
> OR |
88 |
> |
89 |
> b) Try to "mount --move" it from /newroot to /union once the unionfs is |
90 |
> set up. |
91 |
|
92 |
I would lean toward --move if it works, but it will need to be tested. |
93 |
> |
94 |
> I looked at (a) and while I think it would work, it would involve a lot |
95 |
> of changes. Although the value of CHROOT is set to $NEW_ROOT (or $UNION, |
96 |
> if we're using unionfs) early in the script, almost all the commands |
97 |
> after that continue to use $NEW_ROOT explicitly rather than $CHROOT. |
98 |
> Sometimes this probably makes sense (such as mounting livecd) but in |
99 |
> other cases it doesn't, so much (such as in mounting cdrom). I think |
100 |
> these variables need to be rationalized somewhat, so $CHROOT is used |
101 |
> instead of $NEW_ROOT where appropriate. |
102 |
|
103 |
Alot of this unionfs code is an after thought and so it was implemented |
104 |
in such a way that it was minimally impacting to the normal booting |
105 |
method. Overtime I hope to have things cleaned up as we discover issues |
106 |
and/or convert entirely to this boot method. |
107 |
|
108 |
> |
109 |
> There are other things that probably don't hurt, but aren't required |
110 |
> either. For example, even in the unionfs case the code still |
111 |
> initializes $NEW_ROOT with a bunch of stuff that is never needed, and |
112 |
> then is just cleaned up again afterwards. |
113 |
|
114 |
Again see the above comment about code impact and that will explain why |
115 |
things are as they are. |
116 |
|
117 |
If you find a working solution for you that boots the system with or |
118 |
without unionfs support please make a patch and we will look to have it |
119 |
included. |
120 |
|
121 |
Thanks. |
122 |
> -- |
123 |
> ------------------------------------------------------------------------------- |
124 |
> Paul D. Smith <psmith@××××××.com> HASMAT--HA Software Mthds & Tools |
125 |
> "Please remain calm...I may be mad, but I am a professional." --Mad Scientist |
126 |
> ------------------------------------------------------------------------------- |
127 |
> These are my opinions---Nortel Networks takes no responsibility for them. |
128 |
> -- |
129 |
> gentoo-catalyst@g.o mailing list |
130 |
> |
131 |
> |