Received: from disco.pogo.org.uk (disco.pogo.org.uk [93.93.128.62]) by gbr-app-1.alpinelinux.org (Postfix) with ESMTPS id 50AA6225AA5 for <~alpine/users@lists.alpinelinux.org>; Sun, 26 Jan 2025 15:16:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xwax.org; s=swing; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To: Subject:cc:To:From:Date:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description; bh=jo2gOVbPlB9x59O3ww9fdxMPJLtv9vrc5UYlTXt5jZQ=; b=O5GW/ tFbVkcdWGSR54bNhhanDkpZ4QATmGt7BNh1MVQYHot5gFanWMVnh7ITgIFVoMqxNjA0Tut6hetAXg ndFV7gmm9JxSwh+u8xKmCnUf+LseF6oHFa2ddyg3p/Vii93Au0cFwV8Tg+FKDYlBga89vsbyd3aA7 k5jvHWnsGsVA=; Received: from cpc93786-hari17-2-0-cust786.20-2.cable.virginm.net ([82.36.99.19] helo=stax) by disco.pogo.org.uk with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98 (FreeBSD)) (envelope-from ) id 1tc4NZ-00000000GL8-39Sb; Sun, 26 Jan 2025 15:16:53 +0000 Received: from localhost (stax.localdomain [local]) by stax.localdomain (OpenSMTPD) with ESMTPA id ff748378; Sun, 26 Jan 2025 15:16:52 +0000 (UTC) Date: Sun, 26 Jan 2025 15:16:52 +0000 (GMT) From: Mark Hills To: Sertonix cc: ~alpine/users@lists.alpinelinux.org Subject: Re: Solutions for EFI booting / copying kernels In-Reply-To: <86509949be4dc3a8b6cf9ae6482fdd97@posteo.de> Message-ID: <5210eab8-eca6-67ed-dbac-668f8c0c8f00@xwax.org> References: <8f3899df-71b7-6562-7688-7bebc6ac1f94@xwax.org> <37f7104c-96b0-7c19-a35a-081f879c71d6@xwax.org> <86509949be4dc3a8b6cf9ae6482fdd97@posteo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii (useful reply; hope you don't mind me keeping this on-list for all) On Sat, 25 Jan 2025, Sertonix wrote: > On 2025-01-21 12:20, Mark Hills wrote: > > On Mon, 20 Jan 2025, Sertonix wrote: > > > > > > I have a few Alpine systems which use EFI to boot with syslinux. > > > > > > > > I'd like to improve this setup. > > > > > > > > The kernel+initramfs are copied to /efi, where syslinux finds them. > > > > > > > > Invariably, after "apk upgrade" I forget to do this copy, resulting in a > > > > system that won't boot. > > [...] > > > I think it should work if you mount the EFI partition at /boot instead > > > of /efi. Then there isn't any copying needed. > > > > I had assumed having /boot as some kind of DOS/VFAT filesystem would cause > > trouble. It 'feels' very wrong, but I had assumed it would cause problem > > with filenames & permissions managed by apk, disk checks and so on. > > > > Is this a common practice? > > I have used VFAT partitions for /boot without any issue. Thanks for sharing your experience. The web shows up some other posts from people allowing /boot to double as /efi. What I dislike about such a proposal is VFAT lacks journaling and other robusness features compared to ext4, were this partition to fail a check on boot. That's more likely too; now that VFAT is used for a partition that changes on each kernel update. > Mounting /boot as VFAT is as far as I know standard for BIOS boot setups > which alpine supports as well. So there shouldn't be any issues with > that. My experience differs; I don't I or my employers have ever seen VFAT here. Besides, historically LILO _required_ an ext partition to host the kernel (perhaps boot or /); SYSLINUX and GRUB are capable of the same. I can't think of a reason (pre-EFI) that VFAT has ever been required as /boot? Thanks -- Mark