Debian 7.0 on Dreamplug basic installation and booting system external sd card

[Stanley Pilton]

I'm trying to install Debian 7.0 to a dreamplug, using the SD card
slot on the device, rather than the internal card.

I followed [1]. The installation appeared to go okay, but when it
came to booting the newly installed system, the image files didn't
exist.

I popped the SD card into a PC and indeed, uImage and uInitrd were not there.

I attempted to generate the images with the following commands:

$ mkimage -A arm -O linux -T kernel -C none -a 0x00800000 -e
0x00800000 -n kernel -d vmlinuz uImage
$ mkimage -A arm -O linux -T ramdisk -C gzip -a 0x01100000 -e
0x01100000 -n i -d initrd.img uInitrd

The resulting files looked reasonable so I transferred the SD card
back to the dreamplug. They loaded okay. Then I ran "bootm
0x00800000 0x01100000". This printed out some convincing-looking
information about the two images, printed the message "Starting
kernel", and then nothing.

Why didn't the installation work in the first place and is my
technique of generating the images on a PC flawed?

regards, Stanley

[1] <http://www.cyrius.com/debian/kirkwood/sheevaplug/install/>


--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAGtFLY4XpO2DRDDzz9JoXyvDnhvWWkoSJ_qrdw0O=eK5K...@mail.gmail.com

[Martin Michlmayr]

* Stanley Pilton <stanley...@gmail.com> [2013-10-28 16:21]:

> $ mkimage -A arm -O linux -T kernel -C none -a 0x00800000 -e
> 0x00800000 -n kernel -d vmlinuz uImage
> $ mkimage -A arm -O linux -T ramdisk -C gzip -a 0x01100000 -e
> 0x01100000 -n i -d initrd.img uInitrd
>

> Why didn't the installation work in the first place and is my
> technique of generating the images on a PC flawed?

On the DreamPlug, the vmlinuz file isn't enough. You also need the
Device Tree blob. Can you run "flash-kernel" and see if that
generates u* images that will boot?

As to why the installer didn't do that automatically, can you check
the syslog file in /var/log/installer?
--
Martin Michlmayr
http://www.cyrius.com/

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2013102816...@jirafa.cyrius.com

[Stanley Pilton]

On Mon, Oct 28, 2013 at 4:58 PM, Martin Michlmayr <t...@cyrius.com> wrote:

> On the DreamPlug, the vmlinuz file isn't enough. You also need the
> Device Tree blob. Can you run "flash-kernel" and see if that
> generates u* images that will boot?

Right so to get into an environment where I could do this, I
relaunched the installer, answered the questions thru to when all the
storage stuff had been loaded, and then backed out and chose "Execute
a shell".

In the shell, I did the following:

# mkdir /mnt/root /mnt/root/boot
# mount /dev/bfg/root /mnt/root
# mount /dev/sdb1 /mnt/root/boot
# mount -o bind /proc /mnt/root/proc
# mount -o bind /dev /mnt/root/dev
# chroot /mnt/root bash

flash-kernel appeared from its output to be successful:

Taking backup of uInitrd.
Installing new uInitrd.
Taking backup of dtb.
Installing new dtb.

but from the timestamps on /boot/u{Image,Initrd}, no, these files were
not actually updated.

> As to why the installer didn't do that automatically, can you check
> the syslog file in /var/log/installer?

I have looked thru this and can't see anything relevant. Should I
send the whole file through?

regards, Stanley.

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAGtFLY43bPOJzMUxT+rObWqt...@mail.gmail.com

[Stanley Pilton]

I should mention that the storage scheme I chose was "use whole disk
and use lvm", which resulted in a partition for /boot and a VG with an
LV for /

Is this expected to work?

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAGtFLY67H=tafirsrdS8k6-V-Zcxu4...@mail.gmail.com

[Martin Michlmayr]

* Stanley Pilton <stanley...@gmail.com> [2013-10-29 10:56]:

> I should mention that the storage scheme I chose was "use whole disk
> and use lvm", which resulted in a partition for /boot and a VG with an
> LV for /
>
> Is this expected to work?

Yes.

--
Martin Michlmayr
http://www.cyrius.com/

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20131030162...@jirafa.cyrius.com

[Martin Michlmayr]

* Stanley Pilton <stanley...@gmail.com> [2013-10-28 21:51]:

> flash-kernel appeared from its output to be successful:
>
> Taking backup of uInitrd.
> Installing new uInitrd.
> Taking backup of dtb.
> Installing new dtb.
>
> but from the timestamps on /boot/u{Image,Initrd}, no, these files were
> not actually updated.

Can you run
sh -x flash-kernel
to see what's going on?

> > As to why the installer didn't do that automatically, can you check
> > the syslog file in /var/log/installer?
>
> I have looked thru this and can't see anything relevant. Should I
> send the whole file through?

You can send it to me privately (not the list).

--
Martin Michlmayr
http://www.cyrius.com/

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20131030162...@jirafa.cyrius.com

[Ian Campbell]

On Mon, 2013-10-28 at 21:51 +0000, Stanley Pilton wrote:
> but from the timestamps on /boot/u{Image,Initrd}, no, these files were
> not actually updated.

It's possible they ended up on sda1 rather than sdb1?

IIRC this is hardcoded into flash-kernel in Wheezy. I added an override
ability in f-k 3.10 so things should be somewhat easier in Jessie.
Hooking this up to the installer process needs some more thought though.

Ian.

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1383294217.1...@dagon.hellion.org.uk

[Martin Michlmayr]

* Ian Campbell <i...@hellion.org.uk> [2013-11-01 08:23]:

> > but from the timestamps on /boot/u{Image,Initrd}, no, these files were
> > not actually updated.
>
> It's possible they ended up on sda1 rather than sdb1?

Yes, this is what happens. Stanley sent me the logs:
+ mount /dev/sda1 /tmp/flash-kernel.QO3YSugq

Why does it hardcode Boot-Device instead of just putting the files in
the mounted /boot partition?

(As you can tell, I don't know anything about the Dreamplug.)

--
Martin Michlmayr
http://www.cyrius.com/

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20131101170...@jirafa.cyrius.com

[Ian Campbell]

On Fri, 2013-11-01 at 17:04 +0000, Martin Michlmayr wrote:
> * Ian Campbell <i...@hellion.org.uk> [2013-11-01 08:23]:
> > > but from the timestamps on /boot/u{Image,Initrd}, no, these files were
> > > not actually updated.
> >
> > It's possible they ended up on sda1 rather than sdb1?
>
> Yes, this is what happens. Stanley sent me the logs:
> + mount /dev/sda1 /tmp/flash-kernel.QO3YSugq
>
> Why does it hardcode Boot-Device instead of just putting the files in
> the mounted /boot partition?

IIRC the main reason is that the factory shipped u-boot can only speak
FAT which isn't really suitable for mounting as /boot (lack of POSIXy
features like symlinks, for e.g. the vmlinuz link, I think was the main
issue).

On most platforms flash-kernel generally prefers to mount the device
dynamically, for those sorts of reasons. At least that's how I remember
one of the f-k folks explaining it to me.

Ian.

[Martin Michlmayr]

Stanley,

As a workaround, run the installer again, chroot into the installed
system, edit /usr/share/flash-kernel/db/all.db, search for the
Dreamplug entry and change
Boot-Device: /dev/sda1
to
Boot-Device: /dev/sdb1

Then run flash-kernel. The files in /boot should be up to date now.

--
Martin Michlmayr
http://www.cyrius.com/


--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20131102112...@jirafa.cyrius.com

[Martin Michlmayr]

* Ian Campbell <i...@hellion.org.uk> [2013-11-01 20:19]:

> IIRC the main reason is that the factory shipped u-boot can only speak
> FAT which isn't really suitable for mounting as /boot (lack of POSIXy
> features like symlinks, for e.g. the vmlinuz link, I think was the main
> issue).

But since the Dreamplug has a serial adapter, I think it's ok to
require an u-boot upgrade before installing Debian.

> On most platforms flash-kernel generally prefers to mount the device
> dynamically, for those sorts of reasons. At least that's how I remember
> one of the f-k folks explaining it to me.

No, that's not very common at all (although I see there are two other
devices now that do this). The most common way is either to write
directly to flash (for machines that boot from flash), or to put the
files under /boot, under the assumption that /boot is where the device
boots from (and d-i has checks to make sure this is the case, although
d-i cannot check for everything).

Looking at #667681, I see that your original patch put the files in
/boot but Lo�c suggested otherwise. I don't agree with Lo�c's
rationale but I guess I'm 1.5 years late...

If people think it's too late to change the behaviour now, I think it
would be good to at least add a simple message like
Creating boot files on /dev/sdaX
to make it cleaer what's going on.

--
Martin Michlmayr
http://www.cyrius.com/


--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20131102113...@jirafa.cyrius.com

[Ian Campbell]

On Sat, 2013-11-02 at 11:38 +0000, Martin Michlmayr wrote:
> * Ian Campbell <i...@hellion.org.uk> [2013-11-01 20:19]:
> > IIRC the main reason is that the factory shipped u-boot can only speak
> > FAT which isn't really suitable for mounting as /boot (lack of POSIXy
> > features like symlinks, for e.g. the vmlinuz link, I think was the main
> > issue).
>
> But since the Dreamplug has a serial adapter, I think it's ok to
> require an u-boot upgrade before installing Debian.

Agreed, although my rationale would be the presence of JTAG not serial.

I don't know if that is the case for all similar platforms though.

> > On most platforms flash-kernel generally prefers to mount the device
> > dynamically, for those sorts of reasons. At least that's how I remember
> > one of the f-k folks explaining it to me.
>
> No, that's not very common at all (although I see there are two other
> devices now that do this). The most common way is either to write
> directly to flash (for machines that boot from flash),

Right, I was trying to say "most common among devices which do not have
a dedicated flash partition for the kernel" or something like that.

> or to put the
> files under /boot, under the assumption that /boot is where the device
> boots from (and d-i has checks to make sure this is the case, although
> d-i cannot check for everything).

But I see that even what I was trying to say was wrong. My mistake.

> Looking at #667681, I see that your original patch put the files in

> /boot but Loïc suggested otherwise. I don't agree with Loïc's

> rationale but I guess I'm 1.5 years late...
>
> If people think it's too late to change the behaviour now, I think it
> would be good to at least add a simple message like
> Creating boot files on /dev/sdaX
> to make it cleaer what's going on.

We can't really change Wheezy but I'd have no problem with doing it
differently for Jessie+, assuming the upgrade path can be sorted out.

Ian.

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1383562979.8...@kazak.uk.xensource.com

[Martin Michlmayr]

* Ian Campbell <i...@hellion.org.uk> [2013-11-04 11:02]:

> > Looking at #667681, I see that your original patch put the files in

> > /boot but Loďc suggested otherwise. I don't agree with Loďc's

> > rationale but I guess I'm 1.5 years late...
> >
> > If people think it's too late to change the behaviour now, I think it
> > would be good to at least add a simple message like
> > Creating boot files on /dev/sdaX
> > to make it cleaer what's going on.
>
> We can't really change Wheezy but I'd have no problem with doing it
> differently for Jessie+, assuming the upgrade path can be sorted out.

I'd be in favour of changing it but I'd like to hear from Loďc as he
suggested the current behaviour.

--
Martin Michlmayr
http://www.cyrius.com/

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20131106163...@jirafa.cyrius.com

[Loïc Minier]

Hey

Sorry for being late to the party, thanks for waiting for me! :-)

On Sat, Nov 02, 2013, Martin Michlmayr wrote:
> > On most platforms flash-kernel generally prefers to mount the device
> > dynamically, for those sorts of reasons. At least that's how I remember
> > one of the f-k folks explaining it to me.
>
> No, that's not very common at all (although I see there are two other
> devices now that do this). The most common way is either to write
> directly to flash (for machines that boot from flash), or to put the
> files under /boot, under the assumption that /boot is where the device
> boots from (and d-i has checks to make sure this is the case, although
> d-i cannot check for everything).

So let's tackle cases one by one.

First something to keep in mind is that for many platforms there is a
factory installed U-Boot and a Debian one is available; at the moment,
the assumption of which U-Boots are supported are not clearly
documented, except on the (nice) web pages from Martin or other Google
juice.

Concerning devices with flash storage (assuming there is an initrd and
perhaps even DTB flash partition and that the Debian kernel and initrd
will git in the stock partitions...), it's best to just write the
files there, no need to write an interim file to /boot that is going to
be ignored anyway. So flash-kernel should just generate the kernel
(potentially with machine-id prepended, dtb appended, u-boot wrapping
etc.) and initrd in /tmp, write them to flash, and remove the tmp files.

Concerning devices where U-Boot grabs boot files from a filesystem,
there are many variations in different platforms. Usually, the factory
default is to read files from a hardcoded U-Boot device name and
filesystem type, e.g. "fatload mmc 0 uImage". In some slightly more
clever U-Boot configs, there is some kind of scanning (either for a boot
script or for a kernel image) in the form of "iterate over all MMCs,
then iterate over all partitions, then iterate over all filesystems and
try to load file xyz".
There are three issues with these setups; first, this is all very
fragile, with a lot of variation and doesn't allow fancy things like
reading kernel/initrd from RAID, LVM, LUKS etc. or filesystems not
supported by U-Boot.
Second, some U-Boot hardcode the filesystem type or only support
dumb filesystems such as FAT or ext2. This is problematic because
keeping ext2 mounted might result in unrecoverable corruption if the
device crashes with unsynced changes (since U-Boot doesn't know how to
deal with a filesystem that needs fsck-ing) and because sometimes we
have symlinks in /boot.
Third, the boot location is often space constrained and don't allow
piling up old kernels. e.g. a 40MB MMC partition but you've piled up 5
kernels.

With this in mind, I initially opted to list actual boot devices in the
flash-kernel database (Boot-Device: /dev/sda1) using the expected
factory-supported / Debian-supported/recommended U-Boot boot device.
This would be mounted temporarily, only relevant files would be
updated there, and then it would be unmounted. This avoided the
filesystem corruption issue, avoided the symlink issue and avoided the
limited space issue nicely.
The long-term plan was to allow overriding the Boot-Device: by the
end-user (and Ian's patches allow this, albeit I'm afraid they bind us
to keep the database format backwards-compatible forever) and to also
offer a mode where this would be computed based on /boot.

> If people think it's too late to change the behaviour now, I think it
> would be good to at least add a simple message like
> Creating boot files on /dev/sdaX
> to make it cleaer what's going on.

Improved log was a good idea; I've just added one now (1e53a60); maybe
we can work on improved use cases; perhaps we want some
/etc/flash-kernel/boot-device override file that could be an UUID=, a
LABEL= or a /dev pathname (much like fstab) that would be created by
users or by flash-kernel-installer?

Which devices would this be particularly useful on right now and what
formats do we want to support first and foremost? How do we detect the
device U-Boot will look after?

Cheers,
--
Loïc Minier

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20131107164...@bee.dooz.org

[Stanley Pilton]

Loïc,

Thanks for your input. Some thoughts from a user POV below.

For our dreamplugs, we want to have an identical bootloader
configuration on each device, and have the behaviour of the system
from the OS up defined by the content of the removable SD card, not
the internal card. In other words, we would like to be able to change
the SD cards over between two of the devices, and have the whole
system, including the kernel and initrd, come across.

Having the kernel on internal storage and the rest of the system on
external storage does not allow us to do this.

> Which devices would this be particularly useful on right now and what
> formats do we want to support first and foremost? How do we detect the
> device U-Boot will look after?

We are quite happy with constraints such as "it must be an ext2
filesystem directly on a partition of the card", as long as this is
clearly documented.

I think a key point is that the installer and any other software
managing the boot files should know where to write based on where
/boot is. In other words, I wouldn't expect the user to have to tell
the OS twice where the boot partition is - this is already configured
by the /boot mountpoint, isn't it?

Working out what /boot corresponds to in bootloader terms, and thus
configuring the bootloader correctly, then becomes the problem. But I
think the problem should be stated this way round. In simple cases it
should be easy. If it can't be deduced, this error needs to propogate
up to the user.

cheers, Stanley

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAGtFLY6scmsvmi-uYbjoSyAK...@mail.gmail.com

[Loïc Minier]

On Fri, Nov 08, 2013, Stanley Pilton wrote:
> For our dreamplugs, we want to have an identical bootloader
> configuration on each device, and have the behaviour of the system
> from the OS up defined by the content of the removable SD card, not
> the internal card. In other words, we would like to be able to change
> the SD cards over between two of the devices, and have the whole
> system, including the kernel and initrd, come across.
>
> Having the kernel on internal storage and the rest of the system on
> external storage does not allow us to do this.

That's fine; there are other similar cases where the most common default
is SD/MMC, such as Beagle/Panda, despite some revisions having NAND.
When I referred to flash being used for the kernel/initrd, it wasn't
anything mandatory, just something commonly witnessed (I guess it is
often why NAND was included in the device in the first place!).

> > Which devices would this be particularly useful on right now and what
> > formats do we want to support first and foremost? How do we detect the
> > device U-Boot will look after?
>
> We are quite happy with constraints such as "it must be an ext2
> filesystem directly on a partition of the card", as long as this is
> clearly documented.

To be clear, the ext2 requirement typically comes down from U-Boot;
ideally, we'd instead allow users to install their kernel / initrd
anywhere and have a bootloader as clever as GRUB find them by scanning
all block devices and figuring out complex RAID/LVM/filesystem setups,
but we don't have this luxury on ARM. So the device manufacturer
usually picks a bootloader (often U-Boot) and some supported filesystem
(often vfat or ext2) and loads from that, then Debian tools like
flash-kernel try to cope with whatever setup was chosen.

> I think a key point is that the installer and any other software
> managing the boot files should know where to write based on where
> /boot is. In other words, I wouldn't expect the user to have to tell
> the OS twice where the boot partition is - this is already configured
> by the /boot mountpoint, isn't it?

Well, you'd think this is what /boot is for, but if you add the
constraint that the bootloader needs to be able to read /boot and that
the bootloader only speaks vfat / ext2, you might face painful
situations. For instance, you need to keep /boot mounted all the time
as to allow upgrades of the linux-image-* packages which ship files
under /boot, but if there's an unclean shutdown, your filesystem is
unclean and your device might not come up.

Using /boot to store boot related file, but then having flash-kernel
mount some "firmware area", copy just the right boot files into it, then
unmount said area has advantages.

> Working out what /boot corresponds to in bootloader terms, and thus
> configuring the bootloader correctly, then becomes the problem. But I
> think the problem should be stated this way round. In simple cases it
> should be easy. If it can't be deduced, this error needs to propogate
> up to the user.

Sure, we can put the burden on the bootloader, but we typically dont
have much control over it and it's often limited.

I'm all for using a bootloader as capable as GRUB on ARM, but I don't
think this is possible yet?

--
Loïc Minier

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20131109211...@bee.dooz.org

[Paul Wise]

On Sun, Nov 10, 2013 at 5:10 AM, Loïc Minier wrote:

> Sure, we can put the burden on the bootloader, but we typically dont
> have much control over it and it's often limited.
>
> I'm all for using a bootloader as capable as GRUB on ARM, but I don't
> think this is possible yet?

Indeed, bootloaders are often not replaceable for various reasons:

Vendors using non-free sourceless bootloaders.

Vendors not upstreaming their patches to u-boot/etc.

Vendors using crypto to prevent replacement of the bootloader.

I wish we could get vendors to settle on the OpenMoko way of doing
things: modifiable primary bootloader and a backup mostly-read-only
bootloader that lets you overwrite the primary bootloader over USB
using the DFU protocol (or similar).

--
bye,
pabs

http://wiki.debian.org/PaulWise

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAKTje6EzMnsfQiWOez0hc-w-...@mail.gmail.com

[Stanley Pilton]

Sorry if this is repeating myself, but just to ensure I've been
understood (and please just view this as one individual user
expressing a preference):

I wouldn't describe my preference as being to put the burden on the
bootloader. I am happy with a simple bootloader with limited
capabilities, which eg constrains /boot to be ext2 on a direct
partition. What I think is important is for the OS to understand the
bootloader's capabilities and integrate. Both at installation time
and when the boot files change as a result of upgrades or config
changes. As an interim measure, the user configuring the OS can do
some of this with the right documentation.

This is very much putting the burden on the OS (and user configuring
the OS), not the bootloader.

It would be great to at least have the option of using straight-up
/boot for the boot files, and constraining what /boot can live on. In
practical terms here that just means that a system configuration is
possible such that /boot/uImage and /boot/uInitrd are regenerated at
the right time, whenever their respective input files are updated.

regards, Stanley.

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAGtFLY6WxbCRHkCCO+FuvMHN...@mail.gmail.com

[Martin Michlmayr]

* Loďc Minier <loic....@dooz.org> [2013-11-09 22:10]:

> Well, you'd think this is what /boot is for, but if you add the
> constraint that the bootloader needs to be able to read /boot and that
> the bootloader only speaks vfat / ext2, you might face painful
> situations.

So here's how I see things. In my opinion, there are two separate
classes of devices: off the shelve devices that are not easily
hackable (i.e. in this case, don't have a serial console by default
nor an easy way to recover via JTAG) and other devices that are
hackable.

The QNAP devices are examples of the first class. While you can add a
serial console, it's not there by default and voids your warranty.
Furthermore, there's no easy way to recover the system if the
bootloader is broken. Therefore, our policy is not to touch the boot
loader at all (neither the binary nor the configuration) and live with
what we have. This leads to certain hacks in flash-kernel, such as
overriding the root device passed to the kernel from the u-boot
environment.

On the other hand, there are devices like the SheevaPlug, which are
made to be hackable. You can easily recover if you flash a broken
u-boot. Therefore, we require users to upgrade u-boot and set
specific environment variables. Because the SheevaPlug is hackable, I
was never interested in supporting other plug devices (like the
PogoPlug), which are not. The GuruPlug and DreamPlug are somewhat
inbetween since the JTAG module is external because my assumption is
that anyone who wants to install Debian will get the JTAG module.
Therefore, I think we can expect users to install a specific version
of u-boot and set the u-boot environment.

As such, I feel that we don't need hacks in flash-kernel that assume
that people are running an u-boot that only supports FAT. We can
simply tell people to install a different version of u-boot.

Of course we can support devices that are restricted, e.g. need the
kernel in a specific location. In that case, I don't mind
flash-kernel mounting /dev/sda1 and writing stuff there. We can also
support devices that need the kernel on a specific partition. In that
case, we can even include checks in d-i to ensure that /boot is on
that partition.

However, I don't think this is the right solution for the DreamPlug,
as I consider it a hackable device.

--
Martin Michlmayr
http://www.cyrius.com/

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20131112180...@jirafa.cyrius.com

[Ian Campbell]

On Thu, 2013-11-07 at 17:43 +0100, Loïc Minier wrote:
> Hey
>
> Sorry for being late to the party, thanks for waiting for me! :-)

Sorry for being even later...

> The long-term plan was to allow overriding the Boot-Device: by the
> end-user (and Ian's patches allow this, albeit I'm afraid they bind us
> to keep the database format backwards-compatible forever)

Yes, I hadn't considered this aspect, sorry.

In principal there is nothing to say that /etc/f-k/db has to have the
same syntax as /usr/lib/f-k/db, but that is splitting hairs a bit
because it does require us to keep the existing parser around or add
other compat code, which is certainly a burden.

We could invent a separate syntax for /etc/f-k/db but that adds
basically the same burdens I think, although perhaps it could be more
restrictive and therefore less of a burden. Is it worth it though?

Is an f-k rewrite or db schema change really on the cards? It seems to
have reached the point of maturity with only little incremental bits
required.

Grub on uboot is now looking like a reasonable proposition, at least for
armhf devices, and should probably be what we move towards. I'm not sure
how/if f-k fits into that model. To some extent the problems solved by
f-k are the same ones as would need to be solved to get grub arm-uboot
loaded. I'm currently undecided on whether this means extending f-k to
know about loading /boot/grub/arm-uboot/core.img (which is already a
uImage formatted thing) as a kernel or teaching grub-install (or some
other grub-tool) platform specific stuff in the manner of flash-kernel.

> Improved log was a good idea; I've just added one now (1e53a60); maybe
> we can work on improved use cases; perhaps we want some
> /etc/flash-kernel/boot-device override file that could be an UUID=, a
> LABEL= or a /dev pathname (much like fstab) that would be created by
> users or by flash-kernel-installer?
>
> Which devices would this be particularly useful on right now and what
> formats do we want to support first and foremost? How do we detect the
> device U-Boot will look after?

The mapping from Linux device (or UUID, or LABEL) to the u-boot name
(scsi X:Y, mmc A:B etc) is the big issue with u-boot AFAICT. There's
just no standard scheme.

Once you get into handling separate boot vs boot on / it gets even
nastier -- since the path to the kernel can have /boot on it or not.

This is particularly problematic on systems where there is no dedicated
flash for the kernel so you want to boot out of a regular partition,
e.g. systems where the normal preference would be write a /boot/boot.scr
to load the kernel (or grub). I think writing the correct thing
automatically while allowing for the user's partitioning preferences is
going to turns out to be pretty tricky, if not close to impossible :-(.

There does seem to my eye to be a trend towards more "hackable" devices
(i.e. ones with a serial console), which turns this into at worst a
documentation problem. And on the ARM server side I hope/expect that the
majority will be using EFI (which has standard interfaces) and that
those which do use uboot will have a serial console (again, at worst a
docs problem).

Ian.

--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1388763921.16...@hastur.hellion.org.uk