<div dir="ltr"><div>thanks for this quick feedback Lennart.</div><div>don't worry, this is not an evolution request for systemd :-)</div><div>yes for <span style="font-family:monospace">blockdev --setro</span> and, unfortunately, yes for overflows from file systems.</div><div><i>I had once considered using <span style="font-family:monospace">qemu-nbd/snapshot</span> to "tolerate" some writes without altering the real device (because absorbed by the snapshot)...</i></div><div><br></div><div>regards, lacsaP.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 25 avr. 2022 à 16:33, Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mo, 25.04.22 16:25, Pascal (<a href="mailto:patatetom@gmail.com" target="_blank">patatetom@gmail.com</a>) wrote:<br>
<br>
> hi,<br>
><br>
> the udev rules prohibit renaming anything other than a network device :<br>
> what is (would be) the way to really rename a block device (not just to<br>
> create a symbolic link) ?<br>
<br>
This functionality does not exist in the kernel to my knowledge. And<br>
the uevents for renaming network interface devices are messy enough to<br>
handle, let's please not add this for another subsystem!<br>
<br>
Are you aware of the udev.blockdev_read_only kernel cmdline option<br>
btw?<br>
<br>
(note that Linux is broken, marking a block device read-only actually<br>
is cosmetics mostly. File systems you mount from them may and do still<br>
write to the devices happily regardless whether read-only or<br>
not. Event through loopbck devices actually. You need to pass<br>
'norecovery' as mount option to relevant file systems if you want<br>
true read-only access. It's crazy, if you ask me)<br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br>
</blockquote></div>