Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #258730 > unrolled thread

Re: UUIDS

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: UUIDS <tomas@tuxteam.de> - 2023-05-28 07:20 +0200
    Re: UUIDS Stefan Monnier <monnier@iro.umontreal.ca> - 2023-05-28 15:40 +0200
      Re: UUIDS <tomas@tuxteam.de> - 2023-05-28 17:40 +0200
        Re: UUIDS Stefan Monnier <monnier@iro.umontreal.ca> - 2023-05-28 18:10 +0200
          Re: UUIDS <tomas@tuxteam.de> - 2023-05-28 18:20 +0200

#258730 — Re: UUIDS

[Multipart message — attachments visible in raw view] — view raw

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 prompt.

The system seems to try to mount the root file system, which seems to be
specified in the fstab by UUID. It doesn't. This can have several reasons:

 1) the root fs is somehow broken
 2) some rescue procedure has changed the UUID
 3) perhaps some more

> Am I supposed to be able to sort it out from there?

In theory, yes. Knowledge and practice with initramfs doesn't to seem
widespread, alas. See here [1]. *If* you know which one is your root
partition, you might try to mount it and exit the initramfs shell for
the boot process to continue.

Alternatively, you might want to boot a rescue system, find out whether
you are 1) or 2) above. In case 1) fix, in case 2 boot again with "root=..."
and fix your initramfs afterwards.

In case 3) try to gather more info and come back :)

HTH

[1] https://wiki.debian.org/initramfs
-- 
t

[toc] | [next] | [standalone]

#258732

>> 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 system, which seems to be
> specified in the fstab by UUID. It doesn't. This can have several reasons:

That's quite likely indeed.

This said, I've had such UUID problems in the early boot (initramfs) that
involved the swap partition rather than the root partition because the
code that tries to resume from hibernation looks for some tell-tale sign
in the resume partition (usually also playing the role of the swap
partition), and this is done before trying to mount the root partition.

IIRC booting with `resume=no` on the kernel's command line worked around
the problem in my case.


        Stefan

[toc] | [prev] | [next] | [standalone]

#258733

[Multipart message — attachments visible in raw view] — view raw

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 gives intramfs prompt.
> >
> > The system seems to try to mount the root file system, which seems to be
> > specified in the fstab by UUID. It doesn't. This can have several reasons:
> 
> That's quite likely indeed.
> 
> This said, I've had such UUID problems in the early boot (initramfs) that
> involved the swap partition rather than the root partition because the
> code that tries to resume from hibernation looks for some tell-tale sign
> in the resume partition (usually also playing the role of the swap
> partition), and this is done before trying to mount the root partition.

Yes, the boot loader not finding the root partition came also to mind.
I deemed that less likely because, if I understood correctly, the OP
is already in an initramfs shell.

> 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. Not finding that partition
is then cause for much grief (refusing to boot _at all_ does seem
like one of those really nerdy design decisions which possibly isn't
helpful to end users...)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#258736

>> 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 there is such a dumped state from which to resume.

> Not finding that partition is then cause for much grief (refusing to
> boot _at all_ does seem like one of those really nerdy design
> decisions which possibly isn't helpful to end users...)

IIRC the problem comes when it decides that maybe the swap partition
hasn't shown up yet, so it waits (which in turn calls for a timeout
system, etc... IOW, extra complexity that's difficult to justify and
hard to test) :-(

[ Of course, an option could be to ask the user whether to wait or to just
  skip the resume, but there might be no screen/keyboard connected or no
  admin/user at the helm, so it's not a reliable solution either.  ]


        Stefan

[toc] | [prev] | [next] | [standalone]

#258737

[Multipart message — attachments visible in raw view] — view raw

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 yet, so it waits (which in turn calls for a timeout
> system, etc... IOW, extra complexity that's difficult to justify and
> hard to test) :-(
> 
> [ Of course, an option could be to ask the user whether to wait or to just
>   skip the resume, but there might be no screen/keyboard connected or no
>   admin/user at the helm, so it's not a reliable solution either.  ]

Right. Sigh, it seems you just can't win. I solved it by having no swap :)

Cheers
-- 
t

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web