Failure to create persistent disk

[mdj2000]

Good morning to the entire forum and especially to the Kaspersky staff. I begin with the premise of praising the product especially the rescue disk. This is because it is one of the very few software to create emergency disks that I sincerely appreciate these stand alone solutions.

Now let's move on to the description of the problem.
1. I create a virtual disk through the Windows disk management console. 4 Gb VHDX disk.
2. Always through the Windows disk management console I mount the hard disk for its subsequent modification
3. I use RUFUS to write the ISO correctly downloaded from the site using the ISO Image function as the DD image creates a virtual disk similar to an unmodifiable CD
4. I unmount the disk from the Windows disk management console
5. I create a virtual machine on Hyper-V and in the configuration I associate the virtual hard disk.
6. I try to boot and everything works correctly. The system starts.
7. Now I try to create a persistent disk. It seems that everything is fine but the report shows me a warning. "warinig: Unable do get device geometry"

8. I save the backstore data and restart the system
9. I update the antivirus database.
10. I restart the system but unfortunately I discover that it has not saved the previous update and I find myself back to square one. I performed a check and it seems that the persistence is still there because it asks me if Leave it/Backup/Delete.

Where is the error in the persistence. Am I doing something wrong in the configuration or is there some hidden parameter in the pre-boot to make everything work?. Thanks for anyone who can help me

Edited November 3 by mdj2000
Description of error

[Buddel]

Try KRD 2024 BETA if you haven't already:

 

[Yury N.]

For KRD2024 used Debian/Ubuntu persistence mechanism

1) Use Rufus for create "persistent" partition. Select appropriate partition size.



2) Add option "persistence" to linux loading. Similar to "trace" option https://support.kaspersky.com/krd18/diagnostics/14223



3) All change will be stored to persistent partition.

You need to add "persistence" option every time when you want to use the persistence storage!
 

[mdj2000]

On 11/4/2024 at 8:44 PM, Buddel said:

Try KRD 2024 BETA if you haven't already:

 

The test with the BETA ISO was unsuccessful. It even crashed during boot. Here is a screenshot of the error. It certainly deserves more attention, but this is another topic on the forum and not my problem here

[mdj2000]

On 11/5/2024 at 1:34 PM, Yury N. said:

For KRD2024 used Debian/Ubuntu persistence mechanism

1) Use Rufus for create "persistent" partition. Select appropriate partition size.



2) Add option "persistence" to linux loading. Similar to "trace" option https://support.kaspersky.com/krd18/diagnostics/14223



3) All change will be stored to persistent partition.

You need to add "persistence" option every time when you want to use the persistence storage!
 

Sorry but this solution also did not produce results.
1. we have a different screen in the boot options

2. when creating persistence i get this error

I also noticed that when RUFUS creates a partition dedicated to persistence it does not create any volume inside. Both without volume and with fat32 volume I get the same error posted previously.

I await further solutions, and sorry if I responded late. Thanks

[mdj2000]

I also tried to change the size of the persistence in rufus. Starting from a base of 4 Gb virtual hard disk I followed the example in the figure creating a persistent partition of 1024 mb in RUFUS. Well... with the boot setting "persistence", the creation of the partition was successful but based on the 3 Gb partition (minus the space dedicated to the operating system so 2.3 Gb) and not on the 1 Gb partition created with RUFUS.

Even in this case the update is only temporary. Upon reboot, with all the boot options, it does not maintain persistence.

[Yury N.]

В 14.11.2024 в 23:53, mdj2000 сказал:

Sorry but this solution also did not produce results.
1. we have a different screen in the boot options

This solution was for KRD2024. It is not suitable for KRD2018.

 

В 14.11.2024 в 23:35, mdj2000 сказал:

The test with the BETA ISO was unsuccessful. It even crashed during boot. Here is a screenshot of the error. It certainly deserves more attention, but this is another topic on the forum and not my problem here

Try changing the minimum memory size to 2Gb. And try disabling dynamic memory.

 

 

[mdj2000]

On 11/16/2024 at 7:36 AM, Yury N. said:

This solution was for KRD2024. It is not suitable for KRD2018.

 

Try changing the minimum memory size to 2Gb. And try disabling dynamic memory.

 

 

ok. I downloaded the new ISO 2024 second beta. Created a 4 gb virtual hard disk.
Used RUFUS with 3 Gb persistence.
Created a 2nd generation virtual machine with 2 Gb of RAM under Hyper-V and the boot is correct.

Unfortunately, adding the "persistence" boot option does not affect the final result. After powering on, changing the boot, updating KRD, and then restarting with the same boot change, it turns out that the update has skipped.

 

No issues whatsoever regarding dynamic memory allocation. This was a reference to a first generation virtual machine.

We are still waiting for a solution.

[Yury N.]

12 часов назад, mdj2000 сказал:

Unfortunately, adding the "persistence" boot option does not affect the final result. After powering on, changing the boot, updating KRD, and then restarting with the same boot change, it turns out that the update has skipped.

You must use "persistence" option every time you want to use persistence partition.

Another option is adding "persistence" option to boot/grub/krd_menu.cfg file in main partition (created by RUFUS).

[mdj2000]

12 hours ago, Yury N. said:

You must use "persistence" option every time you want to use persistence partition.

Another option is adding "persistence" option to boot/grub/krd_menu.cfg file in main partition (created by RUFUS).

but it still doesn't work. I can't figure out where the problem is. I shared the 'virtual hard disk' at this link. Let's see if anyone can get it to work. 

https://mega.nz/file/IsQVCIzQ#mWSVnF2oK68_z5F9zaHU8fWmYb6A4XRfMfsHqltuR18

I tried both with the modification at each boot adding the word "persistence". As well as I modified the file boot/grub/krd_menu.cfg with the "persistence" but I get no benefit. After the complete boot with the option, the update, the reboot with the persistence option again the update disappears. Where is the error? Maybe this version is not designed for persistence either.
I wait, who knows

[Yury N.]

You have two FAT32 partitions (see Disk Managment screen). How did you create them? Maybe you reformatted the second partition?




After Rufus must be two partitions: FAT32 and EXT2

 

Edited November 19 by Yury N.

[mdj2000]

13 hours ago, Yury N. said:

You have two FAT32 partitions (see Disk Managment screen). How did you create them? Maybe you reformatted the second partition?




After Rufus must be two partitions: FAT32 and EXT2

 

ok I apologize for the first sharing. It was a test I did on the second partition, but I did it because even with the second partition of EXT3 it does not become persistent.
The old sharing link is no longer valid and I created another one.

https://mega.nz/file/4lYF2DIL#SIAm2WcWZjIqVUpEuMgWH9G2Bh-AfUJ5r_OIH8j6Vik

This time the link contains the 4 Gb virtual hard disk file, updated with RUFUS as you indicate, verified without affecting anything the two partitions of which the second as EXT3, added the modification to the boot / grub / krd_menu.cfg file with the "persistence" entry. Started, updated, restarted and unfortunately no persistence of the updates.

Let's check this new file and if possible try it with Hyper-V and try to understand where the error is.

Anyway I add that even if up to now we have not yet achieved a result I want to thank you

[KarDip]

Hello @mdj2000

Thank you for providing a detailed description of your process and the issue you're encountering with Kaspersky Rescue Disk (KRD) persistence. Based on your explanation, it seems the persistence is not functioning correctly, even though the process appears to partially succeed.

Here’s a breakdown of potential reasons for this issue and steps to troubleshoot or resolve it:

---

Possible Causes and Solutions

1. Virtual Disk Geometry Error: The warning message "Unable to get device geometry" suggests that the virtual disk’s configuration might not fully support the expected parameters for Kaspersky Rescue Disk persistence.

   • Solution: Ensure the VHDX file system is formatted as FAT32 (preferred) or another supported filesystem by KRD. NTFS may not work properly with persistence in some cases. If you’re using a dynamic-sized VHDX, consider creating a fixed-sized VHDX instead, as dynamic disks may cause compatibility issues with certain boot utilities.

2. ISO Boot Mode: If the ISO image is written using RUFUS in DD mode, the persistence might not be supported, as KRD might not recognize the changes due to the "read-only" nature of the virtual disk presented.

   • Solution: Instead of using DD image mode, ensure RUFUS is set to ISO image mode, as you mentioned in step 3. Verify the configuration settings and test by recreating the virtual disk with the recommended settings.

3. Hyper-V Configuration: Hyper-V might not properly emulate the storage controller required for KRD persistence.

   • Solution:
     • Configure the virtual machine's hard disk as IDE or a standard SCSI controller instead of advanced or pass-through settings.
     • Check Hyper-V settings for compatibility mode options, ensuring it supports legacy BIOS/MBR boot if applicable.

4. Kaspersky Rescue Disk Persistence Feature: The persistence feature in KRD is designed for physical USB drives and might not work reliably in virtual environments.

   • Solution: Test the same ISO and persistence configuration on a physical USB drive using RUFUS to rule out any issues specific to the virtual environment.

5. Antivirus Database Directory: Sometimes, persistence can fail because the antivirus database update files are not saved in the expected directory.

   • Solution: After creating the persistent storage and booting into KRD, manually check the /mnt or /dev directory for mounted storage and verify whether the updates are being stored on the persistent volume. Ensure the volume is mounted and writable during the update process.

6. Log Files and Errors: The KRD might provide additional error logs that can help pinpoint the problem.

   • Solution: Check the KRD logs under /var/log/ or within the KRD interface to identify specific errors related to persistence or database updates.

---

Testing Steps to Isolate the Problem

1. Create a physical USB drive with the KRD ISO using RUFUS (ensure persistence is enabled).
2. Test the persistence feature on a physical system to ensure it works outside the virtual environment.
3. Recreate the virtual disk in FAT32 format with a fixed size, ensuring compatibility.
4. Switch the virtual disk controller in Hyper-V to IDE or SCSI and retest.

---

Final Notes

The issue seems to stem from the virtual environment setup, as KRD persistence is designed primarily for physical media. Virtual disks in Hyper-V may not always emulate the required hardware behaviour, leading to issues like device geometry errors and failed persistence.

Testing in a physical environment should help determine if the problem is specific to the virtual setup or a general issue with KRD persistence.

Let me know if you need further clarification or assistance!

Thank you

Edited November 20 by KarDip
error console

[Yury N.]

13 часов назад, mdj2000 сказал:

https://mega.nz/file/4lYF2DIL#SIAm2WcWZjIqVUpEuMgWH9G2Bh-AfUJ5r_OIH8j6Vik

It's correct VHD. For check pesistence on this VHD:

1) Load to KRD
2) Create "test.log" file on Desktop and write something there
3) Reboot
4) Load to KRD
5) Check for the presence of file "test.log"

Edited November 20 by Yury N.

[mdj2000]

18 hours ago, KarDip said:

Hello @mdj2000

Thank you for providing a detailed description of your process and the issue you're encountering with Kaspersky Rescue Disk (KRD) persistence. Based on your explanation, it seems the persistence is not functioning correctly, even though the process appears to partially succeed.

Here’s a breakdown of potential reasons for this issue and steps to troubleshoot or resolve it:

---

Possible Causes and Solutions

1. Virtual Disk Geometry Error: The warning message "Unable to get device geometry" suggests that the virtual disk’s configuration might not fully support the expected parameters for Kaspersky Rescue Disk persistence.

   • Solution: Ensure the VHDX file system is formatted as FAT32 (preferred) or another supported filesystem by KRD. NTFS may not work properly with persistence in some cases. If you’re using a dynamic-sized VHDX, consider creating a fixed-sized VHDX instead, as dynamic disks may cause compatibility issues with certain boot utilities.

2. ISO Boot Mode: If the ISO image is written using RUFUS in DD mode, the persistence might not be supported, as KRD might not recognize the changes due to the "read-only" nature of the virtual disk presented.

   • Solution: Instead of using DD image mode, ensure RUFUS is set to ISO image mode, as you mentioned in step 3. Verify the configuration settings and test by recreating the virtual disk with the recommended settings.

3. Hyper-V Configuration: Hyper-V might not properly emulate the storage controller required for KRD persistence.

   • Solution:
     • Configure the virtual machine's hard disk as IDE or a standard SCSI controller instead of advanced or pass-through settings.
     • Check Hyper-V settings for compatibility mode options, ensuring it supports legacy BIOS/MBR boot if applicable.

4. Kaspersky Rescue Disk Persistence Feature: The persistence feature in KRD is designed for physical USB drives and might not work reliably in virtual environments.

   • Solution: Test the same ISO and persistence configuration on a physical USB drive using RUFUS to rule out any issues specific to the virtual environment.

5. Antivirus Database Directory: Sometimes, persistence can fail because the antivirus database update files are not saved in the expected directory.

   • Solution: After creating the persistent storage and booting into KRD, manually check the /mnt or /dev directory for mounted storage and verify whether the updates are being stored on the persistent volume. Ensure the volume is mounted and writable during the update process.

6. Log Files and Errors: The KRD might provide additional error logs that can help pinpoint the problem.

   • Solution: Check the KRD logs under /var/log/ or within the KRD interface to identify specific errors related to persistence or database updates.

---

Testing Steps to Isolate the Problem

1. Create a physical USB drive with the KRD ISO using RUFUS (ensure persistence is enabled).
2. Test the persistence feature on a physical system to ensure it works outside the virtual environment.
3. Recreate the virtual disk in FAT32 format with a fixed size, ensuring compatibility.
4. Switch the virtual disk controller in Hyper-V to IDE or SCSI and retest.

---

Final Notes

The issue seems to stem from the virtual environment setup, as KRD persistence is designed primarily for physical media. Virtual disks in Hyper-V may not always emulate the required hardware behaviour, leading to issues like device geometry errors and failed persistence.

Testing in a physical environment should help determine if the problem is specific to the virtual setup or a general issue with KRD persistence.

Let me know if you need further clarification or assistance!

Thank you

It seems that we have returned to the 2018 version from 2024 for a certain point. Let's try to make a point of the situation by making several clarifications and tests to avoid confusion
1. in the 2024 version with both VHDX and 3 Gb fixed VHD error in the persistence of the update.
2. I am sure that the writing mode of all VHDX is in single and mandatory ISO mode when choosing persistence in RUSUF. Probably as far as I understand persistence is not needed for the 2018 version
3. regarding the hardware settings in Hyper-V they are the following: on generation 2 only SCSI control while on generation 1 both IDE and SCSI, boot on generation 1 for the 2018 version and generation 2 for the 2024 version. The difference is that the operating system can be 32 bit in the 1 and only 6 bit with UEFI in the second
4. I understand that the function is only for physical USB drives and it works but if we can find a solution also in a virtual environment, welcome otherwise we have wasted a lot of time to understand it. And I am convinced that it should also work in a virtual environment.
5. in the /mnt/krd2024/bases folder the folder is empty. It could be a cause of the problem
6. I will publish links with the LOG folder in the various cases

10 hours ago, Yury N. said:

It's correct VHD. For check pesistence on this VHD:

1) Load to KRD
2) Create "test.log" file on Desktop and write something there
3) Reboot
4) Load to KRD
5) Check for the presence of file "test.log"

creating a file on the desktop with dummy content inside remains even after reboot. Proof that persistence works but only partially

We could also reason in reverse. Please provide me with a link to a 3 or 4 GB virtual hard disk with persistence on board already working.

the old share link has been deleted

[KarDip]

13 hours ago, Yury N. said:

It's correct VHD. For check pesistence on this VHD:

1) Load to KRD
2) Create "test.log" file on Desktop and write something there
3) Reboot
4) Load to KRD
5) Check for the presence of file "test.log"

hello @Yury N.

Your outlined steps provide a straightforward way to test persistence functionality with the Kaspersky Rescue Disk (KRD) in a virtualized environment or any setup where persistence is expected. Let’s analyse and ensure this approach covers all aspects:

---

Steps for Persistence Verification

1. Load into KRD:

   • Boot into KRD using the configured environment (physical USB or virtual machine with the VHD attached).

2. Create test.log:

   • On the Desktop, create a file named test.log using the text editor available in KRD.
   • Write something distinctive in the file (e.g., "Persistence Test - Date & Time").

3. Reboot:

   • Restart the system without making any other changes.

4. Reload into KRD:

   • Boot back into the same KRD environment (using the same physical USB or virtual setup).

5. Check for test.log:

   • Navigate to the Desktop and verify if the file test.log exists with the content intact.

---

Expected Results

1. If persistence is working:
   • The test.log file should still be present on the Desktop with the exact content you entered before the reboot.
2. If persistence is not working:
   • The test.log file will not be present after the reboot, indicating that changes made during the session were not saved.

---

Further Diagnostics if Persistence Fails

If persistence does not work, follow these additional steps to isolate the cause:

Step 1: Verify VHD Configuration

• Ensure the VHD is mounted and writable during KRD’s runtime.
• Use lsblk or fdisk in the terminal (if available) to confirm the disk is detected and mounted.

Step 2: Check Mount Points

• Confirm that the persistent storage (VHD) is correctly mounted to /mnt/krd2024 or the appropriate directory.

Step 3: Permissions

• Verify that the /mnt/krd2024 directory and its subfolders have appropriate write permissions.

Step 4: Logs

• Check the system logs for any errors related to mounting or saving data to the persistent disk:

  bash

  Copy code

  dmesg | grep mount cat /var/log/syslog
• Look for issues like read-only file system or disk not found.

Step 5: Test Physical USB Persistence

• Perform the same test on a physical USB drive to confirm whether the issue is specific to the virtualized environment.

Step 6: Compare Versions

• Repeat the test with KRD 2018 and 2024 to confirm if the problem lies within the version itself or the specific setup.

---

Outcome of Tests

1. If the test works on a physical USB but fails in a virtualized environment, it suggests a compatibility issue with the virtual setup (Hyper-V, VHDX format, etc.).
2. If both setups fail, there may be a configuration or software issue within the KRD 2024 persistence implementation.

Let me know the results, and we can further troubleshoot based on your findings!

Thank you

Hello @mdj2000

The issue you’re encountering with Kaspersky Rescue Disk (KRD) 2024 and its persistence setup in a virtual environment appears to involve several layers, including version differences, hardware configurations, and how persistence is handled. Here's a breakdown of the situation, points to consider, and possible solutions:

---

Key Observations

1. Persistence Issues in KRD 2024:

   • VHDX or fixed 3GB VHD setups fail to maintain persistent updates.
   • Persistence appears not to function as expected when the setup is deployed in a virtualized environment like Hyper-V.

2. 2018 vs. 2024 Versions:

   • KRD 2018 does not seem to require persistence.
   • KRD 2024 introduces persistence but struggles to retain updates on VHD/VHDX in virtualized scenarios.

3. Hardware Differences in Hyper-V:

   • Generation 1: Supports both IDE and SCSI controllers, compatible with 32-bit and legacy boot options.
   • Generation 2: Requires UEFI and supports only 64-bit operating systems, offering better performance but stricter hardware requirements.

4. Empty /mnt/krd2024/bases Folder:

   • The empty folder suggests that the base files for updates are either not being created or are not saved due to permission, pathing, or improper configuration during the persistence setup.

5. USB vs. Virtual Environments:

   • Persistence appears to function reliably on physical USB setups.
   • Virtual environments may lack compatibility for certain file system operations or need additional configuration for proper disk mounting.

---

Tests and Clarifications

To refine the analysis, here are some steps you can perform:

Test 1: Verify Persistence on Physical USB

• Confirm that persistence works on a physical USB drive by updating the KRD 2024 bases and rebooting to check if the updates are retained.
• If this works, the issue is likely tied to the virtual environment setup or the way VHDX/VHD is configured.

Test 2: Check Hyper-V Disk Configuration

• Ensure the virtual hard disk (VHDX) is correctly attached and writable:
  • For Generation 1, try using IDE controllers.
  • For Generation 2, verify that the SCSI controller is recognized during boot.
• Use dynamic expansion for VHD instead of fixed size and check if this affects persistence.

Test 3: Inspect Logs

• Share the logs from the /mnt/krd2024 directory to identify where the failure occurs.
• Focus on errors related to mounting, permissions, or writing to the bases folder.

Test 4: Enable Debugging

• Boot KRD 2024 in debug mode (if available) to capture detailed logs during the update and reboot process.

Test 5: Alternative Virtualization Platforms

• Test KRD 2024 on other virtualization platforms like VMware or VirtualBox to determine if the issue is specific to Hyper-V.

---

Potential Causes

1. File System Compatibility:

   • The persistence system might rely on specific file systems or disk types that are not correctly emulated in a virtualized environment.

2. Boot Mode Compatibility:

   • Ensure that UEFI is properly configured if using Generation 2 in Hyper-V.

3. Permissions Issues:

   • KRD may not have sufficient permissions to write to the VHDX file during runtime in a virtualized environment.

4. Software Limitation:

   • Kaspersky may not officially support persistence for KRD in virtual environments.

---

Possible Solutions

1. Force Mounting the bases Folder:

   • Manually mount and verify the /mnt/krd2024/bases directory to check if it's writable.

2. Create a Pre-Updated KRD ISO:

   • Update KRD 2024 bases on a physical USB drive, then convert the USB contents into an ISO and attach it to the virtual machine.

3. Check and Modify Boot Parameters:

   • Ensure the boot parameters explicitly include paths to persistence.

4. Feedback to Kaspersky:

   • If persistence on virtual machines is critical, consider reaching out to Kaspersky technical support to clarify whether this feature is supported and to report your findings.

5. Manual Updates in Virtual Environment:

   • As a workaround, periodically update the bases folder manually by copying files from a physical USB setup or downloading them externally.

---

Conclusion

While persistence works reliably on physical USB drives, achieving the same in a virtualized environment may involve advanced configurations or is potentially unsupported. The empty /mnt/krd2024/bases folder is a significant clue, suggesting an issue with the write process.

Testing and sharing uploaded logs To Kaspersky Technical support will provide more clarity to share.

Thank you

 

[Yury N.]

9 часов назад, mdj2000 сказал:

1. in the 2024 version with both VHDX and 3 Gb fixed VHD error in the persistence of the update.

Please provide a screenshot of your problem.

[mdj2000]

Here is the first link containing zip file with screenshots and pre and post reboot logs of KRD version 2018 with fixed 3Gb VHD. I have included screenshots of all the individual steps. If anyone is not clear I can also make a screen recording. At this point I draw the first conclusion if someone does not suggest a solution, that as far as the 2018 version is concerned it is not possible to create a persistence on a fixed virtual disk emulated on Hyper-V.

https://mega.nz/file/I8BV3KgR#8Hb4Pvn_hSWJ1yl-3M7wf6d8M2erkDX1jarnAT8u7l4

Further upload of the 2024 version test will follow.

[mdj2000]

Here I attach links on the tests of the 2024 version with the relative LOGs. Here too I deduce that persistence does not work with fixed VHD and virtual machine on Hyper-V.

https://mega.nz/file/ttJkBbBA#UcZTA3-uYCSxNbb9PJcOQH9G4d69XhJK3-GR9E4jsKY

I hope to have created an opportunity for study in fixing what I consider an error

[mdj2000]

I am sorry to communicate and therefore to close the thread.
After a few days, having no further solutions in this regard, there is no solution regarding a persistence on KRD 2018 and 2024 on VHD part of Hyper-V