, UUID or LABEL. These identities
are for the devices, not parts of the file system.
Your understanding is wrong: the UUIDs you are talking about are a
feature of the filesystem--that's why they appear in lsblk -f
(filesystem) output. You can find the same UUID in filesystem-specific
gt; > to
> > > be able to address the individual underlying devices. Only /dev/sdxn
> > > style
> > > addressing can do this, not duplicate UUIDs, or duplicate LABELs.
> >
> > If those we are talking about are file system UUIDs/LABELs (and all evidence
this, not duplicate UUIDs, or duplicate LABELs.
If those we are talking about are file system UUIDs/LABELs (and all evidence
supports that), they *are not* duplicate. They are *the same*. Change "one"
and *poof* the "other" will change along. Because they are on the file system,
wh
5e91
> │ └─md3 ext4 39c39c24711-ab43-497c-bf3e-12b403257.4G
>
> If I wanted to retire /dev/sdg6 from the Raid array, I would not be able to
> use the UUID, only the unique SDxn.
>
> Aren't UUIDs supposed to be unique?
People see the phrase "UUID" and t
; : exactly the point I would like to make. mdadm needs to
> be able to address the individual underlying devices. Only /dev/sdxn style
> addressing can do this, not duplicate UUIDs, or duplicate LABELs.
If those we are talking about are file system UUIDs/LABELs (and all evidence
supp
want to disturb
its
two underlying partitions separately except via mdadm.
"except via mdadm" : exactly the point I would like to make. mdadm needs to be
able to address the individual underlying devices. Only /dev/sdxn style
addressing can do this, not duplicate UUIDs, or duplicate LABELs.
Roger
Roger Price composed on 2024-11-26 03:57 (UTC-0500):
> Felix Miata wrote:
>> Members of a raid filesystem have to be seen as an integral part of one
>> filesystem,
>> a special case. It's another reason I stick to use of LABELs.
>> # lsblk -f | egrep -A1 'raid|NAME'
>> NAME FSTYPE
> Sent: Tuesday, November 26, 2024 at 2:51 AM
> From: "Roger Price"
> To: "debian-user Mailing List"
> Subject: The "uniqueness" of UUIDs
>
> On Tue, 26 Nov 2024, George at Clug wrote:
>
> > "$ lsblk -f" output is very nic
d, and it's the only way for Raid specification. For example
> /proc/mdstat contains no mention of device UUIDs.
>
> > It is only a problem if you want to specify now and expect it to be
> > still valid after the next reboot.
>
> I'm guessing that this feature is something
Roger Price (12024-11-26):
> I'm guessing that this feature is something systemd has given us.
Your hate is making you guess wrong.
--
Nicolas George
On Tue, 26 Nov 2024, Nicolas George wrote:
Roger Price (12024-11-26):
You have to specify sda5 or sdb5.
There is nothing wrong with having to specify sda5 or sdb5.
Indeed, and it's the only way for Raid specification. For example /proc/mdstat
contains no mention of device UUIDs.
system allows to attach individual "things" (perhaps
> UUIDs?) to each of its components you could do that (no idea whether Linux
> RAID allows that, though).
Of course it does. MD raid devices contain both an UUID for the array
and an UUID for the device.
I will let somebody with more
what I saw:
...
Aren't UUIDs supposed to be unique? Roger
The UUID reported might be the one of the file system.
Actually and as usual, the documentation clarifies the situation:
-f, --fs
Output info about filesystems. This option is equiva‐
lent to -o NA
;
> UUID_SUB="7821cc06-e7f5-358b-cf95-fb0ec2f34585"
> LABEL="10.218.0.100:3" TYPE="linux_raid_member"
> PARTUUID="b24f-06"
>
> # blkid /dev/md0
> /dev/md0: UUID="8a31b513-cd62-4639-b5e5-3a8f8879164f" BLOCK_SIZE=&qu
ene on "msi85:0tmp". You have
> to specify sda5 or sdb5.
LABELS exist at two levels: partitions (if your partition table allows for
it) and file systems.
All things which are "in" the file system will be "in" the RAID, because
you make the file system "on top
er"
PARTUUID="b24f-06"
# blkid /dev/md0
/dev/md0: UUID="8a31b513-cd62-4639-b5e5-3a8f8879164f" BLOCK_SIZE="4096"
TYPE="ext4"
The UUIDs are the same for sdg6 and sdh6 but there is a UUID_SUB to distinguish
them. blkid sees a new value for md0's UUID, not the same as lsblk.
Roger
Roger Price (12024-11-26):
> You have
> to specify sda5 or sdb5.
There is nothing wrong with having to specify sda5 or sdb5.
It is only a problem if you want to specify now and expect it to be
still valid after the next reboot.
Re
On Tue, 26 Nov 2024, Felix Miata wrote:
Members of a raid filesystem have to be seen as an integral part of one
filesystem,
a special case. It's another reason I stick to use of LABELs.
# lsblk -f | egrep -A1 'raid|NAME'
NAME FSTYPEFSVER LABEL UUID FSAVAIL FSUSE%
ray, I would not be able to
> use the UUID, only the unique SDxn.
>
> Aren't UUIDs supposed to be unique? Roger
On Tue, Nov 26, 2024 at 08:51:21AM +0100, Roger Price wrote:
[...]
> Aren't UUIDs supposed to be unique? Roger
Not if someone copies them, not. They are numbers. There's no magic.
Cheers
--
t
signature.asc
Description: PGP signature
On Tue, 26 Nov 2024, Nicolas George wrote:
Roger Price (12024-11-26):
UUID sdg6 = UUID sdh6 !
Aren't UUIDs supposed to be unique?
Yes, they are: somebody did something wrong on your suystem. Odds it was
you. It sure was not me :-Þ
When did you add the most recent of these drives? Ho
Nicolas George (12024-11-26):
> Yes, they are: somebody did something wrong on your suystem. Odds it was
> you. It sure was not me :-Þ
>
> When did you add the most recent of these drives? How did you add it?
My bad, I read the output on my system incorrectly. Forget these two
paragraphs please.
, only the unique SDxn.
Aren't UUIDs supposed to be unique? Roger
The UUID reported might be the one of the file system. As the lsblk
output is truncated I can not really guess the context of those lines;
in all cases I checked here, non-unique UUIDs show up on components that
are reporte
D sdg6 = UUID sdh6 ! If I wanted to retire /dev/sdg6 from the Raid array,
> I
> would not be able to use the UUID, only the unique SDxn.
> Aren't UUIDs supposed to be unique? Roger
Members of a raid filesystem have to be seen as an integral part of one
filesystem,
a special
7.4G
If I wanted to retire /dev/sdg6 from the Raid array, I would not be able to use
the UUID, only the unique SDxn.
Aren't UUIDs supposed to be unique? RogerNAMEFSTYPEFSVER LABEL UUID
FSAVAIL FSUSE% MOUNTPOINT
...
ââsdg6 linux_
Roger Price (12024-11-26):
> UUID sdg6 = UUID sdh6 ! If I wanted to retire /dev/sdg6 from the Raid
> array, I would not be able to use the UUID, only the unique SDxn.
UUIDs are important if you want the system to choose the right drive
with nu human supervision. Do you often retire drives
9eddce5e91
│ └─md3 ext4 1.0 39c24711-ab43-497c-bf3e-12b4032575ac 758.4G 7% /mnt/home
UUID sdg6 = UUID sdh6 ! If I wanted to retire /dev/sdg6 from the Raid array, I
would not be able to use the UUID, only the unique SDxn.
Aren't UUIDs supposed to be unique? Roger
anything and boot such
> a system with all the drives installed, it may be arbitrary as to
> WHICH ONE gets called md0! It will depend upon which one mdadm
> starts assembling first. The other one will be renamed, often to
> something weird like md127.
>
> To solve that problem one w
orse, if you don't do anything and boot such
a system with all the drives installed, it may be arbitrary as to
WHICH ONE gets called md0! It will depend upon which one mdadm
starts assembling first. The other one will be renamed, often to
something weird like md127.
To solve that problem one would
e
>>data, i.e. does the Debian12 installer recognize the member HDDs
>>and will allow me to configure /dev/md0?
>
> The reason behing using UUIDs is that individual disks don't have
> persistent names attached: /dev/sda might be /dev/sdb next time, etc.
>
> MD RAID
rying to fix? Filesystems have a UUID. MD RAID devices
> have a UID. And MD RAID member devices also have UUIDs, but they are
> all different *kinds* of UUID. Only filesystems have a filesystem
> UUID that you use in /etc/fstab and other places. You mount things
> by filesystem UUID. You do
think this is
>the case for the two member HDDs of md0 (cat /proc/mdstat).
>Is there an easy way to fix this?
>
>If I need to reinstall, can I keep the two member HDDs with all the
>data, i.e. does the Debian12 installer recognize the member HDDs
>and will allow me to configure /dev
; mounted using UUID and not device names. I do not think this is
> the case for the two member HDDs of md0 (cat /proc/mdstat).
> Is there an easy way to fix this?
What are you trying to fix? Filesystems have a UUID. MD RAID devices
have a UID. And MD RAID member devices also have UUIDs, but t
hello Debian experts,
I have /dev/md0 mounted at /storage which consists of two HDDs.
Now I would like to add an SSD drive for better performance of
VMs. Usually, before doing this, I make sure that all of my disks are
mounted using UUID and not device names. I do not think this is
the case for t
On Sun, May 28, 2023 at 12:05:07PM -0400, Stefan Monnier wrote:
> >> IIRC booting with `resume=no` on the kernel's command line worked around
> >> the problem in my case.
[on restore & missing swap partition]
> IIRC the problem comes when it decides that maybe the swap partition
> hasn't shown up
>> IIRC booting with `resume=no` on the kernel's command line worked around
>> the problem in my case.
>
> Yes, in your case, the system dumped its state into swap and kept
> a remark "where" to get that state back.
Actually, it had not. But when booting up, it still needs to check
whether or not
On Sun, May 28, 2023 at 09:34:58AM -0400, Stefan Monnier wrote:
> >> I'm sure it used to be that you could swap linux discs between PCs and it
> >> would sort itself out but I try swapping disks about and booting and they
> >> complain
> >> "Cannot find UUID..lots of identifying numbers"
> >> and g
>> I'm sure it used to be that you could swap linux discs between PCs and it
>> would sort itself out but I try swapping disks about and booting and they
>> complain
>> "Cannot find UUID..lots of identifying numbers"
>> and gives intramfs prompt.
>
> The system seems to try to mount the root file s
On Sun, May 28, 2023 at 12:37:20AM +0100, mick.crane wrote:
> I'm sure it used to be that you could swap linux discs between PCs and it
> would sort itself out but I try swapping disks about and booting and they
> complain
> "Cannot find UUID..lots of identifying numbers"
> and gives intramfs promp
Am 28.05.2023 um 01:37 schrieb mick.crane:
> (...)
> and gives intramfs prompt.
> Am I supposed to be able to sort it out from there?
> like how?
> mick
oh the initramfs prompt... that is not the place to fix it easily.
much easier to stop while booting grub (like asking for the menuitem,
you are
Am 28.05.2023 um 01:37 schrieb mick.crane:
> I'm sure it used to be that you could swap linux discs between PCs and
> it would sort itself out but I try swapping disks about and booting and
> they complain
> "Cannot find UUID..lots of identifying numbers"
> and gives intramfs prompt.
> Am I suppose
On 5/27/23 16:37, mick.crane wrote:
I'm sure it used to be that you could swap linux discs between PCs and
it would sort itself out
Yes. Please add that to my list of reasons for preferring BIOS-MBR booting:
https://www.mail-archive.com/debian-user@lists.debian.org/msg792977.html
but I tr
ing installation
media?
As always, as long as required drivers are included in the initrd, if you know
enough about device names, filesystem LABELs and filesystems involved, booting
can
be accomplished manually from a Grub prompt without involving UUIDs, but from an
initramfs prompt it can be harder
On May 27, 2023 4:37:20 PM PDT, "mick.crane" wrote:
>I'm sure it used to be that you could swap linux discs between PCs and it
>would sort itself out
Yes, it still works like that. I do it frequently.
but I try swapping disks about and booting and they complain
>"Cannot find UUID..lots of ide
I'm sure it used to be that you could swap linux discs between PCs and
it would sort itself out but I try swapping disks about and booting and
they complain
"Cannot find UUID..lots of identifying numbers"
and gives intramfs prompt.
Am I supposed to be able to sort it out from there?
like how?
mi
>> Every time you have to reboot, it means your OS has somewhat failed you.
> i don't think that at all. remember that each person can
> have different preferences, requirements and expectations.
That's why I wrote "have to".
Of course, if you choose to reboot it, it's not you OS's fault.
> sy
On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote:
> > > > > On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote:
> > > > > > While I'm sure this can be managed by explicitly setting UUIDs, I've
> > > > > > found it
Stefan Monnier wrote:
>>> PS: The only problem with LVM names is that Linux doesn't let you
>>> rename a volume group while it's active (at least last time I tried),
>>> which makes it painful to rename the volume group in which lives your
>>> root partition.
>> How painful is it to dd a live cd, b
6PM -0500, Stefan Monnier wrote:
> > > While I'm sure this can be managed by explicitly setting UUIDs, I've
> > > found it much more pleasant to manage explicit names (I personally
> > > prefer LVM names over filesystem labels, but filesystem labels work well
>
> > are large numbers of commoditised objects to name.
>
> Usually a UUID collision is a result of a subtle mistake, like cloning
> a disk and then trying to mount a file system by UUID while the clone
> is still attached. At least, that's the first scenario I can think of.
There a
gt; While I'm sure this can be managed by explicitly setting UUIDs, I've
> > > > found it much more pleasant to manage explicit names (I personally
> > > > prefer LVM names over filesystem labels, but filesystem labels work well
> > > > for those filesys
On Tue, 04 Feb 2020 22:19:25 -0500
Stefan Monnier wrote:
> > How painful is it to dd a live cd, boot from it and rename?
>
> Very. It's called "downtime".
> Every time you have to reboot, it means your OS has somewhat failed
> you.
>
>
> Stefan
>
You are absolutely right!
> Usually a UUID collision is a result of a subtle mistake, like cloning
> a disk and then trying to mount a file system by UUID while the clone
> is still attached. At least, that's the first scenario I can think of.
I wouldn't call it a "subtle mistake". Instead it's what *always*
happens when
On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote:
> I don't suppose either of us will meet a UUID collision in our
> lifetimes, and it's obviously a sensible scheme to use where there
> are large numbers of commoditised objects to name.
Usually a UUID collision is a result of a subtle
On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote:
On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote:
On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote:
> While I'm sure this can be managed by explicitly setting UUIDs, I've
> found it much
; For those reading along or finding this in search results: no, filesystem
> > > UUIDs don't change for no detectable reason. Don't implement anything
> > > based
> > > on this theory.
> >
> > What he meant is that filesystem UUIDs are (re)create
>>What he meant is that filesystem UUIDs are (re)created automatically
>>based on a heuristic of what it means for a filesystem to be "the same".
> You understand that he didn't actually say that, right? This seems like your
> own personal bugaboo instead.
Def
On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote:
Me too, so I usually label the permanent stuff at least. UUID's can and
will change for no detectable reason.
For those reading along or finding this in search results: no, filesystem
UUIDs don't change for no detecta
>>> Me too, so I usually label the permanent stuff at least. UUID's can and
>>> will change for no detectable reason.
>> For those reading along or finding this in search results: no, filesystem
>> UUIDs don't change for no detectable reason. Don'
>> PS: The only problem with LVM names is that Linux doesn't let you
>> rename a volume group while it's active (at least last time I tried),
>> which makes it painful to rename the volume group in which lives your
>> root partition.
> How painful is it to dd a live cd, boot from it and rename?
Ve
> PS: The only problem with LVM names is that Linux doesn't let you
> rename a volume group while it's active (at least last time I tried),
> which makes it painful to rename the volume group in which lives your
> root partition.
>
How painful is it to dd a live cd, boot from it and rename?
3 m
>> Me too, so I usually label the permanent stuff at least. UUID's can and
>> will change for no detectable reason.
> For those reading along or finding this in search results: no, filesystem
> UUIDs don't change for no detectable reason. Don't implement anything
Michael Stone composed on 2018-01-19 08:57 (UTC-0500):
...
> It's also possible to use filesystem labels, but in practice it turned out
> to be not uncommon for two different systems to have something like "root",
> which caused a lot of trouble when you put a drive from one system into
> anoth
s. It does not "just change". It is
also possible to write a label, or name, on the filesystem. It is
written into the filesystem right next to the UUID. There are a couple
of exceptions: FAT filesystems don't support a true UUID, for example.
There are also partition UUIDs, the
On Thu, Jan 18, 2018 at 06:42:41PM +0100, deloptes wrote:
> Dave Sherohman wrote:
> > What is the recommended method for preventing grub from using UUIDs to
> > refer to filesystems in the current Debian stable distribution?
>
> what is the reason to avoid UUIDs? (if n
On Thu, Jan 18, 2018 at 11:52:11AM -0500, Marc Auslander wrote:
> Dave Sherohman writes:
>
> >What is the recommended method for preventing grub from using UUIDs to
> >refer to filesystems in the current Debian stable distribution?
>
> I don't know about "recom
On Thursday 18 January 2018 20:25:51 David Wright wrote:
> On Thu 18 Jan 2018 at 14:46:26 (-0500), Gene Heskett wrote:
> > On Thursday 18 January 2018 14:22:13 Pascal Hambourg wrote:
> > > Le 18/01/2018 à 19:54, Gene Heskett a écrit :
> > > > UUID's have turned out to be quite volatile over system
>> What is the recommended method for preventing grub from using UUIDs to
>> refer to filesystems in the current Debian stable distribution?
> One method for you use case it to put /boot or at least /boot/grub
> in a plain partition on the same disk as GRUB's core image.
On Thu, Jan 18, 2018 at 08:50:11PM -0500, Cindy-Sue Causey wrote:
I've had it happen, too. Feels like recently, but was probably a
couple years ago, if not more like 3. I could never figure out how it
happened.
vfat filesystem?
Mike Stone
On 1/18/18, Gene Heskett wrote:
> On Thursday 18 January 2018 16:04:26 Don Armstrong wrote:
>
>> On Thu, 18 Jan 2018, Gene Heskett wrote:
>> > On Thursday 18 January 2018 14:22:13 Pascal Hambourg wrote:
>> > > Le 18/01/2018 à 19:54, Gene Heskett a écrit :
>> > > > UUID's have turned out to be quit
On Thu 18 Jan 2018 at 14:46:26 (-0500), Gene Heskett wrote:
> On Thursday 18 January 2018 14:22:13 Pascal Hambourg wrote:
>
> > Le 18/01/2018 à 19:54, Gene Heskett a écrit :
> > > UUID's have turned out to be quite volatile over system upgrades.
> >
> > Not on mine.
> >
> > > Give me a familiar di
On Thu, 18 Jan 2018, Gene Heskett wrote:
> On Thursday 18 January 2018 16:04:26 Don Armstrong wrote:
> > Which UUID changed? The filesystem UUID shouldn't change unless you
> > reformat the partition, and the partition UUID shouldn't change
> > unless you repartition it (or you specifically change
of these days I need to convert it to 64 bit. Probably by putting
most of that stuff on the amandatapes partition, putting in a fresh 1T
drive, and installing a 64 bit jessie. Once thats running, I have a 2T
drive that I'll format for amanda and swap this one out. Nothing wrong
with it, but
had the UUID change on this system, on my
> amandatapes drive at almost every install or upgrade.
Which UUID changed? The filesystem UUID shouldn't change unless you
reformat the partition, and the partition UUID shouldn't change unless
you repartition it (or you specifically change
On Thursday 18 January 2018 14:22:13 Pascal Hambourg wrote:
> Le 18/01/2018 à 19:54, Gene Heskett a écrit :
> > UUID's have turned out to be quite volatile over system upgrades.
>
> Not on mine.
>
> > Give me a familiar disklabel any day.
>
> Don't you mean a filesystem or partition label ?
> "Dis
Le 18/01/2018 à 19:54, Gene Heskett a écrit :
UUID's have turned out to be quite volatile over system upgrades.
Not on mine.
Give me a familiar disklabel any day.
Don't you mean a filesystem or partition label ?
"Disklabel" is a synonym for "partition table".
Le 18/01/2018 à 10:31, Dave Sherohman a écrit :
What is the recommended method for preventing grub from using UUIDs to
refer to filesystems in the current Debian stable distribution?
One method for you use case it to put /boot or at least /boot/grub in a
plain partition on the same disk as
On Thursday 18 January 2018 12:42:41 deloptes wrote:
> Dave Sherohman wrote:
> > What is the recommended method for preventing grub from using UUIDs
> > to refer to filesystems in the current Debian stable distribution?
>
> what is the reason to avoid UUIDs? (if not very
On Thu 18 Jan 2018 at 11:52:11 (-0500), Marc Auslander wrote:
> Dave Sherohman writes:
>
> >What is the recommended method for preventing grub from using UUIDs to
> >refer to filesystems in the current Debian stable distribution?
> >
>
> I don't know about &
Dave Sherohman wrote:
> What is the recommended method for preventing grub from using UUIDs to
> refer to filesystems in the current Debian stable distribution?
what is the reason to avoid UUIDs? (if not very private)
Dave Sherohman writes:
>What is the recommended method for preventing grub from using UUIDs to
>refer to filesystems in the current Debian stable distribution?
>
I don't know about "recommended" but could you put your own menu
entry into /etc/grub.d and make it the default?
ifies
> the root device ("set root='lvmid/[UUID]').
It's subtle, but that's probably why the parameter is called
GRUB_DISABLE_LINUX_UUID and not GRUB_DISABLE_UUID.
>From the docs:
'GRUB_DISABLE_LINUX_UUID'
Normally, 'grub-mkconfig' wi
On Thu, Jan 18, 2018 at 11:11:32AM +0100, Stephan Seitz wrote:
> On Do, Jan 18, 2018 at 03:31:30 -0600, Dave Sherohman wrote:
> >What is the recommended method for preventing grub from using UUIDs to
> >refer to filesystems in the current Debian stable distribution?
>
> I
On Do, Jan 18, 2018 at 03:31:30 -0600, Dave Sherohman wrote:
What is the recommended method for preventing grub from using UUIDs to
refer to filesystems in the current Debian stable distribution?
In /etc/default/grub I have the option:
# Uncomment if you don’t want GRUB to pass „root=UUID=xxx
Hi,
On Thu, 18 Jan 2018 03:31:30 -0600
Dave Sherohman wrote:
> What is the recommended method for preventing grub from using UUIDs to
> refer to filesystems in the current Debian stable distribution?
not sure about this; have you tried to set
GRUB_DISABLE_LINUX_UUID=true
in /etc/defaul
What is the recommended method for preventing grub from using UUIDs to
refer to filesystems in the current Debian stable distribution?
---
In an attempt to head off a "but you really want to use UUIDs!" debate:
The specific use-case I'm dealing with here is cloned virtual machine
On Sun, Jun 4, 2017 at 12:59 AM, Pascal Hambourg wrote:
> Le 03/06/2017 à 17:48, Gene Heskett a écrit :
>>
>>
>> I don't believe that will work. dd runs on the raw device, not to an
>> artificially created "partition".
>
>
> dd runs on any type of device, including partitions.
>
But it copies th
nor is it an NTFS partition editor.
> otherwise the
> partition would have been left half ntfs half ext4.
The MBR partition is left half used by the NTFS file system and half
unused. The unused part may have some useless bits of ext4 left
behind, but it has nothing like a file system in it
arches
by UUID for the kernel/ramdisk, and the kernel searches by UUID for
the root filesystem, and we don't know how it chooses between them.
I think this bit of info gets one level deeper to source of problems.
Do they (a) take the UUID being searched for and look at each disk/
partition'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Jun 03, 2017 at 05:59:06PM +0200, Pascal Hambourg wrote:
> Le 03/06/2017 à 17:48, Gene Heskett a écrit :
> >
> >I don't believe that will work. dd runs on the raw device, not to an
> >artificially created "partition".
>
> dd runs on any type
now how it chooses between them.
Note that the kernel does not know anything about filesystem UUIDs
(stored in filesystem metadata). It only knows about partition UUIDs
(stored in partition tables). The part that uses UUIDs to locate the
root filesystem is the initrd/initramfs userland scripts
UUID for the kernel/ramdisk, and the kernel searches by UUID for
the root filesystem, and we don't know how it chooses between them.
Do they (a) take the UUID being searched for and look at each disk/
partition's UUID for a match, or (b) read all the available UUIDs into
a table (over
Le 03/06/2017 à 17:48, Gene Heskett a écrit :
I don't believe that will work. dd runs on the raw device, not to an
artificially created "partition".
dd runs on any type of device, including partitions.
ect agreement with
> > and go to the juicy part. After all uuids are unique and fstab are
> > all correct, updating-grub would mix match uuids in writing its
> > grub.cfg
> > Two uuids on the same entry! Over and over again till I edited
> > it out to the correct ones
Original Message
From: deb...@lionunicorn.co.uk
To: debian-user@lists.debian.org
On Thu 01 Jun 2017 at 12:24:28 (-0400), Fungi4All wrote:
> Why don't just skip all this that we are in perfect agreement with and go to
> the juicy part.
> After all uuids are unique
On Thu 01 Jun 2017 at 12:24:28 (-0400), Fungi4All wrote:
> Why don't just skip all this that we are in perfect agreement with and go to
> the juicy part.
> After all uuids are unique and fstab are all correct, updating-grub would mix
> match uuids in writing
> its grub.cf
Original Message
Subject: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab
action
From: joel.r...@gmail.com
To: Fungi4All
Fungi4All-san,
I'll try explaining what we don't know whether you understand or not.
I understand everything you have written
imply done, like "accounting" instead of something like "ACTG20170601".
So UUIDs were invented as a new sort of label that would theoretically
never be duplicated. They are separate from the labels that the are
called labels in /etc/fstab and gparted's listing, etc.
This ex
entioning that you had devices listed in your
> mdadm.conf -- just get rid of them.
well, i may have implied that, on account of not being able to
express it - i get it now: the things i thought were "devices" are
actually the UUIDs associated with the RAID array...
> ARRAY /dev/md/
On Mon, Jun 27, 2011 at 8:59 AM, Philip Hands wrote:
>
> I must say that I'm a little beffuddled about how you managed to make
> the system sensitive to which device contains which MD component -- I
> seem to remember you mentioning that you had devices listed in your
> mdadm.conf -- just get rid
1 - 100 of 138 matches
Mail list logo
