Comment 24 for bug 84591

Jerry,

I've been wanting to try reverting to some of the Herd3 packages myself, but hadn't had a chance to try it until last night. It seems that that approach may or may not break something, depending upon what is done.

Last night, I used "diff -y --suppress-common-lines [Herd3 filesystem.manifest location] [Feisty Final filesystem.manifest location]" to generate a list of the packages that are different between Herd3 and Feisty Final (the bracketed phrases above were replaced with the location on my pc of the filesystem manifest for each version). Someone correct me if I am wrong, but that diff list should be a package level description of all of the changes between Herd3 and Feisty Final. At that point, it is a matter of identifying packages that may affect the issue. For example, I had been planning to try reverting to Herd3 packages for at least the casper and ubiquity-casper packages. I honestly didn't expect this to fix the problem, but thought it was a starting point and may be the least likely to break something else.

I tried that reversion last night and it did not fix the problem. In particular, I reverted to casper 1.80 and ubiquity-casper 1.80, which were used in Herd3. To generate the customized livecd with the reverted packages, I followed the approach described at the following link, but there may be other ways to do it.

http://www.atworkonline.it/~bibe/ubuntu/custom-livecd.htm

You can get the old packages from here (https://launchpad.net/ubuntu/) and I believe it is also possible to use the herd3 distribution itself to get the old packages. Launchpad does give some information about what the packages do and what files they contain. You can probably find a list of what is in at least some of these packages here: http://packages.ubuntu.com/ (that link may only give packages used in final releases, but at least some of the herd3 packages were used in edgy).

After reverting to casper 1.80 and ubiquity casper 1.80, everything still booted fine (no obvious broken functionality, although something could be broken without being apparent), but the persistence issue remained in exactly the manner described above. I actually suspect that the problem may be in some of the more fundamental scripts in other packages. In particular, I have listed below some of the other packages that I eventually may try. If anyone disagrees or has other suggestions, feel free to chime in. Also, if anyone else wants to try any of this, it could be a dead end or it could give useful information. If any of the developers have suggestions about what they think we should try, or things that they know will break the distribution, or even if they think this approach will not be fruitful, certainly do not hesitate to say so. This is a fairly trial and error approach, and I would not be surprised if the developers already know enough to take a more focused and well informed approach. But, again, I am new to linux.

The initramfs-tools and initscripts packages seemed like possibilities. The initscripts actually appears to be part of a more fundamental distribution, sysvinit described here: https://launchpad.net/ubuntu/+source/sysvinit/2.86.ds1-14.1ubuntu16. That is the link to the version of sysvinit that was in Edgy (and also in Herd3 of Feisty). It would be interesting to see what happens upon reverting to the herd3 version of that package (we might want to try that reversion together with the casper reversion I described above because we know that those sysvinit packages worked with the older casper versions). I don't know if it would be more or less likely to break something if the reversion was of all of the binary packages that are part of the sysvinit distribution. Either way, this reversion will revert packages that are much more fundamental than casper. So, this reversion may generally be more likely to break something. E.g. it is possible that files upon which these packages depend would need to revert also, and that may break other things, and also there may be other packages that require the updated initramfs-tools and initscripts (in fact, that may be likely, but I haven't looked into it). At some point, this reversion could be a lot of work, but I was thinking that it would make sense to at least start with the packages in the sysvinit distribution and see if reverting some or all of those packages breaks something or helps in any way.

There is a package called startup-tasks that changed. I haven't looked at that at all, so don't know if it is relevant.

I actually saw some discussion in the unionfs mailing list that suggested that there may even be a problem with udev. I haven't had a chance to investigate this in any level of detail, and that discussion was in the context of a completely different issue. But it might be interesting to know the effect of reverting to the herd3 version of udev because that file did change between herd3 and feisty final.