An unofficial Debian Installer for Pinebook Pro

[RMJ250]

Thankyou Daniel! I have been looking forward to Debian Bullseye on my PBP for a while, I hadn't tried your installer as I quite often fail at these things, but I removed line170 form the installer script as mentioned above and it ran flawlessly, typing this from my PBP with Bullseye KDE!! Looking forward to installing it to the EMMC soon,

J

[danielt]

If there are workarounds that are frequently needed then a pull request to the github project would be extremely welcome!

[Tharadash]

If there are workarounds that are frequently needed then a pull request to the github project would be extremely welcome!

Done:
https://github.com/daniel-thompson/pineb...er/pull/35


However, I must add that I have absolutely no idea what this change will affect as well.

[r10game]

This is my dream list. Unfortunately I haven't my PBP delivery yet, and you've moved so quickly before I've had opportunity to contribute!

Is there a dummy kernel package for pinning, or is that not even really necessary?
Maybe a PPA for the Debian packaged kernel and headers/source packages would be worth starting? Some frown on PPA, I know. I build so much for Deb/Ubu/Pop on Intel, it might be worth me taking up these and kernels, once my feet are wet with the machine.

The kernel is handled by the package manager (it's just a ` make bindeb-pkg` from the kernel build system though) with a tiny hack thrown in to ensure the kernel is uncompressed when it is installed to /boot (the u-boot distro boot protocol doesn't work with compressed kernels).

However the kernel is just a download rather than a proper apt repo so there is no kernel upgrade path. A PPA is a good idea although hopefully it can be obsoleted even more quickly than my installer: providing the fuel guage driver and the panel-simple update get upstreamed this cycle PPA can be obsolete as soon as Debian adopts v5.6 kernel!

ı dont thınk so  

[ab1jx]

Has anybody grumbled yet that the kernel doesn't have exfat support? Which I guess more recent Bullseye kernels do, it's been moved into the kernel. It's only an issue if you're trying to read an SD over 32 GB from like your camera. Crosslinking here to http://forums.debian.net/posting.php?mod...0&t=148964 where I posted thinking something in Bullseye was broken.

In Stretch and Buster you can just do fsck <path> or mount <path> and they work, not with this kernel. It can be done, it just takes researching it.

Is the kernel config someplace available, or is there a command to dump out the config from a running kernel? Android has a file called build.prop which is close I think, not sure it's kernel stuff though.

[moonwalkers]

Is the kernel config someplace available, or is there a command to dump out the config from a running kernel?  Android has a file called build.prop which is close I think, not sure it's kernel stuff though.

Kinda depends. First though, build.prop on Android has little to nothing to do with kernel config.
Off the top of my head - there is

Code:

zcat /proc/config.gz

that should print out the config of the currently running kernel, but that doesn't seem to be universal - it works on Debian on my PBP but not on Ubuntu on my work laptop. Probably a part of kernel config in itself. And then there are config files that are usually included in the kernel package and are installed alongside the kernel image in /boot, usually named something like `/boot/config-<version>`.

[ab1jx]

That seems to work but it's not the format I remember, I think I've mostly used menuconfig.  I've built way more BSD kernels than Linux.  Even if I enable the option though, that doesn't supply any code.

I see:

Code:

#
# DOS/FAT/EXFAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
# CONFIG_FAT_DEFAULT_UTF8 is not set
# CONFIG_EXFAT_FS is not set
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y
# end of DOS/FAT/EXFAT/NT Filesystems

So why is there both exfat and ntfs?  cat /proc/filesystems shows ntfs in there, I didn't try it.

[moonwalkers]

That seems to work but it's not the format I remember, I think I've mostly used menuconfig.  I've built way more BSD kernels than Linux.  Even if I enable the option though, that doesn't supply any code.

I see:

Code:

#
# DOS/FAT/EXFAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
# CONFIG_FAT_DEFAULT_UTF8 is not set
# CONFIG_EXFAT_FS is not set
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y
# end of DOS/FAT/EXFAT/NT Filesystems

So why is there both exfat and ntfs?  cat /proc/filesystems shows ntfs in there, I didn't try it.

I'm not sure I follow your question...

What the values in your quote mean is your kernel has built-in drivers supporting all FAT variants except for exFAT, as well as built-in support for NTFS, including read/write support for NTFS. To contrast with Ubuntu kernel on my work laptop:

Code:

CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_FAT_DEFAULT_UTF8 is not set
CONFIG_EXFAT_FS=m
CONFIG_EXFAT_DEFAULT_IOCHARSET="utf8"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

Which means exFAT is a loadable module, same for NTFS support, and NTFS R/W is not provided through kernel module but I have to use FUSE instead. My current PBP kernel is largely the same, except it actually has CONFIG_NTFS_RW set to 'y'.

The difference between 'y' and 'm' in the above configs is 'y' means driver will be built-in, always part of the kernel image on disk and in memory, whereas 'm' will be stored as a separate file and loaded in memory only when kernel actually needs it to access a file system. If that driver is important for getting to the point where kernel can mount the root FS then you need to either make that driver built-in, or make sure that loadable module is included in your initramfs image (which is usually done automatically if your /etc/initramfs-tools/initramfs.conf has MODULES=most). Otherwise if I were you I'd probably just reconfigure those drivers to be more similar to Ubuntu or Debian kernel config and call it a day.

If you don't care for building your own kernel outside of just getting the damn exFAT but would be content with an already working kernel you could use the kernel package that was built by xmixahlx, otherwise if you still prefer to build your own kernel but just want to minimize the amount of manual steps to wade through you could use xmixahlx's script for building a kernel package yourself.

[ab1jx]

That seems to work but it's not the format I remember, I think I've mostly used menuconfig.  I've built way more BSD kernels than Linux.  Even if I enable the option though, that doesn't supply any code.

I see:

Code:

#
# DOS/FAT/EXFAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
# CONFIG_FAT_DEFAULT_UTF8 is not set
# CONFIG_EXFAT_FS is not set
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y
# end of DOS/FAT/EXFAT/NT Filesystems

So why is there both exfat and ntfs?  cat /proc/filesystems shows ntfs in there, I didn't try it.

I'm not sure I follow your question...

exfat is another name for ntfs I thought.  Maybe there are version differences, like Windows95 isn't completely the same as current Windows, whatever that is  https://en.wikipedia.org/wiki/ExFAT.  I need RW I think to delete pictures from the camera's SD.

Or somehow find a compatible exfat.ko file: https://duckduckgo.com/?t=ffnt&q=%22exfat.ko%22&ia=web

I'll look into the xmixahlx option.

[moonwalkers]

exfat is another name for ntfs I thought.  Maybe there are version differences, like Windows95 isn't completely the same as current Windows, whatever that is  https://en.wikipedia.org/wiki/ExFAT.  I need RW I think to delete pictures from the camera's SD.

Or somehow find a compatible exfat.ko file: https://duckduckgo.com/?t=ffnt&q=%22exfat.ko%22&ia=web

I'll look into the xmixahlx option.

No, exFAT is a completely different file system, and as the name implies it belongs to the FAT family of file systems. There are quite a few features in NTFS that exFAT lacks, e.g. file name index, transparent encryption/compression, journaling, alternate data streams, hard and symbolic links, support for sparse files and extent-based allocation, etc. About the only thing where exFAT is superior to NTFS is that it supports volume sizes in excess of 16EiB, if you have that much storage to support in the first place. And the main reason exFAT came into existence is 4GiB file size limit in FAT32, something that already wasn't a problem in NTFS, except that NTFS has file owners and permissions, making data exchange using removable drives quite a bit of a hassle, plus its journaling means flash drives are subjected to more wear.