____Description of problem: Diskdrake have a nifty function that offers to move the contents of folder /var if we create a /var partition on a running system. Use example: I intended to use it to free space in / (failed earlier trying to resize ext4 under LVM on encryption) But it A) fails to copy all content from current/var to new partition; - Specifically in my case folders lib, cache, yp are missing! -> can not boot correctly (in my case i get an unusual graphic login in vt2 with only a text terminal in it, and no virtual console on any other Ctrl-Alt-Fx alternative) B) do not remove the originals (thankfully, as i could easily get it operating by restoring old fstab...) But it does ask to move, so it should copy files, and then remove from original location. But how is it supposed to perform that operation? I hope it will try to make sure all content is moved sucessfully, and THEN remove files at old location. ____Version-Release number of selected component (if applicable): # diskdrake --version Drakxtools version 13.58 ____How reproducible Anytime, i presume ____Steps to Reproduce: 1. Have a running system with /var NOT in a separate partition from / 1b make sure you have a manual copy of your working fstab, and a backup of /var may be good to just in case. 2a Start diskdrake (Mageia Control Center -> manage disk partitions), and enable log window 2b Create a partition /var big enough to contain your /var content, and it will ask if you want to move the contents, select to do so. 2c see in the log window a lot of cp -a /var/<something> lines - but not all folders are copied! (And why not use cp -a /var <destination>?) 3. Reboot: fail. 4. restore fstab.old and you are back (plus a now unused partition) ____Critical I set it to critical as it makes a system not able to boot. The function is apparently offered for someone knowledgeable enough to know what he wants done, but not know to do himself -- and probably even less track what went wrong and how to remedy it!
Created attachment 1404 [details] From diskdrake log window
WORKAROUND ? I guess i can just make new partition and mount it under i.e. /mnt/var, cp -a /var to it, rm -rf /var unmount and remount the partition as /var (and if using diskdrake then say no to copying files) A couple problem i see: mysteriously (for me) /var/cache do not get copied by cp -a /var and a few files in /var/lib/nfs is in use.
Hi, thanks for reporting this bug. Assigned to the package maintainer. (maybe we can the function...) (Please set the status to 'assigned' if you are working on it)
Keywords: (none) => TriagedAssignee: bugsquad => thierry.vignaudCC: (none) => pterjan
First, without even looking at the code, I am very surprised it offers to do so on a running system, it only makes sense during installation, else you will always have some data loss (logs being written in the meantime).
Hmm very surprisingly, this choice is only available outside install while it should be the opposite. It does cp -a of each file or directory in the directory and if they all get copied, removes them. This is only correct if the files can not be modified or created during this process.
I wonder if I am not thinking correctly or if it has always been wrong... Oldest code I could find (diskdrake_interactive.pm,v 1.35 2001/09/24 14:06:46 from Mandrake 8.2) was already only offering it in standalone diskdrake...
I believe i have used this function a few years ago, on mandriva 2008 or so. ...Or it may have been the /tmp folder or other i moved to separate partition... Well it would not be terrible if logging would be missed from this point in time until reboot - but it would be nice if it told the user so, and suggest to reboot. (i solved my space problem last hour now by having diskdrake increase my / on running system, encrypted LVM -Great! :) (and yes i did make a disk image first) )
I think this is a convenient function for us semi-knowledgeable sysadmins to have working, and great tools is a selling point. I think it have similar functionality for other folders under / too, like /usr, /home, /tmp and maybe more. 1) When asking to move content, it should tell to save data and close applications and services. 2) Maybe it could create a script that is run during next shutdown or boot to perform the actual move?
I think that as done now it should only run from installer or livecd and not if the partition has open files. Creating a script for next reboot if some files are open seems like a good idea.
Please look at the bottom of this mail to see whether you're the assignee of this bug, if you don't already know whether you are. If you're the assignee: We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead. If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard. Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why. Thanks :) **************************** @ the reporter and persons in the cc of this bug: If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us. @ the reporter of this bug If you didn't reply yet to a request for more information, please do so within two weeks from now. Thanks all :-D
This message is a reminder that Mageia 1 is nearing its end of life. In approximately 25 days from now, Mageia will stop maintaining and issuing updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '1'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 1's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 1 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- Mageia Bugsquad
Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => WONTFIX
This is a mageia made package and I assume nothing have been changed. Activating it on mga2 so the issue do not get lost. (but i admit i have not *tested*; no suitable test setup now)
Resolution: WONTFIX => (none)Version: 1 => 2Status: RESOLVED => REOPENED
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
I presume nothing have changed, so it still need fixing as it may fool a user to brake the system, thus pushing it to mga3. For fixing see https://bugs.mageia.org/show_bug.cgi?id=4230#c9 and above.
Version: 2 => 3
Mageia 3 changed to end-of-life (EOL) status 4 months ago. http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: REOPENED => RESOLVEDResolution: (none) => OLD
AFAIK it was never neither fixed nor removed. See for ideas how see #c9 and above. Changing to cauldron.
Version: 3 => CauldronResolution: OLD => (none)Status: RESOLVED => REOPENED
There was no action in this report since 2015-03-31 Is this bug still valid with Mga5 and/or current cauldron / mga6dev1 ?
CC: (none) => marja11Keywords: Triaged => NEEDINFO
Ill see if i get time with the dev isos if i have a system i can play with.
(In reply to Marja Van Waes from comment #18) > There was no action in this report since 2015-03-31 > > Is this bug still valid with Mga5 and/or current cauldron / mga6dev1 ? (In reply to Morgan Leijström from comment #19) > Ill see if i get time with the dev isos if i have a system i can play with. Well, no one confirmed this issue and you only reported it 9 years ago, but didn't seem to hit it again. Closing as OLD
Confirmed in comment 5 Good idea in comment 9 Mageia 7 still ask to move when i create a /var (i did not proceed further) As per comment 4 and 6 this behaviour to ask at al is wring it is a bug. And as noted it may be nice if installerask at upgrade or repair time if user create a /var and there is only a / before. Seems complicated, and not to work. I suggest this function to simply be removed. Moving to separate /var is much better performed by booting on a live and perform partition creation, file copy, and edit fstab manually. A user that realise he need to do this operation, very probably know how to do it anyway.
Assignee: thierry.vignaud => mageiatools
Status: RESOLVED => REOPENEDResolution: OLD => (none)Status comment: (none) => Please simply remove this pitfall
Keywords: NEEDINFO => (none)
(In reply to Pascal Terjan from comment #6) > I wonder if I am not thinking correctly or if it has always been wrong... > Oldest code I could find (diskdrake_interactive.pm,v 1.35 2001/09/24 > 14:06:46 from Mandrake 8.2) was already only offering it in standalone > diskdrake... So the tool was created in a time when many users found themselves with too little space left on / I think this tool was meant to provide an easy way to free up some space, losing some logs in the process was probably not such a big deal because doing nothing would lead to / being too full for logs to be written, anyway. (In reply to Morgan Leijström from comment #21) > Confirmed in comment 5 Did Pascal test whether the tool still works and the /var directory is correctly (except for the log files) moved to the new /var partition? I don't read that there. I had hoped to try to reproduce the issue, but didn't find time :-( Setting to unconfirmed for now. When it is confirmed, it would be good to CC the perl maintainers, I think I heard that we'd have more of them and diskdrake is written in Perl.
Summary: Diskdrake do not correctly move contents of /var when offering so => Diskdrake's option to move the /var directory to new /var partition fails to copy everything that's needed for a good working systemStatus: REOPENED => UNCONFIRMEDEver confirmed: 1 => 0
(In reply to Marja Van Waes from comment #22) > So the tool was created in a time when many users found themselves with too > little space left on / Yes and at that time there were not so many Live USB rescue systems, and now we even have our own Lives :) > I think this tool was meant to provide an easy way to free up some space, Meant to yes, but in my test in comment 0 it failed to remove anything... And per comment 5 that is *designed to fail* in running system. > losing some logs in the process was probably not such a big deal Thats true.
Still valid mga8 so i presume mga7 and cauldron too. Optimally not the same person as reporter should confirm - but in lack of other testing this, here i do... Test install dual boot w MSW10 updated mga8 64 bit, plasma: mga8 was installed as test of live installer, with / on btrfs, and /boot is an ext4, no swap. I updated mga8, rebooted, into diskdrake; shrunk an ntfs partititon to make room created a swap partititon created an ext4 partititon, set to /var, diskdrake asked to move, i said yes. And it seemed to complete. Looking in journal it also looked right, including it said write fstab. Reboot: fail; booted to black screen with mouse pointer. checking journal it failed to open various files under /var, i.e sddm failed. checking fstab, i see no mount point for neither swap nor /var. I wont dig more. As i already told this code should be removed, not fixed. Or at least simply inhibited. Operations like this is better performed from i.e a Live USB system, which we nowadays have - Users needing this are probably educated to do this manually. Also see comment 4. It may have its place during classic ISO upgrade, but it seem to have never worked nor been tested, see comment 5. And probably wil never be used unless documented. And for that fixed and tested. Waste of time IMO. As it is now, the only times it offer to help, it destroys the system. -> Remove, please.
Source RPM: drakxtools-13.58-1.mga1.src.rpm => drakxtools-18.45-1.mga1.src.rpmStatus: UNCONFIRMED => NEWEver confirmed: 0 => 1Whiteboard: (none) => MGA7TOO, MGA8TOO
Target Milestone: --- => Mageia 9