| Summary: | Diskdrake's option to move the /var directory to new /var partition fails to copy everything that's needed for a good working system | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Morgan Leijström <fri> |
| Component: | RPM Packages | Assignee: | Mageia tools maintainers <mageiatools> |
| Status: | NEW --- | QA Contact: | |
| Severity: | critical | ||
| Priority: | Normal | CC: | marja11, pterjan |
| Version: | Cauldron | ||
| Target Milestone: | Mageia 9 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA7TOO, MGA8TOO | ||
| Source RPM: | drakxtools-18.45-1.mga1.src.rpm | CVE: | |
| Status comment: | Please simply remove this pitfall | ||
| Attachments: | From diskdrake log window | ||
|
Description
Morgan Leijström
2012-01-22 14:08:58 CET
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) =>
Triaged 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 =>
RESOLVED 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) 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 =>
RESOLVED AFAIK it was never neither fixed nor removed. See for ideas how see #c9 and above. Changing to cauldron. Version:
3 =>
Cauldron 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) =>
marja11 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 Status:
REOPENED =>
RESOLVED 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
Morgan Leijström
2021-03-06 14:57:17 CET
Status:
RESOLVED =>
REOPENED
Morgan Leijström
2021-03-06 14:57:29 CET
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 system (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.rpm
Morgan Leijström
2022-09-14 21:18:25 CEST
Target Milestone:
--- =>
Mageia 9 |