~alpine/devel

14 8

[alpine-devel] Alpine Linux 3.7.0 Release Candidate 1 is out

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20171123224046.0d21352b@ncopa-desktop.copa.dup.pw>
Sender timestamp
1511473246
DKIM signature
missing
Download raw message
Hi!

I am pleased to announce the first release candidate of Alpine Linux
3.7.0.

The big news is that is now support UEFI.

Would be nice to have some help with testing all the different release
variants and architectures.

Thanks!

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<7c37de0831b676c83cf1b043c905d9c3>
In-Reply-To
<20171123224046.0d21352b@ncopa-desktop.copa.dup.pw> (view parent)
Sender timestamp
1511615875
DKIM signature
missing
Download raw message
Thank you for the hard work and the release.

x9p

> Hi!
>
> I am pleased to announce the first release candidate of Alpine Linux
> 3.7.0.
>
> The big news is that is now support UEFI.
>
> Would be nice to have some help with testing all the different release
> variants and architectures.
>
> Thanks!
>
> -nc
>
>
> ---
> 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
---
Details
Message ID
<5A19D088.6040806@adelielinux.org>
In-Reply-To
<91d341bd1e7ad3cb72d75ba6f1ad9bd0> (view parent)
Sender timestamp
1511641224
DKIM signature
missing
Download raw message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/11/17 14:06, x9p wrote:
> 
> could not find the link of rc-1 to test.
> 
> cheers.
> 
> x9p

They can be found at:

https://nl.alpinelinux.org/alpine/v3.7/releases/

or your favourite Alpine mirror..

- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJaGdCFAAoJEMspy1GSK50UOqUP/jOvOvQb8HHJ1u457GdPMNEt
a+kHVOGt59DKPGRE3DamQeYQK183szKPwLSl5wkZB9cO/cAWshrqDYWXY1Tk9o1W
WPxAnq1PyjCNtjJGK3cfgC+TKfzaiHa4YwShyh6jaHC1iV/LvTiExdVt+DTdZyTQ
ycBuOMf10yfhTbO2jQ+qP//nOzq9efD9VwhJgF6ycTQqBfpUUofkRy9/YYStMz/0
FXwVRByVpJvO2+9NwPdTQiJbbp+OhkKqZFeGijxlfLFbP/uaIbV7zVERfVicDPOh
NzBBWqTmV0fdxYgVY/Gjcfn8LHbhp7cRSYgugfIv6z4l8UtNGfWm668GueXKTqyZ
P5FTjV7iF4/LkbCvQghjTFQwB7P9y4dbmJoiEmjwqUIkKma2/hRYLVWT8OWW5Z8j
DnttOWwUH9yOAAPeK5fjUUkfZWold/V3VbyD80EEXauYlKe85aqx8oWfbHizq4Kk
U1NDBLKiCzvqt9q0IedPW+uWDCrI9ndWRSrnmVdQ2+W4kbioeTRFtM5hzD3UF1oD
LkMp/7JB9S0Rdu6l/fQDKS7bh1Hhja6mjWyN/XvF+4lDJ5GWNWaIsTLKu/MTq9ZI
d05jMQm2JHPorUQBTkQ/kJIXLatW5ILRGjR9gdtKK/zg3FRvEX8+vcIQ82Q0607X
5691gxbdeZ9IH/B57iqx
=Xfv/
-----END PGP SIGNATURE-----


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<91d341bd1e7ad3cb72d75ba6f1ad9bd0>
In-Reply-To
<7c37de0831b676c83cf1b043c905d9c3> (view parent)
Sender timestamp
1511640391
DKIM signature
missing
Download raw message
could not find the link of rc-1 to test.

cheers.

x9p

> Thank you for the hard work and the release.
>
> x9p
>
>> Hi!
>>
>> I am pleased to announce the first release candidate of Alpine Linux
>> 3.7.0.
>>
>> The big news is that is now support UEFI.
>>
>> Would be nice to have some help with testing all the different release
>> variants and architectures.
>>
>> Thanks!
>>
>> -nc
>>
>>
>> ---
>> 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
---

[alpine-devel] Alpine Linux 3.7.0 Release Candidate 1 on VirtualBox

Jack Schmidt <alpine@mowsey.org>
Details
Message ID
<39316FB2-BAB3-4357-82FC-32FB65EF5AB8@mowsey.org>
In-Reply-To
<5A19D088.6040806@adelielinux.org> (view parent)
Sender timestamp
1511663942
DKIM signature
missing
Download raw message
Here are my notes on Alpine 3.7.0 rc1 installations using VirtualBox hosted on x86_64 Darwin.


Summary:

* Standard, Extended, Vanilla, Virtual on BIOS just work (minor issues)
* Standard, Extended, Vanilla on EFI has one major issue (bad fsck)
* Virtual is broken on EFI (no kernel support)

In each case I tried to do a base install to an IDE disk, as "sys", default options. I also tried booting the ISO as a run-from-ram system. Virtual on EFI requires a serial console, but otherwise all ISOs run-from-ram smoothly.

The fsck issue needs to be fixed. The 4.9.63 vs 4.9.59 should be fixed. The Virtual EFI probably should be fixed, but is easily worked-around by end users. The minor issues would be nice to increase adoption of bootable alpine, but aren't necessary. I assume docker containers are just fine: I use edge all the time without trouble.


Standard, Extended, Vanilla, Virtual legacy BIOS minor issues:

* Install boot might be too quiet for too long

The BIOS boot takes 5 to 20 seconds, so the "quiet" option in boot/syslinux/syslinux.cfg might need to be accompanied by a "say" or a "menu autoboot" type thing. Grub EFI boot is mostly better, but sometimes takes a long time between messages. The installed version is a little slow, but has a reasonable amount of messages to let you know it is progressing.


Standard, Extended, Vanilla, Virtual both BIOS and EFI minor issues:

* After setup-alpine is complete, eject cdrom
* Install boot and installed root use different kernels, rescue is hard
* (hardened/virthardened) Guest additions kernel version problem

Install for BIOS works easily on Standard, Extended, Vanilla, Virtual. Install for EFI works easily on Standard, Extended, Vanilla, but fails for Virtual.

After the install, setup-alpine asks to reboot, but doesn't "eject -s" (-s required for me) the cd. That means alpine reboots under the readonly cdrom with a tmpfs. This works fine, but is surprising if you are installing software.

After the eject, system comes up much more noisily / green, so probably reassuring.

However, it comes up under 4.9.59-0-*hardened or 4.9.65 vanilla, so one can't use the ISO's 4.9.63 kernel to boot a rescue. If it isn't too much trouble, for the final 3.7 release, it'd be good if the kernel matched on the ISO's boot and the ISO's apk.

Guest additions (mostly not needed by me) are hard to load, since they are in /lib/modules/4.9.65-* but the kernel is actually 4.9.59-*. Once that is fixed, all good.


Standard, Extended, Vanilla EFI issue (vfat.fsck)

* 1.5GB disk required
* vfat.fsck

Alpine is known for it's very small size. The ISOs are a nice size. I have a VM that runs off a 10MB iso, and the Virtual ISO is good at under 40MB. I was trying out ubuntu variations and had to choose my physical network to handle the each-iso-is-a-gig downloads. Alpine is very easy to try. However, the new EFI install creates a 500MB /boot/efi partition to hold 500KB of boot data. It might be worthwhile to check the total size of the disk, and not use so much on it for smaller (1 or 2 gig) drives.

More importantly /boot/efi fails its fsck due to a syntax error:

fsck.vfat: unrecognized option: C

This is from /etc/init.d/fsck. Since the fsck service fails, most of the rest of the boot is not really attempted. / is mounted read-only. Network is down.

Remounting / rw, removing the -C0 from fsck, and rebooting is OK. You still get a scary error, but the system comes up fine.

See also https://bugs.alpinelinux.org/issues/8090 for raspberry pi breakage and suggested fix (seems reasonable to me: write a simple shell script wrapper for fsck.vfat and fsck.fat that ignores ext2/3/4 arguments).

I think this must be fixed before a release.


Virtual EFI fail

Virtual's virthardened kernel lacks EFI support (even in module form). Also it is worse on VirtualBox EFI since it also lacks video drivers. The serial console works, but is hard to use (telnet lacks tab-completion, GNU screen requires socat, and only one terminal). Since /sys/firmware/efi is not available, setup-disk does not realize it was an EFI boot and does everything wrong.

I suspect it would be a good idea to include EFI support for the Virtual ISO / virthardened kernel too. The fix would make Alpine seem more reliable and would cut down on the "why is the screen black?" questions. However, to workaround it is easy to turn off EFI, and legacy BIOS is more standard for virtual machines, I believe.



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Alpine Linux 3.7.0 Release Candidate 1 on VirtualBox

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20171129181404.4df7941b@ncopa-desktop.copa.dup.pw>
In-Reply-To
<39316FB2-BAB3-4357-82FC-32FB65EF5AB8@mowsey.org> (view parent)
Sender timestamp
1511975644
DKIM signature
missing
Download raw message
Hi,

Thanks you very much for testing.

I think the most critical issues are fixed. I have not bothered fix the
eject issue, since I think it mostly affects virtualbox only.

I haven't looked at the alpine-virt + efi issue, yet. I suppose there
are some kernel modules that are needed?

Can you please re-run the tests with the 3.7.0_rc3?

Thanks!

-nc

On Sat, 25 Nov 2017 21:39:02 -0500
Jack Schmidt <alpine@mowsey.org> wrote:

> Here are my notes on Alpine 3.7.0 rc1 installations using VirtualBox hosted on x86_64 Darwin.
> 
> 
> Summary:
> 
> * Standard, Extended, Vanilla, Virtual on BIOS just work (minor issues)
> * Standard, Extended, Vanilla on EFI has one major issue (bad fsck)
> * Virtual is broken on EFI (no kernel support)
> 
> In each case I tried to do a base install to an IDE disk, as "sys", default options. I also tried booting the ISO as a run-from-ram system. Virtual on EFI requires a serial console, but otherwise all ISOs run-from-ram smoothly.
> 
> The fsck issue needs to be fixed. The 4.9.63 vs 4.9.59 should be fixed. The Virtual EFI probably should be fixed, but is easily worked-around by end users. The minor issues would be nice to increase adoption of bootable alpine, but aren't necessary. I assume docker containers are just fine: I use edge all the time without trouble.
> 
> 
> Standard, Extended, Vanilla, Virtual legacy BIOS minor issues:
> 
> * Install boot might be too quiet for too long
> 
> The BIOS boot takes 5 to 20 seconds, so the "quiet" option in boot/syslinux/syslinux.cfg might need to be accompanied by a "say" or a "menu autoboot" type thing. Grub EFI boot is mostly better, but sometimes takes a long time between messages. The installed version is a little slow, but has a reasonable amount of messages to let you know it is progressing.
> 
> 
> Standard, Extended, Vanilla, Virtual both BIOS and EFI minor issues:
> 
> * After setup-alpine is complete, eject cdrom
> * Install boot and installed root use different kernels, rescue is hard
> * (hardened/virthardened) Guest additions kernel version problem
> 
> Install for BIOS works easily on Standard, Extended, Vanilla, Virtual. Install for EFI works easily on Standard, Extended, Vanilla, but fails for Virtual.
> 
> After the install, setup-alpine asks to reboot, but doesn't "eject -s" (-s required for me) the cd. That means alpine reboots under the readonly cdrom with a tmpfs. This works fine, but is surprising if you are installing software.
> 
> After the eject, system comes up much more noisily / green, so probably reassuring.
> 
> However, it comes up under 4.9.59-0-*hardened or 4.9.65 vanilla, so one can't use the ISO's 4.9.63 kernel to boot a rescue. If it isn't too much trouble, for the final 3.7 release, it'd be good if the kernel matched on the ISO's boot and the ISO's apk.
> 
> Guest additions (mostly not needed by me) are hard to load, since they are in /lib/modules/4.9.65-* but the kernel is actually 4.9.59-*. Once that is fixed, all good.
> 
> 
> Standard, Extended, Vanilla EFI issue (vfat.fsck)
> 
> * 1.5GB disk required
> * vfat.fsck
> 
> Alpine is known for it's very small size. The ISOs are a nice size. I have a VM that runs off a 10MB iso, and the Virtual ISO is good at under 40MB. I was trying out ubuntu variations and had to choose my physical network to handle the each-iso-is-a-gig downloads. Alpine is very easy to try. However, the new EFI install creates a 500MB /boot/efi partition to hold 500KB of boot data. It might be worthwhile to check the total size of the disk, and not use so much on it for smaller (1 or 2 gig) drives.
> 
> More importantly /boot/efi fails its fsck due to a syntax error:
> 
> fsck.vfat: unrecognized option: C
> 
> This is from /etc/init.d/fsck. Since the fsck service fails, most of the rest of the boot is not really attempted. / is mounted read-only. Network is down.
> 
> Remounting / rw, removing the -C0 from fsck, and rebooting is OK. You still get a scary error, but the system comes up fine.
> 
> See also https://bugs.alpinelinux.org/issues/8090 for raspberry pi breakage and suggested fix (seems reasonable to me: write a simple shell script wrapper for fsck.vfat and fsck.fat that ignores ext2/3/4 arguments).
> 
> I think this must be fixed before a release.
> 
> 
> Virtual EFI fail
> 
> Virtual's virthardened kernel lacks EFI support (even in module form). Also it is worse on VirtualBox EFI since it also lacks video drivers. The serial console works, but is hard to use (telnet lacks tab-completion, GNU screen requires socat, and only one terminal). Since /sys/firmware/efi is not available, setup-disk does not realize it was an EFI boot and does everything wrong.
> 
> I suspect it would be a good idea to include EFI support for the Virtual ISO / virthardened kernel too. The fix would make Alpine seem more reliable and would cut down on the "why is the screen black?" questions. However, to workaround it is easy to turn off EFI, and legacy BIOS is more standard for virtual machines, I believe.
> 
> 
> 
> ---
> 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
---

Re: [alpine-devel] Alpine Linux 3.7.0 Release Candidate 1 on VirtualBox

Gennady Feldman <gena01@gmail.com>
Details
Message ID
<CAFvNWOQj-M=e=ku1vStxXW9yDKv8S6WmgE=UepgKoVVDJPmEzg@mail.gmail.com>
In-Reply-To
<20171129181404.4df7941b@ncopa-desktop.copa.dup.pw> (view parent)
Sender timestamp
1512053420
DKIM signature
missing
Download raw message
Hi,

>From a quick look looks like:
CONFIG_EFI=y
CONFIG_EFI_STUB=y

are missing from the virthardened config.

Thank you,

On Wed, Nov 29, 2017 at 12:14 PM, Natanael Copa <ncopa@alpinelinux.org>
wrote:

> Hi,
>
> Thanks you very much for testing.
>
> I think the most critical issues are fixed. I have not bothered fix the
> eject issue, since I think it mostly affects virtualbox only.
>
> I haven't looked at the alpine-virt + efi issue, yet. I suppose there
> are some kernel modules that are needed?
>
> Can you please re-run the tests with the 3.7.0_rc3?
>
> Thanks!
>
> -nc
>
> On Sat, 25 Nov 2017 21:39:02 -0500
> Jack Schmidt <alpine@mowsey.org> wrote:
>
> > Here are my notes on Alpine 3.7.0 rc1 installations using VirtualBox
> hosted on x86_64 Darwin.
> >
> >
> > Summary:
> >
> > * Standard, Extended, Vanilla, Virtual on BIOS just work (minor issues)
> > * Standard, Extended, Vanilla on EFI has one major issue (bad fsck)
> > * Virtual is broken on EFI (no kernel support)
> >
> > In each case I tried to do a base install to an IDE disk, as "sys",
> default options. I also tried booting the ISO as a run-from-ram system.
> Virtual on EFI requires a serial console, but otherwise all ISOs
> run-from-ram smoothly.
> >
> > The fsck issue needs to be fixed. The 4.9.63 vs 4.9.59 should be fixed.
> The Virtual EFI probably should be fixed, but is easily worked-around by
> end users. The minor issues would be nice to increase adoption of bootable
> alpine, but aren't necessary. I assume docker containers are just fine: I
> use edge all the time without trouble.
> >
> >
> > Standard, Extended, Vanilla, Virtual legacy BIOS minor issues:
> >
> > * Install boot might be too quiet for too long
> >
> > The BIOS boot takes 5 to 20 seconds, so the "quiet" option in
> boot/syslinux/syslinux.cfg might need to be accompanied by a "say" or a
> "menu autoboot" type thing. Grub EFI boot is mostly better, but sometimes
> takes a long time between messages. The installed version is a little slow,
> but has a reasonable amount of messages to let you know it is progressing.
> >
> >
> > Standard, Extended, Vanilla, Virtual both BIOS and EFI minor issues:
> >
> > * After setup-alpine is complete, eject cdrom
> > * Install boot and installed root use different kernels, rescue is hard
> > * (hardened/virthardened) Guest additions kernel version problem
> >
> > Install for BIOS works easily on Standard, Extended, Vanilla, Virtual.
> Install for EFI works easily on Standard, Extended, Vanilla, but fails for
> Virtual.
> >
> > After the install, setup-alpine asks to reboot, but doesn't "eject -s"
> (-s required for me) the cd. That means alpine reboots under the readonly
> cdrom with a tmpfs. This works fine, but is surprising if you are
> installing software.
> >
> > After the eject, system comes up much more noisily / green, so probably
> reassuring.
> >
> > However, it comes up under 4.9.59-0-*hardened or 4.9.65 vanilla, so one
> can't use the ISO's 4.9.63 kernel to boot a rescue. If it isn't too much
> trouble, for the final 3.7 release, it'd be good if the kernel matched on
> the ISO's boot and the ISO's apk.
> >
> > Guest additions (mostly not needed by me) are hard to load, since they
> are in /lib/modules/4.9.65-* but the kernel is actually 4.9.59-*. Once that
> is fixed, all good.
> >
> >
> > Standard, Extended, Vanilla EFI issue (vfat.fsck)
> >
> > * 1.5GB disk required
> > * vfat.fsck
> >
> > Alpine is known for it's very small size. The ISOs are a nice size. I
> have a VM that runs off a 10MB iso, and the Virtual ISO is good at under
> 40MB. I was trying out ubuntu variations and had to choose my physical
> network to handle the each-iso-is-a-gig downloads. Alpine is very easy to
> try. However, the new EFI install creates a 500MB /boot/efi partition to
> hold 500KB of boot data. It might be worthwhile to check the total size of
> the disk, and not use so much on it for smaller (1 or 2 gig) drives.
> >
> > More importantly /boot/efi fails its fsck due to a syntax error:
> >
> > fsck.vfat: unrecognized option: C
> >
> > This is from /etc/init.d/fsck. Since the fsck service fails, most of the
> rest of the boot is not really attempted. / is mounted read-only. Network
> is down.
> >
> > Remounting / rw, removing the -C0 from fsck, and rebooting is OK. You
> still get a scary error, but the system comes up fine.
> >
> > See also https://bugs.alpinelinux.org/issues/8090 for raspberry pi
> breakage and suggested fix (seems reasonable to me: write a simple shell
> script wrapper for fsck.vfat and fsck.fat that ignores ext2/3/4 arguments).
> >
> > I think this must be fixed before a release.
> >
> >
> > Virtual EFI fail
> >
> > Virtual's virthardened kernel lacks EFI support (even in module form).
> Also it is worse on VirtualBox EFI since it also lacks video drivers. The
> serial console works, but is hard to use (telnet lacks tab-completion, GNU
> screen requires socat, and only one terminal). Since /sys/firmware/efi is
> not available, setup-disk does not realize it was an EFI boot and does
> everything wrong.
> >
> > I suspect it would be a good idea to include EFI support for the Virtual
> ISO / virthardened kernel too. The fix would make Alpine seem more reliable
> and would cut down on the "why is the screen black?" questions. However, to
> workaround it is easy to turn off EFI, and legacy BIOS is more standard for
> virtual machines, I believe.
> >
> >
> >
> > ---
> > 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
> ---
>
>

Re: [alpine-devel] Alpine Linux 3.7.0 Release Candidate 1 on VirtualBox

Jakub Jirutka <jakub@jirutka.cz>
Details
Message ID
<5B02BCE4-04A7-4389-A7F3-BD44477A9C6D@jirutka.cz>
In-Reply-To
<CAFvNWOQj-M=e=ku1vStxXW9yDKv8S6WmgE=UepgKoVVDJPmEzg@mail.gmail.com> (view parent)
Sender timestamp
1512053565
DKIM signature
missing
Download raw message
Wait, VirtualBox *requires* EFI now? If not, why to enable it in kernel for VMs?

Jakub

> On 30. Nov 2017, at 15:50, Gennady Feldman <gena01@gmail.com> wrote:
> 
> Hi,
> 
> From a quick look looks like:
> CONFIG_EFI=y
> CONFIG_EFI_STUB=y
> 
> are missing from the virthardened config.
> 
> Thank you,
> 
> On Wed, Nov 29, 2017 at 12:14 PM, Natanael Copa <ncopa@alpinelinux.org <ncopa@alpinelinux.org>> wrote:
> Hi,
> 
> Thanks you very much for testing.
> 
> I think the most critical issues are fixed. I have not bothered fix the
> eject issue, since I think it mostly affects virtualbox only.
> 
> I haven't looked at the alpine-virt + efi issue, yet. I suppose there
> are some kernel modules that are needed?
> 
> Can you please re-run the tests with the 3.7.0_rc3?
> 
> Thanks!
> 
> -nc
> 
> On Sat, 25 Nov 2017 21:39:02 -0500
> Jack Schmidt <alpine@mowsey.org <alpine@mowsey.org>> wrote:
> 
> > Here are my notes on Alpine 3.7.0 rc1 installations using VirtualBox hosted on x86_64 Darwin.
> >
> >
> > Summary:
> >
> > * Standard, Extended, Vanilla, Virtual on BIOS just work (minor issues)
> > * Standard, Extended, Vanilla on EFI has one major issue (bad fsck)
> > * Virtual is broken on EFI (no kernel support)
> >
> > In each case I tried to do a base install to an IDE disk, as "sys", default options. I also tried booting the ISO as a run-from-ram system. Virtual on EFI requires a serial console, but otherwise all ISOs run-from-ram smoothly.
> >
> > The fsck issue needs to be fixed. The 4.9.63 vs 4.9.59 should be fixed. The Virtual EFI probably should be fixed, but is easily worked-around by end users. The minor issues would be nice to increase adoption of bootable alpine, but aren't necessary. I assume docker containers are just fine: I use edge all the time without trouble.
> >
> >
> > Standard, Extended, Vanilla, Virtual legacy BIOS minor issues:
> >
> > * Install boot might be too quiet for too long
> >
> > The BIOS boot takes 5 to 20 seconds, so the "quiet" option in boot/syslinux/syslinux.cfg might need to be accompanied by a "say" or a "menu autoboot" type thing. Grub EFI boot is mostly better, but sometimes takes a long time between messages. The installed version is a little slow, but has a reasonable amount of messages to let you know it is progressing.
> >
> >
> > Standard, Extended, Vanilla, Virtual both BIOS and EFI minor issues:
> >
> > * After setup-alpine is complete, eject cdrom
> > * Install boot and installed root use different kernels, rescue is hard
> > * (hardened/virthardened) Guest additions kernel version problem
> >
> > Install for BIOS works easily on Standard, Extended, Vanilla, Virtual. Install for EFI works easily on Standard, Extended, Vanilla, but fails for Virtual.
> >
> > After the install, setup-alpine asks to reboot, but doesn't "eject -s" (-s required for me) the cd. That means alpine reboots under the readonly cdrom with a tmpfs. This works fine, but is surprising if you are installing software.
> >
> > After the eject, system comes up much more noisily / green, so probably reassuring.
> >
> > However, it comes up under 4.9.59-0-*hardened or 4.9.65 vanilla, so one can't use the ISO's 4.9.63 kernel to boot a rescue. If it isn't too much trouble, for the final 3.7 release, it'd be good if the kernel matched on the ISO's boot and the ISO's apk.
> >
> > Guest additions (mostly not needed by me) are hard to load, since they are in /lib/modules/4.9.65-* but the kernel is actually 4.9.59-*. Once that is fixed, all good.
> >
> >
> > Standard, Extended, Vanilla EFI issue (vfat.fsck)
> >
> > * 1.5GB disk required
> > * vfat.fsck
> >
> > Alpine is known for it's very small size. The ISOs are a nice size. I have a VM that runs off a 10MB iso, and the Virtual ISO is good at under 40MB. I was trying out ubuntu variations and had to choose my physical network to handle the each-iso-is-a-gig downloads. Alpine is very easy to try. However, the new EFI install creates a 500MB /boot/efi partition to hold 500KB of boot data. It might be worthwhile to check the total size of the disk, and not use so much on it for smaller (1 or 2 gig) drives.
> >
> > More importantly /boot/efi fails its fsck due to a syntax error:
> >
> > fsck.vfat: unrecognized option: C
> >
> > This is from /etc/init.d/fsck. Since the fsck service fails, most of the rest of the boot is not really attempted. / is mounted read-only. Network is down.
> >
> > Remounting / rw, removing the -C0 from fsck, and rebooting is OK. You still get a scary error, but the system comes up fine.
> >
> > See also https://bugs.alpinelinux.org/issues/8090 <https://bugs.alpinelinux.org/issues/8090> for raspberry pi breakage and suggested fix (seems reasonable to me: write a simple shell script wrapper for fsck.vfat and fsck.fat that ignores ext2/3/4 arguments).
> >
> > I think this must be fixed before a release.
> >
> >
> > Virtual EFI fail
> >
> > Virtual's virthardened kernel lacks EFI support (even in module form). Also it is worse on VirtualBox EFI since it also lacks video drivers. The serial console works, but is hard to use (telnet lacks tab-completion, GNU screen requires socat, and only one terminal). Since /sys/firmware/efi is not available, setup-disk does not realize it was an EFI boot and does everything wrong.
> >
> > I suspect it would be a good idea to include EFI support for the Virtual ISO / virthardened kernel too. The fix would make Alpine seem more reliable and would cut down on the "why is the screen black?" questions. However, to workaround it is easy to turn off EFI, and legacy BIOS is more standard for virtual machines, I believe.
> >
> >
> >
> > ---
> > Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org <alpine-devel%2Bunsubscribe@lists.alpinelinux.org>
> > Help:         alpine-devel+help@lists.alpinelinux.org <alpine-devel%2Bhelp@lists.alpinelinux.org>
> > ---
> >
> 
> 
> 
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org <alpine-devel%2Bunsubscribe@lists.alpinelinux.org>
> Help:         alpine-devel+help@lists.alpinelinux.org <alpine-devel%2Bhelp@lists.alpinelinux.org>
> ---
> 
> 

Re: [alpine-devel] Alpine Linux 3.7.0 Release Candidate 1 on VirtualBox

Gennady Feldman <gena01@gmail.com>
Details
Message ID
<CAFvNWOSUKbgm4_GX3NYvwe5x00DBjZ30AjU4FmkTo2a3-=rsdQ@mail.gmail.com>
In-Reply-To
<5B02BCE4-04A7-4389-A7F3-BD44477A9C6D@jirutka.cz> (view parent)
Sender timestamp
1512089449
DKIM signature
missing
Download raw message
HI Jakub,

I am going to answer what I know ( I am sure others will have their own
reasons). I have Virtualbox 5.1.30 (there's also 5.2.x out) installed on
Windows 7.
Right now from what I can see it's NOT a requirement, but the option is
there.

I did download and try to play a bit with the 3.7rc3 both virt and
standard. Virt doesn't even boot. Standard seems to be fine as long as I
don't install the virt kernel and try to boot with it.

>From what I read EFI seems like the replacement for BIOS and should provide
a number of benefits including a better/bigger console (which I like quite
a bit, kinda hate doing console installs
using legacy BIOS inside VirtualBox) and faster boot time among other
things. I might even convert my Alpine VMs to use it once virt kernel
supports it.

I guess from MBR <=> GPT perspective it could go either way. Things might
get interesting with bigger external volumes, but not for something I am
working/messing with right now.

setup-disk does some interesting stuff in EFI mode:
- boot has hard-coded 512 (which seems quite high?)
- creates a swap partition (2G for me). I would love to turn that off if I
am running inside VirtualBox or being able to choose.

I also wanted to ask if it would make sense to have "setup-virtualbox"
script that would install virtualbox packages and tweak some things for VMs
running inside VirtualBox.

Thank you,

Gennady

On Thu, Nov 30, 2017 at 9:52 AM, Jakub Jirutka <jakub@jirutka.cz> wrote:

> Wait, VirtualBox *requires* EFI now? If not, why to enable it in kernel
> for VMs?
>
> Jakub
>
> On 30. Nov 2017, at 15:50, Gennady Feldman <gena01@gmail.com> wrote:
>
> Hi,
>
> From a quick look looks like:
> CONFIG_EFI=y
> CONFIG_EFI_STUB=y
>
> are missing from the virthardened config.
>
> Thank you,
>
> On Wed, Nov 29, 2017 at 12:14 PM, Natanael Copa <ncopa@alpinelinux.org>
> wrote:
>
>> Hi,
>>
>> Thanks you very much for testing.
>>
>> I think the most critical issues are fixed. I have not bothered fix the
>> eject issue, since I think it mostly affects virtualbox only.
>>
>> I haven't looked at the alpine-virt + efi issue, yet. I suppose there
>> are some kernel modules that are needed?
>>
>> Can you please re-run the tests with the 3.7.0_rc3?
>>
>> Thanks!
>>
>> -nc
>>
>> On Sat, 25 Nov 2017 21:39:02 -0500
>> Jack Schmidt <alpine@mowsey.org> wrote:
>>
>> > Here are my notes on Alpine 3.7.0 rc1 installations using VirtualBox
>> hosted on x86_64 Darwin.
>> >
>> >
>> > Summary:
>> >
>> > * Standard, Extended, Vanilla, Virtual on BIOS just work (minor issues)
>> > * Standard, Extended, Vanilla on EFI has one major issue (bad fsck)
>> > * Virtual is broken on EFI (no kernel support)
>> >
>> > In each case I tried to do a base install to an IDE disk, as "sys",
>> default options. I also tried booting the ISO as a run-from-ram system.
>> Virtual on EFI requires a serial console, but otherwise all ISOs
>> run-from-ram smoothly.
>> >
>> > The fsck issue needs to be fixed. The 4.9.63 vs 4.9.59 should be fixed.
>> The Virtual EFI probably should be fixed, but is easily worked-around by
>> end users. The minor issues would be nice to increase adoption of bootable
>> alpine, but aren't necessary. I assume docker containers are just fine: I
>> use edge all the time without trouble.
>> >
>> >
>> > Standard, Extended, Vanilla, Virtual legacy BIOS minor issues:
>> >
>> > * Install boot might be too quiet for too long
>> >
>> > The BIOS boot takes 5 to 20 seconds, so the "quiet" option in
>> boot/syslinux/syslinux.cfg might need to be accompanied by a "say" or a
>> "menu autoboot" type thing. Grub EFI boot is mostly better, but sometimes
>> takes a long time between messages. The installed version is a little slow,
>> but has a reasonable amount of messages to let you know it is progressing.
>> >
>> >
>> > Standard, Extended, Vanilla, Virtual both BIOS and EFI minor issues:
>> >
>> > * After setup-alpine is complete, eject cdrom
>> > * Install boot and installed root use different kernels, rescue is hard
>> > * (hardened/virthardened) Guest additions kernel version problem
>> >
>> > Install for BIOS works easily on Standard, Extended, Vanilla, Virtual.
>> Install for EFI works easily on Standard, Extended, Vanilla, but fails for
>> Virtual.
>> >
>> > After the install, setup-alpine asks to reboot, but doesn't "eject -s"
>> (-s required for me) the cd. That means alpine reboots under the readonly
>> cdrom with a tmpfs. This works fine, but is surprising if you are
>> installing software.
>> >
>> > After the eject, system comes up much more noisily / green, so probably
>> reassuring.
>> >
>> > However, it comes up under 4.9.59-0-*hardened or 4.9.65 vanilla, so one
>> can't use the ISO's 4.9.63 kernel to boot a rescue. If it isn't too much
>> trouble, for the final 3.7 release, it'd be good if the kernel matched on
>> the ISO's boot and the ISO's apk.
>> >
>> > Guest additions (mostly not needed by me) are hard to load, since they
>> are in /lib/modules/4.9.65-* but the kernel is actually 4.9.59-*. Once that
>> is fixed, all good.
>> >
>> >
>> > Standard, Extended, Vanilla EFI issue (vfat.fsck)
>> >
>> > * 1.5GB disk required
>> > * vfat.fsck
>> >
>> > Alpine is known for it's very small size. The ISOs are a nice size. I
>> have a VM that runs off a 10MB iso, and the Virtual ISO is good at under
>> 40MB. I was trying out ubuntu variations and had to choose my physical
>> network to handle the each-iso-is-a-gig downloads. Alpine is very easy to
>> try. However, the new EFI install creates a 500MB /boot/efi partition to
>> hold 500KB of boot data. It might be worthwhile to check the total size of
>> the disk, and not use so much on it for smaller (1 or 2 gig) drives.
>> >
>> > More importantly /boot/efi fails its fsck due to a syntax error:
>> >
>> > fsck.vfat: unrecognized option: C
>> >
>> > This is from /etc/init.d/fsck. Since the fsck service fails, most of
>> the rest of the boot is not really attempted. / is mounted read-only.
>> Network is down.
>> >
>> > Remounting / rw, removing the -C0 from fsck, and rebooting is OK. You
>> still get a scary error, but the system comes up fine.
>> >
>> > See also https://bugs.alpinelinux.org/issues/8090 for raspberry pi
>> breakage and suggested fix (seems reasonable to me: write a simple shell
>> script wrapper for fsck.vfat and fsck.fat that ignores ext2/3/4 arguments).
>> >
>> > I think this must be fixed before a release.
>> >
>> >
>> > Virtual EFI fail
>> >
>> > Virtual's virthardened kernel lacks EFI support (even in module form).
>> Also it is worse on VirtualBox EFI since it also lacks video drivers. The
>> serial console works, but is hard to use (telnet lacks tab-completion, GNU
>> screen requires socat, and only one terminal). Since /sys/firmware/efi is
>> not available, setup-disk does not realize it was an EFI boot and does
>> everything wrong.
>> >
>> > I suspect it would be a good idea to include EFI support for the
>> Virtual ISO / virthardened kernel too. The fix would make Alpine seem more
>> reliable and would cut down on the "why is the screen black?" questions.
>> However, to workaround it is easy to turn off EFI, and legacy BIOS is more
>> standard for virtual machines, I believe.
>> >
>> >
>> >
>> > ---
>> > 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
>> ---
>>
>>
>
>

Re: [alpine-devel] Alpine Linux 3.7.0 Release Candidate 1 on VirtualBox

Gennady Feldman <gena01@gmail.com>
Details
Message ID
<CAFvNWOTC2zBXX8TY0aoa9vdfqbFi+A7wsmk4bHU3PbQhjo6+kg@mail.gmail.com>
In-Reply-To
<CAFvNWOSUKbgm4_GX3NYvwe5x00DBjZ30AjU4FmkTo2a3-=rsdQ@mail.gmail.com> (view parent)
Sender timestamp
1512141004
DKIM signature
missing
Download raw message
Hi Jakub,

Was thinking a bit more about virt + EFI.. Any reason you are against
enabling it? It looks like various VM platforms have already added or are
adding EFI support to replace "legacy BIOS" as part of the VM environment.

Right now that kernel doesn't boot and from the looks of it it's only
enabling 2 modules.

P.S. Can somebody bump community/virtualbox-guest-additions/APKBUILD 5.1.26
=> 5.1.30?

Thank you,

Gennady

On Thu, Nov 30, 2017 at 7:50 PM, Gennady Feldman <gena01@gmail.com> wrote:

> HI Jakub,
>
> I am going to answer what I know ( I am sure others will have their own
> reasons). I have Virtualbox 5.1.30 (there's also 5.2.x out) installed on
> Windows 7.
> Right now from what I can see it's NOT a requirement, but the option is
> there.
>
> I did download and try to play a bit with the 3.7rc3 both virt and
> standard. Virt doesn't even boot. Standard seems to be fine as long as I
> don't install the virt kernel and try to boot with it.
>
> From what I read EFI seems like the replacement for BIOS and should
> provide a number of benefits including a better/bigger console (which I
> like quite a bit, kinda hate doing console installs
> using legacy BIOS inside VirtualBox) and faster boot time among other
> things. I might even convert my Alpine VMs to use it once virt kernel
> supports it.
>
> I guess from MBR <=> GPT perspective it could go either way. Things might
> get interesting with bigger external volumes, but not for something I am
> working/messing with right now.
>
> setup-disk does some interesting stuff in EFI mode:
> - boot has hard-coded 512 (which seems quite high?)
> - creates a swap partition (2G for me). I would love to turn that off if I
> am running inside VirtualBox or being able to choose.
>
> I also wanted to ask if it would make sense to have "setup-virtualbox"
> script that would install virtualbox packages and tweak some things for VMs
> running inside VirtualBox.
>
> Thank you,
>
> Gennady
>
> On Thu, Nov 30, 2017 at 9:52 AM, Jakub Jirutka <jakub@jirutka.cz> wrote:
>
>> Wait, VirtualBox *requires* EFI now? If not, why to enable it in kernel
>> for VMs?
>>
>> Jakub
>>
>> On 30. Nov 2017, at 15:50, Gennady Feldman <gena01@gmail.com> wrote:
>>
>> Hi,
>>
>> From a quick look looks like:
>> CONFIG_EFI=y
>> CONFIG_EFI_STUB=y
>>
>> are missing from the virthardened config.
>>
>> Thank you,
>>
>> On Wed, Nov 29, 2017 at 12:14 PM, Natanael Copa <ncopa@alpinelinux.org>
>> wrote:
>>
>>> Hi,
>>>
>>> Thanks you very much for testing.
>>>
>>> I think the most critical issues are fixed. I have not bothered fix the
>>> eject issue, since I think it mostly affects virtualbox only.
>>>
>>> I haven't looked at the alpine-virt + efi issue, yet. I suppose there
>>> are some kernel modules that are needed?
>>>
>>> Can you please re-run the tests with the 3.7.0_rc3?
>>>
>>> Thanks!
>>>
>>> -nc
>>>
>>> On Sat, 25 Nov 2017 21:39:02 -0500
>>> Jack Schmidt <alpine@mowsey.org> wrote:
>>>
>>> > Here are my notes on Alpine 3.7.0 rc1 installations using VirtualBox
>>> hosted on x86_64 Darwin.
>>> >
>>> >
>>> > Summary:
>>> >
>>> > * Standard, Extended, Vanilla, Virtual on BIOS just work (minor issues)
>>> > * Standard, Extended, Vanilla on EFI has one major issue (bad fsck)
>>> > * Virtual is broken on EFI (no kernel support)
>>> >
>>> > In each case I tried to do a base install to an IDE disk, as "sys",
>>> default options. I also tried booting the ISO as a run-from-ram system.
>>> Virtual on EFI requires a serial console, but otherwise all ISOs
>>> run-from-ram smoothly.
>>> >
>>> > The fsck issue needs to be fixed. The 4.9.63 vs 4.9.59 should be
>>> fixed. The Virtual EFI probably should be fixed, but is easily
>>> worked-around by end users. The minor issues would be nice to increase
>>> adoption of bootable alpine, but aren't necessary. I assume docker
>>> containers are just fine: I use edge all the time without trouble.
>>> >
>>> >
>>> > Standard, Extended, Vanilla, Virtual legacy BIOS minor issues:
>>> >
>>> > * Install boot might be too quiet for too long
>>> >
>>> > The BIOS boot takes 5 to 20 seconds, so the "quiet" option in
>>> boot/syslinux/syslinux.cfg might need to be accompanied by a "say" or a
>>> "menu autoboot" type thing. Grub EFI boot is mostly better, but sometimes
>>> takes a long time between messages. The installed version is a little slow,
>>> but has a reasonable amount of messages to let you know it is progressing.
>>> >
>>> >
>>> > Standard, Extended, Vanilla, Virtual both BIOS and EFI minor issues:
>>> >
>>> > * After setup-alpine is complete, eject cdrom
>>> > * Install boot and installed root use different kernels, rescue is hard
>>> > * (hardened/virthardened) Guest additions kernel version problem
>>> >
>>> > Install for BIOS works easily on Standard, Extended, Vanilla, Virtual.
>>> Install for EFI works easily on Standard, Extended, Vanilla, but fails for
>>> Virtual.
>>> >
>>> > After the install, setup-alpine asks to reboot, but doesn't "eject -s"
>>> (-s required for me) the cd. That means alpine reboots under the readonly
>>> cdrom with a tmpfs. This works fine, but is surprising if you are
>>> installing software.
>>> >
>>> > After the eject, system comes up much more noisily / green, so
>>> probably reassuring.
>>> >
>>> > However, it comes up under 4.9.59-0-*hardened or 4.9.65 vanilla, so
>>> one can't use the ISO's 4.9.63 kernel to boot a rescue. If it isn't too
>>> much trouble, for the final 3.7 release, it'd be good if the kernel matched
>>> on the ISO's boot and the ISO's apk.
>>> >
>>> > Guest additions (mostly not needed by me) are hard to load, since they
>>> are in /lib/modules/4.9.65-* but the kernel is actually 4.9.59-*. Once that
>>> is fixed, all good.
>>> >
>>> >
>>> > Standard, Extended, Vanilla EFI issue (vfat.fsck)
>>> >
>>> > * 1.5GB disk required
>>> > * vfat.fsck
>>> >
>>> > Alpine is known for it's very small size. The ISOs are a nice size. I
>>> have a VM that runs off a 10MB iso, and the Virtual ISO is good at under
>>> 40MB. I was trying out ubuntu variations and had to choose my physical
>>> network to handle the each-iso-is-a-gig downloads. Alpine is very easy to
>>> try. However, the new EFI install creates a 500MB /boot/efi partition to
>>> hold 500KB of boot data. It might be worthwhile to check the total size of
>>> the disk, and not use so much on it for smaller (1 or 2 gig) drives.
>>> >
>>> > More importantly /boot/efi fails its fsck due to a syntax error:
>>> >
>>> > fsck.vfat: unrecognized option: C
>>> >
>>> > This is from /etc/init.d/fsck. Since the fsck service fails, most of
>>> the rest of the boot is not really attempted. / is mounted read-only.
>>> Network is down.
>>> >
>>> > Remounting / rw, removing the -C0 from fsck, and rebooting is OK. You
>>> still get a scary error, but the system comes up fine.
>>> >
>>> > See also https://bugs.alpinelinux.org/issues/8090 for raspberry pi
>>> breakage and suggested fix (seems reasonable to me: write a simple shell
>>> script wrapper for fsck.vfat and fsck.fat that ignores ext2/3/4 arguments).
>>> >
>>> > I think this must be fixed before a release.
>>> >
>>> >
>>> > Virtual EFI fail
>>> >
>>> > Virtual's virthardened kernel lacks EFI support (even in module form).
>>> Also it is worse on VirtualBox EFI since it also lacks video drivers. The
>>> serial console works, but is hard to use (telnet lacks tab-completion, GNU
>>> screen requires socat, and only one terminal). Since /sys/firmware/efi is
>>> not available, setup-disk does not realize it was an EFI boot and does
>>> everything wrong.
>>> >
>>> > I suspect it would be a good idea to include EFI support for the
>>> Virtual ISO / virthardened kernel too. The fix would make Alpine seem more
>>> reliable and would cut down on the "why is the screen black?" questions.
>>> However, to workaround it is easy to turn off EFI, and legacy BIOS is more
>>> standard for virtual machines, I believe.
>>> >
>>> >
>>> >
>>> > ---
>>> > 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
>>> ---
>>>
>>>
>>
>>
>

Re: [alpine-devel] Alpine Linux 3.7.0 Release Candidate 1 on VirtualBox

Details
Message ID
<CAML-UdvZHXPnMUK=moaq81uDm1ann5a-QEdUk_9JaAps5NQssg@mail.gmail.com>
In-Reply-To
<F5BDD5E2-281B-4159-9C38-B28995447BB8@jirutka.cz> (view parent)
Sender timestamp
1512146964
DKIM signature
missing
Download raw message
I have hardware which will not boot in 'legacy BIOS' mode at all (Atom
x5-Z8330-based Intel compute stick), and while VMs don't necessarily need
to emulate that, it can be helpful to force EFI-only boot for debugging
purposes.

On Fri, Dec 1, 2017 at 10:44 AM Jakub Jirutka <jakub@jirutka.cz> wrote:

> Hi Gennady,
>
> Any reason you are against enabling it?
>
>
> I’m not strongly against it, I just prefer to keep number of enabled
> features at minimum (and yes, I know that the current configs are exactly
> opposite). I don’t see any added value of EFI for VMs. Actually I can
> hardly see it even for physical HW, it just allowed vendors to add more
> crap and bloat into it, but that’s a different story.
>
> It other devs don’t mind adding these features, let’s do it.
>
> Jakub
>
> On 1. Dec 2017, at 16:10, Gennady Feldman <gena01@gmail.com> wrote:
>
> Hi Jakub,
>
> Was thinking a bit more about virt + EFI.. Any reason you are against
> enabling it? It looks like various VM platforms have already added or are
> adding EFI support to replace "legacy BIOS" as part of the VM environment.
>
> Right now that kernel doesn't boot and from the looks of it it's only
> enabling 2 modules.
>
> P.S. Can somebody bump community/virtualbox-guest-additions/APKBUILD
> 5.1.26 => 5.1.30?
>
> Thank you,
>
> Gennady
>
> On Thu, Nov 30, 2017 at 7:50 PM, Gennady Feldman <gena01@gmail.com> wrote:
>
>> HI Jakub,
>>
>> I am going to answer what I know ( I am sure others will have their own
>> reasons). I have Virtualbox 5.1.30 (there's also 5.2.x out) installed on
>> Windows 7.
>> Right now from what I can see it's NOT a requirement, but the option is
>> there.
>>
>> I did download and try to play a bit with the 3.7rc3 both virt and
>> standard. Virt doesn't even boot. Standard seems to be fine as long as I
>> don't install the virt kernel and try to boot with it.
>>
>> From what I read EFI seems like the replacement for BIOS and should
>> provide a number of benefits including a better/bigger console (which I
>> like quite a bit, kinda hate doing console installs
>> using legacy BIOS inside VirtualBox) and faster boot time among other
>> things. I might even convert my Alpine VMs to use it once virt kernel
>> supports it.
>>
>> I guess from MBR <=> GPT perspective it could go either way. Things might
>> get interesting with bigger external volumes, but not for something I am
>> working/messing with right now.
>>
>> setup-disk does some interesting stuff in EFI mode:
>> - boot has hard-coded 512 (which seems quite high?)
>> - creates a swap partition (2G for me). I would love to turn that off if
>> I am running inside VirtualBox or being able to choose.
>>
>> I also wanted to ask if it would make sense to have "setup-virtualbox"
>> script that would install virtualbox packages and tweak some things for VMs
>> running inside VirtualBox.
>>
>> Thank you,
>>
>> Gennady
>>
>> On Thu, Nov 30, 2017 at 9:52 AM, Jakub Jirutka <jakub@jirutka.cz> wrote:
>>
>>> Wait, VirtualBox *requires* EFI now? If not, why to enable it in kernel
>>> for VMs?
>>>
>>> Jakub
>>>
>>> On 30. Nov 2017, at 15:50, Gennady Feldman <gena01@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> From a quick look looks like:
>>> CONFIG_EFI=y
>>> CONFIG_EFI_STUB=y
>>>
>>> are missing from the virthardened config.
>>>
>>> Thank you,
>>>
>>> On Wed, Nov 29, 2017 at 12:14 PM, Natanael Copa <ncopa@alpinelinux.org>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Thanks you very much for testing.
>>>>
>>>> I think the most critical issues are fixed. I have not bothered fix the
>>>> eject issue, since I think it mostly affects virtualbox only.
>>>>
>>>> I haven't looked at the alpine-virt + efi issue, yet. I suppose there
>>>> are some kernel modules that are needed?
>>>>
>>>> Can you please re-run the tests with the 3.7.0_rc3?
>>>>
>>>> Thanks!
>>>>
>>>> -nc
>>>>
>>>> On Sat, 25 Nov 2017 21:39:02 -0500
>>>> Jack Schmidt <alpine@mowsey.org> wrote:
>>>>
>>>> > Here are my notes on Alpine 3.7.0 rc1 installations using VirtualBox
>>>> hosted on x86_64 Darwin.
>>>> >
>>>> >
>>>> > Summary:
>>>> >
>>>> > * Standard, Extended, Vanilla, Virtual on BIOS just work (minor
>>>> issues)
>>>> > * Standard, Extended, Vanilla on EFI has one major issue (bad fsck)
>>>> > * Virtual is broken on EFI (no kernel support)
>>>> >
>>>> > In each case I tried to do a base install to an IDE disk, as "sys",
>>>> default options. I also tried booting the ISO as a run-from-ram system.
>>>> Virtual on EFI requires a serial console, but otherwise all ISOs
>>>> run-from-ram smoothly.
>>>> >
>>>> > The fsck issue needs to be fixed. The 4.9.63 vs 4.9.59 should be
>>>> fixed. The Virtual EFI probably should be fixed, but is easily
>>>> worked-around by end users. The minor issues would be nice to increase
>>>> adoption of bootable alpine, but aren't necessary. I assume docker
>>>> containers are just fine: I use edge all the time without trouble.
>>>> >
>>>> >
>>>> > Standard, Extended, Vanilla, Virtual legacy BIOS minor issues:
>>>> >
>>>> > * Install boot might be too quiet for too long
>>>> >
>>>> > The BIOS boot takes 5 to 20 seconds, so the "quiet" option in
>>>> boot/syslinux/syslinux.cfg might need to be accompanied by a "say" or a
>>>> "menu autoboot" type thing. Grub EFI boot is mostly better, but sometimes
>>>> takes a long time between messages. The installed version is a little slow,
>>>> but has a reasonable amount of messages to let you know it is progressing.
>>>> >
>>>> >
>>>> > Standard, Extended, Vanilla, Virtual both BIOS and EFI minor issues:
>>>> >
>>>> > * After setup-alpine is complete, eject cdrom
>>>> > * Install boot and installed root use different kernels, rescue is
>>>> hard
>>>> > * (hardened/virthardened) Guest additions kernel version problem
>>>> >
>>>> > Install for BIOS works easily on Standard, Extended, Vanilla,
>>>> Virtual. Install for EFI works easily on Standard, Extended, Vanilla, but
>>>> fails for Virtual.
>>>> >
>>>> > After the install, setup-alpine asks to reboot, but doesn't "eject
>>>> -s" (-s required for me) the cd. That means alpine reboots under the
>>>> readonly cdrom with a tmpfs. This works fine, but is surprising if you are
>>>> installing software.
>>>> >
>>>> > After the eject, system comes up much more noisily / green, so
>>>> probably reassuring.
>>>> >
>>>> > However, it comes up under 4.9.59-0-*hardened or 4.9.65 vanilla, so
>>>> one can't use the ISO's 4.9.63 kernel to boot a rescue. If it isn't too
>>>> much trouble, for the final 3.7 release, it'd be good if the kernel matched
>>>> on the ISO's boot and the ISO's apk.
>>>> >
>>>> > Guest additions (mostly not needed by me) are hard to load, since
>>>> they are in /lib/modules/4.9.65-* but the kernel is actually 4.9.59-*. Once
>>>> that is fixed, all good.
>>>> >
>>>> >
>>>> > Standard, Extended, Vanilla EFI issue (vfat.fsck)
>>>> >
>>>> > * 1.5GB disk required
>>>> > * vfat.fsck
>>>> >
>>>> > Alpine is known for it's very small size. The ISOs are a nice size. I
>>>> have a VM that runs off a 10MB iso, and the Virtual ISO is good at under
>>>> 40MB. I was trying out ubuntu variations and had to choose my physical
>>>> network to handle the each-iso-is-a-gig downloads. Alpine is very easy to
>>>> try. However, the new EFI install creates a 500MB /boot/efi partition to
>>>> hold 500KB of boot data. It might be worthwhile to check the total size of
>>>> the disk, and not use so much on it for smaller (1 or 2 gig) drives.
>>>> >
>>>> > More importantly /boot/efi fails its fsck due to a syntax error:
>>>> >
>>>> > fsck.vfat: unrecognized option: C
>>>> >
>>>> > This is from /etc/init.d/fsck. Since the fsck service fails, most of
>>>> the rest of the boot is not really attempted. / is mounted read-only.
>>>> Network is down.
>>>> >
>>>> > Remounting / rw, removing the -C0 from fsck, and rebooting is OK. You
>>>> still get a scary error, but the system comes up fine.
>>>> >
>>>> > See also https://bugs.alpinelinux.org/issues/8090 for raspberry pi
>>>> breakage and suggested fix (seems reasonable to me: write a simple shell
>>>> script wrapper for fsck.vfat and fsck.fat that ignores ext2/3/4 arguments).
>>>> >
>>>> > I think this must be fixed before a release.
>>>> >
>>>> >
>>>> > Virtual EFI fail
>>>> >
>>>> > Virtual's virthardened kernel lacks EFI support (even in module
>>>> form). Also it is worse on VirtualBox EFI since it also lacks video
>>>> drivers. The serial console works, but is hard to use (telnet lacks
>>>> tab-completion, GNU screen requires socat, and only one terminal). Since
>>>> /sys/firmware/efi is not available, setup-disk does not realize it was an
>>>> EFI boot and does everything wrong.
>>>> >
>>>> > I suspect it would be a good idea to include EFI support for the
>>>> Virtual ISO / virthardened kernel too. The fix would make Alpine seem more
>>>> reliable and would cut down on the "why is the screen black?" questions.
>>>> However, to workaround it is easy to turn off EFI, and legacy BIOS is more
>>>> standard for virtual machines, I believe.
>>>> >
>>>> >
>>>> >
>>>> > ---
>>>> > 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
>>>> ---
>>>>
>>>>
>>>
>>>
>>
>
> --
-- Kiyoshi Aman

Re: [alpine-devel] Alpine Linux 3.7.0 Release Candidate 1 on VirtualBox

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20171201173722.7d94d98c@ncopa-desktop.copa.dup.pw>
In-Reply-To
<CAFvNWOQj-M=e=ku1vStxXW9yDKv8S6WmgE=UepgKoVVDJPmEzg@mail.gmail.com> (view parent)
Sender timestamp
1512146242
DKIM signature
missing
Download raw message
On Thu, 30 Nov 2017 09:50:20 -0500
Gennady Feldman <gena01@gmail.com> wrote:

> Hi,
> 
> From a quick look looks like:
> CONFIG_EFI=y
> CONFIG_EFI_STUB=y
> 
> are missing from the virthardened config.

Thank you. this was very useful.

I am sorry that we didn't have time to get that in before the 3.7.0
release.

I believe it is useful to be able to choose wherever you want use EFI
or legacy bios, even for the virt kernel, so i think we should fix this.

Thank you!

-nc

> 
> Thank you,
> 
> On Wed, Nov 29, 2017 at 12:14 PM, Natanael Copa <ncopa@alpinelinux.org>
> wrote:
> 
> > Hi,
> >
> > Thanks you very much for testing.
> >
> > I think the most critical issues are fixed. I have not bothered fix the
> > eject issue, since I think it mostly affects virtualbox only.
> >
> > I haven't looked at the alpine-virt + efi issue, yet. I suppose there
> > are some kernel modules that are needed?
> >
> > Can you please re-run the tests with the 3.7.0_rc3?
> >
> > Thanks!
> >
> > -nc
> >
> > On Sat, 25 Nov 2017 21:39:02 -0500
> > Jack Schmidt <alpine@mowsey.org> wrote:
> >  
> > > Here are my notes on Alpine 3.7.0 rc1 installations using VirtualBox  
> > hosted on x86_64 Darwin.  
> > >
> > >
> > > Summary:
> > >
> > > * Standard, Extended, Vanilla, Virtual on BIOS just work (minor issues)
> > > * Standard, Extended, Vanilla on EFI has one major issue (bad fsck)
> > > * Virtual is broken on EFI (no kernel support)
> > >
> > > In each case I tried to do a base install to an IDE disk, as "sys",  
> > default options. I also tried booting the ISO as a run-from-ram system.
> > Virtual on EFI requires a serial console, but otherwise all ISOs
> > run-from-ram smoothly.  
> > >
> > > The fsck issue needs to be fixed. The 4.9.63 vs 4.9.59 should be fixed.  
> > The Virtual EFI probably should be fixed, but is easily worked-around by
> > end users. The minor issues would be nice to increase adoption of bootable
> > alpine, but aren't necessary. I assume docker containers are just fine: I
> > use edge all the time without trouble.  
> > >
> > >
> > > Standard, Extended, Vanilla, Virtual legacy BIOS minor issues:
> > >
> > > * Install boot might be too quiet for too long
> > >
> > > The BIOS boot takes 5 to 20 seconds, so the "quiet" option in  
> > boot/syslinux/syslinux.cfg might need to be accompanied by a "say" or a
> > "menu autoboot" type thing. Grub EFI boot is mostly better, but sometimes
> > takes a long time between messages. The installed version is a little slow,
> > but has a reasonable amount of messages to let you know it is progressing.  
> > >
> > >
> > > Standard, Extended, Vanilla, Virtual both BIOS and EFI minor issues:
> > >
> > > * After setup-alpine is complete, eject cdrom
> > > * Install boot and installed root use different kernels, rescue is hard
> > > * (hardened/virthardened) Guest additions kernel version problem
> > >
> > > Install for BIOS works easily on Standard, Extended, Vanilla, Virtual.  
> > Install for EFI works easily on Standard, Extended, Vanilla, but fails for
> > Virtual.  
> > >
> > > After the install, setup-alpine asks to reboot, but doesn't "eject -s"  
> > (-s required for me) the cd. That means alpine reboots under the readonly
> > cdrom with a tmpfs. This works fine, but is surprising if you are
> > installing software.  
> > >
> > > After the eject, system comes up much more noisily / green, so probably  
> > reassuring.  
> > >
> > > However, it comes up under 4.9.59-0-*hardened or 4.9.65 vanilla, so one  
> > can't use the ISO's 4.9.63 kernel to boot a rescue. If it isn't too much
> > trouble, for the final 3.7 release, it'd be good if the kernel matched on
> > the ISO's boot and the ISO's apk.  
> > >
> > > Guest additions (mostly not needed by me) are hard to load, since they  
> > are in /lib/modules/4.9.65-* but the kernel is actually 4.9.59-*. Once that
> > is fixed, all good.  
> > >
> > >
> > > Standard, Extended, Vanilla EFI issue (vfat.fsck)
> > >
> > > * 1.5GB disk required
> > > * vfat.fsck
> > >
> > > Alpine is known for it's very small size. The ISOs are a nice size. I  
> > have a VM that runs off a 10MB iso, and the Virtual ISO is good at under
> > 40MB. I was trying out ubuntu variations and had to choose my physical
> > network to handle the each-iso-is-a-gig downloads. Alpine is very easy to
> > try. However, the new EFI install creates a 500MB /boot/efi partition to
> > hold 500KB of boot data. It might be worthwhile to check the total size of
> > the disk, and not use so much on it for smaller (1 or 2 gig) drives.  
> > >
> > > More importantly /boot/efi fails its fsck due to a syntax error:
> > >
> > > fsck.vfat: unrecognized option: C
> > >
> > > This is from /etc/init.d/fsck. Since the fsck service fails, most of the  
> > rest of the boot is not really attempted. / is mounted read-only. Network
> > is down.  
> > >
> > > Remounting / rw, removing the -C0 from fsck, and rebooting is OK. You  
> > still get a scary error, but the system comes up fine.  
> > >
> > > See also https://bugs.alpinelinux.org/issues/8090 for raspberry pi  
> > breakage and suggested fix (seems reasonable to me: write a simple shell
> > script wrapper for fsck.vfat and fsck.fat that ignores ext2/3/4 arguments).  
> > >
> > > I think this must be fixed before a release.
> > >
> > >
> > > Virtual EFI fail
> > >
> > > Virtual's virthardened kernel lacks EFI support (even in module form).  
> > Also it is worse on VirtualBox EFI since it also lacks video drivers. The
> > serial console works, but is hard to use (telnet lacks tab-completion, GNU
> > screen requires socat, and only one terminal). Since /sys/firmware/efi is
> > not available, setup-disk does not realize it was an EFI boot and does
> > everything wrong.  
> > >
> > > I suspect it would be a good idea to include EFI support for the Virtual  
> > ISO / virthardened kernel too. The fix would make Alpine seem more reliable
> > and would cut down on the "why is the screen black?" questions. However, to
> > workaround it is easy to turn off EFI, and legacy BIOS is more standard for
> > virtual machines, I believe.  
> > >
> > >
> > >
> > > ---
> > > 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
---

Re: [alpine-devel] Alpine Linux 3.7.0 Release Candidate 1 on VirtualBox

Natanael Copa <n@tanael.org>
Details
Message ID
<20171201173756.51b76959@ncopa-desktop.copa.dup.pw>
In-Reply-To
<CAFvNWOTC2zBXX8TY0aoa9vdfqbFi+A7wsmk4bHU3PbQhjo6+kg@mail.gmail.com> (view parent)
Sender timestamp
1512146276
DKIM signature
missing
Download raw message
On Fri, 1 Dec 2017 10:10:04 -0500
Gennady Feldman <gena01@gmail.com> wrote:
 
> P.S. Can somebody bump community/virtualbox-guest-additions/APKBUILD 5.1.26
> => 5.1.30?  

done. Thanks!

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Alpine Linux 3.7.0 Release Candidate 1 on VirtualBox

Jakub Jirutka <jakub@jirutka.cz>
Details
Message ID
<F5BDD5E2-281B-4159-9C38-B28995447BB8@jirutka.cz>
In-Reply-To
<CAFvNWOTC2zBXX8TY0aoa9vdfqbFi+A7wsmk4bHU3PbQhjo6+kg@mail.gmail.com> (view parent)
Sender timestamp
1512146658
DKIM signature
missing
Download raw message
Hi Gennady,

> Any reason you are against enabling it?


I’m not strongly against it, I just prefer to keep number of enabled features at minimum (and yes, I know that the current configs are exactly opposite). I don’t see any added value of EFI for VMs. Actually I can hardly see it even for physical HW, it just allowed vendors to add more crap and bloat into it, but that’s a different story.

It other devs don’t mind adding these features, let’s do it.

Jakub

> On 1. Dec 2017, at 16:10, Gennady Feldman <gena01@gmail.com> wrote:
> 
> Hi Jakub,
> 
> Was thinking a bit more about virt + EFI.. Any reason you are against enabling it? It looks like various VM platforms have already added or are adding EFI support to replace "legacy BIOS" as part of the VM environment.
> 
> Right now that kernel doesn't boot and from the looks of it it's only enabling 2 modules.
> 
> P.S. Can somebody bump community/virtualbox-guest-additions/APKBUILD 5.1.26 => 5.1.30?
> 
> Thank you,
> 
> Gennady
> 
> On Thu, Nov 30, 2017 at 7:50 PM, Gennady Feldman <gena01@gmail.com <gena01@gmail.com>> wrote:
> HI Jakub,
> 
> I am going to answer what I know ( I am sure others will have their own reasons). I have Virtualbox 5.1.30 (there's also 5.2.x out) installed on Windows 7. 
> Right now from what I can see it's NOT a requirement, but the option is there. 
> 
> I did download and try to play a bit with the 3.7rc3 both virt and standard. Virt doesn't even boot. Standard seems to be fine as long as I don't install the virt kernel and try to boot with it.
> 
> From what I read EFI seems like the replacement for BIOS and should provide a number of benefits including a better/bigger console (which I like quite a bit, kinda hate doing console installs
> using legacy BIOS inside VirtualBox) and faster boot time among other things. I might even convert my Alpine VMs to use it once virt kernel supports it.
> 
> I guess from MBR <=> GPT perspective it could go either way. Things might get interesting with bigger external volumes, but not for something I am working/messing with right now.
> 
> setup-disk does some interesting stuff in EFI mode:
> - boot has hard-coded 512 (which seems quite high?)
> - creates a swap partition (2G for me). I would love to turn that off if I am running inside VirtualBox or being able to choose.
> 
> I also wanted to ask if it would make sense to have "setup-virtualbox" script that would install virtualbox packages and tweak some things for VMs
> running inside VirtualBox.
> 
> Thank you,
> 
> Gennady
> 
> On Thu, Nov 30, 2017 at 9:52 AM, Jakub Jirutka <jakub@jirutka.cz <jakub@jirutka.cz>> wrote:
> Wait, VirtualBox *requires* EFI now? If not, why to enable it in kernel for VMs?
> 
> Jakub
> 
>> On 30. Nov 2017, at 15:50, Gennady Feldman <gena01@gmail.com <gena01@gmail.com>> wrote:
>> 
>> Hi,
>> 
>> From a quick look looks like:
>> CONFIG_EFI=y
>> CONFIG_EFI_STUB=y
>> 
>> are missing from the virthardened config.
>> 
>> Thank you,
>> 
>> On Wed, Nov 29, 2017 at 12:14 PM, Natanael Copa <ncopa@alpinelinux.org <ncopa@alpinelinux.org>> wrote:
>> Hi,
>> 
>> Thanks you very much for testing.
>> 
>> I think the most critical issues are fixed. I have not bothered fix the
>> eject issue, since I think it mostly affects virtualbox only.
>> 
>> I haven't looked at the alpine-virt + efi issue, yet. I suppose there
>> are some kernel modules that are needed?
>> 
>> Can you please re-run the tests with the 3.7.0_rc3?
>> 
>> Thanks!
>> 
>> -nc
>> 
>> On Sat, 25 Nov 2017 21:39:02 -0500
>> Jack Schmidt <alpine@mowsey.org <alpine@mowsey.org>> wrote:
>> 
>> > Here are my notes on Alpine 3.7.0 rc1 installations using VirtualBox hosted on x86_64 Darwin.
>> >
>> >
>> > Summary:
>> >
>> > * Standard, Extended, Vanilla, Virtual on BIOS just work (minor issues)
>> > * Standard, Extended, Vanilla on EFI has one major issue (bad fsck)
>> > * Virtual is broken on EFI (no kernel support)
>> >
>> > In each case I tried to do a base install to an IDE disk, as "sys", default options. I also tried booting the ISO as a run-from-ram system. Virtual on EFI requires a serial console, but otherwise all ISOs run-from-ram smoothly.
>> >
>> > The fsck issue needs to be fixed. The 4.9.63 vs 4.9.59 should be fixed. The Virtual EFI probably should be fixed, but is easily worked-around by end users. The minor issues would be nice to increase adoption of bootable alpine, but aren't necessary. I assume docker containers are just fine: I use edge all the time without trouble.
>> >
>> >
>> > Standard, Extended, Vanilla, Virtual legacy BIOS minor issues:
>> >
>> > * Install boot might be too quiet for too long
>> >
>> > The BIOS boot takes 5 to 20 seconds, so the "quiet" option in boot/syslinux/syslinux.cfg might need to be accompanied by a "say" or a "menu autoboot" type thing. Grub EFI boot is mostly better, but sometimes takes a long time between messages. The installed version is a little slow, but has a reasonable amount of messages to let you know it is progressing.
>> >
>> >
>> > Standard, Extended, Vanilla, Virtual both BIOS and EFI minor issues:
>> >
>> > * After setup-alpine is complete, eject cdrom
>> > * Install boot and installed root use different kernels, rescue is hard
>> > * (hardened/virthardened) Guest additions kernel version problem
>> >
>> > Install for BIOS works easily on Standard, Extended, Vanilla, Virtual. Install for EFI works easily on Standard, Extended, Vanilla, but fails for Virtual.
>> >
>> > After the install, setup-alpine asks to reboot, but doesn't "eject -s" (-s required for me) the cd. That means alpine reboots under the readonly cdrom with a tmpfs. This works fine, but is surprising if you are installing software.
>> >
>> > After the eject, system comes up much more noisily / green, so probably reassuring.
>> >
>> > However, it comes up under 4.9.59-0-*hardened or 4.9.65 vanilla, so one can't use the ISO's 4.9.63 kernel to boot a rescue. If it isn't too much trouble, for the final 3.7 release, it'd be good if the kernel matched on the ISO's boot and the ISO's apk.
>> >
>> > Guest additions (mostly not needed by me) are hard to load, since they are in /lib/modules/4.9.65-* but the kernel is actually 4.9.59-*. Once that is fixed, all good.
>> >
>> >
>> > Standard, Extended, Vanilla EFI issue (vfat.fsck)
>> >
>> > * 1.5GB disk required
>> > * vfat.fsck
>> >
>> > Alpine is known for it's very small size. The ISOs are a nice size. I have a VM that runs off a 10MB iso, and the Virtual ISO is good at under 40MB. I was trying out ubuntu variations and had to choose my physical network to handle the each-iso-is-a-gig downloads. Alpine is very easy to try. However, the new EFI install creates a 500MB /boot/efi partition to hold 500KB of boot data. It might be worthwhile to check the total size of the disk, and not use so much on it for smaller (1 or 2 gig) drives.
>> >
>> > More importantly /boot/efi fails its fsck due to a syntax error:
>> >
>> > fsck.vfat: unrecognized option: C
>> >
>> > This is from /etc/init.d/fsck. Since the fsck service fails, most of the rest of the boot is not really attempted. / is mounted read-only. Network is down.
>> >
>> > Remounting / rw, removing the -C0 from fsck, and rebooting is OK. You still get a scary error, but the system comes up fine.
>> >
>> > See also https://bugs.alpinelinux.org/issues/8090 <https://bugs.alpinelinux.org/issues/8090> for raspberry pi breakage and suggested fix (seems reasonable to me: write a simple shell script wrapper for fsck.vfat and fsck.fat that ignores ext2/3/4 arguments).
>> >
>> > I think this must be fixed before a release.
>> >
>> >
>> > Virtual EFI fail
>> >
>> > Virtual's virthardened kernel lacks EFI support (even in module form). Also it is worse on VirtualBox EFI since it also lacks video drivers. The serial console works, but is hard to use (telnet lacks tab-completion, GNU screen requires socat, and only one terminal). Since /sys/firmware/efi is not available, setup-disk does not realize it was an EFI boot and does everything wrong.
>> >
>> > I suspect it would be a good idea to include EFI support for the Virtual ISO / virthardened kernel too. The fix would make Alpine seem more reliable and would cut down on the "why is the screen black?" questions. However, to workaround it is easy to turn off EFI, and legacy BIOS is more standard for virtual machines, I believe.
>> >
>> >
>> >
>> > ---
>> > Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org <alpine-devel%2Bunsubscribe@lists.alpinelinux.org>
>> > Help:         alpine-devel+help@lists.alpinelinux.org <alpine-devel%2Bhelp@lists.alpinelinux.org>
>> > ---
>> >
>> 
>> 
>> 
>> ---
>> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org <alpine-devel%2Bunsubscribe@lists.alpinelinux.org>
>> Help:         alpine-devel+help@lists.alpinelinux.org <alpine-devel%2Bhelp@lists.alpinelinux.org>
>> ---
>> 
>> 
> 
> 
> 

Re: [alpine-devel] Alpine Linux 3.7.0 Release Candidate 1 on VirtualBox

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20171201183253.7c4a2c8e@ncopa-desktop.copa.dup.pw>
In-Reply-To
<CAFvNWOTC2zBXX8TY0aoa9vdfqbFi+A7wsmk4bHU3PbQhjo6+kg@mail.gmail.com> (view parent)
Sender timestamp
1512149573
DKIM signature
missing
Download raw message
On Fri, 1 Dec 2017 10:10:04 -0500
Gennady Feldman <gena01@gmail.com> wrote:

> P.S. Can somebody bump community/virtualbox-guest-additions/APKBUILD 5.1.26
> => 5.1.30?  

done!

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)