Re: naming a partition after the fact?
On 9/29/23 23:31, Max Nikulin wrote:
On 30/09/2023 02:54, gene heskett wrote:
On 9/29/23 15:17, Andy Smith wrote:
Probably, but adding a label to a *filesystem* is easy, so will
that suit your needs? "man e2label" for ext* filesystems.
That is what I couldn't remember Andy, thanks.
In the case of GPT, partitions may have names that are independent of
filesystem labels. It is similar to partition UUID and filesystem UUID.
If not, what are you actually trying to achieve with partition
names? I can't think what use they have ever been to me in several
decades.
Non volatility. Partition names are permanent until changed, or the
drive upchucks. blkid's are quite a bit more volatile and have bitten
me several times in now long past history.
Unless you figure out what you did wrong file system (or partition)
UUIDs, you may be bitten by partition (or file system labels) more
severely. Some variants:
- Blindly clone a disk without further steps to assign new UUIDs and
accidentally plug both disks, so system may pick partition from any of
them. E.g. sgdisk has -G, --randomize-guids (filesystem IDs are not
affected however, so need to be changed separately)
That, while possible, is highly unlikely here as I have only one rpi4b.
And I don't have a habit of moving drives around.
- Random number generator is not properly initialized, so assigned UUIDs
are not random (no real time clock, lack of entropy inside a VM or
inside a container).
This last s/b valid for rpi's as they have no hdwe clock, and many of
the 3d printer drivers run inside a python venv whose isolation
completeness seems to be suspect. It is a good way to hide python diffs
though.
For instance and going off-topic, I'm getting bogus status data from
klipper running on bananapi-m5's unless I exit the firefox running on
this maschine and then restart it on a per print basis. I blame that on
firefoxes/linux's caching though. Linux's caching is something else, If
I make a mod to an openscad file, then resave the .3mf, I have to use
cura's search from root of filesystem in order to be assured I actually
get the new file and not the old, supposedly overwritten version. Then I
have to do the same thing in mc by rescanning the directory before I
copy the newly sliced gcode to the printer over an sshfs mount.
cura apparently uses inotify, but mc does not despite its being the
swiss army knife of file utils. And using kde plasma here, it gets in
the way and screws the moose by hiding the small "are you sure"
requestor completely behind the main requestor showing where the file
will be written to, so you have to figure out how move immovable stuff
off it before you see it. Maddening BS but that's KDE and Ingo K.
doesn't herd his cats all that well. KDE should not be "getting in the
way" but it does.
All of which is not germain to this swap vs u-sd card battle.
on arm64, its seems the man pages blindly reference each other w/o
adequately doing so in the case of swaps. Assuming a PARTLABEL has been
applied the rest of the fstab line starting with:
PARTLABEL=partname none swap
with a -o priority of 1000 would look like?
Since I know the /dev/name of the partition, I've found
swapon/swapoff /dev/name
works but by PARTLABEL as above is opaque.
From the zram0 name for swap by default, I'm assuming that is stolen
from the limited dram the pi has, which seems a bit circular, so once
this PARTLABEL is working, how do I delete that zram0 since it is not
included in fstab?
Thanks Andy. Take care & stay well.
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>
Reply to: