On 2015-05-17 01:36, Jacco Ligthart wrote:
On 05/17/2015 01:01 AM, Gordan Bobic wrote:
But, as the pi normally boots without an initrd (which I like) and
adjusting it to have an initrd seems non-trivial (according to
google) I
decided to leave it at ext4.
How is it non-trivial? What boot loader does it use? U-boot handles
this reasonably gracefully.
It doesn't use uboot.
There are a couple of binary blobs that need to be with the right
filename on the first partion (vfat of course).
The last one will look for 'kernel.img', 'cmdline.txt' and
'config.txt'.
Hmm... That sounds a bit u-boot-ish. I seem to recall that more recent
versions of uboot get their configs from similarly named files rather
than nvram or similar flash storage - mainly because there are many
devices that don't have nvram/flash for the u-boot variables.
Apparently it is possible to specify an initrd in the cmdline.txt and
config.txt, but there are many stories that it stopped working after
normal kernel updates. One of the things is that, apart from a
filename,
you need to tell it at what memory location it should be loaded and the
filesize in hex.
That doesn't sound too difficult, it's similar to what u-boot on
various Kirkwood devices does.
On some of my ARM machines there are other interesting-ish constraints
such as initramfs size constraints because the boot loader doesn't
know how to get the images from anything but internal NAND addresses.
For example, without re-doing the layout of internal NAND formatting
(probably possible, haven't looked that closely) on the QNAP NAS that
I'm using as one of my internal servers, the kernel uImage is limited
to 2MB and the initramfs is limited to 9MB - which is about half the
size those end up in default configuration on x86 boxen.
But unfortunately, we have to cross each of those bridges individually
on ARM, at least until sensible standards are introduced and the
embedded one-off product induced brain damage / mentality is treated
out of ARM device manufacturers (it may be some time).
Another option is to somehow put your initrd inside the kernel. I have
never seen how that should be done. But, more importantly, that would
require custom kernels.
Hmm... How does that work? Are we talking about some proprietary
blob format that a proprietary boot loader knows how to extract into
memory and run from there?
I'm not saying it cannot be done, only that there are lots of people
having issues getting it to work reliably.
I sympathise...
Things I'm still considering are nodiratime and data=writeback for
ext4.
Is fiddling with FS options really that advantageous over letting the
user just configure it the way they want, including picking the FS
they want themselves?
Of course everybody is free to choose their own FS. And they already
are.
I would advocate to have one good image for each device. That includes
our best choice of FS (with reasonable options), ntp/chrony on for
devices without hwclock, appropriate sysctl settings (if they differ
from default), the right (extra) modules loaded or blacklisted, etc.
This will enable users to get up-and-running quickly, which is
something
i think is important.
Having more than one image (per device) to maintain will be quite a
burden on us.
Depending on how many devices we are talking about, having one image
per device may well be unworkable. I'm in the unfortunate position
where I have ARM machines that I bought over a year ago that I still
haven't gotten around to getting up and running because of various
time constraints. In fact, in some cases the manufacturer of the board
has gone out of business in the meantime, so the value of my doing it
would be strictly limited to my having another ARM machine to play
with (which is very limited indeed).
For all 'special' setups, we might just explain how to do that on the
wiki.
Perhaps. Unfortunately, a wiki article for that kind of thing would
be both generic and require device specific knowledge on part of the
user. For example, even if I have zfs-fuse-dracut module that works
for me, it would still require the use of an initrd, and since the
kernel will inevitably be a major unknown, it would rely on the user
being able to resolve an issues arising from that themselves.
In the end, it is not that difficult. Thinking about this, if we
create a better comps.xml, we could instruct people to 'yum
groupinstall
base --installroot=xxx --config=yyy' instead of creating all kinds of
tar.gz files.
Doesn't that imply already having a running system?
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
