Given that hibernation has always worked before ...

I have installed, side by side, Linux MX 23 "Libretto" in a
system running Debian Bookworm (BTW an AMAZING installer,
especially the powerful disk utility to manage partition
during install : the distro was the live version).

The two install SHARE the same swap partition (64 GB wide,
the same as RAM, that had been enough).

I have manually synced the two FSTAB to update Debian FSTAB
(formatting the MX ROOT, /, and its /HOME, in two different
partitions, that Debian used to mount, the UUID were
changed, so the need to revise this). The SWAP partition was
set to be "use as such, no formatting", and actually its
UUID has not changed.

Now the two systems work finely (and MX also hibernates),
but Debian no longer does, without any error message.

What could have happened and how to diagnose the problem and
to solve ?

Since the SWAP UUID has remained the same, it is an
unexpected outcome to me ... Debian correctly reports the
free/used swap space (at least in the panel gadget).

Tnx for any suggestions

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 2023-06-23 13:00, MarioCPPP wrote:
> Given that hibernation has always worked before ...
>
> I have installed, side by side, Linux MX 23 "Libretto" in a system
> running Debian Bookworm (BTW an AMAZING installer, especially the
> powerful disk utility to manage partition during install : the distro
> was the live version).
>
> The two install SHARE the same swap partition (64 GB wide, the same as
> RAM, that had been enough).
>
> I have manually synced the two FSTAB to update Debian FSTAB (formatting
> the MX ROOT, /, and its /HOME, in two different partitions, that Debian
> used to mount, the UUID were changed, so the need to revise this). The
> SWAP partition was set to be "use as such, no formatting", and actually
> its UUID has not changed.
>
> Now the two systems work finely (and MX also hibernates), but Debian no
> longer does, without any error message.

Did you actually read the logs?

>
> What could have happened and how to diagnose the problem and to solve ?
>
> Since the SWAP UUID has remained the same, it is an unexpected outcome
> to me ... Debian correctly reports the free/used swap space (at least in
> the panel gadget).

I would verify that the kernel command line is actually pointing at the
correct swap partition.

--
Cheers, Carlos.

On 6/23/23 13:00, MarioCPPP wrote:

> The two install SHARE the same swap partition (64 GB wide, the same as
> RAM, that had been enough).

This could end up in a funny thing, you hibernate one os, then next time
you boot you want to start the other and then you end up with the first.

Location where you store the data should be different IMHO.

> Now the two systems work finely (and MX also hibernates), but Debian no
> longer does, without any error message.

Did you check the logs?
Dmesg?

> What could have happened and how to diagnose the problem and to solve ?

There can be applications that prevents hibernation, for example
VirtualBox, you have to figure it out yourself by closing one
application at the time.

> Since the SWAP UUID has remained the same, it is an unexpected outcome
> to me ... Debian correctly reports the free/used swap space (at least in
> the panel gadget).

As long as the used memory + used swap is smaller than the swap itself,
it's not an issue of swap space.

--
//Aho

On 2023-06-23 14:49, J.O. Aho wrote:
> On 6/23/23 13:00, MarioCPPP wrote:
>
>> The two install SHARE the same swap partition (64 GB wide, the same as
>> RAM, that had been enough).
>
> This could end up in a funny thing, you hibernate one os, then next time
> you boot you want to start the other and then you end up with the first.
>
> Location where you store the data should be different IMHO.

On the contrary.

The booting kernel checks the swapped image, and either bail out if they
don't match, or boots the swapped image no matter what kernel you ask to
boot. Both are correct results.

It is when using different swaps that you can manage to boot a different
system, which it may then try to mount the hibernated partitions,
creating a Royal Corruption.

Happened to me, I know what I'm talking about. ;-)

....

--
Cheers, Carlos.

On 6/23/23 15:08, Carlos E.R. wrote:

> It is when using different swaps that you can manage to boot a different
> system, which it may then try to mount the hibernated partitions,
> creating a Royal Corruption.
> Happened to me, I know what I'm talking about. ;-)

Don't use unified grub for multiple distors, you will end up with all
distros to use the same resume swap partition.

--
//Aho

On 2023-06-23, J.O. Aho <user@example.net> wrote:
> On 6/23/23 13:00, MarioCPPP wrote:
>
>> The two install SHARE the same swap partition (64 GB wide, the same as
>> RAM, that had been enough).
>
> This could end up in a funny thing, you hibernate one os, then next time
> you boot you want to start the other and then you end up with the first.

If you're sharing file systems between then there's nothing gained by
having multiple hibernation stores, you can only run or suspend one OS
at a time involve a second and you'll get disk corruption.

--
Jasen.
🇺🇦 Слава Україні

On 23/06/23 13:49, Carlos E.R. wrote:
> On 2023-06-23 13:00, MarioCPPP wrote:
>> Given that hibernation has always worked before ...
>>
>> I have installed, side by side, Linux MX 23 "Libretto" in
>> a system running Debian Bookworm (BTW an AMAZING
>> installer, especially the powerful disk utility to manage
>> partition during install : the distro was the live version).
>>
>> The two install SHARE the same swap partition (64 GB wide,
>> the same as RAM, that had been enough).
>>
>> I have manually synced the two FSTAB to update Debian
>> FSTAB (formatting the MX ROOT, /, and its /HOME, in two
>> different partitions, that Debian used to mount, the UUID
>> were changed, so the need to revise this). The SWAP
>> partition was set to be "use as such, no formatting", and
>> actually its UUID has not changed.
>>
>> Now the two systems work finely (and MX also hibernates),
>> but Debian no longer does, without any error message.
>
> Did you actually read the logs?

no, not at all. Which ones ? Where ?
I was stating no errors reported on screen advices

>
>>
>> What could have happened and how to diagnose the problem
>> and to solve ?
>>
>> Since the SWAP UUID has remained the same, it is an
>> unexpected outcome to me ... Debian correctly reports the
>> free/used swap space (at least in the panel gadget).
>
> I would verify that the kernel command line is actually
> pointing at the correct swap partition.

the swap is USED, but, apart from FSTAB, what is the kernel
command line ? Where could I find it ?

>
>
>

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 24/06/23 03:08, Jasen Betts wrote:
> On 2023-06-23, J.O. Aho <user@example.net> wrote:
>> On 6/23/23 13:00, MarioCPPP wrote:
>>
>>> The two install SHARE the same swap partition (64 GB wide, the same as
>>> RAM, that had been enough).
>>
>> This could end up in a funny thing, you hibernate one os, then next time
>> you boot you want to start the other and then you end up with the first.
>
> If you're sharing file systems between then there's nothing gained by
> having multiple hibernation stores, you can only run or suspend one OS
> at a time involve a second and you'll get disk corruption.
>

I have a doubt : shouldn't hibernation process at least
close any open FILE HANDLES (and also FLUSH BUFFERS) ? To
not do this seems really risky.
The reverse (reopening, assigning FILE * to the matching
processes) should be possible on reload.
But leaving the disk in "open" state seems a nightmare

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 23/06/23 14:49, J.O. Aho wrote:
> On 6/23/23 13:00, MarioCPPP wrote:
>
>> The two install SHARE the same swap partition (64 GB wide,
>> the same as RAM, that had been enough).
>
> This could end up in a funny thing, you hibernate one os,
> then next time you boot you want to start the other and then
> you end up with the first.

yes, it used to happen and it will again.
Not reliably, in the course of various upgrades during
years, I faced every scenarios
1) to have 2 resume systems "last one" aware, that correctly
bypassed the wrong selection (or the default one on timeout)
and resumed the correct saved state regardless of the
attempt to start the wrong one
2) one able and the other not able
3) both unable to detect the inconsistency, that dumped the
saved state and restarted from fresh

now, I have not yet understood which one is up : the problem
happened once only, and I tend not to make it happen
deliberatedly ! For the little I can recall, MX loaded (it
is the last installed and has set itself as the default on
timeout) from fresh discarding Debian saved status. The
reverse I still dunno. It is a bit delusional (having both
newer kernel, I had hoped they'd have been able to detect
the inconsistence, a thing just experimented before ... but
maybe there are also other config variables hidden to me
that change the course of events)

>
> Location where you store the data should be different IMHO.
>

not a viable solution. I just "waste" 64 GB SSD space, the
double is unbearable

>
>
>> Now the two systems work finely (and MX also hibernates),
>> but Debian no longer does, without any error message.
>
> Did you check the logs?
> Dmesg?

no ... to me, this, is like to look for the famous needle in
the haystack

>
>> What could have happened and how to diagnose the problem
>> and to solve ?
>
> There can be applications that prevents hibernation, for
> example VirtualBox, you have to figure it out yourself by
> closing one application at the time.

this was the first thing I thought about, and I had closed
everything "visible" ...

>
>
>> Since the SWAP UUID has remained the same, it is an
>> unexpected outcome to me ... Debian correctly reports the
>> free/used swap space (at least in the panel gadget).
>
> As long as the used memory + used swap is smaller than the
> swap itself, it's not an issue of swap space.

I never try to hibernate with RAM deeply loaded, since I
still reckon there is some risk of data loss. I tend to
close the open documents and some programs (i.g.
LibreOffice, compilers, thunderbird, and so ... I tend to
let Firefox opened, relying on its very robust crash
restoring ability)

>

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 2023-06-24 12:38, MarioCPPP wrote:
> On 24/06/23 03:08, Jasen Betts wrote:
>> On 2023-06-23, J.O. Aho <user@example.net> wrote:
>>> On 6/23/23 13:00, MarioCPPP wrote:
>>>
>>>> The two install SHARE the same swap partition (64 GB wide, the same as
>>>> RAM, that had been enough).
>>>
>>> This could end up in a funny thing, you hibernate one os, then next time
>>> you boot you want to start the other and then you end up with the first.
>>
>> If you're sharing file systems between then there's nothing gained by
>> having multiple hibernation stores,  you can only run or suspend one OS
>> at a time involve a second and you'll get disk corruption.
>>
>
> I have a doubt : shouldn't hibernation process at least close any open
> FILE HANDLES (and also FLUSH BUFFERS) ? To not do this seems really risky.
> The reverse (reopening, assigning FILE * to the matching processes)
> should be possible on reload.
> But leaving the disk in "open" state seems a nightmare

less nightmare than reopening.

The idea of hibernation is to freeze the RAM in disk. Minimal
alterations. Programs are frozen, not restarted or changed.

--
Cheers, Carlos.

On 2023-06-24 12:23, MarioCPPP wrote:
> On 23/06/23 13:49, Carlos E.R. wrote:
>> On 2023-06-23 13:00, MarioCPPP wrote:
>>> Given that hibernation has always worked before ...
>>>
>>> I have installed, side by side, Linux MX 23 "Libretto" in a system
>>> running Debian Bookworm (BTW an AMAZING installer, especially the
>>> powerful disk utility to manage partition during install : the distro
>>> was the live version).
>>>
>>> The two install SHARE the same swap partition (64 GB wide, the same
>>> as RAM, that had been enough).
>>>
>>> I have manually synced the two FSTAB to update Debian FSTAB
>>> (formatting the MX ROOT, /, and its /HOME, in two different
>>> partitions, that Debian used to mount, the UUID were changed, so the
>>> need to revise this). The SWAP partition was set to be "use as such,
>>> no formatting", and actually its UUID has not changed.
>>>
>>> Now the two systems work finely (and MX also hibernates), but Debian
>>> no longer does, without any error message.
>>
>> Did you actually read the logs?
>
> no, not at all. Which ones ? Where ?
> I was stating no errors reported on screen advices

Well, it is the first thing to do when diagnosing some problem in Linux.
I am not familiar with Debian, but you could try:

journalctl -b

>
>>
>>>
>>> What could have happened and how to diagnose the problem and to solve ?
>>>
>>> Since the SWAP UUID has remained the same, it is an unexpected
>>> outcome to me ... Debian correctly reports the free/used swap space
>>> (at least in the panel gadget).
>>
>> I would verify that the kernel command line is actually pointing at
>> the correct swap partition.
>
> the swap is USED, but, apart from FSTAB, what is the kernel command line
> ? Where could I find it ?

At the very start of the journal, for instance:

Apr 14 23:41:33 Telcontar kernel: Linux version
5.14.21-150400.24.55-default (geeko@buildhost) (gcc (SUSE Linux) 7.5.0,
GNU ld (GNU Binutils; SUSE Linux Enterprise 15)
2.39.0.20220810-150100.7.40) #1 SMP>
Apr 14 23:41:33 Telcontar kernel: Command line:
BOOT_IMAGE=/vmlinuz-5.14.21-150400.24.55-default
root=UUID=ac173013-18ad-4c4e-921e-fd2ecfb56495
resume=/dev/disk/by-label/nvme-swap splash=verbose verbose

See the resume=...?

In my distro, it is configured in "/etc/default/grub"

--
Cheers, Carlos.

On Sat, 24 Jun 2023 12:38:04 +0200, MarioCPPP wrote:

<Snip>

>> Did you check the logs?
>> Dmesg?
>
> no ... to me, this, is like to look for the famous needle in the
> haystack

Grep is your friend. dmesg | grep search term example dmesg | grep
mxlinux or dmesg | grep debian or dmesg | grep swap

Good luck.......

--
Pull my finger

On 24/06/23 16:48, Killadebug wrote:
> On Sat, 24 Jun 2023 12:38:04 +0200, MarioCPPP wrote:
>
> <Snip>
>
>>> Did you check the logs?
>>> Dmesg?
>>
>> no ... to me, this, is like to look for the famous needle in the
>> haystack
>
> Grep is your friend. dmesg | grep search term example dmesg | grep
> mxlinux or dmesg | grep debian or dmesg | grep swap
>
> Good luck.......
>

root@pcname:~# dmesg | grep resume
[ 6.898884] Process accounting resumed

root@pcname:~# dmesg | grep swap
[ 0.103517] Spectre V1 : Mitigation: usercopy/swapgs
barriers and __user pointer sanitization
[ 0.922183] zswap: loaded using pool lzo/zbud
[ 5.139580] Adding 67174396k swap on /dev/sdb1.
Priority:-2 extents:1 across:67174396k SSFS

root@pcname:~# dmesg | grep vmlinuz
[ 0.000000] Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64
root=UUID=b7e3be4f-15a0-4e58-a323-fd6b0e4fbf4d ro quiet
[ 0.014894] Kernel command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64
root=UUID=b7e3be4f-15a0-4e58-a323-fd6b0e4fbf4d ro quiet
[ 0.014925] Unknown kernel command line parameters
"BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64", will be
passed to user space.
[ 1.045483]
BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64
root@pcname:~#

dunno, seems not to be mentioned any relevant resume device.
But yesterday the hibernation worked.

I still have to find what slows so much the shut down : the
process "wrapper-linux-X" and "java"
and to solve the unmounting, particularly the /tmp, which is
not linked nor BIND mounted, is reluctant for unknown reasons

>
>

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 2023-06-25 11:50, MarioCPPP wrote:
> On 24/06/23 16:48, Killadebug wrote:
>> On Sat, 24 Jun 2023 12:38:04 +0200, MarioCPPP wrote:
>>
>> <Snip>
>>
>>>> Did you check the logs?
>>>> Dmesg?
>>>
>>> no ... to me, this, is like to look for the famous needle in the
>>> haystack
>>
>> Grep is your friend. dmesg | grep search term    example  dmesg | grep
>> mxlinux or dmesg | grep debian or dmesg | grep swap
>>
>> Good luck.......
>>
>
> root@pcname:~# dmesg | grep resume
> [    6.898884] Process accounting resumed
>
> root@pcname:~# dmesg | grep swap
> [    0.103517] Spectre V1 : Mitigation: usercopy/swapgs barriers and
> __user pointer sanitization
> [    0.922183] zswap: loaded using pool lzo/zbud
> [    5.139580] Adding 67174396k swap on /dev/sdb1. Priority:-2 extents:1
> across:67174396k SSFS
>
> root@pcname:~# dmesg | grep vmlinuz
> [    0.000000] Command line:
> BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64
> root=UUID=b7e3be4f-15a0-4e58-a323-fd6b0e4fbf4d ro quiet
> [    0.014894] Kernel command line:
> BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64
> root=UUID=b7e3be4f-15a0-4e58-a323-fd6b0e4fbf4d ro quiet
> [    0.014925] Unknown kernel command line parameters
> "BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64", will be passed to
> user space.
> [    1.045483] BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64
> root@pcname:~#
>
>
> dunno, seems not to be mentioned any relevant resume device.
> But yesterday the hibernation worked.

You have a very interesting log entry in your "dmesg | grep vmlinuz"
output above. Don't you see it?

It is saying that the kernel command line is BAD, and is using another
line instead, ignoring the given one.

And that kernel can not be hibernated, obviously.

>
> I still have to find what slows so much the shut down : the process
> "wrapper-linux-X" and "java"
> and to solve the unmounting, particularly the /tmp, which is not linked
> nor BIND mounted, is reluctant for unknown reasons

Typically, some running process is still using a file in /tmp.

--
Cheers, Carlos.

On 25/06/23 13:46, Carlos E.R. wrote:
> On 2023-06-25 11:50, MarioCPPP wrote:
>> On 24/06/23 16:48, Killadebug wrote:
>>> On Sat, 24 Jun 2023 12:38:04 +0200, MarioCPPP wrote:
>>>
>>> <Snip>
>>>
>>>>> Did you check the logs?
>>>>> Dmesg?
>>>>
>>>> no ... to me, this, is like to look for the famous
>>>> needle in the
>>>> haystack
>>>
>>> Grep is your friend. dmesg | grep search term    example
>>> dmesg | grep
>>> mxlinux or dmesg | grep debian or dmesg | grep swap
>>>
>>> Good luck.......
>>>
>>
>> root@pcname:~# dmesg | grep resume
>> [    6.898884] Process accounting resumed
>>
>> root@pcname:~# dmesg | grep swap
>> [    0.103517] Spectre V1 : Mitigation: usercopy/swapgs
>> barriers and __user pointer sanitization
>> [    0.922183] zswap: loaded using pool lzo/zbud
>> [    5.139580] Adding 67174396k swap on /dev/sdb1.
>> Priority:-2 extents:1 across:67174396k SSFS
>>
>> root@pcname:~# dmesg | grep vmlinuz
>> [    0.000000] Command line:
>> BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64
>> root=UUID=b7e3be4f-15a0-4e58-a323-fd6b0e4fbf4d ro quiet
>> [    0.014894] Kernel command line:
>> BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64
>> root=UUID=b7e3be4f-15a0-4e58-a323-fd6b0e4fbf4d ro quiet
>> [    0.014925] Unknown kernel command line parameters
>> "BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64", will
>> be passed to user space.
>> [    1.045483]
>> BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64
>> root@pcname:~#
>>
>>
>> dunno, seems not to be mentioned any relevant resume device.
>> But yesterday the hibernation worked.
>
> You have a very interesting log entry in your "dmesg | grep
> vmlinuz" output above. Don't you see it?
well, I dunno the correct syntax of the load command for the
zipped ram image ... how could I solve the problem (and what
is the problem ?) :D
>
> It is saying that the kernel command line is BAD, and is
> using another line instead, ignoring the given one.
>
> And that kernel can not be hibernated, obviously.
mmm, actually it has just resumed twice ever since, and the
behaviour hasn't been replicated (without me doing anything).
There is also another strange fact.
Randomly, when I login as root in a terminal "box", to
update sth, it suggests performing a CHKBOOT ... a cmq whose
I completely dunno, but I simply "obey".
Could this have sth to do with either one of : 1) creating
the boot problem (I wasn't aware of), or 2) resolving it
(temporarily) ?
I'm very confused with this all

>
>
>>
>> I still have to find what slows so much the shut down :
>> the process "wrapper-linux-X" and "java"
>> and to solve the unmounting, particularly the /tmp, which
>> is not linked nor BIND mounted, is reluctant for unknown
>> reasons
>
> Typically, some running process is still using a file in /tmp.
where could I find the culprit and, later, how to make it
die gracefully ? I mean not manually killing it.
>
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 2023-06-25 16:00, MarioCPPP wrote:
> On 25/06/23 13:46, Carlos E.R. wrote:
>> On 2023-06-25 11:50, MarioCPPP wrote:
>>> On 24/06/23 16:48, Killadebug wrote:
>>>> On Sat, 24 Jun 2023 12:38:04 +0200, MarioCPPP wrote:
>>>>
>>>> <Snip>
>>>>
>>>>>> Did you check the logs?
>>>>>> Dmesg?
>>>>>
>>>>> no ... to me, this, is like to look for the famous needle in the
>>>>> haystack
>>>>
>>>> Grep is your friend. dmesg | grep search term    example dmesg | grep
>>>> mxlinux or dmesg | grep debian or dmesg | grep swap
>>>>
>>>> Good luck.......
>>>>
>>>
>>> root@pcname:~# dmesg | grep resume
>>> [    6.898884] Process accounting resumed
>>>
>>> root@pcname:~# dmesg | grep swap
>>> [    0.103517] Spectre V1 : Mitigation: usercopy/swapgs barriers and
>>> __user pointer sanitization
>>> [    0.922183] zswap: loaded using pool lzo/zbud
>>> [    5.139580] Adding 67174396k swap on /dev/sdb1. Priority:-2
>>> extents:1 across:67174396k SSFS
>>>
>>> root@pcname:~# dmesg | grep vmlinuz
>>> [    0.000000] Command line:
>>> BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64
>>> root=UUID=b7e3be4f-15a0-4e58-a323-fd6b0e4fbf4d ro quiet
>>> [    0.014894] Kernel command line:
>>> BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64
>>> root=UUID=b7e3be4f-15a0-4e58-a323-fd6b0e4fbf4d ro quiet
>>> [    0.014925] Unknown kernel command line parameters
>>> "BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64", will be passed
>>> to user space.
>>> [    1.045483] BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64
>>> root@pcname:~#
>>>
>>>
>>> dunno, seems not to be mentioned any relevant resume device.
>>> But yesterday the hibernation worked.
>>
>> You have a very interesting log entry in your "dmesg | grep vmlinuz"
>> output above. Don't you see it?
>
> well, I dunno the correct syntax of the load command for the zipped ram
> image ... how could I solve the problem (and what is the problem ?) :D
>
>>
>> It is saying that the kernel command line is BAD, and is using another
>> line instead, ignoring the given one.
>>
>> And that kernel can not be hibernated, obviously.
>
> mmm, actually it has just resumed twice ever since, and the behaviour
> hasn't been replicated (without me doing anything).
>
> There is also another strange fact.
> Randomly, when I login as root in a terminal "box", to update sth, it
> suggests performing a CHKBOOT ... a cmq whose I completely dunno, but I
> simply "obey".
> Could this have sth to do with either one of : 1) creating the boot
> problem (I wasn't aware of), or 2) resolving it (temporarily) ?
>
> I'm very confused with this all

Well, I don't know the distro you are using in any detail. I can't know.

>>> I still have to find what slows so much the shut down : the process
>>> "wrapper-linux-X" and "java"
>>> and to solve the unmounting, particularly the /tmp, which is not
>>> linked nor BIND mounted, is reluctant for unknown reasons
>>
>> Typically, some running process is still using a file in /tmp.
>
> where could I find the culprit and, later, how to make it die gracefully
> ? I mean not manually killing it.

Again, I don't know the distro you are using in any detail. I can't
know. My guess, your distro shutdown scripts do not contemplate properly
people that put /tmp on a different partition. You have to ask them.
They can well say "not supported scenario".

--
Cheers, Carlos.

On 23/06/23 13:00, MarioCPPP wrote:

Damn, it happened again.

I had hibernated Debian and, on power on, I forgot to attend
the boot, and it booted MX 23 without detection. It
discarded the saved image and booted itself.

Now, I refuse to think that the newest kernel is unaware of
the mismatch (of the loading system vs the saved image).
I tend more to think of some sort of misconfiguration.

I don't know how to configure GRUB loader, but, to simply
patch the situation, how to change the DEFAULT system to be
loaded at boot ?

Since MX23 has been installed LAST, it set up itself as the
default.
I'd like to edit "some" grub config file to restore Debian
as the default, since I mostly use it and hence I'd reduce
the likeliness of discarding saved ram from hibernations ...

what I have to edit ?

Obv. If sb knows of more robust kernel command line
parameters that ensure to check the matching with saved
states, even better.

tnx

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 2023-06-28 12:41, MarioCPPP wrote:
> On 23/06/23 13:00, MarioCPPP wrote:
>
>
> Damn, it happened again.
>
> I had hibernated Debian and, on power on, I forgot to attend the boot,
> and it booted MX 23 without detection. It discarded the saved image and
> booted itself.
>
> Now, I refuse to think that the newest kernel is unaware of the mismatch
> (of the loading system vs the saved image).
> I tend more to think of some sort of misconfiguration.
>
> I don't know how to configure GRUB loader, but, to simply patch the
> situation, how to change the DEFAULT system to be loaded at boot ?
>
> Since MX23 has been installed LAST, it set up itself as the default.
> I'd like to edit "some" grub config file to restore Debian as the
> default, since I mostly use it and hence I'd reduce the likeliness of
> discarding saved ram from hibernations ...
>
> what I have to edit ?

If you get this:

Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64
root=UUID=b7e3be4f-15a0-4e58-a323-fd6b0e4fbf4d ro quiet

it will not resume from hibernation. You need there a "resume=..."
section pointing to the swap partition.

Where to change that, I have no idea, for your distro. Maybe
/etc/default/grub

The distribution that is hibernating is responsible for setting grub to
boot the correct kernel on the next boot, but will not do this if there
is another grub. It can only control this in its own grub.

Which grub boots, if there are more than one, is selected by the UEFI.
You see that with command efibootmgr

--
Cheers, Carlos.

On 6/28/2023 6:59 AM, Carlos E.R. wrote:
> On 2023-06-28 12:41, MarioCPPP wrote:
>> On 23/06/23 13:00, MarioCPPP wrote:
>>
>>
>> Damn, it happened again.
>>
>> I had hibernated Debian and, on power on, I forgot to attend the boot, and it booted MX 23 without detection. It discarded the saved image and booted itself.
>>
>> Now, I refuse to think that the newest kernel is unaware of the mismatch (of the loading system vs the saved image).
>> I tend more to think of some sort of misconfiguration.
>>
>> I don't know how to configure GRUB loader, but, to simply patch the situation, how to change the DEFAULT system to be loaded at boot ?
>>
>> Since MX23 has been installed LAST, it set up itself as the default.
>> I'd like to edit "some" grub config file to restore Debian as the default, since I mostly use it and hence I'd reduce the likeliness of discarding saved ram from hibernations ...
>>
>> what I have to edit ?
>
> If you get this:
>
> Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64 root=UUID=b7e3be4f-15a0-4e58-a323-fd6b0e4fbf4d ro quiet
>
> it will not resume from hibernation. You need there a "resume=..." section pointing to the swap partition.
>
> Where to change that, I have no idea, for your distro. Maybe /etc/default/grub
>
>
> The distribution that is hibernating is responsible for setting grub to boot the correct kernel on the next boot, but will not do this if there is another grub. It can only control this in its own grub.
>
> Which grub boots, if there are more than one, is selected by the UEFI. You see that with command efibootmgr
>

Here's an entry from my notes file. I was having trouble with slow
boot caused by the definition of swap, so I "fixed it" :-)

*******
Ubuntu, caught searching for btrfs, mdadm, is caused by swap UUID.

1) Edit /etc/fstab and correct blkid of swap (so Ubuntu can find its swap).
2) Initramfs also has a swap check.

open /etc/initramfs-tools/conf.d/resume
replace RESUME=UUID=xxx with RESUME=none (or use the correct blkid!)
issue sudo update-initramfs -u
reboot your system

I did an update-grub just in case.
*******

Maybe that entry will give some keywords for Googling.

Paul

On 28/06/23 14:25, Paul wrote:
> On 6/28/2023 6:59 AM, Carlos E.R. wrote:
>> On 2023-06-28 12:41, MarioCPPP wrote:
>>> On 23/06/23 13:00, MarioCPPP wrote:
>>>
>>>
>>> Damn, it happened again.
>>>
>>> I had hibernated Debian and, on power on, I forgot to
>>> attend the boot, and it booted MX 23 without detection.
>>> It discarded the saved image and booted itself.
>>>
>>> Now, I refuse to think that the newest kernel is unaware
>>> of the mismatch (of the loading system vs the saved image).
>>> I tend more to think of some sort of misconfiguration.
>>>
>>> I don't know how to configure GRUB loader, but, to simply
>>> patch the situation, how to change the DEFAULT system to
>>> be loaded at boot ?
>>>
>>> Since MX23 has been installed LAST, it set up itself as
>>> the default.
>>> I'd like to edit "some" grub config file to restore
>>> Debian as the default, since I mostly use it and hence
>>> I'd reduce the likeliness of discarding saved ram from
>>> hibernations ...
>>>
>>> what I have to edit ?
>>
>> If you get this:
>>
>> Kernel command line:
>> BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.6-rt-amd64
>> root=UUID=b7e3be4f-15a0-4e58-a323-fd6b0e4fbf4d ro quiet
>>
>> it will not resume from hibernation. You need there a
>> "resume=..." section pointing to the swap partition.
>>
>> Where to change that, I have no idea, for your distro.
>> Maybe /etc/default/grub
>>
>>
>> The distribution that is hibernating is responsible for
>> setting grub to boot the correct kernel on the next boot,
>> but will not do this if there is another grub. It can only
>> control this in its own grub.
>>
>> Which grub boots, if there are more than one, is selected
>> by the UEFI. You see that with command efibootmgr
>>
>
> Here's an entry from my notes file. I was having trouble
> with slow
> boot caused by the definition of swap, so I "fixed it" :-)
>
> *******
> Ubuntu, caught searching for btrfs, mdadm, is caused by swap
> UUID.
>
> 1) Edit /etc/fstab and correct blkid of swap (so Ubuntu can
> find its swap).
the two fstab (I have dual boot) had just been synced before
: both use the same swap partition.
> 2) Initramfs also has a swap check.
>
>     open /etc/initramfs-tools/conf.d/resume
>     replace RESUME=UUID=xxx with RESUME=none  (or use the
> correct blkid!)
>     issue sudo update-initramfs -u
>     reboot your system
>
> I did an update-grub just in case.
but in which of the two ?
Now I have done update-grub IN DEBIAN (running).
BTW it informs me it will not execute os-prober to find
other oses.
I manually executed os-prober, it detected LinuxMX, but
later, redoing grub-update, produced the same msg. Evidently
the two commands cannot "communicate" the way I hoped
(setting some persistent info somewhere)
Maybe I'll try to execute grub update also in MX when I'll
be using it again.
As to the command line arguments, I understand very little,
dunno what to write and where, and for now I abstain from
making my machine unbootable at all :D :D
> *******
>
> Maybe that entry will give some keywords for Googling.
>
>    Paul
>
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 6/28/23 19:08, MarioCPPP wrote:
> On 28/06/23 14:25, Paul wrote:

>> 2) Initramfs also has a swap check.
>>
>>      open /etc/initramfs-tools/conf.d/resume
>>      replace RESUME=UUID=xxx with RESUME=none  (or use the correct
>> blkid!)
>>      issue sudo update-initramfs -u
>>      reboot your system
>>
>> I did an update-grub just in case.
>
> but in which of the two ?

If you configured your grub correctly you can always force re-install
the kernel and it will update the initramfs and update the bootloader.

> Now I have done update-grub IN DEBIAN (running).
> BTW it informs me it will not execute os-prober to find other oses.

This for you haven't configured GRUB_DISABLE_OS_PROBER to be true.

--
//Aho

On Wed, 28 Jun 2023 12:41:11 +0200, MarioCPPP wrote:
> On 23/06/23 13:00, MarioCPPP wrote:
>
>
> Damn, it happened again.
>
> I had hibernated Debian and, on power on, I forgot to attend
> the boot, and it booted MX 23 without detection. It
> discarded the saved image and booted itself.
>
> Now, I refuse to think that the newest kernel is unaware of
> the mismatch (of the loading system vs the saved image).
> I tend more to think of some sort of misconfiguration.
>
> I don't know how to configure GRUB loader, but, to simply
> patch the situation, how to change the DEFAULT system to be
> loaded at boot ?

IT IS BEST to not patch the situation, easy to patch grub.cfg
but next kernel upgrade will wipe out aall custom/patche changes.

The other common problem I see is users with multi boot installs.

Last installed OS creates the new grub.cfg and installs it.
If it is a clone install, the previous install is in charge.
User needs to know which OS grub is in charge.

update-grub should rescan your system and build a new grub.cfg
unless you have disabled GRUB_DISABLE_OS_PROBER in /etc/grub.d/default_grub

grub-install --recheck /dev/sda tells grub to install the boot loader
to be used in sda's mbr.

grub2-set-default xxx will set what selection is to be the default boot.

Commands given may be specific to my linux install
$ cat /etc/release
Mageia release 9 (Cauldron) for x86_64

If commands do not work you will need to get actual grub commands.
Search engine will get you to a grub manual.

On 29/06/23 08:14, J.O. Aho wrote:
> On 6/28/23 19:08, MarioCPPP wrote:
>> On 28/06/23 14:25, Paul wrote:
>
>>> 2) Initramfs also has a swap check.
>>>
>>>      open /etc/initramfs-tools/conf.d/resume
>>>      replace RESUME=UUID=xxx with RESUME=none  (or use
>>> the correct blkid!)
>>>      issue sudo update-initramfs -u
>>>      reboot your system
>>>
>>> I did an update-grub just in case.
>>
>> but in which of the two ?
>
> If you configured your grub correctly
I have never ever configured it at all.
Each (of the two) distro I've installed, did it all on its
own. The only thing I've chosen is where : the SAME MBR of
the same drive (it is a legacy partitioned, non GPT), and
the order. Long beforehand, Debian. Recently, MX 23.
I would not even be able to configure grub
> you can always force
> re-install the kernel and it will update the initramfs and
> update the bootloader.
>
>
>> Now I have done update-grub IN DEBIAN (running).
>> BTW it informs me it will not execute os-prober to find
>> other oses.
>
> This for you haven't configured GRUB_DISABLE_OS_PROBER to be
> true.
it must be the default value. Defined somewhere, somehow, I
guess ...
>
>
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 29/06/23 16:22, Bit Twister wrote:
> On Wed, 28 Jun 2023 12:41:11 +0200, MarioCPPP wrote:
>> On 23/06/23 13:00, MarioCPPP wrote:
>>
>>
>> Damn, it happened again.
>>
>> I had hibernated Debian and, on power on, I forgot to attend
>> the boot, and it booted MX 23 without detection. It
>> discarded the saved image and booted itself.
>>
>> Now, I refuse to think that the newest kernel is unaware of
>> the mismatch (of the loading system vs the saved image).
>> I tend more to think of some sort of misconfiguration.
>>
>> I don't know how to configure GRUB loader, but, to simply
>> patch the situation, how to change the DEFAULT system to be
>> loaded at boot ?
>
> IT IS BEST to not patch the situation, easy to patch grub.cfg
> but next kernel upgrade will wipe out aall custom/patche changes.

so sad ! :(

>
> The other common problem I see is users with multi boot installs.
>
> Last installed OS creates the new grub.cfg and installs it.
> If it is a clone install,

I dunno what a clone install is. I booted a live distro, and
installed from scratch on an empty partition. Debian has
been just there beforehand.

> the previous install is in charge.
> User needs to know which OS grub is in charge.

the latest install (MX 23's copy of grub : or at least
Debian's splash screen has been replaced by MX's ... it
would be strange to have changed only a splash screen, true ?).

>
> update-grub

executed from which of the two distros ?

> should rescan your system and build a new grub.cfg
> unless you have disabled GRUB_DISABLE_OS_PROBER in /etc/grub.d/default_grub

I have done nothing. The situation is what it is regardless
of me.

/etc/grub.d/default_grub of what DISTRO, again ?

>
>
> grub-install --recheck /dev/sda tells grub to install the boot loader
> to be used in sda's mbr.

intresting ! An option I'll study

>
> grub2-set-default xxx will set what selection is to be the default boot.

again, an useful suggestion
I need to understand how to get exactly the values to
replace XXX

TNX

>
> Commands given may be specific to my linux install
> $ cat /etc/release
> Mageia release 9 (Cauldron) for x86_64
>
> If commands do not work you will need to get actual grub commands.
> Search engine will get you to a grub manual.

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 29/06/23 16:22, Bit Twister wrote:
> On Wed, 28 Jun 2023 12:41:11 +0200, MarioCPPP wrote:
>> On 23/06/23 13:00, MarioCPPP wrote:
>>
>>
>> Damn, it happened again.
>>
>> I had hibernated Debian and, on power on, I forgot to attend
>> the boot, and it booted MX 23 without detection. It
>> discarded the saved image and booted itself.
>>
>> Now, I refuse to think that the newest kernel is unaware of
>> the mismatch (of the loading system vs the saved image).
>> I tend more to think of some sort of misconfiguration.
>>
>> I don't know how to configure GRUB loader, but, to simply
>> patch the situation, how to change the DEFAULT system to be
>> loaded at boot ?
>
> IT IS BEST to not patch the situation, easy to patch grub.cfg
> but next kernel upgrade will wipe out aall custom/patche changes.
>
> The other common problem I see is users with multi boot installs.
>
> Last installed OS creates the new grub.cfg and installs it.
> If it is a clone install, the previous install is in charge.
> User needs to know which OS grub is in charge.
>
> update-grub should rescan your system and build a new grub.cfg
> unless you have disabled GRUB_DISABLE_OS_PROBER in /etc/grub.d/default_grub

I have examined both Debian's folders and MX23's folders of
/etc/grub.d and ...
NONE contains a file (or subfolder) named default_grub

Then, I examined a file named 30_os-prober (in both Distros)

MX23 (the one "in charge" of the boot) copy reports a row :

if [ "x$(debconf-get-selections |grep
'^grub-pc\sgrub2/enable_os_prober\sboolean\strue' | awk
'{print $4}')" = "xtrue" ]; then
export GRUB_DISABLE_OS_PROBER="false"
fi

set -e

........

if [ "x${GRUB_DISABLE_OS_PROBER}" = "xtrue" ]; then
exit 0
fi

if [ -z "`which os-prober 2> /dev/null`" ] || [ -z "`which
linux-boot-prober 2> /dev/null`" ] ; then
# missing os-prober and/or linux-boot-prober
exit 0
fi

OSPROBED="`os-prober | tr ' ' '^' | paste -s -d ' '`"
if [ -z "${OSPROBED}" ] ; then
# empty os-prober output, nothing doing
exit 0
fi

=====================================================

Debian copy reports

if ! command -v os-prober > /dev/null || ! command -v
linux-boot-prober > /dev/null ; then
# missing os-prober and/or linux-boot-prober
exit 0
fi

if [ "x${GRUB_DISABLE_OS_PROBER}" = "xtrue" ]; then
grub_warn "$(gettext_printf "os-prober will not be
executed to detect other bootable partitions.\nSystems on
them will not be added to the GRUB boot
configuration.\nCheck GRUB_DISABLE_OS_PROBER documentation
entry.")"
exit 0
fi

grub_warn "$(gettext_printf "os-prober will be executed to
detect other bootable partitions.\nIts output will be used
to detect bootable binaries on them and create new boot
entries.")"

OSPROBED="`os-prober | tr ' ' '^' | paste -s -d ' '`"
if [ -z "${OSPROBED}" ] ; then
# empty os-prober output, nothing doing
exit 0
fi

I dunno if this INFO could help to understand the situation

Tnx again

>
>
> grub-install --recheck /dev/sda tells grub to install the boot loader
> to be used in sda's mbr.
>
> grub2-set-default xxx will set what selection is to be the default boot.
>
> Commands given may be specific to my linux install
> $ cat /etc/release
> Mageia release 9 (Cauldron) for x86_64
>
> If commands do not work you will need to get actual grub commands.
> Search engine will get you to a grub manual.