Unable to upgrade from v4.7.4 to v4.7.5 #7214

kekkers23 · 2019-07-01T12:31:36Z

Expected Behavior (or desired behavior if a feature request)

Upgrade to v4.7.5

Actual Behavior

Fails without a noticeable error message, possibly one of the messages in the laravel log or upgrade log is indicating what the issue is. I have tried clearing cache using different commands from exisitng supprot threads however I believe there is an issue with my system causing this issue.

Not running SELinux as far as I am aware and ran command as sudo -u snipeit php upgrade.php where snipeit:www-data has file ownership/permissions.

Please confirm you have done the following before posting your bug report:

[ yes] I have enabled debug mode
[ yes] I have read checked the Common Issues page

Provide answers to these questions:

Is this a fresh install or an upgrade? Upgrade
Version of Snipe-IT you're running v4.7.4
Version of PHP you're running PHP 7.2.19
Version of MySQL/MariaDB you're running MySQl 5.7.26
What OS and web server you're running Snipe-IT on Ubuntu 18.04.01
What method you used to install Snipe-IT (install.sh, manual installation, docker, etc) git/composer
WITH DEBUG TURNED ON, if you're getting an error in your browser, include that error
What specific Snipe-IT page you're on, and what specific element you're interacting with to trigger the error
If a stacktrace is provided in the error, include that too.
Any errors that appear in your browser's error console.
Confirm whether the error is reproducible on the demo: https://snipeitapp.com/demo.
Include any additional information you can find in storage/logs and your webserver's logs.
https://pastebin.com/JcKb1hMr (removed email and changed to [email protected])
Include what you've done so far in the installation, and if you got any error messages along the way.
https://pastebin.com/5picEAjL
Indicate whether or not you've manually edited any data directly in the database Not touched

Please do not post an issue without answering the related questions above. If you have opened a different issue and already answered these questions, answer them again, once for every ticket. It will be next to impossible for us to help you.

https://snipe-it.readme.io/docs/getting-help

The text was updated successfully, but these errors were encountered:

kekkers23 · 2019-07-02T16:07:45Z

Let me know if anything further is required

neudodo · 2019-07-04T07:10:45Z

this is my problem too.
Maybe the problem...
Fixed #7164, #7145 - change table name to permission_groups

kekkers23 · 2019-07-09T09:40:31Z

this is my problem too.
Maybe the problem...
Fixed #7164, #7145 - change table name to permission_groups

I tried this but I just get an error stating that it is missing the groups table

davidmatthews85 · 2019-07-09T14:42:58Z

Same issue as above with my other vm test box on same spec - it bricked Snipe. Ended up firing up a new test VM but on php7.1 and Ubuntu 16.04 and appears fine so far.

neudodo · 2019-07-09T16:18:33Z

I use docker container i hope will be solution

kekkers23 · 2019-07-10T09:10:54Z

Hoping @snipe will take a look at this one

kekkers23 · 2019-07-15T09:50:28Z

Issue still on going

davidmatthews85 · 2019-07-18T08:13:57Z

Just had another look at my old test vm: it was related to tables already existing: I used php artisan migrate and was complaining about various tables in the database which had to dropped one by one within mysql and once done that sorted the issue and was able to access the asset manager :)

kekkers23 · 2019-07-19T09:02:47Z

Just had another look at my old test vm: it was related to tables already existing: I used php artisan migrate and was complaining about various tables in the database which had to dropped one by one within mysql and once done that sorted the issue and was able to access the asset manager :)

Thanks for your input however I did try this, and again since your comment with nothing to migrate. I believe something else is wrong in either a package dependency or permission etc.

kekkers23 · 2019-07-23T08:27:50Z

Still ongoing

kekkers23 · 2019-07-30T11:09:52Z

Weekly update, no further progress made @snipe any help here would be appreciated

kekkers23 · 2019-08-07T12:55:02Z

Another update, still ongoing issue - any support would be helpful @snipe

davidmatthews85 · 2019-08-12T14:50:26Z

I've just noticed today that there was an 4.7.6 release at backend of July and it wouldn't update with the www-data owner permissions set but worked fine with my local user account

kekkers23 · 2019-08-15T09:48:53Z

I've just noticed today that there was an 4.7.6 release at backend of July and it wouldn't update with the www-data owner permissions set but worked fine with my local user account

Hey thanks for letting me know, unfortunately still the same issue - tried migrating etc with no change.

snipe · 2019-08-15T10:01:24Z

I believe something else is wrong in either a package dependency or permission etc.

This isn't true - we have thousands of customers who were upgraded to latest without issue.

The area of code that affects according to your stack trace is here:

snipe-it/app/Http/Controllers/Api/AssetsController.php

Lines 614 to 620 in 124b249

    
           } elseif (request('checkout_to_type')=='user') { 
        
               // Fetch the target and set the asset's new location_id 
        
               $target = User::find(request('assigned_user')); 
        
               $asset->location_id = ($target) ? $target->location_id : ''; 
        
               $error_payload['target_id'] = $request->input('assigned_user'); 
        
               $error_payload['target_type'] = 'user'; 
        
           }

[2019-06-26 15:25:00] production.ERROR: Property [location_id] does not exist on this collection instance. {"userId":1,"email":"[email protected]","exception":"[object] (Exception(code: 0): Property [location_id] does not exist on this collection instance. at /var/www/snipeit/vendor/laravel/framework/src/Illuminate/Support/Collection.php:1793)
[stacktrace]
#0 /var/www/snipeit/app/Http/Controllers/Api/AssetsController.php(617): Illuminate\\Support\\Collection->__get('location_id')
#1 [internal function]: App\\Http\\Controllers\\Api\\AssetsController->checkout(Object(App\\Http\\Requests\\AssetCheckoutRequest), '126')

That output from your upgrade definitely doesn't look right. You shouldn't be seeing all of those M files, which implies your files have been modified locally on your machine outside of git:

Git is installed.
-- -- M .all-contributorsrc
M   .dockerignore
M   .env.example
M   .env.testing
M   .env.testing-ci

(etc)

You can try running:

git stash
git fetch
git checkout master
git pull
composer install --no-dev
php artisan migrate
php artisan cache:clear
php artisan view:clear
composer dump-autoload

kekkers23 · 2019-08-15T15:17:23Z

I believe something else is wrong in either a package dependency or permission etc.

This isn't true - we have thousands of customers who were upgraded to latest without issue.

The area of code that affects according to your stack trace is here:

snipe-it/app/Http/Controllers/Api/AssetsController.php

Lines 614 to 620 in 124b249

} elseif (request('checkout_to_type')=='user') {

// Fetch the target and set the asset's new location_id

$target = User::find(request('assigned_user'));

$asset->location_id = ($target) ? $target->location_id : '';

$error_payload['target_id'] = $request->input('assigned_user');

$error_payload['target_type'] = 'user';

}
[2019-06-26 15:25:00] production.ERROR: Property [location_id] does not exist on this collection instance. {"userId":1,"email":"[email protected]","exception":"[object] (Exception(code: 0): Property [location_id] does not exist on this collection instance. at /var/www/snipeit/vendor/laravel/framework/src/Illuminate/Support/Collection.php:1793)
[stacktrace]
#0 /var/www/snipeit/app/Http/Controllers/Api/AssetsController.php(617): Illuminate\\Support\\Collection->__get('location_id')
#1 [internal function]: App\\Http\\Controllers\\Api\\AssetsController->checkout(Object(App\\Http\\Requests\\AssetCheckoutRequest), '126')
That output from your upgrade definitely doesn't look right. You shouldn't be seeing all of those M files, which implies your files have been modified locally on your machine outside of git:
Git is installed.
-- -- M .all-contributorsrc
M   .dockerignore
M   .env.example
M   .env.testing
M   .env.testing-ci
(etc)

You can try running:
git stash
git fetch
git checkout master
git pull
composer install --no-dev
php artisan migrate
php artisan cache:clear
php artisan view:clear
composer dump-autoload

Hi snipe thank you for responding its really appreciated. I was referring to something being incorrect with one of my packages/dependencies not your app.

I ran through the commands you mentioned where git stash asked for a user which it then asked for another operator to be added onto the command. No change in version, I then re-ran the php upgrade where it looks to have the same output.

Can you best advise how we can proceed - I can provide any additional information required.

davidmatthews85 · 2019-08-15T20:56:25Z

I'd personally get a backup of your data from within snipe and create a new vm/system it's the easiest way to resolve the issue

…

On Thu, 15 Aug 2019, 16:17 kekkers23, ***@***.***> wrote: I believe something else is wrong in either a package dependency or permission etc. This isn't true - we have thousands of customers who were upgraded to latest without issue. The area of code that affects according to your stack trace is here: https://github.com/snipe/snipe-it/blob/124b249df4b521944c0c34c1c50414aaa6f5c4cf/app/Http/Controllers/Api/AssetsController.php#L614-L620 [2019-06-26 15:25:00] production.ERROR: Property [location_id] does not exist on this collection instance. ***@***.***","exception":"[object] (Exception(code: 0): Property [location_id] does not exist on this collection instance. at /var/www/snipeit/vendor/laravel/framework/src/Illuminate/Support/Collection.php:1793) [stacktrace] #0 /var/www/snipeit/app/Http/Controllers/Api/AssetsController.php(617): Illuminate\\Support\\Collection->__get('location_id') #1 [internal function]: App\\Http\\Controllers\\Api\\AssetsController->checkout(Object(App\\Http\\Requests\\AssetCheckoutRequest), '126') That output from your upgrade definitely doesn't look right. You shouldn't be seeing all of those M files, which implies your files have been modified locally on your machine outside of git: Git is installed. -- -- M .all-contributorsrc M .dockerignore M .env.example M .env.testing M .env.testing-ci (etc) You can try running: git stash git fetch git checkout master git pull composer install --no-dev php artisan migrate php artisan cache:clear php artisan view:clear composer dump-autoload Hi snipe thank you for responding its really appreciated. I was referring to something being incorrect with one of my packages/dependencies not your app. I ran through the commands you mentioned where git stash asked for a user which it then asked for another operator to be added onto the command. No change in version, I then re-ran the php upgrade where it looks to have the same output. Can you best advise how we can proceed - I can provide any additional information required. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7214?email_source=notifications&email_token=AJRUMM5FXQUBVWPMEAPAW63QEVXRJA5CNFSM4H4R5EY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4MDDKY#issuecomment-521679275>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJRUMM2GYEJ7IXUAAOQMEHLQEVXRJANCNFSM4H4R5EYQ> .

kekkers23 · 2019-08-16T10:56:25Z

I'd personally get a backup of your data from within snipe and create a new vm/system it's the easiest way to resolve the issue

Thats maybe the next best option, I have done this already when I initially installed it with sudo then re-installed securely. However, all of the guides online install this as sudo so I was struggling a little bit to get things going correctly. I know the snipeIT docs are fairly fleshed out however they only cover the snipeIT side of things for the most part which I understand.

If you know of a good resource which details a secure install of SnipeIT I'd be happy to migrate things across to a new VM - better to resolve this sooner than later.

stale · 2019-10-15T13:43:27Z

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

stale · 2019-10-22T14:28:58Z

This issue has been automatically closed because it has not had recent activity. If you believe this is still an issue, please confirm that this issue is still happening in the most recent version of Snipe-IT and reply to this thread to re-open it.

stale bot added the stale label Oct 15, 2019

stale bot closed this as completed Oct 22, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unable to upgrade from v4.7.4 to v4.7.5 #7214

Unable to upgrade from v4.7.4 to v4.7.5 #7214

kekkers23 commented Jul 1, 2019 •

edited

Loading

kekkers23 commented Jul 2, 2019

neudodo commented Jul 4, 2019 •

edited

Loading

kekkers23 commented Jul 9, 2019

davidmatthews85 commented Jul 9, 2019

neudodo commented Jul 9, 2019

kekkers23 commented Jul 10, 2019

kekkers23 commented Jul 15, 2019

davidmatthews85 commented Jul 18, 2019

kekkers23 commented Jul 19, 2019

kekkers23 commented Jul 23, 2019

kekkers23 commented Jul 30, 2019

kekkers23 commented Aug 7, 2019

davidmatthews85 commented Aug 12, 2019

kekkers23 commented Aug 15, 2019

snipe commented Aug 15, 2019 •

edited

Loading

kekkers23 commented Aug 15, 2019

davidmatthews85 commented Aug 15, 2019 via email

kekkers23 commented Aug 16, 2019 •

edited

Loading

stale bot commented Oct 15, 2019

stale bot commented Oct 22, 2019

Unable to upgrade from v4.7.4 to v4.7.5 #7214

Unable to upgrade from v4.7.4 to v4.7.5 #7214

Comments

kekkers23 commented Jul 1, 2019 • edited Loading

Expected Behavior (or desired behavior if a feature request)

Actual Behavior

Please confirm you have done the following before posting your bug report:

Provide answers to these questions:

kekkers23 commented Jul 2, 2019

neudodo commented Jul 4, 2019 • edited Loading

kekkers23 commented Jul 9, 2019

davidmatthews85 commented Jul 9, 2019

neudodo commented Jul 9, 2019

kekkers23 commented Jul 10, 2019

kekkers23 commented Jul 15, 2019

davidmatthews85 commented Jul 18, 2019

kekkers23 commented Jul 19, 2019

kekkers23 commented Jul 23, 2019

kekkers23 commented Jul 30, 2019

kekkers23 commented Aug 7, 2019

davidmatthews85 commented Aug 12, 2019

kekkers23 commented Aug 15, 2019

snipe commented Aug 15, 2019 • edited Loading

kekkers23 commented Aug 15, 2019

davidmatthews85 commented Aug 15, 2019 via email

kekkers23 commented Aug 16, 2019 • edited Loading

stale bot commented Oct 15, 2019

stale bot commented Oct 22, 2019

kekkers23 commented Jul 1, 2019 •

edited

Loading

neudodo commented Jul 4, 2019 •

edited

Loading

snipe commented Aug 15, 2019 •

edited

Loading

kekkers23 commented Aug 16, 2019 •

edited

Loading