[Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only

Douglas McClendon dmc.fedora at filteredperception.org
Wed Aug 22 18:26:13 UTC 2007


Jeremy Katz wrote:
> On Tue, 2007-08-21 at 16:29 -0500, Douglas McClendon wrote:
>> Jeremy Katz wrote:
>>> On Mon, 2007-08-20 at 05:23 -0500, Douglas McClendon wrote:
>>> For the overlay info bit, we could potentially just stuff it
>>> in /sbin/halt.local for now I think.
>> I saw halt.local.  I don't think you noticed how brutally ugly what I 
>> was doing was.
>>
>> The goal of that code after halt.local is to get the overlayfs cleanly 
>> unmounted.
>>
>> The way I currently accomplished that, was to YANK the snapshot overlay 
>> out of the root device.  The only thing that makes this even remotely 
>> palatable, is the fact that the root device has been remounted read 
>> only.  Which is the one thing that has happened between this code and 
>> the halt.local.  (thus making halt.local not a workable place for this code)
> 
> Ah yeah, oh well.  Was at least a thought.  Although, continuing with
> just stupid thinking out loud, why yank it?  We've mounted the root
> device ro, so we should also be able to make the overlay device read
> only at that point.  Which would then lead to it being clean on the next
> boot and should be reliable.  Unless I'm missing something, which I
> probably am since it's still early

No, I think you you're right.  The same thought hit me last night.  I 
think the key (if it works) is using losetup -r to change the overlay 
loopback device to readonly before trying the unmount.  I think not 
realizing that that is possible is what put me on the wrong track.


> 
>> Thinking about it, the way to make it less horrendously ugly, would be 
>> to copy the binaries used from the rootfs (dmsetup, losetup, rm, mount) 
>> to a tmpfs first, since after the yanking, there is really no guarantee 
>> that any data read from the rootfs can be relied on.
> 
> Alternately (and I've had this discussion before with someone, although
> I forget whom), we really want to be able to get back to running from
> the initramfs on shutdown.  eg, that's the only way we'll ever be able
> to eject the CD for reboot.  And at that point, we do have the binaries
> we care about and can rely on them and maybe could have this be cleaner.

I also came to this conclusion.  It is also quite logical in the sense 
of tearing things down in the reverse order of how they are built up. 
Also if the ideas about putting gdm and other stuff into initramfs, that 
also makes more sense.  Part of it, would be doing something similar to 
what I did with /mnt/overlayfs to make the originial initramfs mount 
point remain visible after the pivotroot.  I'll give it a shot.


> 
>>> +# IMPORTANT TODO: while mount scanning find a way to determine if the 
>>> +#                 filesystem was not cleanly unmounted.  If so, IGNORE IT,
>>> +#                 as it may be part of a hibernated OS !!!!!!!
>>>
>>> Maybe instead of using cleanly unmounted vs not as the key, we should
>>> look at swaps to see if they have the SWSUSP signature?  That's a pretty
>>> straight-forward thing to check, but I can't quite convince myself if
>>> it's as safe or not.
>> My worry about this- is things like *3* current hibernate 
>> implementations for linux.  That means that you have many possible 
>> signatures to check, and there is no way to predict signature changes in 
>> future versions of hibernation.
> 
> There's no way to predict the future, period.  Generally, as the world
> around the live image being created changes, things like initrds, etc
> have to evolve too.  But, I'm not at all tied one way or another.  I
> wonder if we could actually just take advantage of fsck to tell us if
> it's clean or dirty -- I guess only if we did a "don't change anything
> run" and not anything more programatic.

That sounds promising.

> 
> [snip]
>>> So yeah, overall, this is looking pretty spiffily good to me and I'm
>>> leaning towards starting to get it merged in so that we can start
>>> getting real use of it
>> We'll see where I'm at in another 24-48 hours, cleaning up the most 
>> obviously ugly things and perhaps making a more testable patch.
> 
> If we want to get to where it's available by default in F8, it'll
> definitely be good to have something for test2, even if some of the
> "pull the plug" corner cases aren't happy.  The only reason I feel okay
> with making the auto case the default is that while it's automatic to
> use if setup, you still have to setup the overlay file.  So unless
> you've already done the setup work to opt-in, you're not going to get
> hit that hard.


The reason why I would disagree (fairly strongly), is that even if you 
haven't set up the persistent device, all this code is going to be 
running at boot time, that is probing and looking at all the partitions 
on the system, in a much drastically more invasive fashion than has 
historically been the case.  I don't think that there is anything that 
could happen in a week or two that would make me feel comfortable enough 
about the solidness of the code that I would endorse that.

Now, only doing that if the f8t2 user reads the disclaimer in the docs 
before finding out they need to type "overlay=auto" at the boot prompt, 
that I have no problem with.

-dmc




More information about the livecd mailing list