Author Topic: Final call for TP3 (Read 44323 times)

Adam Boardman · « **Reply #30 on:** February 07, 2019, 03:57:43 am »

Quote from: ArchiMark

Has getting ethernet working been addressed?

Yes that's been working fine since August: https://github.com/gemian/gemini-linux-kern...509d60851cba362

ArchiMark · « **Reply #31 on:** February 07, 2019, 09:00:45 am »

Quote from: Adam Boardman

Quote from: ArchiMark
Has getting ethernet working been addressed?

Yes that's been working fine since August: https://github.com/gemian/gemini-linux-kern...509d60851cba362

Great!

Thanks for all your excellent work for the Gemini!

Mark

PlasmaStrike · « **Reply #32 on:** February 07, 2019, 09:27:14 am »

Multiple image choices would be nice.

Minimal Image -- I would like to set up this device from scratch arch linux style. That way I can try different window mangers under the gemini without trying to rip out lxde, As well for logging in I only want auto login, as I only use the device so lightdm is over complicated and a waste of spce among other things. I clean base to start off with would be nice. for instance here is what somebody else is doing with the base image New gemini experience. I will try to get exwm working with ming

Kde image -- I wouldn't use this but would have a different suite of apps compared to lxqt

other de/wm images -- So people can chose a base they want like void linux

Adam Boardman · « **Reply #33 on:** February 17, 2019, 05:50:29 am »

Given Planets Gemini update 68, specifically releasing sfos 3 beta from Jolla, plus:

Quote

We will update the partition tool with new versions of the software when new images will be released by the community.

This has taken the pressure off the TP3 release which I had thought was supposed to go out along with the new Android 8 + SFOS 3 etc.

So we might as well wait till we've got a few more things sorted out. Plus someone needs to figure out what the plan is with multi-OS in the new LVM land of the sfos release. I'm assuming we can lvm resize things to fit in a debian image too? But as that would require reformatting my device I'm unsurprisingly not so keen.

idc · « **Reply #34 on:** February 17, 2019, 06:37:48 am »

Thanks for this update. I very much want to try out Sailfish OS, but would like to be able to try Debian at the same time. For the moment I've held off installing SFOS, because I was hoping for a new Debian TP3 at the same time. If it really isn't due soon, I guess I might just give sailfish a go. But wouldn't it be better to get the new TP3 out anyway? There must be a fair number of people like myself who are waiting for it, and the increase in users might just help give it a boost. (My excuse for not having sorted it so far is being 'time poor' for fiddling with lots of settings.) I'm sure there are others like myself who are desperate for an escape from Google and Android on the Gemini. The hardware (by which I suppose I mean the keyboard) is great; I'm just waiting for a better OS!

Anyway, all this by way of thanking you, Adam, and others for the work that is being done on getting Linux running well on the gemini. If there is anything we can do to encourage you, please say!
Ian

Quote from: Adam Boardman

Given Planets Gemini update 68, specifically releasing sfos 3 beta from Jolla, plus:
Quote
We will update the partition tool with new versions of the software when new images will be released by the community.
This has taken the pressure off the TP3 release which I had thought was supposed to go out along with the new Android 8 + SFOS 3 etc.

So we might as well wait till we've got a few more things sorted out. Plus someone needs to figure out what the plan is with multi-OS in the new LVM land of the sfos release. I'm assuming we can lvm resize things to fit in a debian image too? But as that would require reformatting my device I'm unsurprisingly not so keen.

Adam Boardman · « **Reply #35 on:** February 17, 2019, 07:51:07 am »

Quote from: idc

I very much want to try out Sailfish OS, but would like to be able to try Debian at the same time.

Check some other recent threads on the Sailfish chat, or for that matter the partition tool itself, you'll find that Planet have decided against the 'stowaways' form of multi OS hosting thus meaning that you can only install Android+One other OS with the flash tool. The options disappear as you select them from the drop-downs on the partition tool.

This is what I was referring too with my multi-OS comment above, if your game for it then you could try installing the Android+Sailfish as from planet (get happy with it and decide how much space you want to keep for it), then resize (shrink) your Sailfish LVM volumes, and get back to us and we could try making a LVM compatible version of Debian that you could then 'dd' to a boot partition/root unzip from within sailfish to a new debian volume in the space made available by shrinking the sfos volume. First thing I'd like to know is what the sailfish volume names/size etc are. The idea is that our debian LVM release (probably TP3) would have different names from sailfish and so you could then install either A+S or A+D from planet then later do the resize and copy the other one (or Kali/UBPorts/Other future OS) across later for multi-os usage. Thus allowing OS changes without resorting to the flash tool.

I'd also be interested to know if people would want to have things split so that maybe a stretch root and a buster root are available with a debianhome that they both mount so that you can share user files between os's? (could possibly also extend to get sfos/kali to mount the same root?) Or is it best to keep things clean and just allow users to mount the other homes as desired, there are some bits of software that change their file formats between versions and so for example Telegram Desktop gets confused when you launch the stretch version after launching the buster one (you just have to login/2fa again).

andrewl · « **Reply #36 on:** February 19, 2019, 02:30:45 am »

Quote

I'd also be interested to know if people would want to have things split so that maybe a stretch root and a buster root are available with a debianhome that they both mount so that you can share user files between os's? (could possibly also extend to get sfos/kali to mount the same root?) Or is it best to keep things clean and just allow users to mount the other homes as desired, there are some bits of software that change their file formats between versions and so for example Telegram Desktop gets confused when you launch the stretch version after launching the buster one (you just have to login/2fa again).

I chose sailfish for all three positions on the online tool and all space to linux, zero for Android and the Gemini boots to sailfish, runs sailfish and there’s no Android there spoiling the party.

Adam Boardman · « **Reply #37 on:** February 19, 2019, 04:52:33 pm »

If you could do a 'sudo lvscan' to tell me the volume names that would be handy.

bled82 · « **Reply #38 on:** February 22, 2019, 01:15:33 pm »

CIFS/SMB/NFS support I was unable to map widnows network share and my search indicated that the kernel modules don't support it ? Looking to map windows shares over network or vpn , I use zerotier one its really a nice vpn mesh network solution and quick .

Adam Boardman · « **Reply #39 on:** February 23, 2019, 04:29:37 am »

Quote from: bled82

CIFS/SMB/NFS support

Can you perhaps list the modules you want added? Preferably after testing that the kernel boots & works. You can build a kernel on the device by pulling down https://github.com/gemian/gemini-linux-kernel-3.18.git and checking out the native branch, a 'debuild -b -uc -us' will give you a .deb to install, but you might find it easier to just selectively copy the relevant lines from: debian/rules to make a new .img file.
You'll want to add your modules to: arch/arm64/configs/aeon6797_6m_n_halium_defconfig

mithrandir · « **Reply #40 on:** February 23, 2019, 09:03:59 am »

Adam, maybe it is worth taking a look at my kernel configuration at: https://www.mygnu.de/2019/02/modular-linux-...-lid-close-fix/. Well, the kernel boots and includes most useful modules and some other stuff. Some documentation on the config changes can be found in the older kernel posts there. Might make sense to use this config or something similar for the main kernel.

Btw.: Thx for the cut+paste fix.This greatly increases usability of the Gemini. Great job. Never thought it is a kernel issue. Thought it might have been some problem with my keyboard config...

Mith

Adam Boardman · « **Reply #41 on:** February 23, 2019, 09:35:53 am »

I did try experimenting with building as modules based upon your blog (old version of that granted, actually very old I've clearly not been paying much attention to your kernel config work), but couldn't get it to work. Tested patches welcome, if you get a working kernel from a debuild on debian stretch (use native or packaging branch depending on arm64 vs amd64 host).

mithrandir · « **Reply #42 on:** February 23, 2019, 10:51:52 am »

Quote from: Adam Boardman

I did try experimenting with building as modules based upon your blog (old version of that granted, actually very old I've clearly not been paying much attention to your kernel config work), but couldn't get it to work. Tested patches welcome, if you get a working kernel from a debuild on debian stretch (use native or packaging branch depending on arm64 vs amd64 host).

I'll give it a try using the debuild aproach. My build machine for the Gemini kernels usually is a jetson board running Ubuntu 16.04. This should be ok for the debuild aproach. Right? Don' t have a powerful enough machine running Stretch... Otherwise I had to install a VM on my Laptop...

How does the kernel deb package distinguish which boot partition to flash? Have not tried any of the kernel debs on the Gemini, yet. Just want to make sure not to flash the wrong partition while testing (using the 1st boot partition for Debian).

Mith

Adam Boardman · « **Reply #43 on:** February 23, 2019, 11:30:55 am »

I'd recommend you add a lxd/lxc Debian 9 container (thats how I test my kernel builds using the packaging branch), the build server does it though jenkins arm on amd building from the native branch as whilst I got the packaging branch building there I couldn't get it to put the right arch in the package in the right place.

I don't remember whether it was a build problem or a boot problem with the modules version but I remember getting stuck and deciding it wasn't important enough for me to be bothered with trying to figure it out.

If you've got the latest bootloader then we know which button you pressed to boot so we display the correct 'dd' line to install the kernel, if not then you get a more generic message telling you to select the right partition yourself.

The idea is once we've got some good feedback on the suggestion being right we might swap the kernel package to actually do the 'dd' itself, for now kernel updates are manual so you needn't worry about it writing to the wrong place.

mithrandir · « **Reply #44 on:** February 23, 2019, 11:37:28 am »

Do I get you right, that if I build on amd64 I have to fork from the packaging branch and if I build on arm64 I have to fork from master?

News:

Author Topic: Final call for TP3 (Read 44323 times)