On 19/05/16 06:46, deloptes wrote: > Peter Hillier-Brook wrote: > >> On 18/05/16 22:02, deloptes wrote: >>> Peter Hillier-Brook wrote: >>> >>>> On 17/05/16 18:02, Felix Miata wrote: >>>>> Peter Hillier-Brook composed on 2016-05-17 16:41 (UTC+0100): >>>>> >>>>>> I recently re-formatted and re-partitioned a second disk that I use >>>>>> for experimenting with various distributions. A consequence is that >>>>>> previous UUIDs have disappeared into the bit bucket but, during >>>>>> booting of my main system a script somewhere is trying to use the swap >>>>>> partition that used to exist on the second disk. >>>>> >>>>>> This is not a major problem, as the system boots after a 90 second >>>>>> delay for a start job that is never going to start and a dependency >>>>>> failure message is output, but I would like to find and fix the >>>>>> problem. Can anyone offer a pointer to a likely source? >>>>> >>>>> That was happening here last summer: >>>>> https://bugzilla.opensuse.org/show_bug.cgi?id=936964 >>>>> >>>>> Maybe all that's needed to fix it is initrd rebuilding. >>>>> >>>>> Mounting by UUID is an optional default. Mounting life is simpler here, >>>>> because I don't use UUID mounting on any of my hundreds of multiboot >>>>> installations. Most of my mounts are by LABEL, strings I as a fallible >>>>> human choose and can remember, according to usage, disk name and/or >>>>> hostname. >>>> >>>> Thanks for the very useful pointers. I don't know who is the culprit, >>>> but fstab has an entry for swap with a UUID that is not consistent with >>>> the actual UUID for the swap partition. I'm going with your advice and >>>> switch to using labels. >>>> >>>> Thanks again. >>>> >>>> Peter HB >>> >>> UUID is better flexible solution in many cases - why not updating fstab >>> to have the correct uuid? >> >> Because I prefer an identifier that I can remember. :-) > > Haha, that's fair enough. It took me about 1h to reverse the setup to paper, > that I have done few years ago on one server with 12disks > Not only uuid, but crypt and lvm on top. I finally draw a map with this. > I suggest not relaying on memory anyway ;-) My memory has been working hard for very nearly 80 years, so I don't (can't) rely on it. :-)
Attachment:
signature.asc
Description: OpenPGP digital signature