aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2020-01-19T11:05:05Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/7612Alpine Linux can't boot with UEFI if partitioned with Gparted2020-01-19T11:05:05ZNazar MokrynskyiAlpine Linux can't boot with UEFI if partitioned with GpartedI’ve discovered very interesting bug with Alpine Kernel (I believe it is
kernel, since GRUB2/Syslinux/Gummiboot/Ubuntu’s Kernel were verified to
work under the same partitioning and only Alpine Kernel refused to boot
properly).
Imagine ...I’ve discovered very interesting bug with Alpine Kernel (I believe it is
kernel, since GRUB2/Syslinux/Gummiboot/Ubuntu’s Kernel were verified to
work under the same partitioning and only Alpine Kernel refused to boot
properly).
Imagine 2 identical UEFI setups of Alpine Linux that only differ in disk
partitioning. Assume we start with just created disk (sda) in VirtualBox
VM.
The first way to partition is Gparted:
- create GPT partition table
- create small FAT32 partition (say 300M) (sda1)
- create ext4 partition for the rest of available space (sda2)
- apply changes
- set esp flag on sda1
The second way to partition disk is using gdisk:
- create partition table
- create small EFI System partition (say 300M) (sda1)
- create ext4 partition for the rest of available space (sda2)
- write changes to the disk
With disk partitioned using Gparted as described above system will stop
booting after boot manager with black screen. Disk partitioned with
gdisk will boot fine.
I’ve also tried FAT16 with Gparted - no difference, modifying layout
prepared with gdisk using Gparted (like resizing ext4 partition) also
seems to breaks boot process for Alpine Linux (needs more testing, was
only replicated once).
This issue is not a coincidence and was replicated both under VirtualBox
VM and on physical machine multiple (>2) times.
3.6.2 STANDARD x86\_64 build was used during testing.
*(from redmine: issue id 7612, created on 2017-07-31)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/8093Raspberry Pi: Clock skew messages on startup; simple fix2019-07-12T15:29:42ZHarald BeckerRaspberry Pi: Clock skew messages on startup; simple fixThe Raspberry Pi has no hardware clock, so it throw warnings and errors
on OpenRC startup, even when using swclock service instead of hwclock.
A simple fix make OpenRC happy and let those messages vanish:
Create an empty file /etc/init...The Raspberry Pi has no hardware clock, so it throw warnings and errors
on OpenRC startup, even when using swclock service instead of hwclock.
A simple fix make OpenRC happy and let those messages vanish:
Create an empty file /etc/init.d/.use-swclock to signal usage of this
hack (just to be able to disable on systems with hardware clock).
Add the following snippet in /lib/rc/sh/init.sh, just after setting up
/proc:
if \[ -e /etc/init.d/.use-swclock \]; then
“$RC\_LIBEXECDIR/sbin/swclock” /etc/init.d
fi
… with this added, OpenRC set the system clock to the date/time of
/etc/init.d (the last modification time), then use this date to create
the /run directories. As the time of the dependency tree
/run/openrc/deptree is now not below the date of /etc/init.d we are gone
and OpenRC is happy.
The clock shall then still be set with either swclock service or an NTP
service.
The hack just make OpenRC happy and suppresses the confusing “Clock
skew” messages. As far as I can tell, it has no other impacts.
*(from redmine: issue id 8093, created on 2017-11-02)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9978Allow initramfs search depth to be user-configurable2021-01-09T18:04:01ZChloe KudryavtsevAllow initramfs search depth to be user-configurableCurrently, the initramfs searches for two items:
- A “bootrepo”, identified by a `.boot_repository` file
- An apkovl file, identified as `*.apkovl.tar.gz*`
This is done within `nlplug-findfs`, which recurses into various
coldplugge...Currently, the initramfs searches for two items:
- A “bootrepo”, identified by a `.boot_repository` file
- An apkovl file, identified as `*.apkovl.tar.gz*`
This is done within `nlplug-findfs`, which recurses into various
coldplugged devices.
The depth of the recursion is controlled by
`struct recurseopts.maxdepth`, which is hardcoded to 1 in
`nlplug-findfs.c::893`.
There is also a `find_boot_repositories` function in
`initramfs-init.in::240`, which uses a hardcoded maxdepth of 3.
However, `find_boot_repositories` seems to be more of a fallback, only
being called after relocation, and using `$ALPINE_REPO` if/when
available.
This is fine for the default images, in which `apks` is in the root of
the filesystem, but makes creating custom boot media much more
difficult.
As such, please make the maxdepth configurable, with the initramfs flag
being shared between `nlplug-findfs` and `find_boot_repositories`.
These are the things that would need to be done, from what I can tell:
1. Add a new initramfs-init command line option, e.g “depth”, which
should default to 1 (current value).
2. Use `$KOPT_depth` in `find_boot_repositories`.
3. Add a new int to `struct ueventconf`, e.g “depth”, which should be
of type int, or unsigned int.
4. Add parsing for ‘d’ in `main()` and document it in `usage()`.
5. Set `.maxdepth` to `conf->depth` in `nlplug-findfs.c::893`.
6. Set various invocations of `trigger_path` to use `conf->depth`
instead of a hardcoded `max_depth` when appropriate.
7. Pass `-d $KOPT_depth` to `nlplug-findfs` when appropriate within
`initramfs-init`.
8. Document the changes in `nlplug-findfs.1.in` and
`mkinitfs-bootparam.7.in`.
*(from redmine: issue id 9978, created on 2019-02-12)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10385kernel option apkovl is not working2023-05-09T14:24:06Zalgitbotkernel option apkovl is not workingCheck **initramfs-init.in** file:
- **unpack\_apkovl** is called before setting **$repofile**
That’s why booting is crashes with filed to install openssl package
*(from redmine: issue id 10385, created on 2019-05-01)*Check **initramfs-init.in** file:
- **unpack\_apkovl** is called before setting **$repofile**
That’s why booting is crashes with filed to install openssl package
*(from redmine: issue id 10385, created on 2019-05-01)*3.19.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10547after install on ssd on reboot sysroot failed2019-07-12T15:48:46Zmartin lolliniafter install on ssd on reboot sysroot failedInstalling alpine in a eeepc netbook and running alpine iso from a
sdcard then execute setup-alpine, last, install \[sys\] to ssd disk to
/dev/sdb.
Reboot and get this sysroot failed. More Details on error.jpg.
The UUID is /dev/sda3 ...Installing alpine in a eeepc netbook and running alpine iso from a
sdcard then execute setup-alpine, last, install \[sys\] to ssd disk to
/dev/sdb.
Reboot and get this sysroot failed. More Details on error.jpg.
The UUID is /dev/sda3 not /dev/sda1 that is the boot partition.
I try changing UUID in extlinux.conf without positive effect.
*(from redmine: issue id 10547, created on 2019-06-09)*
* Uploads:
* ![error](/uploads/e1179e5e98ef129af350017d06eb13bc/error.jpeg)
* ![blkidemergencyconsole](/uploads/0220ab274335e2ca44ec5e50c3abd3a1/blkidemergencyconsole.jpeg) blkid command on emergency console
* ![blkidfromsdcard](/uploads/5949d7c1a7dd2f9281803e7f78b62738/blkidfromsdcard.jpeg) blkid command from console booting from sdcard
* ![kernelpanic](/uploads/d5621daab266883bf2493b6ccb223395/kernelpanic.jpeg) exit command from emergency consoleNatanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11589Diskless APKOVL loading dosn't work on btrfs and xfs filesystems, or nvme-bas...2022-05-02T09:07:13ZTyler James FrederickDiskless APKOVL loading dosn't work on btrfs and xfs filesystems, or nvme-based devicesHi,
I'm using the stock 3.11.6 ISO in conjunction with an APKOVL for a diskless-boot. The configuration works just fine when I place the APKOVL on an ext4-formatted partition on a SCSI-device. However, when I place the same APKOVL on an...Hi,
I'm using the stock 3.11.6 ISO in conjunction with an APKOVL for a diskless-boot. The configuration works just fine when I place the APKOVL on an ext4-formatted partition on a SCSI-device. However, when I place the same APKOVL on any of the following, it's not loaded:
* A btrfs-formatted partition
* An xfs-formatted partition
* Any partition on an NVMe device (e.g. nvme0n1p1)
* Anywhere other than the root of a partition (e.g. in a subdirectory)
I can see the last item being by design, but as for the others, there's already native btrfs/xfs/nvme support, so I would expect them to be supported out-of-the-box.
Thanks!