- This topic has 8 replies, 4 voices, and was last updated Mar 26-2:25 pm by Anonymous.
-
Posts
-
eltuno
Hey
I’ve just remastered my live MX and something has struck me, as it complained about not having enough space to make it.
Looking for space to free, I thought I could just delete the old linuxfs file, aptly named linuxfs.old, and then starting the tool again it stopped whining and everything went fine.
So here’s my question : why include linuxfs.old and rootfs.old in the calculation of available space, as these files are going to be overwritten anyway ? These files are not needed anymore. If something goes wrong, there will be two new old files created (yeah) from the current state, i.e. from the state before remaster begins.
So in my opinion there’s much more space available than what that tool claims.
- This topic was modified 4 years, 1 month ago by eltuno.
anticapitalista
Those files do not get overwritten.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
Yeah technically maybe they don’t, they just get deleted and then replaced by new ones with the same name. But that’s still the same question to me.
OK maybe they get opened and changed, but here’s another way to ask my question.
How come linuxfs and linuxfs.old have approximately the same size after remaster has just been done ?
I expected one to be nearly empty …
anticapitalista
linuxfs.old and rootfs.old are the renamed working files before you do the remaster. They are not changed at all. They are, if you like, backup files, just in case remaster fails. Then you can use the rolback feature.
See here for info: Remaster
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
BitJam
Looking for space to free, I thought I could just delete the old linuxfs file, aptly named linuxfs.old, and then starting the tool again it stopped whining and everything went fine.
The live-remaster tool should force you to either delete the .old files or move them somewhere else before it starts. If it is not doing so then this is a bug we need to fix.
why include linuxfs.old and rootfs.old in the calculation of available space,[…]
You did not specify which calculation of available space. As anti already explained, those files are needed for the “rollback” feature which IMO is an essential part of our live system. We try very hard to avoid making a live-usb unbootable, or worse to destroy the user’s information. You are suggesting we stop treating user’s data as valuable for momentary personal convenience for your particular situation and I disagree.
If your boot after a remaster was successful and you are sure you don’t want to rollback then you can just run live-remaster again and it will help you delete those files and you will still have an opportunity to bail out later. I think we have another program that helps you manage those files as well. I agree this is still an inconvenience in some situations but it is slight and I believe this slight inconvenience to one group of users is greatly outweighed by not totally screwing over another group of users.
From a computer science standpoint we are doing the right thing. You should not destroy information you may eventually need until you have to. For example, this is the guiding principle behind the Linux virtual memory system. So we hang onto the .old files for as long as possible until the users decides they are not needed, often when they start another remaster.
\rant
Context is worth 80 IQ points -- Alan Kay
Anonymous
“remastercc”
Muddy waters. Hmm, that labelname might be mentioned in MX linux.
In antiX I drew a blank when I checked “which remastercc” and “locate remastercc”.why include linuxfs.old and rootfs.old in the calculation of available space
It’s a good (multiple) questions, eltuno.
The rationale behind “why so” is probably absent from the concise docs.Why? because they truly exist, truly occupy space, at the time of the calculation.
these files are going to be overwritten anyway
[hold that thought]
These files are not needed anymore.
Personally, I retain several. In case of a desired rollback, you (I) might not realize “needed” until until it’s too late.
But… are you running an up-to-date antiX system?
On my system, /usr/local/bin/live-remaster DOES ASK, offers to remove the *.old filesedited to added:
Aha! Looks like the live-remaster could be revised so that its “check and ask to remove” step will occur prior to performing the space calculation(s).leftovers="$SQFILE_NAME.old rootfs.old rootfs.bad $SQFILE_NAME.new $SQFILE_NAME.bad $SQFILE_NAME.tmp" BAD_FILES="" for file in $leftovers; do [ -e "$SQFILE_DIR/$file" ] && BAD_FILES="$BAD_FILES $file" done kill_bg_info_box [ $boot_avail -lt $safe_estimate_xz ] && \ error_box_pf "Have: %s megs available. Need: %s." "[n]$boot_avail[/]" "[n]$safe_estimate_xz[/]" while [ "$BAD_FILES" ]; do yes_no_box \ "$(gt "Leftover files found")" \ "" \ "$(gt "The following file(s) already exist")" \ "$(pfgt "in the %s directory:" "[f]$SQFILE_DIR[/]")" \ "" \ "[f]$BAD_FILES[/]" \ "" \ "$(gt "They may be left over from a previous remastering.")" \ "$(gt "Do you want to fix this problem now?")" \ "$(gt "(the alternative is to quit now)")"How come linuxfs and linuxfs.old have approximately the same size after remaster has just been done ?
EDIT: Removed my incorrect reply. Sorry, I had misread the quesion.
From a computer science standpoint we are doing the right thing.
Yes, I agree.
From a usability, or user advocacy, or lets-meet-in-the-middle standpoint though…
I also agree that it would be beneficial to check/ask as Step 1Found *.old files present. Would you prefer to: 1) rename *.old to *._{mtime}stamp 2) delete rootfs.old 3) exit the live-remaster script and manually move/archive the *.old files
- You must be logged in to reply to this topic.
