Summary: | LiveCD: oopses at rm on Acer Aspire 1524WLMi | ||
---|---|---|---|
Product: | Gentoo Release Media | Reporter: | Grzegorz Kulewski <grzegorz> |
Component: | Everything | Assignee: | Gentoo LiveCD Package Maintainers <livecd> |
Status: | RESOLVED NEEDINFO | ||
Severity: | normal | CC: | amd64 |
Priority: | High | ||
Version: | 2004.3 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Grzegorz Kulewski
2004-12-17 02:07:08 UTC
file /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/elf/tst-tlsmod6.os.dt: No space left on device Did you notice this? Any tips? I really need to have Gentoo on this laptop _fast_. Then use GRP. > file /var/tmp/portage/glibc-2.3.4.20040808-r1/work/build/elf/tst-tlsmod6.os.dt: > No space left on device > > Did you notice this? Yes, but there was space on device! There was plenty of it - see included info. I suspect that this message is the result of kernel oopses before. The same instalation can be done with x86 without problems. > Any tips? I really need to have Gentoo on this laptop _fast_. > > Then use GRP Not that fast... :-) Besides if kernel is failing then GRP install can fail too. First ooops apperared loooong before the error message about -ENOSPC and kernel was in unreliable state since then. I really think that there is some problem with that kernel. Since it is official kernel, Gentoo developers have System.map for it and can track down this ooops in minutes and confirm my words. I am trying without /var/tmp as tmpfs. Will report results later. Thanks. Whoa... you had /var/tmp as tmpfs? I missed that. I would be willing to bet that is the problem, but I couldn't be positive on it without testing more myself. If having /var/tmp as a real filesystem on disk doesn't help, then I'll have to turn this over to the amd64 experts on the amd64 team. > Whoa... you had /var/tmp as tmpfs? I missed that. > > I would be willing to bet that is the problem, but I couldn't be positive on it without testing more myself. Probably, but 1. it should work 2. it works with x86 So it is probably some bug with _this_ kernel on LiveCD. I will be glad if you will recomend mounting /var/tmp as tmpfs in the docs, especially for machines with >= 1Gb of RAM (but 512 MB is good too). It really helps with small packages and with bigger probably too. At least you should test if it works before releasing LiveCD. Thanks! We really cannot test for every corner case that someone will want to utilize. Especially given our limited resources. To be honest, doing a bootstrap with /var/tmp as tmpfs is simply a really poor idea. You are starving the system of memory that it could be using to bootstrap. While it might work, it still is not recommended, which is why we defintiely would not mention it in the documentation. Try booting without using tmpfs and with "nosmp" as an option on the kernel command line. Also, what is up with CFLAGS="-O2 -O3 -Os -march=athlon64 -mtune=athlon64 -fomit-frame-pointer -fforce-addr -pipe"?? You can't have more than one -O and expect it to compile properly. > To be honest, doing a bootstrap with /var/tmp as tmpfs is simply a really poor idea. You are starving the system of memory that it could be using to bootstrap. While it might work, it still is not recommended, which is why we defintiely would not mention it in the documentation. I disagree with you. Compilation will never require more than about 128 MB of memory. The rest will be used ba disk cache. So people with > 512 MB RAM will not starve the compilation because of oom. But every temporary file written to /var/tmp will go to disk - and it is pointless, because it will: - take disk bandwitch - take CPU time (IDE disks can eat CPU time badly) - use painfully SLOW laptop disk - wake disk if it is sleeping - increase the disk usage => increase probability that disk will fail (laptop disk are not designed to run 24h/day with very high load - this is poor IDE not some server SCSI! - possibly increase fragmentation on my / filesystem - and all these files will be removed in < 30 minutes (and some after less than 5 minutes)! So why do I need them on my disk??? And especially for some strange ebuilds like americas-army thar require several gigs at /var/tmp (I will bet they need only 1/2 of that, but that is another story...) I have >3GB of swap. Conclusion: using tmpfs on /var/tmp is more or less like not using it with exception that cached pages are marked "do-not-write-to-disk" and that disk is not abused. I meansured it on x86. If you want to prove me wrong - show me your meansures. I love to be proven wrong. And I will not call it corner case. But still including this idea in the docs or testing it before release is only suggestion... > Also, what is up with CFLAGS="-O2 -O3 -Os -march=athlon64 -mtune=athlon64 -fomit-frame-pointer -fforce-addr -pipe"?? You can't have more than one -O and expect it to compile properly. No, I can. Read gcc manual. It will take _last_ == -Os. But some stupid bad designed ebuilds (at least in not so far past) stripped everything but -O2 and/or -O3. This way if -Os will be stripped -O3 or -O2 (in this order) will be used. If not -Os will be used. (I reported request to audit strip-flags and filter-flags (or redesign them) for such stupidities like above or not removing -Os and removing -fno-align-* long ago but bugs were rejected and I do not have time to do this myself currently). Thanks. No offense, but I don't care if you disagree with me or not. I don't consider it up for discussion. I *would* call it a corner case and won't spend my limited time testing for such. It is not documented nor supported by Gentoo. This means you're on your own when doing such things. While we will work to help respolve problems that you uncover (such as this one) you cannot expect us to test for every possible instance. By the way, I maintain americas-army and can tell you that it does, indeed *require* all that space. You are always free to install FEATURES=-sandbox to save yourself the space, but it definitely requires it when using the sandbox, as it has to unpack a ~700MB tarball, then also copy the contents of that tarball into the sandbox image location. I'm not going ot get into an argument over this stuff, so I'm just going to let this go to the amd64 team to work. Anyway, rather than posting argumentative contrary reports, it would have been much nicer had you tried booting with "nosmp" and seeing if that solved the problem, along with not using tmpfs, as requested. I do not have your hardware, so I cannot perform these tests myself and require you to perform them if you wish for me to make modifications to possibly prevent this problem in the future. > Anyway, rather than posting argumentative contrary reports, it would have been much nicer had you tried booting with "nosmp" and seeing if that solved the problem, along with not using tmpfs, as requested.
Of course I did that! Doing everyting as above _without_ mounting tmpfs helped - my bootstrap ended successfully just now.
I will not try to boot with nosmp because I must install next packages fast, sorry. Maybe later.
Anyway, rather than posting what should I do, it would have been much nicer had you tried greping recent kernel bk changelogs about fixes of tmpfs on AMD64 in kernels > 2.6.9... :-) I am pretty sure that this was fixed in recent kernels. And I will make my own kernel (something around 2.6.10-rc3 with extra patches possibly - definitely not SMP but PREEMPT) and will mount /var/tmp as tmpfs and try to merge gnome and others when I will finish merging system. I will report results as soon as it will be done.
Thanks.
First of all the disclaimer: I am not a friend of discussions in bugs, but i can't keep my trap shut ;) I have a system with 1 GB RAM, as probably most amd64 users. aqua tmp # pwd /var/tmp aqua tmp # du -sh . 4.8G . perhaps i should mention that i recently did a `rm -rf /var/tmp/portage/*`, because it took about 8 GB of space. that's why i wouldn't recommend such a configuration in our documentation. whoever wants to use it is free to do so, but i wouldn't recommend it. you have a athlon64, which afaik doesn't support 2-way or higher and doesn't have HT-support or something similiar, so smp really doesn't make sence. it would be nice if you could test it with nosmp later i did a grep on ChangeLog-2.6.10-rc* and found nothing that seems to be related to your issue. Sorry, you didn't make it clear that you had tried it. I'm glad that you found the solution to the problem with the LiveCD, which was that your bootstrap failed. Now, it failed because of a kernel bug. We have now determned that by going through the process as I've been requesting it. There would have been NO REASON to suspect that it is an actual kernel bug until after we were able to determine that the bug is, in fact, caused by a bug in tmpfs in the kernel. Without prior knowledge of this, I would have *never* known what sort of thing to look for as a possible solution. Do you see where I am getting with this? If you *knew* that the problem was with the tmpfs implementation on amd64 in the 2.6.9 kernel, then you could have said that instead of pasting page after page of infomarion that would lead me to run around trying to determine the actual issue. I am not a soothsayer, I'm simply a developer. Anyway, this isn't really something we can go back and "fix" for the previous release, but we can make sure to take note of it and ensure it works for the next release, but at the same time, we only test for things in the handbook, including options we have given. While it is very possible to do millions of other things to get a working Gentoo system, we simply do not have the time nor the manpower to test for every single one, and to verify bugs that were unknown at release time when we make the releases. We have to limit ourselves or we would never release. This is unfortunate, but the truth. We do not support, endorse, nor recommend using tmpfs for /var/tmp, but we also will not stop you from doing so. Since we do not recommend it, we naturally won't test for it. Anyway, I'm getting very long-winded, so I'm going to stop now... ;] blubb: SMP is default for the kernels on the LiveCD, since there was no proven reason against it and it reduced complexity (and LiveCD size) So far, we have not found a single bug reported that could be attributed to SMP, but we still ask that users that have any kernel-related bug and are not on a SMP system to try with nosmp. Chris: yes i know, but when i remember my first steps with linux (not that far ago) i remember that a SMP-kernel caused multiple oops/panics on serveral things that are really not related to this, short: it was a pain in the ass. anyway, times have changed and it shouldn't be a problem but it possibly could have been that smp is the bad thing again. it won't hurt to enable nosmp. is this still an issue with 2005.0? This bug is very old now (3 months) and we've had no updates - I'm going to assume its been resolved, however Grzegorz should feel free to reopen and update with more current information if he's still having a problem. |