Hi,
This is basically http://bugs.alpinelinux.org/issues/2529
Problem: if generated an apkovl on x86, copy that apkovl to x86_64, it
will fail to boot. It might be handy to convert a 32bit system to
64bit. (or to arm when that is possible)
I can see 2 possible options:
1) It just happens automatic.
the init script detects the mismatch and silently just fixes it for
user.
benefits:
* things just works. just copy the apkovl and reboot. job done.
drawbacks:
* it might be unintentional. If user intended to upgrade a 64bit
install to a new 64bit but by mistake did it 32 bit, the mistake
will be discovered late, if all. (the production system fails
weeks later due to out of memory even if you had 16GB ram...)
2) Display error message and fail if config arch mismatch unless boot
option given. If use wants switch architecture he will need explicit
give a boot option (maybe update_apk_arch?) and the arch will be
updated automatically. The error message could tell about the boot
option.
benefits:
* Alpine don't try to be smart. User is in full control.
* we fail early in case the change was unintentional.
drawbacks:
* User might be doing remote upgrade and might not have access to
boot console. So user need remember to manually edit the
syslinux.cfg to not lose the remote box - and edit it back after
reboot.
Both are equally easy to implement.
I am in favor of option #2 (I like the don't-try-to-be-too-smart way of
think)
Keep in mind that even it unlikely, there might be some apps that have
arch specific configuration.
What do you think?
Are there other things I might have missed?
Thanks!
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On 2014-01-06 10:18, Natanael Copa wrote:
> Hi,> > This is basically http://bugs.alpinelinux.org/issues/2529>
Looks like issue 2529 is now closed. Which option did you choose?
-elactrum
> Problem: if generated an apkovl on x86, copy that apkovl to x86_64, it> will fail to boot. It might be handy to convert a 32bit system to> 64bit. (or to arm when that is possible)> > I can see 2 possible options:> > 1) It just happens automatic.> the init script detects the mismatch and silently just fixes it for> user.> > benefits:> * things just works. just copy the apkovl and reboot. job done.> > drawbacks:> * it might be unintentional. If user intended to upgrade a 64bit> install to a new 64bit but by mistake did it 32 bit, the mistake> will be discovered late, if all. (the production system fails> weeks later due to out of memory even if you had 16GB ram...)> > > 2) Display error message and fail if config arch mismatch unless boot> option given. If use wants switch architecture he will need > explicit> give a boot option (maybe update_apk_arch?) and the arch will be> updated automatically. The error message could tell about the boot> option.> > benefits:> * Alpine don't try to be smart. User is in full control.> > * we fail early in case the change was unintentional.> > drawbacks:> * User might be doing remote upgrade and might not have access to> boot console. So user need remember to manually edit the> syslinux.cfg to not lose the remote box - and edit it back after> reboot.> > > Both are equally easy to implement.> I am in favor of option #2 (I like the don't-try-to-be-too-smart way > of> think)> > Keep in mind that even it unlikely, there might be some apps that have> arch specific configuration.> > What do you think?> > Are there other things I might have missed?> > Thanks!> > > ---> Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org> Help: alpine-devel+help@lists.alpinelinux.org> ---
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Fri, 10 Jan 2014 15:48:10 -0600
elactrum@jamailca.com wrote:
> On 2014-01-06 10:18, Natanael Copa wrote:> > Hi,> > > > This is basically http://bugs.alpinelinux.org/issues/2529> > > > Looks like issue 2529 is now closed. Which option did you choose?
I ended up with option 1.
> -elactrum> > > Problem: if generated an apkovl on x86, copy that apkovl to x86_64, it> > will fail to boot. It might be handy to convert a 32bit system to> > 64bit. (or to arm when that is possible)> > > > I can see 2 possible options:> > > > 1) It just happens automatic.> > the init script detects the mismatch and silently just fixes it for> > user.> > > > benefits:> > * things just works. just copy the apkovl and reboot. job done.> > > > drawbacks:> > * it might be unintentional. If user intended to upgrade a 64bit> > install to a new 64bit but by mistake did it 32 bit, the mistake> > will be discovered late, if all. (the production system fails> > weeks later due to out of memory even if you had 16GB ram...)> > > > > > 2) Display error message and fail if config arch mismatch unless boot> > option given. If use wants switch architecture he will need > > explicit> > give a boot option (maybe update_apk_arch?) and the arch will be> > updated automatically. The error message could tell about the boot> > option.> > > > benefits:> > * Alpine don't try to be smart. User is in full control.> > > > * we fail early in case the change was unintentional.> > > > drawbacks:> > * User might be doing remote upgrade and might not have access to> > boot console. So user need remember to manually edit the> > syslinux.cfg to not lose the remote box - and edit it back after> > reboot.> > > > > > Both are equally easy to implement.> > I am in favor of option #2 (I like the don't-try-to-be-too-smart way > > of> > think)> > > > Keep in mind that even it unlikely, there might be some apps that have> > arch specific configuration.> > > > What do you think?> > > > Are there other things I might have missed?> > > > Thanks!> > > > > > ---> > Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org> > Help: alpine-devel+help@lists.alpinelinux.org> > ---> > > ---> Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org> Help: alpine-devel+help@lists.alpinelinux.org> --->
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---