Skip to main content
Topic: [BUG Report][OpenRC] Harddisk is "locked" after deleting and repartition (Read 746 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

[BUG Report][OpenRC] Harddisk is "locked" after deleting and repartition

Hey, I don't know if this is the right place for this thread. Please forgive, and move the accordingly please.

Anyway, what it's about: I have noticed in the last 2 years on several different systems (BIOS, UEFI, notebooks, desktops, Intel, AMD, SSDs, HDDs, any combination) that as soon as I start the installation image (no matter which, whether GUI or Base) and perform the installation steps, from the point after I have run cfdisk and thus partitioned my hard drive, I can not format the resulting partitions with mkfs.ext4 for example, because then an error message/information is given that the partitions cannot be formatted because they are "locked"/in use. Only a reboot of the system helps. Or you can start gparted from a usb stick e.g. before the actual installation and partition the hard drive first and then start the artix installation image.

I noticed this again today when I wanted to set up my "new" notebook (thinkpad x240, 1 sata ssd).

I never reported this because I thought this is surely known and will be fixed in the future.

But since this is now for almost 2 years and the error is still there, I thought I post this times :-)

Reproducible up to the current version: artix-base-openrc-20220713-x86_64.iso

Thanks a lot.

(text translated with deepl, hope everything is understandable)

Edit: This occurs in VMs too (Proxmox, Virtualbox, Vmware Workstation).  I dont know if this same error happens on other versions like s6 suite or so.

Edit2: Sometimes even fdisk -l dont show the new partitions after cfdisk, than a format isnt possible because mkfs.ex4 for example dont see the parititions.

Re: [BUG Report][OpenRC] Harddisk is "locked" after deleting and repartition

Reply #1
If I remember correctly, cfdisk explicitly notifies that any changes will not take effect until after a reboot, is that right?

I usually use gparted, so I am not certain about this.

 

Re: [BUG Report][OpenRC] Harddisk is "locked" after deleting and repartition

Reply #2
Anyway, what it's about: I have noticed in the last 2 years on several different systems (BIOS, UEFI, notebooks, desktops, Intel, AMD, SSDs, HDDs, any combination) that as soon as I start the installation image (no matter which, whether GUI or Base) and perform the installation steps, from the point after I have run cfdisk and thus partitioned my hard drive, I can not format the resulting partitions with mkfs.ext4 for example, because then an error message/information is given that the partitions cannot be formatted because they are "locked"/in use. Only a reboot of the system helps. Or you can start gparted from a usb stick e.g. before the actual installation and partition the hard drive first and then start the artix installation image.
The only way for this to happen - disk/partition be locked and "unformattable" - is if it's mounted. Before starting any partitioning/formatting operations, make sure any partitions on that disk are unmounted. The "lsblk" command will help you see what is mounted where.

Re: [BUG Report][OpenRC] Harddisk is "locked" after deleting and repartition

Reply #3
The only way for this to happen - disk/partition be locked and "unformattable" - is if it's mounted. Before starting any partitioning/formatting operations, make sure any partitions on that disk are unmounted. The "lsblk" command will help you see what is mounted where.

But if they would be mounted, you cant delete and create partitions with cfdisk?

I try to create a video with my smartphone from the install process. Maybe this helps.

Tried right now to install in a VM (kvm). There this Bug didnt happens anymore.



Re: [BUG Report][OpenRC] Harddisk is "locked" after deleting and repartition

Reply #5
Not sure what you mean. If a partition is mounted, it's not safe for cfdisk to alter the partition table and it fails.

Yes. But because cfdisk DOESNT fail, it means that the partition arent mount.

And in fact, after checking it, they arent mount.

But i have some new good and bad Information:

The good one: That "locked/in use" is wrong, it is in fact:

Code: [Select]
#mkfs.ext4 /dev/vda1
mke2fs 1.46.2 (28-Feb-2021)
The file /dev/vda1 does not exist and no size was specified.

And fdisk -l shows:

Code: [Select]
#fdisk -l
Disk /dev/vda: 32 GiB, 34359738368 bytes, 67108864 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdcd1dd75

Device     Boot    Start      End  Sectors  Size Id Type
/dev/vda1  *        2048 65107967 65105920   31G 83 Linux
/dev/vda2       65110014 67106815  1996802  975M  5 Extended
/dev/vda3       65110016 67106815  1996800  975M 82 Linux swap / Solaris


and i can cd to /dev and see vda1 even with ls -l.

But somehow, only after i restart mkfs.ext4 see /dev/vda1. Tested other mkfs.* too.

And now the "bad" Information:

The last 24 hours i tried it dozens times (because i wanted to record it with smartphone like promised) on two other machines. And i have not counted it exactly now, but felt this happened every 20 times (atleast in virt-manager (kvm)).

On the mentioned device, the thinkpad x240, i tried it few times too. and there it happend sometimes too.

It looks that i had simply bad luck everytime i wished to install artix  :'(

Dunno how to reproduce this relaible.

The Steps i took to install is straigt forward:

-Start from ISO
-Set Timezone, Locale etc in the first Menu and "start" the iso.
-Login with artix artix
-Login to root with su
-cfdisk /dev/vda and create the partitions
-mkfs.ext4 /dev/vda1 and at there, sometimes its fails with the in this post mentioned error. Mostly not.

Re: [BUG Report][OpenRC] Harddisk is "locked" after deleting and repartition

Reply #6
partitions are

/dev/sdXY

/dev/sda1 or /dev/sdc3 etc
Cat Herders of Linux

Re: [BUG Report][OpenRC] Harddisk is "locked" after deleting and repartition

Reply #7
partitions are

/dev/sdXY

/dev/sda1 or /dev/sdc3 etc

This isnt fully true.

It depends what Storage you use, and what technology behind that.

IDE for example: /dev/hdX
SATA/SCSI: /dev/sdX
nvme: /dev/nvmeX
virtio: /dev/vdX

and few other niche ones (like floppy).

Re: [BUG Report][OpenRC] Harddisk is "locked" after deleting and repartition

Reply #8
Not sure what you mean. If a partition is mounted, it's not safe for cfdisk to alter the partition table and it fails.
I stand corrected, not *fdisk but mkfs refuses to operate on mounted partitions.

From your last post, I can't see anything wrong on you side. It must be a KVM thing; I've never seen that mkfs.ext4 error in Virtualbox.

Re: [BUG Report][OpenRC] Harddisk is "locked" after deleting and repartition

Reply #9
From your last post, I can't see anything wrong on you side. It must be a KVM thing; I've never seen that mkfs.ext4 error in Virtualbox.

i cant see anything wrong too. This dont happens only in a KVM Machine. I tested it on two machines and a VM last weekend. Sometimes it happens, mostly not. Dont know why, and dont know how to "force" it to show.

The only one common thing between all machines i have and tried Artix on, is that all got a 256GB Samsung 850 SSD (except the KVM of course, because there its virtio (host a nvme)). 

Dont know where i could get or should show for logs etc, if that happens again.

But like said, maybe a thing not worth to spend hours of work for you guys, for something that it seems only me happend because i was unlucky.

I can only say, that this never happend, doesnt matter how many times i tried, on arch linux. So i guess it could be maybe openrc (or the delivered kernel? but i guess the kernel dont differ from that arch uses?).

The only thing i dont tried until now, is to create and use a another usb stick, or even a cd. Maybe the USB Stick is to slow? (ventoy, simple usb 3.0 32gb stick). Maybe the Stick get sometimes hiccups or something? (never tried that, because i thought it is to unlikely. or ventoy maybe? but than this should never happen in the VM, because there the iso is directly used).

Next time i have again much time free, i do more research and give you guys information about that.