Who maintains initramfs-tools?

Paul Albrecht albrecht at rdi1.com
Mon Jul 28 21:04:19 UTC 2008


On Thu, 2008-07-24 at 12:44 -0400, Ben Collins wrote:
> On Thu, 2008-07-24 at 11:37 -0500, Paul Albrecht wrote:
> > On Thu, 2008-07-24 at 12:10 -0400, Ben Collins wrote:
> > > On Thu, 2008-07-24 at 10:54 -0500, Paul Albrecht wrote:
> > > > On Thu, 2008-07-24 at 11:30 -0400, Ben Collins wrote:
> > > > > On Thu, 2008-07-24 at 09:56 -0500, Paul Albrecht wrote:
> > > > > > On Tue, 2008-07-22 at 10:13 -0400, Ben Collins wrote:
> > > > > > > On Tue, 2008-07-22 at 09:08 -0500, Paul Albrecht wrote:
> > > > > > > > On Tue, 2008-07-22 at 07:31 -0600, Tim Gardner wrote: 
> > > > > > > > > Paul Albrecht wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > Who maintains the initramfs-tools package?
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > >From the changelog I see 5 different people for the last 5 uploads. What
> > > > > > > > > do you need?
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I hacked initramfs-tools so I could run ubuntu on a 2 gigabyte partition
> > > > > > > > and I was wondering whether it was worthwhile pushing the changes
> > > > > > > > upstream.
> > > > > > > > 
> > > > > > > > What I do specifically is first install ubuntu on a 8 gigabyte flash
> > > > > > > > disk. Then I further configure the system the way I want and squash the
> > > > > > > > root file system. Finally, I write the squashed root file system to a 2
> > > > > > > > gigabyte flash disk.
> > > > > > > > 
> > > > > > > > With my hack to initramfs-tools, which simply union mounts the squashed
> > > > > > > > root with a cow layer, I get a usable desktop on a 2 gigabyte partition.
> > > > > > > 
> > > > > > > This sounds a lot like our livecd, and even more like the work we've
> > > > > > > done for the classmate PC. I'd compare what you've done with that and
> > > > > > > see if there is anything common.
> > > > > > > 
> > > > > > 
> > > > > > Rereading your response I'm not sure I understood you. Are you saying
> > > > > > you think I should look at what you did for the classmate PC? How would
> > > > > > I do that?
> > > > > > 
> > > > > > The reason I posted here was because I'd like to get the code that
> > > > > > handles loop file systems tweaked a bit so I don't have to pin the
> > > > > > initramfs-package.
> > > > > 
> > > > > I didn't do the classmate PC stuff. If you talk to ogra on Freenode IRC,
> > > > > he can tell you where his code is. All I'm saying is that there's at
> > > > > least three different implementations, and we need to settle on one :)
> > > > > 
> > > > > Last thing I want to do is have three different ways for this to be done
> > > > > in initramfs-tools.
> > > > > 
> > > > 
> > > > Why do you think you need three different implementations? It doesn't
> > > > matter how liveCDs or PC classmate are handled. It's really irrelevant. 
> > > > 
> > > > I'm simply suggesting a minor enhancement to the way loop file systems
> > > > are handled for the case of a local mount. This isn't much more than
> > > > tweak to code that handles the init loop option which is at the end of
> > > > mountroot routine in local/scripts.
> > > > 
> > > > Of course, I can fix up the initrd to work the way I want, but then I
> > > > have to pin the package which I'd rather avoid because then I can't pick
> > > > up updates to the package.
> > > > 
> > > > Didn't think there would be any objection because the change is small,
> > > > the risk of regression is negligible, and the change is possibly useful
> > > > to others.
> > > 
> > > Maybe if you attached a patch I could give you better comments...
> > > 
> > 
> > I don't have a patch for you, but I have attached a copy of
> > scripts/local which I hacked to do what I want. I haven't indented my
> > changes so they should be easy to spot at line numbers 78-94. This is
> > after the root device is mounted and before mountroot deals with any
> > loop file systems present on the device.
> > 
> > What I'm suggesting is fixing up the code that handles loop file system
> > so that it can be optionally union mounted with a cow layer. Then my
> > hack wouldn't be needed.
> 
> I need to see a diff between the original and this one. Please don't
> make me find all this myself.
> 

Here's are two patches for a less hackish fix:

I added two knobs to init to specify the cow device and file system
type:

--- init	2008-07-28 15:57:16.000000000 -0500
+++ init.hacked	2008-07-28 15:56:45.000000000 -0500
@@ -132,6 +132,12 @@
 	break)
 		break=premount
 		;;
+	snap=*)
+		SNAP=${x#snap=}
+		;;
+	snaptype=*)
+		SNAPTYPE=${x#snaptype=}
+		;;
 	esac
 done
 
I modified scripts/local so that the code which handles loop file
systems union mounts the loop file system with he cow layer:

--- local	2008-07-28 15:57:38.000000000 -0500
+++ local.hacked	2008-07-28 15:56:53.000000000 -0500
@@ -107,6 +107,16 @@
 		# FIXME This has no error checking
 		mount ${roflag} -o loop -t ${FSTYPE} ${LOOPFLAGS} "/host/${LOOP#/}"
${rootmnt}
 
+		if [ "$SNAP" ] ; then
+			mkdir -p /snap
+			mount -n -t ${SNAPTYPE} ${SNAP} /snap
+			mount -n -t aufs -o br:/snap=rw:${rootmnt}=ro none ${rootmnt}
+			mount -o move /snap ${rootmnt}/snap
+			if [ -d ${rootmnt}/snap ]; then
+				mount -o move /snap ${rootmnt}/snap
+			fi
+		fi
+
 		if [ -d ${rootmnt}/host ]; then
 			mount -o move /host ${rootmnt}/host
 		fi

How do I get this fix pushed upstream?

-- 
Paul Albrecht




More information about the kernel-team mailing list