Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #258736
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: UUIDS |
| Date | 2023-05-28 18:10 +0200 |
| Message-ID | <GAr7Y-c2Ds-13@gated-at.bofh.it> (permalink) |
| References | <GAc8V-bTh7-3@gated-at.bofh.it> <GAc8V-bTh7-5@gated-at.bofh.it> <GAgYV-bWzx-3@gated-at.bofh.it> <GAoMN-c16q-7@gated-at.bofh.it> <GAqEV-c2dR-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
>> 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
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web