TRIOS Installer -- shiny new v7.0.7 ( not late at all )...

[filip]

^ You say you do not see this on the Trios side right?  What distro level are they?

My thinking is this could be a SID issue ..

Jessie.

@SID:

Possibly...
I have a feeling it's one of those dumbest ass things that on the "outside" appear perfectly normal and fine, yet silently casue issues and a major pain to detect. 
And when you finally find it, you go like "I don't wanna live on this planet anymore"... 

Anyhow, as they say, it's just a matter of time....
Will post progress updates as they come. 

[VastOne]

Be aware that on the latest SID updates (and on VSIDO installs with the new ISO) there is a delay of about 20 seconds and then a message

Code: [Select]

gave up waiting on suspend/resume device
and then it boots normally

Not sure where the message even comes from as it is immediate .. possibly initramfs update but I am not sure

It is not causing any issues other than a blank 20 second delay.. strange one I have never seen before

Does NOT happen boot of ISO to LiveCD, only after installed..

It could also be an SSD issue since that is what I am running on

[filip]

Be aware that on the latest SID updates (and on VSIDO installs with the new ISO) there is a delay of about 20 seconds and then a message

Code: [Select]

gave up waiting on suspend/resume device
and then it boots normally

Not sure where the message even comes from as it is immediate .. possibly initramfs update but I am not sure

It is not causing any issues other than a blank 20 second delay.. strange one I have never seen before

Does NOT happen boot of ISO to LiveCD, only after installed..

It could also be an SSD issue since that is what I am running on

Try this:

1. Reboot
2. Remove "resume=/dev/sdxy" from kernel cmdline ( press "e" when grub shows, then find it on the "linux" line and remove ) & hit F10 to boot.

If the error goes away, and you haven't formated/deleted/moved the swap partition, then it's likely some systemd bustage ( though changelog doesn't indicate anything related ).

When you hibernate your machine, RAM content is dumped onto the swap partition for a persistent storage. Then, when you turn back on, "resume=/dev/sdxy" line is used to point the kernel to that partition as the resume device containing the previous state.

So, if you're not using hibernation, it's safe to remove the same line from "GRUB_CMDLINE_LINUX_DEFAULT" in "/etc/default/grub" file, and then run "update-grub", however do keep in mind that if you ever hibernate the machine, it will NOT resume into previous state, but boot normaly instead!
Otherwise if you moved your swap, correct the "/dev/sdxy" in the same file & update-grub.

[VastOne]

I do not have that on any line, I do not use swap and never ever have used hibernation even when I do use a laptop

This has also started to happen on this my build machine that is also completely up to SID levels..

This is nothing new in SID, just a hiccup that is only a concern if someone boots VSIDO on a new install and does not wait the 20 seconds on the boot and gets frustrated..

Cheers

[VastOne]

@filip

I saw your cofi89 questions on the VSIDO IRC.. I do not always cover that anymore.. Simply, I have been selfless forever and it has gotten me nowhere

To answer your question I did solve the network issue on V-Box with a tweak to a refracta file used in building the ISO

Thanks
 

[filip]

I do not have that on any line, I do not use swap and never ever have used hibernation even when I do use a laptop

This has also started to happen on this my build machine that is also completely up to SID levels..

This is nothing new in SID, just a hiccup that is only a concern if someone boots VSIDO on a new install and does not wait the 20 seconds on the boot and gets frustrated..

Cheers

Yeah, it's some update ( possibly systemd ) related then.

... I do not always cover that anymore.. Simply, I have been selfless forever and it has gotten me nowhere

No problem!
I know that feeling... 

To answer your question I did solve the network issue on V-Box with a tweak to a refracta file used in building the ISO

Great, thanks! 

[hakerdefo]

@filip Great work on the installer 
Keep it up 

Cheers!!!

[filip]

@filip Great work on the installer 
Keep it up 

Cheers!!!

Thank you! 


@VastOne:

The "resume device" hang propagated to Stretch as well. And for once it actually has nothing to do with systemd.
You were right, issue was introduced in "initramfs-tools", v128 in order to fix the bug where some NVMe drives were slow to enumerate partitions causing the system to fail to resume from hibernation...

See changelog and a bug report.

The weird part is the wait time they've set ( ~20sec ). I mean what for, seriously!? Even the guy who reported the bug said that adding a 1sec delay fixed the issue for him... 

Anyway, until they sort it out, the quick fix is to add the "resume=/dev/sdXY" to the "GRUB_CMDLINE_LINUX_DEFAULT" in "/etc/default/grub" file, where "/dev/sdXY" is your swap partition ( worked for me atleast @Stretch ). 
You might even get away with any partition ( not just swap ), as long as you don't have any data on it ( untested!!! ).


EDIT:

I've also looked at the actuall shell scripts used, however I'm having a bit of a hard time reading them ( I've never really understood why Debianers always write shell scripts in such obfuscated and "hard to read" way  ).
I'll let you know If I get anywhere with that...