So, I guess I have a different opinion about this. Part of the problem with the RPi (or any not-totally-mainstream) platform is that major distros don't have the resources to target the specific drivers, kernel opts etc. to make it boot properly with all peripherals operational, and even if they do this for one model, things break when a new hardware rev is released (RPi2->3 or RPi3B -> B+ even). What they do have is their own (aarch32 or aarch64) repositories, often containing versions of software not available on Raspbian, particularly (for now anyhow) when you look at the 64-bit side of things.feelslikeautumn wrote: ↑Tue Feb 26, 2019 7:52 pmSorry sakaki, but I don't get it. This seems like a huge amount of work, but I honestly don't see the point of it. Who is going to produce the images for pinc? I can't see Fedora, openSUSE, Ubuntu etc producing official images especially to run under this. There doesn't seem to be a lot of individuals interested in producing 'normal' images, and this just fragments things further. There is already NOOBS, PINN, grub2 and u-boot capable of producing a multi-os SD card.
Well, I hear you. In fact I was genuinely in two minds about this point to begin with (see my point 2 under "Productionization (of the Userland Packages)" in this earlier post), but ShiftPlusOne's comments tipped me towards generalizing it. I think I can see how this more general approach could work, but maybe I'm mistaken - it wouldn't be the first time for sure ^-^ But even if I'm wrong, I think the more limited goals will still be delivered, I'll just have burnt some cycles building out some generality that doesn't get used. Hopefully over the next couple of weeks, with the help of others on here, I'll be able to fill out the current rough outline of the design into something well formed that is bounded and can be delivered in the timescale I've allotted to it.
Yes, perhaps so. Well, we're going to be 95% of the way with this once your initial packaging of the demo system is complete. I suppose the main question is, whether we want to be able to support just 1 guest OS at any time, or >1. Once you go >1, there needs to be a way for end users to control that, which (realistically) entails a small management GUI etc. Whether or not a community image server exists is not really critical to that design point, more an imagining of how life-cycle management for guest images could operate in general.
Sorry, going to have to delay it a bit unfortunately.sakaki wrote: So, sticking with the plan of record for now, perhaps we should try and complete the 'debification' of the demo components by Mar 8, and in the meantime everyone can continue discussion on this thread about a more general design.
I think most people who have a genuine need for 64 bit are just wanting to surf the web using a reasonably up-to-date web browser.
Then there is me. I want to run a cluster of distributed CockroachDB instances. Cockroach can be hacked to build and run on 32 bit machines but it's a chore and not optimal.I think most people who have a genuine need for 64 bit are just wanting to surf the web using a reasonably up-to-date web browser.
Do what? There never was a time when the Pi was the only ARM SBC that could run Linux around. There have been many for many years before the Pi.Being able to run a variety of operating systems was guaranteed when Pi was the only SBC around.
Moving backwards, there has been for many yearsMoving forward it is plausible that there will be many SBCs on which Linux runs well.
For whom to remain relevant?To remain relevant most Linux distributions should run well on the Pi.
Delusional?People who say 32bit is enough are delusional or have yet to bump into 32bit limitations.
But you don't need 64 bit for this. Firefox has been working fine under armhf on other distros for nearly a year.ejolson wrote: ↑Sat Mar 09, 2019 3:17 amI think most people who have a genuine need for 64 bit are just wanting to surf the web using a reasonably up-to-date web browser.
At the start of the year the final piece for working pi wifi was included in linux-firmware. It means that wifi should work out of the box for distros going forward. Bluetooth is still problematic I think.Having said this, I do like the idea of providing a standard way for ARM Linux to run on the Pi without having to separately configure custom drivers and boot loaders for each distribution.
I think this is what I was trying to say. When Pi was the only cheap SBC it set the standard. Currently Raspberry Pi has the market share to define their own standards, but bucking the trend in the future may eventually put Pi in the minority.
Not sure. I haven't looked at that package yet.sakaki wrote: For the raspbian userland support package, would it help if I supplied an install script, that would work on an unpacked tree from the GitHub source release tarball (e.g. this one), installing say from $SRCDIR (root of the unpacked tarball) to $DESTDIR (temporary or real filesystem install root)?
Thank you for the offer. All in all, I don't think there's much to do on my end, it's just a matter of setting aside half an hour or so to just do it.sakaki wrote: I'm very aware that you have loads of day-job stuff to do, and you're helping out on this in your spare time, so anything I can do to minimize your work on this, please just let me know!
That sounds fine I think (if by target directory you mean "/var/lib/machines/debian-stretch-64" - incidentally, you may need to create the parent directory /var/lib/machines also if it does not exist, chmod 0700). A user issuing "purge" would expect to have any user-created content (installed 64-bit apps etc.) deleted I take it, per Debian guidelines?ShiftPlusOne wrote: ↑Mon Mar 18, 2019 9:44 pmFor the postinst and postrm scripts to handle the edge cases properly, does this sound about right:
On postinst, it should extract the tarball if the target directory does not exist.
On postrm, it should leave the directory in place.
If the user purges the package, it should stop the machine if it's running, then remove it.
Any potential issues with that?
It seems to be added when systemd-container is installed, but I'll check for that as well, thankssakaki wrote: you may need to create the parent directory /var/lib/machines also if it does not exist, chmod 0700)
Yeah, piuparts (a debian package QC tool, installs the package) notes down all the new files, purges it and then makes sure the system is left exactly as it was before the package is installed, which would mean the user loses all data related to that package.sakaki wrote: A user issuing "purge" would expect to have any user-created content (installed 64-bit apps etc.) deleted I take it, per Debian guidelines?
We're targetting Buster for almost everything we're doing at pi towers right now and it seems like the release shouldn't be that far off.sakaki wrote: I assume we should target this rather than Stretch for the production release, as it will soon be the stable variant?
I'd go by user feedback. If they run into issues and mirroring solves those issues, then maybe it's worthwhile.sakaki wrote: Things seem to work (I assume it is using the C locale, and UTC or whatever), but is this OK? Or should I try to automatically 'reflect' the locale and timezone from the host, much as passwords, groups etc. are?
Code: Select all
pi@raspberrypi: ~ $ wget -c https://github.com/sakaki-/raspbian-nspawn-64/archive/v1.2.0.tar.gz pi@raspberrypi: ~ $ tar -xzpf v1.2.0.tar.gz pi@raspberrypi: ~ $ cd raspbian-nspawn-64-1.2.0 pi@raspberrypi: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh preinst # stops any running services pi@raspberrypi: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh install # installs files to $DESTDIR pi@raspberrypi: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh postinst # enables (but does not start) supplied services
Code: Select all
pi@raspberrypi: ~ $ wget -c https://github.com/sakaki-/raspbian-nspawn-64/archive/v1.2.0.tar.gz pi@raspberrypi: ~ $ tar -xzpf v1.2.0.tar.gz pi@raspberrypi: ~ $ cd raspbian-nspawn-64-1.2.0 pi@raspberrypi: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh prerm # stops any running services pi@raspberrypi: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh uninstall # remove any files, leaving configs pi@raspberrypi: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh postrm # remove any desktop files etc pi@raspberrypi: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh preinst # stops any running services (redundant actually) pi@raspberrypi: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh install # installs files to $DESTDIR pi@raspberrypi: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh postinst # enables (but does not start) supplied services
Could you tell me more about systemd-nspawn containers and what they can and cannot do?