Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LVM partitions not deleted properly on wipe #3028

Open
ThomasMouraBachmann opened this issue Dec 18, 2024 · 3 comments
Open

LVM partitions not deleted properly on wipe #3028

ThomasMouraBachmann opened this issue Dec 18, 2024 · 3 comments

Comments

@ThomasMouraBachmann
Copy link

ThomasMouraBachmann commented Dec 18, 2024

Which ISO version are you using?

2024.12.01

The installation log

Could not determine the filesystem: None
Could not determine the filesystem: parted.FileSystem instance --
  type: linux-swap(v1)  geometry: <parted.geometry.Geometry object at 0x76c87589eba0>  checked: False
  PedFileSystem: <_ped.FileSystem object at 0x76c875876d80>
Could not determine the filesystem: None

https://0x0.st/XCM6.log or https://0x0.st/XCuP.log or https://0x0.st/XCub.log

describe the problem

log.txt

Hardware model detected: Gigabyte Technology Co., Ltd. B650 GAMING X; UEFI mode: True
Processor model detected: AMD Ryzen 5 7600X 6-Core Processor
Memory statistics: 30701756 available out of 32463564 total installed
Could not detect virtual system: ['/usr/bin/systemd-detect-virt'] exited with abnormal exit code [1]: none

System is not running in a VM: ['/usr/bin/systemd-detect-virt'] exited with abnormal exit code [1]: none

Virtualization detected: None; is VM: False
Graphics devices detected: dict_keys(['Advanced Micro Devices, Inc. [AMD/ATI] Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT] (rev c1)'])

@ThomasMouraBachmann ThomasMouraBachmann changed the title test Could not determine the filesystem: None Dec 18, 2024
@C0rn3j
Copy link
Contributor

C0rn3j commented Dec 18, 2024

Creating partitions: /dev/nvme0n1
	Type: primary
	Filesystem: fat32
	Geometry: 2048 start sector, 2097152 length
	Type: primary
	Filesystem: btrfs
	Geometry: 2099200 start sector, 3904927920 length
Traceback (most recent call last):
  File "/usr/lib/python3.12/site-packages/archinstall/__init__.py", line 337, in run_as_a_module
    main()
  File "/usr/lib/python3.12/site-packages/archinstall/__init__.py", line 330, in main
    importlib.import_module(mod_name)
  File "/usr/lib/python3.12/importlib/__init__.py", line 90, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 995, in exec_module
  File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
  File "/usr/lib/python3.12/site-packages/archinstall/scripts/guided.py", line 186, in <module>
    guided()
  File "/usr/lib/python3.12/site-packages/archinstall/scripts/guided.py", line 182, in guided
    fs_handler.perform_filesystem_operations()
  File "/usr/lib/python3.12/site-packages/archinstall/lib/disk/filesystem.py", line 70, in perform_filesystem_operations
    device_handler.partition(mod, partition_table=partition_table)
  File "/usr/lib/python3.12/site-packages/archinstall/lib/disk/device_handler.py", line 712, in partition
    disk.commit()
  File "/usr/lib/python3.12/site-packages/parted/decorators.py", line 28, in new
    ret = fn(*args, **kwds)
          ^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/parted/disk.py", line 208, in commit
    return self.__disk.commit()
           ^^^^^^^^^^^^^^^^^^^^
_ped.IOException: Partition(s) 2, 3 on /dev/nvme0n1 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.

It's the same error as #1789, the exception is still not caught.

Shouldn't it be caught and partprobe attempted, or user at least informed?

@codefiles
Copy link
Contributor

@C0rn3j
I disagree with using partprobe as a solution here. Can you identify what is causing the exception to occur?

@codefiles
Copy link
Contributor

codefiles commented Dec 19, 2024

The log shows that device nvme0n1 was being installed to and would be wiped, including of all existing partitions, by the installer. On that device, the existing partition nvme0n1p3 should have been wiped but was not (the partition is visible in the log under disk states of the second run after the first run should have wiped it). This partition therefore stays in use as the partition table is changed and thus the exception.

The following is pertinent information from the log about the partition:

                {
                    "name": "nvme0n1p3",
                    "path": "/dev/nvme0n1p3",
                    "pkname": "nvme0n1",
                    ...
                    "fstype": "LVM2_member",
                    "fsver": "LVM2 001",
                    ...
                    "children": [
                        {
                            "name": "VG_XenStorage--13ab9ae7--5c42--a888--d71f--0e26ff49b0af-MGT",
                            "path": "/dev/mapper/VG_XenStorage--13ab9ae7--5c42--a888--d71f--0e26ff49b0af-MGT",
                            "pkname": "nvme0n1p3",
                            ...
                            "type": "lvm",
                            ...
                        },
                        {
                            "name": "VG_XenStorage--13ab9ae7--5c42--a888--d71f--0e26ff49b0af-VHD--759ca1c3--356e--41d9--890b--5f3e2dea82cf",
                            "path": "/dev/mapper/VG_XenStorage--13ab9ae7--5c42--a888--d71f--0e26ff49b0af-VHD--759ca1c3--356e--41d9--890b--5f3e2dea82cf",
                            "pkname": "nvme0n1p3",
                            ...
                            "type": "lvm",
                            ...
                        }
                    ]
                },

This is how device wiping is handled:

def _wipe(self, dev_path: Path) -> None:
"""
Wipe a device (partition or otherwise) of meta-data, be it file system, LVM, etc.
@param dev_path: Device path of the partition to be wiped.
@type dev_path: str
"""
with open(dev_path, 'wb') as p:
p.write(bytearray(1024))
def wipe_dev(self, block_device: BDevice) -> None:
"""
Wipe the block device of meta-data, be it file system, LVM, etc.
This is not intended to be secure, but rather to ensure that
auto-discovery tools don't recognize anything here.
"""
info(f'Wiping partitions and metadata: {block_device.device_info.path}')
for partition in block_device.partition_infos:
luks = Luks2(partition.path)
if luks.isLuks():
luks.erase()
self._wipe(partition.path)
self._wipe(block_device.device_info.path)

Apparently the device wiping logic is not sufficient for an LVM partition. This bug can be reproduced by installing to a device that contains an existing logical volume and having the device set to be wiped by the installer.

@svartkanin svartkanin changed the title Could not determine the filesystem: None LVM partitions not deleted properly on wipe Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants