Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Why doesn't Gentoo use UUID=... in fstab? -- Solved
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
py-ro
Veteran
Veteran


Joined: 24 Sep 2002
Posts: 1449
Location: St. Wendel

PostPosted: Mon Apr 21, 2014 3:22 pm    Post subject: Reply with quote

Since you are using GPT anyways, just use PARTUUID, should work.
Back to top
View user's profile Send private message
1clue
Veteran
Veteran


Joined: 05 Feb 2006
Posts: 1351

PostPosted: Mon Apr 21, 2014 5:54 pm    Post subject: Reply with quote

OK that worked, except for LVM volumes which don't have PARTUUID. But since the host isn't booting off those I don't think it matters. Right now there's only swap on there, but when I start adding VMs it will be pretty crowded.

Come to think of it though, maybe /dev/vg/lv path identifiers make more sense in that case.

Thanks.
Back to top
View user's profile Send private message
saellaven
Apprentice
Apprentice


Joined: 23 Jul 2006
Posts: 241

PostPosted: Tue Apr 22, 2014 12:43 am    Post subject: Reply with quote

1clue wrote:
OK so let me pose this question:

How do I set things up so that no matter what happens regarding new hardware, all the partitions are attached in the proper order?

I thought that UUID was supposed to solve it.


UUID is fine once your root file system (and possibly others*) is up... Anything you do has the potential to break when adding/changing hardware though, and every layer of abstraction (such as using an initramfs) comes with new ways for things to break in addition to the old ways. I suppose someone could extend an existing boot manager, create a new one or add UUID handling code to the kernel, but even that will only go so far (say your root directory gets corrupted). At some point, a sysadmin has to be responsible for the hardware in their machine, even if it means setting a new root UUID after rebuilding a corrupted root.

And that's why I try to keep my system as simple as possible, with most of the handholding removed. This way, when I change something, I will notice any immediate effects and can fix them while everything is fresh in my mind. I had a friend that used another distribution back about a decade ago... I helped him set up some servers and such by remotely editing config files in /etc and much to my surprise, the distro's config tools rewrote his config files on his next reboot a week or two later. Not the first time software has decided it knows what's best and changes things to something completely wrong.

For non-removable media, I use /dev/sd* devices for root/boot and /dev/mapper/* for my LVM partitions in my fstab. I used to mount by LABEL/UUID but stopped after udev's upstream decided it would be fun to potentially break things for arbitrary reasons. Frankly, given their history in breaking userspace carelessly and without concern for the consequences, I don't trust them or anything that might rely on them in terms of stability.


* again, see what the systemd folks and friends have tried to force by artificially limiting systemd's ability to have a separate /usr, usrmerge, etc. They say it's to prevent system breakage, but it causes a whole different set of problems that they don't care about and the Gentoo Council has said that it is perfectly fine for new versions of util-linux and such to move its files all over the place should the upstream or gentoo devs choose to do so. The result is, stuff that should be in /lib may very well end up in /usr in the future. The vote was absolutely insidious and the Council utterly irresponsible, but I'll stop there in this thread
Back to top
View user's profile Send private message
1clue
Veteran
Veteran


Joined: 05 Feb 2006
Posts: 1351

PostPosted: Tue Apr 22, 2014 1:38 am    Post subject: Reply with quote

Please try to avoid systemd politics on this thread. I hear you, but I do NOT want my support thread taken over by that battleground.

My boxes of this category seem to have a lot of disk changes. For one thing, the box in question has an ejectable SATA enclosure for backups, and for another my requirements are changing fairly often. That combined with the unfortunate acquisition of a bunch of WD green drives that all turned to crap on me in short order, and I've been sticking drives in and yanking them out more than any other setups I can remember.

I somehow thought that UUID was supposed to be the same anywhere. Move a drive from system A to system B and the UUID is still the same. Must not be so. My preference would be that no matter how many drives showed up in what order, my partitions would always be the ones I set up.
Back to top
View user's profile Send private message
saellaven
Apprentice
Apprentice


Joined: 23 Jul 2006
Posts: 241

PostPosted: Tue Apr 22, 2014 2:20 am    Post subject: Reply with quote

1clue wrote:
Please try to avoid systemd politics on this thread. I hear you, but I do NOT want my support thread taken over by that battleground.


I only included it, in so much as it matters why UUID might not be the most reliable thing going forward with regard to boot activity, and stopped there. I don't intend for it to take over the thread, just to provide an example of how things can arbitrarily change and cause pain.

Quote:

My boxes of this category seem to have a lot of disk changes. For one thing, the box in question has an ejectable SATA enclosure for backups, and for another my requirements are changing fairly often. That combined with the unfortunate acquisition of a bunch of WD green drives that all turned to crap on me in short order, and I've been sticking drives in and yanking them out more than any other setups I can remember.


So long as some hardware doesn't take over sda (such as adding extra controllers to your system), /dev/sda should be stable for booting (again, barring swapping that drive). In the past, I had a system with 4 IDE devices and three difference SCSI controllers inside it (with a total of 5 more hard drives between them). Using LABEL at the time kept everything sane with one exception - when the Linux drivers switched over from IDE to SATA, causing a rename up the chain with the IDE taking over sd[abcd]. I was prepared for this when I installed my new kernel though, and was immediately able to observe and correct the change for my root/boot partitions and with the proper root loading, everything else loaded fine by LABEL regardless of what node it was on.

And therein lies the key... a sysadmin needs to keep up on all the relevant changes to both the hardware and software on their system or else things can end up broken. Automation can only help so much, and, I would argue, can often hinder a non-experienced person (or even a more experienced one) by lulling them into a sense of complacency and helplessness when things do unexpectedly break, leaving them with no knowledge on how to handle it. "It just works" is great until it doesn't... and this is further exacerbated when something is in a constant state of change (hardware or software).

Anyway, you can mount your disks by UUID... just be wary of using UUID for root (and potentially a separate /usr). And keep in mind that an initramfs solution to UUID for root has the potential to break in random, unexpected ways in the future if you don't regularly rebuild it when updating certain key programs even if you don't change your kernel (regular binary distros update initramfs whenever there is a userspace or kernel change for you, so it isn't an issue there).

Quote:

I somehow thought that UUID was supposed to be the same anywhere. Move a drive from system A to system B and the UUID is still the same. Must not be so. My preference would be that no matter how many drives showed up in what order, my partitions would always be the ones I set up.


UUID is the same everywhere... it's just contained in the filesystem, not in the hardware tables and, at least as of my last research, the Linux kernel doesn't contain the code to mount via those filesystem descriptors directly, as userspace mount handles them entirely and then passes the proper reference expected to the kernel.


Last edited by saellaven on Tue Apr 22, 2014 5:23 am; edited 1 time in total
Back to top
View user's profile Send private message
1clue
Veteran
Veteran


Joined: 05 Feb 2006
Posts: 1351

PostPosted: Tue Apr 22, 2014 3:33 am    Post subject: Reply with quote

OK all that makes sense well enough. I got bit by that IDE to SATA renumber, but not so incredibly bad since I knew it might happen.

I'm usually the one who shouts about complacency, so I guess it was my turn to have it come around.

Thanks.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4009

PostPosted: Tue Apr 22, 2014 11:52 am    Post subject: Reply with quote

saellaven wrote:
For non-removable media, I use /dev/sd* devices for root/boot and /dev/mapper/* for my LVM partitions in my fstab

I am not sure about LVM, but /dev/sd* for root/boot can be dangerous if there is more than /dev/sda*, even if you do not touch the hardware: Depending on your board and some other conditions, the order of letters might depend on the initialization order of corresponding controllers, and thus on some boots the order may have changed. Admittedly, in practice this is very unlikely, but it can be a severe issue if you are hundred miles away from the machine and need to reboot with a new kernel...
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum