Description of problem: When you edit the options via the Mageia Control Center's "Set up boot system", under Advanced, despite the option being clicked for "Clean /tmp at each boot", the option is not remembered, so /tmp is not cleaned at each boot. Version-Release number of selected component (if applicable): Mageia1 How reproducible: As described above.
Component: Installation => RPM PackagesHardware: i586 => AllSource RPM: (none) => drakxtools
It works here. It places the following line in /etc/fstab: none /tmp tmpfs defaults 0 0 which turns /tmp into a memory-based filesystem. Does your /etc/fstab not have that line ? If it does, why do you think that /tmp isn't being cleaned ?
CC: (none) => ftg
There is no such entry in my fstab to clean the /tmp drive, the entry in MCC does not seem to action it when you click ok. After every boot, the "Clean /tmp" box is deselected in MCC, and there is no entry ever made to clean /tmp in /etc/fstab.
I always select the option during install summary, but I just tried to unset it from MCC and the /etc/fstab line disappeared. The I re-set it and the line appeared again. Possibly you don't save changes to /etc across a boot, or /etc/fstab is not writable to root ? If you check the box in MCC, do you finish the bootloader installation, or just check the box and exit the tool ? If you check the box and finish bootloader installation, is the /etc/fstab entry present at that time ?
The only option I checked on install was the security setting, which was unset in Mageia (normally Mandriva sets a basic security setting on install). I didn't check any other settings in the summary as they seemed to be correct (they usually are). User and group of fstab is root, so it should be writable to by MCC. Something else seems to be going on preventing the code to clear /tmp being added to fstab.
The following is what is in fstab, I did not create fstab, it was Mandriva 2010.0... UUID=whatever /tmp ext3 acl,noatime 1 2
(In reply to comment #5) > The following is what is in fstab, I did not create fstab, it was Mandriva > 2010.0... > > UUID=whatever /tmp ext3 acl,noatime 1 2 AFAIK that means that during custom setup you explicitly mounted an ext3 partition as /tmp. I'd bet that if you comment out that line in /etc/fstab and reboot, MCC will work as I described. Whether it should work even with that line there is a question for someone with more drakboot experience than I. There may be some reason why it shouldn't. What did you select for disk setup options in MDV 2010.0 ? If you didn't add that line to /etc/fstab yourself, then one of the automated partitioning options did (I've never used them), and I would think the tool would support having it there. Possibly the intent of the tool is to simply toggle between use of a tmpfs and use of the /tmp directory on the root partition. It may have no way to "remember" a more custom /tmp setup like the one you describe, and wouldn't be able to put it back later if you unchecked the box. In fact, I wouldn't be surprised if this occurred in the past, and someone "fixed" it by disabling the check/uncheck facility for anything other than the "none" tmpfs.
I've done a bit of reading up on what you've written. parted cannot change the /tmp partition to tmpfs, no such type. http://www.gnu.org/software/parted/manual/html_chapter/parted_6.html#SEC54 I run a number of Linux machines, so I can't 100% say what happened, but I would guess that when I installed Mandriva on the pc I am nor testing Mageia on, I stated a size for /tmp, but was not automatically stated what type it is, unlike say the swap partition, which automatically filled in as swap type. I tried your suggestion of commenting out /tmp but KDE refuses to even start.
Sorry for the confusion, I didn't literally mean the old "tmpfs" filesystem; I just used that to refer to an in-memory filesystem that would start fresh at each boot. As for KDE not starting, MDV must have created a /tmp mountpoint in your root filesystem, and it may not have correct permissions. Since that is what will be used for /tmp if you comment out the line, that might explain the KDE failure. /tmp needs to be drwxrwxrwx
Note that you'll have to comment out the fstab line, reboot, and change the /tmp permissions from a virtual console (CTRL-ALT-F1), then reboot again and try KDE.
I performed chmod -R 777 /tmp But it really didn't help, maybe I'm doing something wrong with permissions, but the problem with enabling the checkbox in MCC and getting it to remember it remains, despite a number of reboots.
I commented out my fstab line, rebooted, saw that the original /tmp in my root directory was already drwxrwxrwx, and got into KDE just fine.
Commented out the /tmp entry in fstab and rebooted. When trying to get into KDE, I get the following error. "Call to lnusertemp failed (temporary directories full?), Check your installation." Then dumps me back to the user password entry screen.
How much free space is there on your root partition ? You might try inserting the none /tmp tmpfs defaults 0 0 line manually into fstab with the existing line commented out and reboot. If KDE works with that, then try seeing if you can toggle the existence of the new line with MCC.
#13 Frank, I tried your suggestion below as my root does have a fair bit of space, and it did work. none /tmp tmpfs defaults 0 0 So I tried different combinations of the existing entry for /tmp, and have come up with the following that worked, solving the problem. UUID=whatever /tmp tmpfs defaults 0 0 Now on reboots, the /tmp partition is cleaned out each time and new files and directories created. The check box in MCC is now able to be toggled and IS remembered. The problem should not have occurred in the first place, and seems to have been in Mnadriva, and carried over to Mageia. Maybe on installing Mageia a check should be run to make sure the /tmp drive is tmpfs not ext3?
The "problem" is really a misunderstanding and a misnomer. The option "clear /tmp at boot" does no such thing. What is does is replace the /tmp in your root partition with a mounted memory-based tmpfs which always starts out empty. It doesn't "clear" anything on any existing /tmp. There is a possible bug/enhancement here, in that the tool apparently won't work if you have a real partition defined to be mounted as /tmp. Instead, it simply does nothing silently. As far as I'm concerned, that's a bug. If it's not going to do what you asked, it should say so, and say why. Whether it should support replacing a real external /tmp with a tmpfs needs to be discussed. It may be, as I said before, that there is no provision for undoing it, or there may be some other consideration. I doubt that it's specific to ext3. This needs to be decided by someone more familiar with the history and capabilities of this tool than I.
CC: (none) => thierry.vignaudSeverity: normal => enhancement
Summary: MCC boot system options not remembering "clean /tmp on boot" => drakboot does not remembering "clean /tmp on boot"
@ Ski Is this issue still present in current cauldron?
Keywords: (none) => USABILITYCC: (none) => marja11Summary: drakboot does not remembering "clean /tmp on boot" => If /tmp is a partition, drakboot does not remember "clean /tmp on boot"
Looking at this again, I notice that what got it to work was changing "acl" to "defaults", so maybe that was the problem all along.
Keywords: (none) => NEEDINFO
If you add a line with CLEAN_TMP=1 to /etc/sysconfig/system, then /etc/init.d/mandrake_everytime will clean the /tmp directory.
CC: (none) => davidwhodgins
(In reply to comment #17) > Looking at this again, I notice that what got it to work was changing "acl" to > "defaults", so maybe that was the problem all along. Thanks for replying Closing
Status: NEW => RESOLVEDResolution: (none) => FIXED