Installed clonezilla from PPM, now Xenial64 won't boot(Given up)

[number77]

Hello
I am running or was Xenial64 on a Dell E6230.
Last thing I did was to install clonezilla from PPM. On reboot it loads kernel, sfs, zdrv, savefile then starts switch root to a layered filesystem. It never does but stops.
What could I have done and is there any way back.
Help really appreciated.
Thanks
number77

[rockedge]

So right after installing clonezilla you did the reboot? Is there a backup of the savefile?

What was run (if anything) after installing clonezilla?

[number77]

So right after installing clonezilla you did the reboot? Is there a backup of the savefile?

What was run (if anything) after installing clonezilla?

I ran clonezilla to see if it ran, it did. I closed the pc down and later re booted. I had forgotten to remove the usb key with acronis true image on and it booted to that.I shut it down, removed it and tried to boot into xenial64. Problem started. I have a savefile about six months old, could try that.
What do you think.

[bigpup]

Try booting not using the save.
Just to see if it boots to working desktop.
If it does.
That says the basic install is working.

Thus the save file/folder has some issue, because it will not boot using the save.
If the save is the problem.

Could try this:
To test for and repair errors in Linux file system, use "e2fsck".

Boot Xenialpup, using boot option: puppy pfix=ram so save is not used.

The save file can not be in use.

Mount the partition the save is on.

Open a terminal, and enter:

e2fsck /path to savefile

For example:
Save file is on partition sda1.
e2fsck -p /mnt/sda1/pupsave.2fs

To check a save folder use the method for checking a partition.
Check the partition the save folder is on.

To do the whole partition:
Need to boot from a live Puppy or a Puppy on a different partition to do a partition check.
(the partition must be unmounted)
Example:
partition sda1

e2fsck -p /dev/sda1

[number77]

Try booting not using the save.
Just to see if it boots to working desktop.
If it does.
That says the basic install is working.

Thus the save file/folder has some issue, because it will not boot using the save.
If the save is the problem.

Could try this:
To test for and repair errors in Linux file system, use "e2fsck".

Boot Xenialpup, using boot option: puppy pfix=ram so save is not used.

The save file can not be in use.

Mount the partition the save is on.

Open a terminal, and enter:

e2fsck /path to savefile

For example:
Save file is on partition sda1.
e2fsck -p /mnt/sda1/pupsave.2fs

To check a save folder use the method for checking a partition.
Check the partition the save folder is on.

To do the whole partition:
Need to boot from a live Puppy or a Puppy on a different partition to do a partition check.
(the partition must be unmounted)
Example:
partition sda1

e2fsck -p /dev/sda1

It will start in ram mode, so if this is the same as pfix=ram I will proceed.
I also have xenial 32 bit on another partition so can check the partition the save file is on.
I will do one step at a time

[wizard]

Same problem in fossa64, reported here:

viewtopic.php?t=4151

wizard

[number77]

Tried to examine problem HDD externally with HDD to USB converter.
Got
e2fsck -p /dev/sdb2
/dev/sdb2: clean, 9160/1340864 files, 417470/5361693 blocks
What does that mean.

[number77]

Same problem in fossa64, reported here:

viewtopic.php?t=4151

wizard

Is there any way to UN-install clonezilla from the save file using HDD externally.

[wizard]

I have not tried it, by my knowledge it would be possible, but a very convoluted process.

wizard

[bigpup]

Tried to examine problem HDD externally with HDD to USB converter.
Got
e2fsck -p /dev/sdb2
/dev/sdb2: clean, 9160/1340864 files, 417470/5361693 blocks
What does that mean.

That indicates nothing is wrong with the file system on the partition sdb2
That is a good check of the save if it is a save folder on sdb2.
But this only checks the file system.

Clonzilla could still have done something to the files or programs needed to properly boot Xenialpup64.

[bigpup]

Same problem in fossa64, reported here:

viewtopic.php?t=4151

wizard

Is there any way to UN-install clonezilla from the save file using HDD externally.

If you boot Xenialpup64 not using the save.
Click on the bad save file or folder to open it in Rox.
Pfind can be used to search for clonzilla
Use advanced options to specifically tell it to search in that opened save location.
The stuff it finds can be deleted manually.
Right click menu for a listed item, has options to delete or move to trash.

Start deleting any clonzilla directories.
Redo the search.
Hopefully there will only be a few other specific files still needed to delete.

But really the best option is to use a backup good copy of the save, that we all should be making.

[number77]

But really the best option is to use a backup good copy of the save, that we all should be making.
[/quote]

I have done this and deleted or moved to trash all clonezilla files. Pfind does not find any clonezilla files on the partition. Still will not start. Any ideas?

Alternatively I have a backup on ext HDD, xenialpup64save.2fs. What would be the best way to use it. If I keep the existing save file should I rename it and as what to not be recognised as a save file.

[wizard]

Did some testing on fossa64 9.5 and guess that it will be the same on your xenial64.

Here is a archive that contains 2 files, overall_install_report.txt and login_4.8.1.files . My test showed that the login_4.8.1 package was the one keeping the system from booting so delete those files first and try to boot.

-boot with no save file
-open: login_4.8.1.files in your editor, this is a list of files to delete
-using rox, click the corrupted save file to open it
-using rox, navigate to the files in the list and delete them

-reboot using the modified save file
-open the file: overall_install_report.txt, this is a list of all the packages cz installed
-use the ppm to remove the packages

wizard

cz_fix.tar.gz

(1.03 KiB) Downloaded 17 times

[bigpup]

Just to make sure you understand.
You seem to be using a save file.
The stuff you want to delete is in that save file.

So if you have to boot not using the save, to get to a working desktop.
You need to mount the save file by clicking on it in Rox file manager.
That will open a Rox window showing the contents of the save file.
It will appear to look like the normal file system, because that is what it is. A copy of the file system in a sfs package file.
It contains what is different from the original file system.
Now the contents of the save can be acted on.
You navigate around in that save file internal file system, which is complete separate of the running Puppy file system.

If you have a save you do not want to be seen by the boot process.
Add bak. to the beginning of the name of the save file.
Example:
bak.xenialpup64save.2fs

[number77]

Did some testing on fossa64 9.5 and guess that it will be the same on your xenial64.

Here is a archive that contains 2 files, overall_install_report.txt and login_4.8.1.files . My test showed that the login_4.8.1 package was the one keeping the system from booting so delete those files first and try to boot.

-boot with no save file
-open: login_4.8.1.files in your editor, this is a list of files to delete
-using rox, click the corrupted save file to open it
-using rox, navigate to the files in the list and delete them

-reboot using the modified save file
-open the file: overall_install_report.txt, this is a list of all the packages cz installed
-use the ppm to remove the packages

wizardcz_fix.tar.gz

wizard I cant find any of these files in Xenial64, nor Fossapup

[wizard]

You should disregard my reference to fossa64 9.5 since I only used it to find the problem and document the fix. The steps to fix should be the same for your xenial64.

In one of your post above you said you deleted all the clonezilla files you could find. My question is, did you make a copy of the bad save file to experiment on or were you using the original? If you were editing the original bad file there is a real possibility that it cannot now be recovered. Time to use your backup save file or start over.

wizard

[number77]

You should disregard my reference to fossa64 9.5 since I only used it to find the problem and document the fix. The steps to fix should be the same for your xenial64.

In one of your post above you said you deleted all the clonezilla files you could find. My question is, did you make a copy of the bad save file to experiment on or were you using the original? If you were editing the original bad file there is a real possibility that it cannot now be recovered. Time to use your backup save file or start over.

wizard

Good thinking wizard. Yes I have the backup save file on external HDD. I could reinstall it.

[number77]

You should disregard my reference to fossa64 9.5 since I only used it to find the problem and document the fix. The steps to fix should be the same for your xenial64.

In one of your post above you said you deleted all the clonezilla files you could find. My question is, did you make a copy of the bad save file to experiment on or were you using the original? If you were editing the original bad file there is a real possibility that it cannot now be recovered. Time to use your backup save file or start over.

wizard

No such luck wizard, I copied the bad save file over to ext. HDD but after I had deleted any reference to clonezilla.
I will take your advise and use older backup file and give up.
Thanks for your help. I will make more use of Pupsave backup in future.

[number77]

Thanks for all the help everyone once more.
number77

[wizard]

Even if you can't recover the bad save file itself, you should be able to recover any photos, documents, etc. that were on the bad save file.

wizard

[number77]

Even if you can't recover the bad save file itself, you should be able to recover any photos, documents, etc. that were on the bad save file.

wizard

Thanks wizard.
I have a new save file on the xenial64 partition now which is working fine. I can access the old corrupt save file from ext HDD. Can you recommend any files I could safely transfer to the new from old. Bearing in mind I have not been very carefull keeping it thin lately.

[xenial]

Just to point out.
puppy has cloning software built in and maybe clonezilla is not needed.