The installers offers to turn off LVM (which I'm fairly sure isn't there) and then says I have to reboot to have the kernel recognize the new config. I rebooted all both existing installs, just to be sure.....than try again with same "problem".
Chosing "no" as in don't turn off LVM (twice) the installer continues as it should but didn't ask for which elive to upgrade.
Checking in /var/log/syslog showed a kernel error but I don't remember exactly what.
Of course, it's the only one 3.0.6 has.
No, harm never was a USER, it was a directory (the first alphabetically) in /home that I used as backup.
Nope, wrong passwords i.e I never got to log in as "Elive user". EDIT
I retract that. There was a second "Elive user" that did have the correct password for "triantares".
This was a 3rd party program that brought along it's own installer and installed in /opt.
It's a program to report ship movements, here's the site: https://www.bics.nl/?q=en/node/100000047
No, there never was an old e16 conf.I have never logged out of e17 on that machine. In Vbox it actually freezes when I try to logout.
Menu generation most certainly failed, I tried regeneration with no success.
That's bullshit.
No one, I repeat no-one keeps a comprehensive list of what's installed (and has to be kept) over so many years. That's like saying: "Do a selective backup!" There's always something forgotten.
Except that it isn't a 64bit version of what it was supposed to be and utterly unworkable.
I've got the old 3.0.6 clone running in Virtualbox (that was quite a hassle too but off topic here) on 3.7.4 on my Carbon X1 ....... So my 1 Tb disk is getting well filled.
Running "stable" in "testing Alpha" ..... Hows that for good measure.
EDIT
Logging in to e22 (enlightenment) gives a flashing screen and makes it unable to logout. Had to disable auto-login to get out of that one. Luckily I don't have eplipsy.
It usually is hence my habit of keeping a seperate /home partition.
That's why most distros like Ubuntu have done away with upgrading. It actually isn't a solution just a show as to how far they are willing to [not] go for their userbase.
Still, this is for the sake of testing not for security.
yeah thats because the disks looked "locked" and asked to deactivate a -possible- lvm, but it should not say that they are locked in a first time (because they aren't, or they are?), and this is where the problem is
the username and "user name" are two different things, see:
so by default it always was "Elive User" (instead of John Smith, or whatever name you set in your new user creation)
you can see from this file the list of users and their "name of user" for these usernames
I checked the installer and if you selected the "smart mode upgrade" it should respect everything you have on /opt
maybe your install adds files in /etc or /usr/bin too, but your /opt should remain untouched
hum, definitively this screenshot looks like the very old .e16 confs shipped in previous elive versions, you may have not noticed it but you had it
just remove entirely the dir and it will be created a new one
but i wonder why it was not removed automatically by the installer... will need to check that
me (and i have a BIG list, i can tell you)
because is the only way to do it
if you install yourself packages on the system, a lot of dependencies are installed, there's not possible to make a reliable list of "compare which more packages has been installed after the normal system", also, there's different packages and packagenames among OS versions, so again, there's not a reliable way to do it
the only reliable way to do it, is from an own added list, let's say you always want to have thunderbird, just add thunderbird on the list and it will be always reinstalled (with the new dependencies and stuff, because its main package could depend on other ones)
in other words, that's a feature, and is not possilble to make it better (the other option is to not have the feature at all)
makes no sense, every "32bit" thing is changed to "64bit" with the new system, the entire system is overwrited (except your users, your confs, and your own installed apps), in the last one, should still compatible since you can run 32 bit things on this 64bit system. So the change from 32bit to 64bit should always work without problems, there's no problem for not
even from 64bit to 32bit migration (except for your own installed 64bit apps on this case, but very few people does that and should directly know/understand why they not run)
Ya, hmhmmm....
But after reading the latest upgrade experience
from @Thanatermesis,
....
I doubt that it is worth the efforts -
look -
all these outdated apps on 306 and then the shift-up to the new depencies, 64 Bit support
and so on, ect bla blahaaa...
Even an average user will imagine,
that this step is too big for being flawless
and will not lead to a well working system at once -
and therefore he will prefer a Backup of data and settings, e.g. with 'Aptik' (my preference, btw),
and will initiate a Clean install.
Am still talking about 32bit upgrading to 64 bit,
Just for that we are talking about the same here...
Oh yes, /opt was untouched. Everything was still there but all the other stuff that were installed elsewhere were gone.
There is some difference to .e16 and .e16.old but not much. removing it is worth a try.
Done that. It does regenerate a new (better menu) but that's about it.
No background/wallpaper, no dock ..... here's a screenshot"
Regenerating the desktop does the trick after that.
That's a mighty big except IMHO.
I personally think it is not advisable for x32 versions to upgrade to x64 and expect a comparable system.
In theory, what you say is correct ...... but the stupid gimp versus mypaint discord is exemplary for what can go wrong.
All in all it only creates the same system you would've had if you did a fresh install and kept your /home separate.....well maybe the /opt retainment is a boon.
Much ado about nothing IMO.
Of course, I would have been very surprised if it had run without problems.
Did you see my edit that it is now impossible to log into e17?
It only flashes now disabling any logout, too.
Had to disable autologin for that.
Here, tying again on the Dell M6700, still no progress at running nvidia drivers...
It seems that my nvidia card can be driven by the current or legacy 390 private drivers, so I test both... In fact I think that the only option I didn't try is the 340 one that is far old for the M5000M...
The M5000M comes from a HP, but has the same vbios number as the Dell one...
Tried from boot at the private drivers line, and from the 1st line "Live..." and Terminology...
so like said, its possible to respect /srv, /opt, and /usr/local, but not /usr or /etc since they are part of the system which -needs- to be overwrited by the new one
so if the package / software you install is entirely in /opt (or /usr/local, which is more standard) it will just work
hum... this looks very strange, are you sure you are in 3.7.4 ? lol
i mean, your new setup doesn't looks like it is, something is wrong somewhere, or you are not in 3.7.4 or your /etc used is the old one
that's another unrelated thing, this issue is related to "debian buster" but has no relation with elive or the previous 3.0 version, its a dependency problems, the entire system is made from packages and well, debian maintainers doesn't looks like to care much about that like you said, so elive would need to fix it by itself probably (but in the future, after the buster release at least)
and no relation with 32->64 bit too
i dont understand what you mean
"the same system" should eventually be "don't upgrade, just still use 3.0", this is the "same" system
so an upgraded system changes everything
now:
a clean install is a new install without your old users, nor its configurations nor its files, nothing...
the upgrade mode saves (recyclates) as much as possible things, in most of the cases, you end having your system like before but upgraded, some few confs are updated but most of them not (everything in as much as possible)
just like the migration mode, changes entirely your ubuntu system to a debian one, saving the users, its confs, passwords, files, downloads, etc..
if you "make install" and its installed in /usr/local it should work, /opt is less standard and requires things in /usr or /etc sometimes
and, if you install things from your own user, then you should not have problems at all (99% of times), just like you install things on user from those shared hostings (everything installed in the home of the user), this is in fact a more reliable and correct way than using /usr/local or /opt, not system-wide but "for the user"
not sure, but if you are in 3.7.4, the e17 is not usable, so why to worry about e17 ? lol, yeah i know, e17 is nice and more featured, but is not avialable on 3.7.x alphas
or just change it to autologin in e16, but you have a strange issue in e16 (i would need to test it all in a vbox to see what happpens here)
I could create an .ova for you but that would be at least around 20G in size.
I'm not really worried but reflecting how a user might react to a messed up install.
I agree that practically the whole 32bit system has morphed into 64bit from a tech point of view and quite a feat in itself, but ...... a normal user would have some trouble in recognizing his previous system, at the least.
Coming from 3.0 where there never was an option to login to e16 (only "default Xsession"', "elive launcher" and "enlightenment") it will be quite a nasty experience if that user has autologin enabled (it should IMO by default be disabled in a migration case) and only gets a flashing desktop (could old ecomorph settings be to blame here?) and nowhere to go from there.
Like I said before: Normally I would install the newer system over the old one and keep the separate /home partition untouched. ... Create a new user (or change the home directory name of the old user) and slowly migrate old settings over to the new "home", after first checking what using the old "home" does (I'm an optimist at heart ).
Those would be programs I installed myself using source code and I'd know what to expect (usually I'd make a .deb too but they would be 32bit)
The BICS program I had, was a different thing as it runs an own small mysql server as well as hosting a web page locally that allows preformatted e-mail to be sent to their server.
It uses java quite extensively and sets itself up as a service....which I always turned off manualy as it keeps pinging 8.8.8.8 to see if the connection is up.
I suspect there are only 2 or 3 other inland-skippers that use Linux so it was actually quite a fight with them to get another supported linux version newer than RH 5.1 which was what the installer advised initially.
On a side note:
Methinks that if the installer sees an existing "jre" in the old system, it should automatically set it up in the new system too.
It usually isn't installed "just for the fun" but with a function/dependency in mind.
Printer is recognized immediately and gets configured by the system .....Good!
The scanner is not seen i.e "elive-health" is not invoked.
Running "simple-scan" just opens a pop-up saying to go to the Brother website for drivers ....... Bad!
Running "elive-health" manually does the trick but I suspect that any new user will be seriously baffled and indeed go to the website for the drivers.
How can this be changed? Invoke "elive-health" immediately (as its a slow beast) everytime any new printer is recognized, or would that mess up the printer itself ?
I have a minor issue with Virtualbox that it does some "video tearing" when it opens, as well as when it starts up a virtual machine on all my 3.7.4 systems.
It's very short but not as it should be none the less. (opengl?)
Cloning my existing 3.0.6 install to virtualbox (if wanted I can do HOWTO on that too) required my 3Tb backup USB3.0 disk to be used by Vbox, which it didn't at first.
I intend to put the following up in the e16 Howto (though it's more a [buster]system thingy), anybody any comments, additions or thoughts before I put it there?
HOWTO: Getting virtualbox to see and use USB3.0 devices
The current install on 3.7.4 does not have the extensions pack installed (do not mistake this for the VboxGuestAdditions).
One can download this pack from Oracle if wanted: https://www.virtualbox.org/wiki/Downloads
Be sure to take the sha256 checksums file too as you might need the number later.
Install the downloaded .deb with "dpkg" "aptitude", "debi" or "gdebi" or whatever suits your needs best but not with "api".
After which you'll need to run the following command (in the download directory, or use full PATH) as the inhouse virtualbox GUI option does not work on Linux:
"sudo VBoxManage extpack install --replace Oracle_VM_VirtualBox_Extension_Pack-6.0.8.vbox-extpack --accept-license=6d89127c7f043fa96592da96ca87ac5ee9a7afd347d788380f91b695b67d7954" (the checksum here is the correct one for now)
And, after scrolling and accepting the license, it will be installed and you can connect USB3.0 devices.
Only been running 3.7.4 for about 48 hrs - no issues with dock yet - except that if you install an App with snap, the dock cannot find it and you need to set it up manually.
well, at least here in colombia my internet is much faster in this house lol
but don't worry, I did a fast test upgrading 3.0 stable 32bit to 3.7.4 64bit and everything went fine without any problems (i just did a few improvements in the installer for update a few confs)
NOW: you had an issue with the installer where it showed that your disks were busy (asking for deactivate luks/lvm stuff, which leaded to issues), and I don't know the cause of why your disks looked like busy yet (and unable to reproduce yet)... I should look again to your logs to see if there's anything that makes some sense (specific HD structure, etc), so this can be caused when a partition is USED and unable to umount, or a SWAP one, or a cryptsetup (luks) layer mounted (not the partition but the layer, shown in /dev/mapper/)
@triantares E16 wrong desktop settings: I have seen that playing in Live mode, and I was very confused about why E16 looked like the very old settings, after to research WTF is happening (looking like e16 is not using its own conf at all), I found that by some reason Xorg was launched in multiple instanced (probably not instances but it considered it to be run as a new identifier), this means the DISPLAY variable was pointing to :3.0 instead of :0.0
this makes no sense, looks like an updated of debian introduced this issue, where xorg sockets are not cleaned up from /tmp/.X11-unix/* files (removing them solves the problem, or just reboot)
I have not researched what caused this issue, but i improved the Live tools to remove them before to run again, the issue is more serious if happens in installed mode too (which seemed like to be your case?)
So DISPLAY should be always set to :0.0 no matter what (unless you are opening extra graphical sessions for other users or hte same one), and this caused your e16 issue
Probably one of these 2 only possibilities:
disappointed / unsatisfied / bad taste / disliking to try again elive...
complaining (trolls)
no not really, the entire system changed from 32 to 64 bit (or viceversa), the only remaining files are:
user configurations
user files (mp3, videos, documents...)
own installed applications
and none of them are binary-related files, they simply works the same way in both systems, except for the "own installed applications", but very very few people does that and stills not a big problem because when trying to run it, it will simply show an error about "this app is for XXbit system" and he* will install it again (by other side there's big possibilities that will simply run 32 bit things on the new 64bit system)
But stills not a real "related" topic/problem, so in the same way if your OS system upgrades to a newer one, you could have similar issues by running it with different library versions
Well, first of all: e17 not works correctly and now i removed it from the next 3.7.5 (so no login issues should happen now). By other side is true that the user will have a different desktop entirely, but the user should already know from the download of the iso (which says e16) but also after to have run the Live mode (which is needed before to install), so the user will perfectly see that the desktop is entirely different
So in a user-experience perspective, there should be not any "surprise"
This is more or less what the installer does, but in a more "guaranteed" way:
the /home is untouched (except for a few possible confs that should be updated)
then a new user is created in the new OS, but using the same UID/GID as the old one, and same home dir etc... all the things needed to keep a full compatibility with all
same username is also needed because you can have references for user1 that will not match to user2 in the resulting systems, like some confs that has statically set the user home location to get the configs, example: .config/cairo-dock/current_theme/plug-ins/stack/stack.conf: stack dir=/home/thana/.config/cairo-dock/stack
the installer also keeps a few things untouched, like /usr/local or /opt for local installs, nginx configurations from /etc/nginx (and other few confs), where if you have a webserver configured, it should directly work after (but of course by having the nginx packages installed later, or keeped in your packages-to-maintain list, to being always automated to install)
other possilbe confs needed, like hostname or ssh OS keys
so basically it does all the job that a normal user should do by itself, ensuring that everything (possible) is correctly set up and reused
32bit deb packages are integrated on the 64bit system too, in fact, your "steam" package is only available for 32bit (wtf? lol?) and there's a wine-32bit package too in order to make wine working
mmh maybe, but is not very realiable / easy to do that, for example the name of the packages (probably) changes among OS versions, or the entire name itself... that's why having the own list is much safer (you set the name of the package, and you control also if should be installed or not). Also there's no smart way to know if is really needed or not, let's say it was an old dependency in hte older system which is not needed anymore, or the user just played installing a bunch of packages which installed it, in such case the install will be not so clean by adding extra unneeded packages, and similar way for java for any other "possibly wanted software"
it should only if you have the scanner connected (and turned-on) when booting the computer, so elive-health is run at destkop start and should have it listed from lsub (or similar commands)
unfortunately this could require a daemon or something similar to always run, elive-health is a tool that runs once and exits inmediately (not leaving it running to wait / listen for something)
Well, is not perfect but keeps the system light while adding an extra feature to auto install the scanner
yeah i know this, but its a virtualbox issues which does something strange with the window sizes / fullscreen state or similar, you can see a similar behaviour in e17 too
@triantares thanks for the extension-pack details, I was having issue installing it here too the GUI shows an error that doesn't makes much sense not allowing to add it
@triantares let me know if im missing anything to fix before to build 3.7.5, we had a long convo of betatesting for this version and im a bit lost , but i think (if im not wrong) your only issue in the end was the "partitions used" before to install (the lvm/luks umounting message stuff)
Yes, and that was on my helix2 hybrid tablet.
Maybe having swap at the beginning of the disk confused the scan?
I've had clonezilla make a copy of the (untouched) installed 3.6.4 system (/) partition which is only 7-8Gb and can do the same for the original 3.0.6 partition.
I can put them up (this weekend) for download on my home server for you if you like.....or even make you a user so you can connect (ssh no X, it's headless) remotely, if that's easier/faster.
Or I can reinstate the old sytem and let you in remotely for the install. You think the connection can handle the graphics?
As for my scanner and elive-health: It didn't activate after a new boot with scanner connected either but does after being manually invoked.
Mybe add a pop-up text widget if/when an all-in-one printer is detected (or set up) for the first time?
:
).
, but i think (if im not wrong) your only issue in the end was the "partitions used" before to install (the lvm/luks umounting message stuff)
