Hi, On 18.07.2012 15:18, Brian J. Murrell wrote: > On 12-07-18 08:40 AM, Michael Biebl wrote:
>> I stopped right there and didn't look any further > > And didn't even bother to respond as such? You submitted the patch just two weeks ago. At that point wheezy was already frozen. This means this feature will most likely not be accepted by the release team, so it wasn't a pressing issue for me and I simply didn't look at it back then. Instead you just leave a > contributor wondering? I just had a look at it today, when you pinged me again. Remember, I'm doing Debian in my spare time also and I'm (co-)maintainer of over two hundred packages, so I get a lot of bug reports and review requests. I can't answer each and every bug report right away and sometimes I'm just really short in my reply because I simply lack the time. > Seriously though. Why do you have to be like that? We are all in the same boat, trying to make Debian and the open source world better. There is no need to make this personal Anyway back to a more technical level: I need to be honest and say that I don't like the approach to do this via a sysvinit or upstart script which does the copy on each and every boot, even when a/ the kernel doesn't actually change during runtime because it isn't upddated b/ the user doesn't actually use hibernation Also, running grub-mkconfig on every boot is is a very costly operation which can take several seconds. pm-utils is basically installed on every laptop and desktop system. On stable, the kernel practically never changes. Also, hibernation is a rather rarely used feature compared to suspend. So we slow down the boot process unnecessarily for almost everyone. Running the grub update on *every* hibernation is wrong, too. Most of the time the kernel will not have changed in between so this is slowing down hibernate unnecessarily, which should be as fast as possible. What happens to those grub entries after a reboot? It seems to me they are left there as stale hibernate entries. Stale entries are cleared during boot, so we will have those entries at least for one boot cycle, right? I also don't see any error handling anywhere, in case /boot was not writable/big enough to create the stashed kernel. This can happen if you have a separate /boot partition which is small or mounted ro. 08_linux_thaw looks like it could be painful to maintain, it looks rather complex and contains stuff like kexec. Is everything there really necessary? Is that a copy of /etc/grub.d/10_linux which has been extended by you? It has stuff like /etc/linuxmint/info in there which make me curious where it comes from as it generates warnings on my Debian system. I'm not a grub expert, so I'm a bit wary about having to maintain such a file. To sum up: I'm not happy about the general approach to do this kernel stashing during boot and running grub update at boot and before hibernation and the implementation has its flaws, too. You might look into the /etc/kernel/ hooks, which are run whenever a kernel is upgraded. Maybe it allows to do the kernel stashing in a much cleaner way. I would also very much prefer, if the grub specific hook is moved into grub proper. grub already contains the hooks for xen kernels or the recovery mode. So adding boot entries for such stashed hibernate kernel might fit in there, too. I've CCed Colin. Maybe he can comment on this. Colin, the relevant files are attached to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597199#35 Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
