You are not logged in.
Hi all,
Update::
...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)
miyoisomix.i2p
Offline
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.
Offline
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.
miyoisomix.i2p
Offline
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)
miyoisomix.i2p
Offline
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.
Offline
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.
Offline
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)
Offline
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
miyoisomix.i2p
Offline
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?
miyoisomix.i2p
Offline
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.)
Offline
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....
miyoisomix.i2p
Offline
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.)
Offline
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.
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)
miyoisomix.i2p
Offline
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.
Offline
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..
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.
miyoisomix.i2p
Offline
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!
miyoisomix.i2p
Offline
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!!!
I have been Devuanated, and my practice in the art of Devuanism shall continue until my Devuanization is complete. Until then, I will strive to continue in my understanding of Devuanchology, Devuanprocity, and Devuanivity.
Veni, vidi, vici vdevuaned. I came, I saw, I Devuaned.
Offline
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
miyoisomix.i2p
Offline
Is the intel-microcode package installed? That injects a binary into the initrd. I'm wondering if that could be causing the confusion.
Offline
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.
Offline
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 ~~
miyoisomix.i2p
Offline