Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #167959 > unrolled thread
| Started by | Peter Hillier-Brook <phb@hbsys.plus.com> |
|---|---|
| First post | 2016-05-17 17:50 +0200 |
| Last post | 2016-05-17 20:00 +0200 |
| Articles | 10 — 5 participants |
Back to article view | Back to linux.debian.user
swap on second hard drive Peter Hillier-Brook <phb@hbsys.plus.com> - 2016-05-17 17:50 +0200
Re: swap on second hard drive Felix Miata <mrmazda@earthlink.net> - 2016-05-17 19:10 +0200
Re: swap on second hard drive Peter Hillier-Brook <phb@hbsys.plus.com> - 2016-05-18 12:50 +0200
Re: swap on second hard drive deloptes <deloptes@gmail.com> - 2016-05-18 23:10 +0200
Re: swap on second hard drive Peter Hillier-Brook <phb@hbsys.plus.com> - 2016-05-18 23:40 +0200
Re: swap on second hard drive deloptes <deloptes@gmail.com> - 2016-05-19 08:00 +0200
[OT] LABELs Re: swap on second hard drive David Wright <deblis@lionunicorn.co.uk> - 2016-05-19 16:10 +0200
Re: swap on second hard drive Peter Hillier-Brook <phb@hbsys.plus.com> - 2016-05-19 17:50 +0200
Re: swap on second hard drive Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-05-19 20:40 +0200
Re: swap on second hard drive Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-05-17 20:00 +0200
| From | Peter Hillier-Brook <phb@hbsys.plus.com> |
|---|---|
| Date | 2016-05-17 17:50 +0200 |
| Subject | swap on second hard drive |
| Message-ID | <rzPpU-6oq-25@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
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? Thanks in anticipation. Peter HB
[toc] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2016-05-17 19:10 +0200 |
| Message-ID | <rzQFj-7kq-15@gated-at.bofh.it> |
| In reply to | #167959 |
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. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
[toc] | [prev] | [next] | [standalone]
| From | Peter Hillier-Brook <phb@hbsys.plus.com> |
|---|---|
| Date | 2016-05-18 12:50 +0200 |
| Message-ID | <rA7d7-WC-3@gated-at.bofh.it> |
| In reply to | #167961 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2016-05-18 23:10 +0200 |
| Message-ID | <rAgT7-7if-5@gated-at.bofh.it> |
| In reply to | #168000 |
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? ls -al /dev/disk/by-uuid regards
[toc] | [prev] | [next] | [standalone]
| From | Peter Hillier-Brook <phb@hbsys.plus.com> |
|---|---|
| Date | 2016-05-18 23:40 +0200 |
| Message-ID | <rAhma-7ww-17@gated-at.bofh.it> |
| In reply to | #168044 |
[Multipart message — attachments visible in raw view] — view raw
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. :-)
[toc] | [prev] | [next] | [standalone]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2016-05-19 08:00 +0200 |
| Message-ID | <rApa1-49X-11@gated-at.bofh.it> |
| In reply to | #168046 |
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 ;-) regards
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2016-05-19 16:10 +0200 |
| Subject | [OT] LABELs Re: swap on second hard drive |
| Message-ID | <rAwOd-NU-19@gated-at.bofh.it> |
| In reply to | #168062 |
On Thu 19 May 2016 at 07:46:10 (+0200), 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: > >>>> 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. > >> > >> 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 ;-) In the land of car analogies, I think of Serial numbers as VIN, LABELs as number-plate/tag/rego (I write the LABEL onto disks with marker pen), partitions UUIDs as the number on a V5 registration document (UK parlance), UUIDs as the 16-digit number on a V11 (registration renewal). Cheers, David. http://laughbreak.com/lists/if-microsoft-built-cars/
[toc] | [prev] | [next] | [standalone]
| From | Peter Hillier-Brook <phb@hbsys.plus.com> |
|---|---|
| Date | 2016-05-19 17:50 +0200 |
| Message-ID | <rAymZ-1DD-7@gated-at.bofh.it> |
| In reply to | #168062 |
[Multipart message — attachments visible in raw view] — view raw
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. :-)
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2016-05-19 20:40 +0200 |
| Message-ID | <rAB1w-3od-19@gated-at.bofh.it> |
| In reply to | #168062 |
Le 19/05/2016 07:46, deloptes a écrit : > > 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. Tip : lsblk comes in handy to print the relationship between devices.
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2016-05-17 20:00 +0200 |
| Message-ID | <rzRrI-7CL-19@gated-at.bofh.it> |
| In reply to | #167959 |
Le 17/05/2016 17:41, Peter Hillier-Brook a écrit : > 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? The UUID is probably in /etc/fstab (man fstab). If you want your system not to try to use the swap, just comment out the relevant line in /etc/fstab. If you created a new swap partition and want to use it instead of the old one, you have two options. a) Change the UUID of the new swap with mkswap or swaplabel (if you already initialized the swap with mkswap) with the old one. b) Change the UUID in /etc/fstab with the new one (you can get it with blkid). If you use hibernation (suspend to disk), you also need to change the UUID in /etc/initramfs-tools/resume if that file exists, then rebuild the initramfs with update-initramfs. Method a) is much simpler IMO. The use of UUID is not mandatory, but I strongly recommend using any persistent identifier such as label, UUID, partition label or partition UUID and not the device names /dev/sd* which are not reliably persistent when you have multiple disks.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.user
csiph-web