[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