Bug#773309: CONFIG_PSTORE not enabled for arm64
On Thu, 2014-12-18 at 20:08 +, Leif Lindholm wrote: > On Thu, Dec 18, 2014 at 06:35:25PM +, Ian Campbell wrote: > > > > Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what > > > > pstore is, so sorry if this is a silly question). > > > > > > I am actually not concerned about pstore itself, but rather by the > > > lack of similarity between platforms. > > > > Consistency is a worthwhile goal, but not at the expense of enabling > > legacy x86 junk on new architectures where it can never have any > > relevance. I don't know if pstore fits that bill, which is why I was > > asking about it. > > > > If pstore is going to be a useful thing on arm64 then of course we > > should enable it. We should *not* enable it purely to gain the side > > effect of loading efivars (the more so since as discussed below it seems > > like efivars itself is a legacy interface). > > pstore is not legacy nonsense (it's for storing system crash > information persistently). I don't actively care only since I've also > not heard anyone screaming for it. Thanks, it does sound useful rather than legacy. Given what Ben said it does seem like it would be worthwhile to enable. > Ok, so I had a peek in codesearch.debian.net, to see what current > users we have. elilo can be ignored, dracut probably doesn't matter > (?), mdadm has it in platform-intel.c so still wouldn't matter, kernel > doesn't matter and grub2 will work anyway. > > Which leaves us with the risk of out-of-tree software making use of it. My inclination is towards suggesting that if people are running out-of-tree software which needs the efivars interface then they should arrange for it to be loaded themselves (e.g. by adding to /etc/modules). Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773309: CONFIG_PSTORE not enabled for arm64
On Thu, 2014-12-18 at 20:13 +, Leif Lindholm wrote: > *grumble, accidental send* :-) > On Thu, Dec 18, 2014 at 08:08:31PM +, Leif Lindholm wrote: > > > > > (I don't have an x86 EFI system available to poke around and answer > > > > > these for myself). > > > > > > > > > > I'm wondering if we ought to figure out how to load it automatically > > > > > independent of the pstore stuff, for all arches. > > > > > > > > I'd be happy for it not to be autoloaded, as long as it was consistent > > > > across architectures. > > > > > > I think (although I'm somewhat inferring some pieces) that the right > > > answer here is to have something (mountkernfs.sh/systemd/pixies) mount > > > efivarfs and to ignore the deprecated efivars thing on non-x86. The > > > pstore stuff should be considered a separate feature request in its own > > > right. > > Well, that was the actual thing I asked for in this bug, so let's keep > the pstore aspect here. Right. > > > I could clone this bug and retitle+reassign the other half into a bug to > > > handle the efi half, but TBH I think conflating the EFI variable access > > > from userspace requirement with enabling pstore in the kernel is just > > > going to end up causing confusion, so a separate report to get efivarfs > > > mounted would probably be best. > > Fair point. > Coming up. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773309: CONFIG_PSTORE not enabled for arm64
On Thu, 2014-12-18 at 20:08 +, Leif Lindholm wrote: > On Thu, Dec 18, 2014 at 06:35:25PM +, Ian Campbell wrote: > > > > Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what > > > > pstore is, so sorry if this is a silly question). > > > > > > I am actually not concerned about pstore itself, but rather by the > > > lack of similarity between platforms. > > > > Consistency is a worthwhile goal, but not at the expense of enabling > > legacy x86 junk on new architectures where it can never have any > > relevance. I don't know if pstore fits that bill, which is why I was > > asking about it. > > > > If pstore is going to be a useful thing on arm64 then of course we > > should enable it. We should *not* enable it purely to gain the side > > effect of loading efivars (the more so since as discussed below it seems > > like efivars itself is a legacy interface). > > pstore is not legacy nonsense (it's for storing system crash > information persistently). I don't actively care only since I've also > not heard anyone screaming for it. [...] systemd can pull crash logs out of pstore and add them to the journal (and hence to syslog, by default). The bug script in linux-image packages also offers to extract crash logs from pstore. (I don't think I've yet seen a bug report where this was done, but then efi-pstore was disabled by default in the wheezy kernel.) Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#773309: CONFIG_PSTORE not enabled for arm64
*grumble, accidental send* On Thu, Dec 18, 2014 at 08:08:31PM +, Leif Lindholm wrote: > > > > (I don't have an x86 EFI system available to poke around and answer > > > > these for myself). > > > > > > > > I'm wondering if we ought to figure out how to load it automatically > > > > independent of the pstore stuff, for all arches. > > > > > > I'd be happy for it not to be autoloaded, as long as it was consistent > > > across architectures. > > > > I think (although I'm somewhat inferring some pieces) that the right > > answer here is to have something (mountkernfs.sh/systemd/pixies) mount > > efivarfs and to ignore the deprecated efivars thing on non-x86. The > > pstore stuff should be considered a separate feature request in its own > > right. Well, that was the actual thing I asked for in this bug, so let's keep the pstore aspect here. > > I could clone this bug and retitle+reassign the other half into a bug to > > handle the efi half, but TBH I think conflating the EFI variable access > > from userspace requirement with enabling pstore in the kernel is just > > going to end up causing confusion, so a separate report to get efivarfs > > mounted would probably be best. Fair point. Coming up. / Leif -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773309: CONFIG_PSTORE not enabled for arm64
On Thu, Dec 18, 2014 at 06:35:25PM +, Ian Campbell wrote: > > > Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what > > > pstore is, so sorry if this is a silly question). > > > > I am actually not concerned about pstore itself, but rather by the > > lack of similarity between platforms. > > Consistency is a worthwhile goal, but not at the expense of enabling > legacy x86 junk on new architectures where it can never have any > relevance. I don't know if pstore fits that bill, which is why I was > asking about it. > > If pstore is going to be a useful thing on arm64 then of course we > should enable it. We should *not* enable it purely to gain the side > effect of loading efivars (the more so since as discussed below it seems > like efivars itself is a legacy interface). pstore is not legacy nonsense (it's for storing system crash information persistently). I don't actively care only since I've also not heard anyone screaming for it. > > > Is efivars needed only for efibootmgr or are there other reasons to want > > > it? > > > > The /sys/firmware/efi/vars interface exported by efivars is actually a > > legacy api (efivarfs is the preferred one), but since it is still > > shipped, alignment across architectures would be desirable. > > Enabling legacy stuff on new architectures by default is not inherently > desirable IMHO. It would be far better to use the new/proper stuff right > out the gate, at least by default. I agree, with the exception that where use of a legacy API has become widespread enough, we may still need to keep it around until we've killed off any important users. > > There may or may not currently be other users than efibootmgr. > > I can see references in the efivars package (which provides libefivars, > which efibootmgr uses) to efivarfs. Which suggests to me that loading > efivars is not what is needed, but rather the automounting > of /sys/firmware/efi/vars is. That would need to be a bug against some > other package (the mountkernfs.sh providing one would be my best guess, > which may well be systemd these days via some other means, #744301 seems > related, although it goes further). Absolutely - I intend to raise that bug on initscripts (but even looking into that opened up a bit of a rabbit hole). Ok, so I had a peek in codesearch.debian.net, to see what current users we have. elilo can be ignored, dracut probably doesn't matter (?), mdadm has it in platform-intel.c so still wouldn't matter, kernel doesn't matter and grub2 will work anyway. Which leaves us with the risk of out-of-tree software making use of it. > > > (I don't have an x86 EFI system available to poke around and answer > > > these for myself). > > > > > > I'm wondering if we ought to figure out how to load it automatically > > > independent of the pstore stuff, for all arches. > > > > I'd be happy for it not to be autoloaded, as long as it was consistent > > across architectures. > > I think (although I'm somewhat inferring some pieces) that the right > answer here is to have something (mountkernfs.sh/systemd/pixies) mount > efivarfs and to ignore the deprecated efivars thing on non-x86. The > pstore stuff should be considered a separate feature request in its own > right. > > I could clone this bug and retitle+reassign the other half into a bug to > handle the efi half, but TBH I think conflating the EFI variable access > from userspace requirement with enabling pstore in the kernel is just > going to end up causing confusion, so a separate report to get efivarfs > mounted would probably be best. > > Ian. > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773309: CONFIG_PSTORE not enabled for arm64
Control: severity -1 wishlist On Wed, 2014-12-17 at 16:30 +, Leif Lindholm wrote: > On Wed, Dec 17, 2014 at 02:57:17PM +, Ian Campbell wrote: > > > Could we enable CONFIG_PSTORE for arm64 as well, please? > > > > Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what > > pstore is, so sorry if this is a silly question). > > I am actually not concerned about pstore itself, but rather by the > lack of similarity between platforms. Consistency is a worthwhile goal, but not at the expense of enabling legacy x86 junk on new architectures where it can never have any relevance. I don't know if pstore fits that bill, which is why I was asking about it. If pstore is going to be a useful thing on arm64 then of course we should enable it. We should *not* enable it purely to gain the side effect of loading efivars (the more so since as discussed below it seems like efivars itself is a legacy interface). > > Is efivars needed only for efibootmgr or are there other reasons to want > > it? > > The /sys/firmware/efi/vars interface exported by efivars is actually a > legacy api (efivarfs is the preferred one), but since it is still > shipped, alignment across architectures would be desirable. Enabling legacy stuff on new architectures by default is not inherently desirable IMHO. It would be far better to use the new/proper stuff right out the gate, at least by default. > There may or may not currently be other users than efibootmgr. I can see references in the efivars package (which provides libefivars, which efibootmgr uses) to efivarfs. Which suggests to me that loading efivars is not what is needed, but rather the automounting of /sys/firmware/efi/vars is. That would need to be a bug against some other package (the mountkernfs.sh providing one would be my best guess, which may well be systemd these days via some other means, #744301 seems related, although it goes further). > > (I don't have an x86 EFI system available to poke around and answer > > these for myself). > > > > I'm wondering if we ought to figure out how to load it automatically > > independent of the pstore stuff, for all arches. > > I'd be happy for it not to be autoloaded, as long as it was consistent > across architectures. I think (although I'm somewhat inferring some pieces) that the right answer here is to have something (mountkernfs.sh/systemd/pixies) mount efivarfs and to ignore the deprecated efivars thing on non-x86. The pstore stuff should be considered a separate feature request in its own right. I could clone this bug and retitle+reassign the other half into a bug to handle the efi half, but TBH I think conflating the EFI variable access from userspace requirement with enabling pstore in the kernel is just going to end up causing confusion, so a separate report to get efivarfs mounted would probably be best. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773309: CONFIG_PSTORE not enabled for arm64
On Wed, Dec 17, 2014 at 02:57:17PM +, Ian Campbell wrote: > > Could we enable CONFIG_PSTORE for arm64 as well, please? > > Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what > pstore is, so sorry if this is a silly question). I am actually not concerned about pstore itself, but rather by the lack of similarity between platforms. As an example - grub-install currently performs a "modprobe efivars" before attempting to execute efibootmgr. Having different default behaviour x86/arm64 could however lead to future bugs of code tested only on one or the other. > Any idea what causes efi_pstore to be loaded automatically? Yes. When /sys/fs/pstore exists, /etc/init.d/mountkernfs.sh mounts a pstore filesystem there. This was not the case on wheezy, and hence efi_pstore and efivars were not autoloaded on x86 on wheezy. > Is efivars needed only for efibootmgr or are there other reasons to want > it? The /sys/firmware/efi/vars interface exported by efivars is actually a legacy api (efivarfs is the preferred one), but since it is still shipped, alignment across architectures would be desirable. There may or may not currently be other users than efibootmgr. > (I don't have an x86 EFI system available to poke around and answer > these for myself). > > I'm wondering if we ought to figure out how to load it automatically > independent of the pstore stuff, for all arches. I'd be happy for it not to be autoloaded, as long as it was consistent across architectures. / Leif -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773309: CONFIG_PSTORE not enabled for arm64
On Tue, 2014-12-16 at 17:52 +, Leif Lindholm wrote: > Package: src:linux > Severity: normal > X-Debbugs-CC: i...@debian.org > > I noticed efivars was being automatically loaded on boot on my > installed amd64 Jessie, but not on my arm64 Jessie. The > installer/rescue image automatically loads it for both. > Turns out on amd64, efivars is being pulled in as a dependency for > efi_pstore, which is not built for arm64 since CONFIG_PSTORE is not > enabled. > > Upstream, CONFIG_PSTORE is not enabled since CONFIG_MISC_FS is not > enabled in the upstream defconfig. In debian, however, CONFIG_MISC_FS > is enabled for all architectures, but CONFIG_PSTORE only for > ia64/kernelarch-x86. > > Could we enable CONFIG_PSTORE for arm64 as well, please? Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what pstore is, so sorry if this is a silly question). Any idea what causes efi_pstore to be loaded automatically? Is efivars needed only for efibootmgr or are there other reasons to want it? (I don't have an x86 EFI system available to poke around and answer these for myself). I'm wondering if we ought to figure out how to load it automatically independent of the pstore stuff, for all arches. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773309: CONFIG_PSTORE not enabled for arm64
Package: src:linux Severity: normal X-Debbugs-CC: i...@debian.org I noticed efivars was being automatically loaded on boot on my installed amd64 Jessie, but not on my arm64 Jessie. The installer/rescue image automatically loads it for both. Turns out on amd64, efivars is being pulled in as a dependency for efi_pstore, which is not built for arm64 since CONFIG_PSTORE is not enabled. Upstream, CONFIG_PSTORE is not enabled since CONFIG_MISC_FS is not enabled in the upstream defconfig. In debian, however, CONFIG_MISC_FS is enabled for all architectures, but CONFIG_PSTORE only for ia64/kernelarch-x86. Could we enable CONFIG_PSTORE for arm64 as well, please? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
