MV&C's picture
MV&C - Wed, 2019/02/06 - 16:00

I just launched an instance of Magento 2 from the AWS Marketplace. I used SSH to go through the initialization process. After setting passwords and a domain, I am at an error window and cant proceed any further. See attched screenshot.

 

Attached: 
Image icon Annotation 2019-02-06 085950.jpg
Forum: 
Support
Tags: 
magento
aws
awsmp
marketplace
MV&C's picture

MV&C - Wed, 2019/02/06 - 17:00

After initializing and visiting the default URL for magento in my browser I got an error message that required me to put Magento In developer mode. Once in developer mode, I see the following message in my browser:

 

InvalidArgumentException: Unable to unserialize value, string is corrupted. in /var/www/magento/lib/internal/Magento/Framework/Serialize/Serializer/Serialize.php:38 Stack trace: #0 [internal function]: Magento\Framework\Serialize\Serializer\Serialize->Magento\Framework\Serialize\Serializer\{closure}(8, 'unserialize(): ...', '/var/www/magent...', 42, Array) #1 /var/www/magento/lib/internal/Magento/Framework/Serialize/Serializer/Serialize.php(42): unserialize('\xD7\xC1\xDB\xF4\xCE\x9E\xD7>\x16\xEDxrT_\xDA...', Array) #2 /var/www/magento/lib/internal/Magento/Framework/Serialize/Serializer/Sensitive.php(61): Magento\Framework\Serialize\Serializer\Serialize->unserialize('\xD7\xC1\xDB\xF4\xCE\x9E\xD7>\x16\xEDxrT_\xDA...') #3 /var/www/magento/app/code/Magento/Config/App/Config/Type/System.php(235): Magento\Framework\Serialize\Serializer\Sensitive->unserialize('\xD7\xC1\xDB\xF4\xCE\x9E\xD7>\x16\xEDxrT_\xDA...') #4 /var/www/magento/app/code/Magento/Config/App/Config/Type/System.php(171): Magento\Config\App\Config\Type\System->loadScopeData('stores', 'default') #5 /var/www/magento/lib/internal/Magento/Framework/App/Config.php(131): Magento\Config\App\Config\Type\System->get('stores/default/...') #6 /var/www/magento/lib/internal/Magento/Framework/App/Config.php(80): Magento\Framework\App\Config->get('system', 'stores/default/...') #7 /var/www/magento/app/code/Magento/Developer/Model/Logger/Handler/Debug.php(63): Magento\Framework\App\Config->getValue('dev/debug/debug...', 'stores') #8 /var/www/magento/vendor/monolog/monolog/src/Monolog/Handler/AbstractProcessingHandler.php(29): Magento\Developer\Model\Logger\Handler\Debug->isHandling(Array) #9 /var/www/magento/vendor/monolog/monolog/src/Monolog/Logger.php(337): Monolog\Handler\AbstractProcessingHandler->handle(Array) #10 /var/www/magento/lib/internal/Magento/Framework/Logger/Monolog.php(48): Monolog\Logger->addRecord(400, 'Unable to unser...', Array) #11 /var/www/magento/vendor/monolog/monolog/src/Monolog/Logger.php(616): Magento\Framework\Logger\Monolog->addRecord(400, 'Unable to unser...', Array) #12 /var/www/magento/lib/internal/Magento/Framework/App/Bootstrap.php(262): Monolog\Logger->error('Unable to unser...') #13 /var/www/magento/index.php(39): Magento\Framework\App\Bootstrap->run(Object(Magento\Framework\App\Http\Interceptor)) #14 {main}

Jeremy Davis's picture

Jeremy Davis - Wed, 2019/02/06 - 22:13

Hi Bryan, sorry I missed this while I was researching and posting my initial response (below).

I have actually also just double checked my notes and realised that how we worked around it with the previous user who hit this, was to use the built-in Webshell to initialise the appliance. [Update: it turns out that Webshell is not required - via PuTTY is also an option - see my latest post below] I suspect that there is some work that may be required within the (initially broken) terminal to get to that point (and it appears my notes may not be as complete as I would like). Unfortunately, I don't recall the name of the user who had this issue previously, but I will search through our support portal to find the explicit steps required.

Also, another easier way to workaround this issue would be to use our TurnKey Hub. That provides a web interface for this initial setup, thus completely avoiding the need to log in via PuTTY to run the initialisation; and thus the issue you are hitting. (FWIW the character rendering issue will still exist in PuTTY, but won't be fatal to get you started).

Anyway, sorry that I haven't been as fast replying as ideal, but FWIW I'm in Australia and it has only just gone 7am. It's probably also worth noting that even via our support portal within the TurnKey Hub (link within the support section of the AWS Marketplace listing) the promised turnaround (FWIW same as the default paid AWS support - unless you pay for priority support) is one work day. You posted ~6 hours ago, so I'm smashing that! :)

Regardless, our refund guarantee is "no questions asked" so no problem at all. Assuming that you wish to proceed with the refund, please contact me via support@turnkeylinux.org and provide your AWS ID#, the email address linked to your AWS account, plus the instance type, size and region. Armed with that info, I should be able to find you within the AWS system and authorise a refund. [Update: Oops, sorry, just noticed that you posted your AWS account ID, I'll double check that's enough.]

Jeremy Davis's picture

Jeremy Davis - Thu, 2019/02/07 - 07:30

I'm unable to grant your refund and am wondering if you accidentally made a typo when posting your AWS user ID? I've sent you an email about it. Please get in touch ASAP (ideally reply to the email - or send new mail to support@turnkeylinux.org) so I can process your refund for you. Thanks.

Jeremy Davis's picture

Jeremy Davis - Wed, 2019/02/06 - 21:56

Another user has come across a similar issue relatively recently, but I was unable to reproduce it and unfortunately don't recall exactly what the workaround was. Although I'm fairly certain it was an encoding issue between the server and PuTTY and I suspect that this is the same issue you are experiencing.

Looking at your screenshot, it certainly seems to match that. Unfortunately, that has been a somewhat ongoing issue for Windows users which there isn't a consistent/easy fix that we can pre-apply (that won't break things for other users on other platforms). It is somewhat dependant on how Windows is configured and what character set it is expecting.

FWIW there are a list of possible tweaks that can be tried on this StackExchange Q&A. That thread explicitly relates to "Midnight Commander" (aka "mc"), but many of the suggestions should relate generally to PuTTY.

First up, I would suggest setting UTF-8 as the remote character set in PuTTY - as per the last part of this answer. It may also be necessary to set 'Terminal-type string' as noted in this answer. [update] It turns out that the character set you need to set is "DEC-MCS" (not UTF-8) as detailed in my post below.

It just so happens that I have a Windows 10 laptop handy at the moment (I normally don't use Windows) so will test it out on that and see if I can clarify the issue a bit better. It would be really helpful if you could please confirm the Windows locale that you are using (i.e. locations settings IIRC) and I'll have a look and check to see if I can reproduce this and confirm a workaround.

FWIW, Windows 10 now has a native OpenSSH client available. I haven't yet tested it, but I suspect that will avoid this issue (but not 100% sure)

I will post back ASAP, but if you have any further info to share such as your Windows locale and/or if either/both of those PuTTY setting tweaks work, I'd love to hear.

Jeremy Davis's picture

Jeremy Davis - Thu, 2019/02/07 - 00:40

And actually, it appears to be a bit more involved than I first thought.

I have worked out how to fix the weird line drawing and garbled output. To make it display cleanly with PuTTY, it is required to set the "Translation" to "DEC-MCS". I.e. within PuTTY; select "Window" >> "Translation" >> "Remote character set" >> "DEC-MCS" (from the dropdown options).

However, the "DIALOG_ERROR" error still occurs! :(

FWIW, there is a clunky workaround. After completing the firstboot initialisation (exiting out of the erroring screen by hitting escape twice, then "Yes" to the "Do you really want to quit?" message), the rest of the initialisation completes successfully. After doing that,from the commandline type the following:

sudo /usr/lib/inithooks/bin/magento.py --pass='MyPa$$w0rd' --email="myemail@example.com" \
     --domain="www.my-real-domain.com" --privkey=SKIP --pubkey=SKIP

Substituting "MyPa$$w0rd", for your own password, "myemail@example.com" for your real email address and "www.my-real-domain.com" for your real domain.

Please also note the single quotes around the password. This reduces the chances of some special characters (such as $) being misinterpreted. Although be aware that some special characters will still be problematic, such as single quotes and the Windows slash (aka backslash, i.e. '\'). If in doubt, select a password that only contains upper case, lower case and numbers, then update it within Magento itself.

Anyway, I'll have to dig in a little deeper. I'll post back once I have a better fix. Once I have devised a proper fix, I plan to also update the Magento appliance so it includes the fix OOTB.

Jeremy Davis's picture

Jeremy Davis - Thu, 2019/02/07 - 06:55

It turns out that the cause of this issue is because the default PuTTY screen size is too small to display all the text of the next screen that should show! I could actually reproduce it from within my Linux SSH client too by reducing the size of the window.

The simple workaround is to increase the size of the putty window (click on the bottom right corner and drag the screen larger) as soon as you start. Or alternatively, you can explicitly set it to something like 80 x 43 (default it 80 x 24) via the PuTTY "Window" config option (i.e. columns: 80 & rows: 43).

FWIW the reason why I had never hit it before is that the default size of my SSH client window is quite large. This is really good to know as in future, I will ensure to test that all the dialog windows fit properly within the default PuTTY screen size. I don't think that there are any bigger than that Magento screen, but perhaps...

I have fixed the appliance code, plus made a couple of other minor improvements (see what I've done here if you're interested). An updated appliance is currently building. Unfortunately it won't be available via the AWS Marketplace for a week or 2 (by the time our publishing process is complete and AWS update the listing), but I'm pretty pleased that I've worked out the issue and have a fix.

Apologies again on your poor experience Bryan, but thanks so much for taking the time to report it, even if you weren't happy with the response time...

Add new comment