2 2

[alpine-devel] using x86 apkovl on x86_64 and vice versa

Natanael Copa
Details
Message ID
<20140106171817.0ebe90e3@ncopa-desktop.alpinelinux.org>
Sender timestamp
1389025097
DKIM signature
missing
Download raw message
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
---
Details
Message ID
<a9a70d8acfde74e6dd3da202aba27d74@qcslink.com>
In-Reply-To
<20140106171817.0ebe90e3@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1389390490
DKIM signature
missing
Download raw message
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
---
Natanael Copa
Details
Message ID
<20140112211118.425e14e5@ncopa-desktop.alpinelinux.org>
In-Reply-To
<a9a70d8acfde74e6dd3da202aba27d74@qcslink.com> (view parent)
Sender timestamp
1389557478
DKIM signature
missing
Download raw message
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
---