Summary: | genkernel 3.1.6 truncates initrds and images when /boot is full | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matteo Settenvini <matteo-ml> |
Component: | [OLD] Core system | Assignee: | Gentoo Genkernel Maintainers <genkernel> |
Status: | RESOLVED NEEDINFO | ||
Severity: | critical | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Kernel config |
Description
Matteo Settenvini
2005-04-03 03:30:12 UTC
Created attachment 55170 [details]
Kernel config
My kernel config.
If you try without gensplash? No, it's not gensplash. I noticed that after compiling and installing the initrd, I had exactly 0b space left on /boot. What's strange, it's that genkernel did copy the initrd on /boot anyway (usually, shouldn't it complain when there's no space left on device?) and truncated it (at least, that's what I think). Regenerating the initrd after removing some old kernels from /boot did produce a good initrd. However, reproducing the old conditions (almost full /boot) and recreating the initrd with genkernel brings in exactly the same issue. This bug can be closed also as a WORKSFORME (or INVALID), but keep in mind that genkernel seems to truncate part of the initrd when copying it to /boot and there's no space left on device. Is it possible that some function read free kbytes using 1024 as a base, and some other does it with 1000? Just an idea of mine, though, and quite general: if it was to be true, could be also a "cp"/"install" problem. Hrm, interesting; genkernel does "cp /var/tmp/genkernel/.../initrd-${kernel-version} /boot" and cp should fail when /boot is running low on space... If you reproduce the same full conditions and just copy over an initrd using cp does that also truncate? Yes, it does, even if reporting an error. For example, I did a: cd /boot for i in `seq 1 10`; do cp initrd-2.6.11.gentoo-r3 i.tmp$i; done The space filled up, and I got the obvious error: cp: writing to `i.tmp5': No space left on device But when looking at /boot with ls -l: matteo@tulip ~ $ ls -l /boot/ total 13896 [...] -rw-r--r-- 1 root root 643475 mar 10 11:56 initrd-2.6.11-gentoo-r3 -rw-r--r-- 1 root root 643475 apr 7 11:19 i.tmp1 -rw-r--r-- 1 root root 643475 apr 7 11:19 i.tmp2 -rw-r--r-- 1 root root 643475 apr 7 11:19 i.tmp3 -rw-r--r-- 1 root root 643475 apr 7 11:19 i.tmp4 -rw-r--r-- 1 root root 536576 apr 7 11:19 i.tmp5 [...] As you can see, i.tmp5 isn't 643475 as it should, and yet it hasn't been removed. So we should see if the original file and target one have the same size (md5sum?), and else we should _remove_ the partial file in /boot. Just an idea, though. But doesn't genkernel already checks for that? The second time I used it it gave me a warning because of having no space on /boot... why the first time it went on silently? What filesystem are you using for /boot? I'm not able to reproduce it here so it may be the local configuration that caused it to fluke the first time... ext2 as recommended. Can you please try 3.2.0_pre9 and see if that still gives the same problem? If it does then please try copying an oversized file to /boot using cp again and then do echo $? and see what gives. at the moment genkernel 3.2.0_pre18 produces unbootable images for me (the initramfs image reports it lacks mkdir and so on when booting, and it cannot mount root), so I'll have to wait for it to become stable. clear your caches with genkernel and try again. Also did you change your busybox config? genkernel-3.2.2 is out. While it may not fix your issue we are unable to replicate it. Please send more debug output if this is still and issue with the latest genkernel. |