[Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

stanz · 2019-02-21 05:34:49

Hi all,
Update::

fsmithred's fix - from post #7 wrote:

...You could add RESUME=none to initramfs.conf then run update-initramfs -u -k all

-----------
That's what I got here...Miyo-XTRA Ascii - upgraded to beowulf, started 3 days ago.
Added main contrib non-free each day to test & fix expected brake-age.
Using repo: deb.devuan.org/merged/ beowulf main

Since yesterday, just after grub screen - start of boot, I get 6-8 weird symbols (before fsck - happened on other installs.)
20 seconds later, it switches to,
Gave up waiting for suspend/resume device 'by-uuid/bla-bla-bla-bla-&bla'
5 minutes later! Changes to:

Could not stat the resume device file 'by-uuid/8ebla-bla-blaa-again-lastbla'
Please type in the full path to try again or
Press ENTER to boot the system: _

After pressing enter, flashing text scroools by as usual.

** There is NO 'device/file' in the 4 folders, in /dev/disk/ with the uuid!
** During the install procedure, I "uncheck" using "uuid" -and- "check" using "labels" for devices.
(although, swap gets a uuid.!?)
** I don't need or want uuid, I like to name my partitions/devices.

Before I do another re-install, I'd like to try to figure/fix this out.

It's been awhile... log files to check?
What script/program is doing the "uuid & suspend/resume" check?

And...is this my own issue? lol
Thx...asta

Last edited by stanz (2019-02-26 01:05:52)

fsmithred · 2019-02-21 13:55:33

There's a resume file in your initrd that has that uuid inside it. In a live session, run lsinitramfs /initrd.img | grep resume to see if it's there. That uuid should correspond to a swap partition. There's a way to avoid this when making the snapshot. It's in the readme. Starting with refractasnapshot-10.2 the script will do it for you (or ask what to do.)

If you have no swap partition, you can probably get rid of the file by running update-initramfs -u. The other way to get rid of it is to unpack the initrd, remove the file (conf/conf.d/resume) and then repack the initrd. If you need the commands for that I can post them after another cup of coffee.

stanz · 2019-02-22 03:07:48

Thx fsmithred...I never want to get inbetween of anyone - and their coffee...and this issue isn't worth it.

I re-read the readme and found your words in CREATING A SNAPSHOT FROM AN ENCRYPTED SYSTEM,
which I haven't done encryped yet, so I glanced thru that section brainlessly.
Yep, as you typed, 10.2 ** 10.2 and later versions **. I'm NOT encryped, BUT do have swap partition-
already setup, and also 'uncheck' question about 'swap file'.
Same with formatting, I done did it.
And choose 'labels', cause my memory span is short! (but swap gets uuid? and 8GB usb's?)

...the script will edit the snapshot's initrd to remove conf/conf.d/cryptroot and/or
conf/conf.d/resume so that the snapshot iso will boot successfully.

So miyo's iso I used, should not have those files -after- my install?

I ran the command: (and thank you, for adding commands - as you do!!)

~$ lsinitramfs /initrd.img | grep resume
conf/conf.d/zz-resume-auto
scripts/local-premount/resume
usr/bin/resume

and I can't view them - till I uppack `em...but your saying it still affects my installed system/bootup..?

Geez fsmithred... this sounds like my problem, I've not even read anyone asking about those symbols.

stanz · 2019-02-22 03:24:57

This will NOT affect the initrd on the host system.

That answers one of my questions, but the suspend/resume device uuid shows it might?
anyway...
Did a image upgrade early in the wee hours, from - 4.9.0-5-amd64, to 4.19.0-2-amd64 and
all delays and waiting has gone.
Will boot back to 4.9 and see if continues there.

Yep ~ still there.
Well, I'd say - someone please delete this post!

Last edited by stanz (2019-02-22 04:37:00)

fsmithred · 2019-02-22 12:05:20

The script is set to remove conf/conf.d/resume and conf/conf.d/cryptroot. Those files don't exist. They changed the name of resume to zz-resume-auto, and not relevant to your case, they moved cryptroot from conf/conf.d/ to the root of the initrd.

OK. Edit /usr/bin/refractasnapshot. Change this:

   274          if [ -f conf/conf.d/resume ] ; then
   275                  echo "Removing resume"
   276                  rm -f conf/conf.d/resume
   277          fi

To this:

   274          if [ -f conf/conf.d/zz-resume-auto ] ; then
   275                  echo "Removing resume"
   276                  rm -f conf/conf.d/zz-resume-auto
   277          fi

The line numbers might be offset by a few. In the gui version it's around lines 321-323.

Edit: Wait. See next post when it arrives. I'd like to know what's inside that file.

fsmithred · 2019-02-22 12:38:16

As ordinary user, in your home run the following commands.

mkdir extracted
cd extracted
zcat /initrd.img | cpio -i

Then look in conf/conf.d/zz-resume-auto. If you have more than one kernel, you can replace '/initrd.img' with the real paths, '/boot/initrd.img-4.whatever' (but unpack them into different directories, like extracted and extracted2 for instance.)

My beowulf has conf/conf.d/resume. I don't know why yours is different.

fsmithred · 2019-02-22 13:10:30

Go ahead and modify refractasnapshot as I indicated a couple posts above and see if it works. If you use the cli script, please add the -d option for a verbose log. If that doesn't work, you may need to do the steps listed below.

More info...

https://lists.debian.org/debian-user/20 … 00195.html

++++ BEGIN apt-listchanges: News MESSAGE ++++
initramfs-tools (0.129) unstable; urgency=medium
* Some systems that do not support suspend-to-disk (hibernation) will
require a configuration change to explicitly disable this.
From version 0.128, the boot code waits for a suspend/resume device
to appear, rather than checking just once. If the configured or
automatically selected resume device is not available at boot time,
this results in a roughly 30 second delay.
You should set the RESUME variable in
/etc/initramfs-tools/conf.d/resume or
/etc/initramfs-tools/initramfs.conf to one of:
- auto - select the resume device automatically
- none - disable use of a resume device
- UUID=<uuid> - use a specific resume device (by UUID)
- /dev/<name> - use a specific resume device (by kernel name)
-- Ben Hutchings <ben@decadent.org.uk> Thu, 20 Apr 2017 23:21:32
+0100</ben@decadent.org.uk>
++++ END apt-listchanges: News MESSAGE ++++

Hmm.. My resume file contains 'RESUME=none' but there's no RESUME variable in /etc/initramfs-tools/initramfs.conf. I guess the scripts in /usr/share/initramfs-tool/ figured it out in my system. You could add RESUME=none to initramfs.conf then run update-initramfs -u -k all and then make a new snapshot. Note that this would change the host initrd. (both of them)

stanz · 2019-02-23 00:52:55

https://lists.debian.org/debian-user/20 … 00195.html
That changes things abit.

Thx for your time with this fsmithred, as always.

I gots a 'honey-do' list in front of me today...will return asap

stanz · 2019-02-23 06:20:03

fsmithred wrote:

As ordinary user, in your home run the following commands.
mkdir extracted
cd extracted
zcat /initrd.img | cpio -i

This looks in /boot dir?

:~/extracted$ zcat /initrd.img | cpio -i

gzip: /initrd.img: not in gzip format
cpio: premature end of archive

:~/extracted$ zcat /boot/initrd.img-4.9.0-5-amd64 | cpio -i

gzip: /boot/initrd.img-4.9.0-5-amd64: not in gzip format
cpio: premature end of archive

I did run bleachbit couple times, to reduce snapshot size.

:~/extracted$ zcat /boot/initrd.img-4.19.0-2-amd64 | cpio -i

gzip: /boot/initrd.img-4.19.0-2-amd64: not in gzip format
cpio: premature end of archive

I'm gonna reinstall on other partition, and do all this before install - than after -
and before upgrading the image, then after (if thats possible?).

Then redo again with your edit to /usr/bin/refractasnapshot.

What`ta ya think?

fsmithred · 2019-02-23 16:31:36

The initrd is not in gzip format. Use this line instead:

xzcat /initrd.img | cpio -d -i -m

Yes, you can just call the initrd directly (in /boot) instead of using the symlink.

Please get refractainstaller 9.5.2 from ceres. It should be in the repo by now (or very soon.)

stanz · 2019-02-24 08:25:19

banging my head against the wall...
i got this to work on your refracta9 install and seen your RESUME=none.
i read this and a few other cpio search results, to get hint of what i'm doing here.

now I'm in the troubled system and cannot reproduce that success (3 hours now!).
maybe i'm missing a package, in this install?
i dislike pastebin - but pasted all my attempts there not to clutter here.

i'll try again in the morn`in....

fsmithred · 2019-02-24 13:58:44

I'm not sure what success you're expecting. Did you repack the initrd, and if so, what changes did you make to it? Or are you still trying to unpack it?

file /boot/initrd.img-4.19.0-2-amd64 should tell you what compression is used. Use the corresponding zcat or xzcat command above to unpack it. Tell me which compression was used and what you found inside the initrd. Possible choices of things to do would be remove the offending files, edit the offending files, maybe something else.

Maybe you're missing these?

Rebuild initrd with gzip compression:
find . -print0 | cpio -0 -H newc -o | gzip -c > ../initrd.img

Rebuild initrd with xz compression:
find . | cpio -o -H newc | xz --check=crc32 --x86 --lzma2=dict=512KiB > ../initrd.img

Then of course, you have to replace the original with your changed version. (keep a backup copy of the original and copy the modified one to /boot, and make sure the name corresponds to what your boot menu expects it to be.)

stanz · 2019-02-25 06:17:45

fsmithred post#9 wrote:

You could add RESUME=none to initramfs.conf then run update-initramfs -u -k all and then make a new snapshot. Note that this would change the host initrd. (both of them)

I finally did that, and rebooted with the 4.9.0-5-amd64, which still showed the symbols - but, with NO delay!
So I'll mark this solved, although I'm still continuing trying to unpack the initrd.

fsmithred wrote:

I'm not sure what success you're expecting.....Or are you still trying to unpack it?

Yes, those commands complain...

:~$ xzcat initrd.img | cpio -d -i -m
xzcat: initrd.img: No such file or directory
cpio: premature end of archive

and with the help of that 'file' command...

:~$ file initrd.img
	initrd.img: ASCII cpio archive (SVR4 with no CRC)

Frustrating to me, it didn't work on miyoXtra, as quick as it did on refracta9. That's why I thought
maybe you had a 'helping' package installed on your system - that is not on miyo's.??
Well, I have more research to search.
Thanks again fsmithred..

Last edited by stanz (2019-02-25 06:18:40)

fsmithred · 2019-02-25 18:26:37

No such file or directory

You're sure it's there? You didn't change directory between running xzcat and running file? Try using the full path to the real file instead of the symlink. (/boot/initrd.img-<version>)

BTW, it's better if you don't have the initrd inside the directory where you extract it. You don't want it to end up inside the new initrd when you repack it.

stanz · 2019-02-25 23:56:21

fsmithred, post #2 wrote:

There's a resume file in your initrd that has that uuid inside it. In a live session, run lsinitramfs /initrd.img | grep resume to see if it's there.

I'm working in miyo's live session now...
/boot/initrd.img-4.9.0-5-amd64
All ran as regular user...

miyo@miyolinux:~$ lsinitramfs /initrd.img | grep resume
scripts/local-premount/resume
bin/resume

We don't have here, the conf/conf.d/zz-resume-auto, that showed up in the updated (delayed) install.

To answer..

fsmithred, same post wrote:

If you have no swap partition...

I always have swap partition setup before all installs.
And wonder why swap gets an 'uuid', even tho I choose 'labels'?

Then created new folder for work, :~/initrdtest$, cd into it-
Will stick with 'full path' to file...

miyo@miyolinux:~/initrdtest$ xzcat /boot/initrd.img-4.9.0-5-amd64 | cpio -d -i -m
xzcat: /boot/initrd.img-4.9.0-5-amd64: File format not recognized
cpio: premature end of archive

To check, if su might be different.

root@miyolinux:/home/miyo/initrdtest# xzcat /boot/initrd.img-4.9.0-5-amd64 | cpio -d -i -m
xzcat: /boot/initrd.img-4.9.0-5-amd64: File format not recognized
cpio: premature end of archive

Checked with:

$ file /boot/initrd.img-4.9.0-5-amd64
/boot/initrd.img-4.9.0-5-amd64: ASCII cpio archive (SVR4 with no CRC)

I'll hold off on editing /usr/bin/refractasnapshot, and upgrading to refractainstaller 9.5.2 from ceres,
till I get this "extraction/edit/repack" done...then move into snapshot & installer.

stanz · 2019-02-26 00:59:23

This is moving off topic now (?) and really has little to do with derivatives or MiyoXtra,
I suppose a new topic in "Other Issues" or "DIY", might be best...?
Documentation? I donno...somewhere!

MiyoLinux · 2019-02-26 02:12:51

Wow! Looks like I've missed a lot since I last visited! Sorry...I've been busy doing taxes, taking online classes to renew my license for my job (240 hours worth and only 1/3 of the way finished), and playing with beowulf builds as I've had the chance.

stanz, I've had those pink symbols before (I don't remember which build(s) they were on). At the time I thought it was strange, and I couldn't find anything to explain it...so I attributed it to some conspiracy brought on by the Illuminati. LOLOLOLOL!!!

I never noticed any side-effects or strange behavior, so I just chalked it up to one of the extra benefits of using Miyo. LOLOLOLOLOLOLOLOL!!!

stanz · 2019-02-26 21:52:35

Hey Miyo! Good to see your words man. kewl stuff (not taxes) keeping ya busy~
"Illuminti"...I thought that to. one kinda looks like the ace of diamonds...(whats that mean?!) lol
I haven't seen any log files reflecting anything of interest...and its before 'fsck' clears /dev ?
That messege was totally a new thing, glad fsmithred passed the fix!
I'll continue this 'unpacking initrd.img' in DIY, cause I likes to tinker
stay well...
asta

fsmithred · 2019-02-27 09:06:03

Is the intel-microcode package installed? That injects a binary into the initrd. I'm wondering if that could be causing the confusion.

ralph.ronnquist · 2019-02-27 10:45:13

If the file has an initial microcode blob before the ramdisk file system, you'll probably need two successive cpio calls to read it. And even more fun, the second part might be compressed separately, which then needs decompression into the pipeline as well.

For example: unpack first archive (microcode) and check type of second (probably gzipped).

cat /initrd.img | ( cpio -i ; file - )

Then: unpack the first archive, then the second with gunzip-ing

cat /initrd.img |  ( cpio -i ; gunzip | cpio -i )

Or if you like: unpack first, and copy second (compressed) into a file ramdisk.gz

cat /initrd.img |  ( cpio -i ; cat > ramdisk.gz )

The last one might be useful if you want to repack things manually since it lets you work out the byte size of the first archive, so you can prepend those bytes to a repacked image.

jaromil · 2019-02-27 20:27:52

wow I remember those commands but never saw them in so much elegance 8^)

stanz · 2019-02-28 07:00:37

Yes fsmithred, intel-microcode package installed...I also checked that cpio, gzip, & others were installed.
miyoxtra's lite on preinstalling abunch of packages...its good to check.
As noted above somewhere, I first successed unpacking the img file in Refracta9.

~$ file /boot/initrd.img-4.9.0-8-amd64
	/boot/initrd.img-4.9.0-8-amd64: XZ compressed data

That worked just as you typed it would, being XZ compressed data.

I then checked my 5 other installs with the same result of:

$ file /boot/initrd.img-4.9.0-5-amd64
/boot/initrd.img-4.9.0-5-amd64: ASCII cpio archive (SVR4 with no CRC)

Same result for the /boot/initrd.img-4.19.0-2-amd64.
Now that's answered -

ralph.ronnquist, thanks for your post...this is my official 1st introduction to cpio.

$ cat initrd.img-4.9.0-5-amd64 | ( cpio -i ; file - )
62 blocks
/dev/stdin: ASCII cpio archive (SVR4 with no CRC)

That unpacked a kernel folder,->x86 folder->microcode folder->AuthenticAMD.bin file.

$ cat initrd.img-4.9.0-5-amd64 |  ( cpio -i ; gunzip | cpio -i )
62 blocks

gzip: stdin: not in gzip format
cpio: premature end of archive

Again, a kernel folder, ->x86 folder->microcode folder->AuthenticAMD.bin file.
New to me, but you guys know this already.
Now on to:

$ cat initrd.img-4.9.0-5-amd64 |  ( cpio -i ; cat > ramdisk.gz )
62 blocks

$ ls
initrd.img-4.9.0-5-amd64  kernel  ramdisk.gz

I just had to try...

$ gunzip ramdisk.gz
gzip: ramdisk.gz: not in gzip format

Ol`well, it's ok to try things.

$ cat ramdisk.gz |  ( cpio -i ; gunzip | cpio -i )
3102 blocks
cpio: etc/console-setup/null: Cannot mknod: Operation not permitted
160946 blocks
$ ls
bin   etc   initrd.img-4.9.0-5-amd64  lib    ramdisk.gz  sbin     usr
conf  init  kernel                    lib64  run         scripts

That's it! wow ~ both awesome & as jaromil typed "elegance"!
Nothing left to do, but repack it all now... fsmithred post #2 was the fix - no resume file in conf/conf.d.
I think I'll do this again, on the other installs - after successful repacking of course

Oh, fsmithred - Did the info answer post #12 questions? If not let me know - I'll find `em.
Shoot, long post - I'm done for this nite!
asta ~~

The officially official Devuan Forum!

#1 2019-02-21 05:34:49

[Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#2 2019-02-21 13:55:33

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#3 2019-02-22 03:07:48

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#4 2019-02-22 03:24:57

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#5 2019-02-22 12:05:20

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#6 2019-02-22 12:38:16

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#7 2019-02-22 13:10:30

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#8 2019-02-23 00:52:55

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#9 2019-02-23 06:20:03

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#10 2019-02-23 16:31:36

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#11 2019-02-24 08:25:19

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#12 2019-02-24 13:58:44

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#13 2019-02-25 06:17:45

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#14 2019-02-25 18:26:37

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#15 2019-02-25 23:56:21

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#16 2019-02-26 00:59:23

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#17 2019-02-26 02:12:51

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#18 2019-02-26 21:52:35

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#19 2019-02-27 09:06:03

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#20 2019-02-27 10:45:13

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#21 2019-02-27 20:27:52

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

#22 2019-02-28 07:00:37

Re: [Fixed] Upgraded "Miyo-XTRA Beowulf" boot suspend/resume delay

Board footer