I'm trying to build an image for my router, which (after all) seems to need Grub.EFI64...
Here is my config:
caillette = host hn $ props
& hasPartitionTableType GPT
& hasPartition
( partition VFAT
`mountedAt` "/boot/efi"
`partLocation` Beginning
`setSize` MegaBytes 10
`setFlag` EspFlag
)
& hasPartition
( partition EXT2
`mountedAt` "/boot"
`setSize` MegaBytes 150
)
& hasPartition
( partition EXT4
`mountedAt` "/"
`partLocation` End
`addFreeSpace` MegaBytes 500
)
& standardSystem (Stable "stretch") X86_64
[ "home router" ]
& Apt.installed ["linux-image-amd64"]
& serialGrub
where
serialGrub :: Property (HasInfo + DebianLike)
serialGrub = "/etc/default/grub" `File.containsLines`
[ "GRUB_CMDLINE_LINUX=\"console=ttyS0,115200n8 biosdevname=0\""
, "GRUB_SERIAL_COMMAND=\"serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1\""
, "GRUB_TERMINAL=serial"
]
-- `onChange` Grub.mkConfig
`requires` Grub.installed Grub.EFI64
`describe` "GRUB configured for PC Engines' APU2 serial console"
When running propellor it fails with:
...
mkfs.fat 4.1 (2017-01-24)
loop deleted : /dev/loop0
rsync: change_dir "/srv/router.img.chroot/boot/efi" failed: No such file or directory (2)
0 100% 0.00kB/s 0:00:00 (xfr#0, to-chk=0/0)rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1196) [sender=3.1.2]
loop deleted : /dev/loop0
laptop built disk image /srv/router.img ... failed
laptop overall ... failed
Shouldn't /boot/efi be automatically created?
When I add a
File.dirExists "/boot/efi"property, it goes further, but fails at the end:AFAICS, DiskImage.imageFinalized creates any mount points that were not rsynced over from the chroot. But, I guess that partitionsPopulated is expecting the mount point to exist in order to rsync its content over, and if nothing created /boot/efi that would explain the rsync error. I've added a check to prevent that problem.
As for the unmount problem, it's a problem with the order it traverses the mount points for unmounting. That is using "unmountBelow" with the directory where the disk image partitions are loop mounted. If that unmounts
bootfirst, it will implicitly unmountboot/efi(due to --lazy) and then will fail when it tries to explicitly unmount it. Added sorting that should fix that.Let me know how that goes, I've not tested it with your config.
OK. I tried to run propellor again, I got a new error (probably related to the recent alignment changes):
That's definitely due to the alignment changes, I knew those changes could run afoul of parted's checks, but in my tests they seemed to work.
Could you paste /srv/router.img.parttable, that should have enough infromation for me to reproduce the problem.
Reproduced it with that information.
The problem only occurs with the gpt partition table. With "mklabel msdos", the mkpart command succeeds.
So, gpt must have an additional restriction of some kind. I don't know what. The highest end position that parted will accept for that partition is 1660927487B; slightly smaller partitions are accepted. It's not a requirement that the position or size be divisible by anything in particular. Perhaps gpt needs some amount of reserved space at the end of the disk or something.
Before 4MiB alignment was added, here's what propellor did for the same PartTable, which worked.
It would be good for propellor to not need to know about all the minutia of partition tables. Seems that the way it used to call parted gave it enough wiggle room that it avoided this kind of problem.
To make parititions well aligned, propellor needs to precisely control where they begin (since parted does not have a way to configure modern alignment requirments). Perhaps propellor could precisely specify where a partition begins, but use the "MB" to leave wiggle room in where it ends so parted can pick a suitable end point.
Let's see.. this works with the gpt example:
That lets parted end the last partition right at the ideal 1660927487B. The previous two partitions end right where propellor expects. (Hopefully parted never rounds a MB value up!)
Ok, I've convinced myself to make propellor use this wacky technique of B for the start position and fractional MB for the end position! I've implemented it, hopefully my analysis above is good to make this work with all the different kinds of partition tables.
Ouch, that does not seem like it was easy to debug... Thanks for looking into this!
I now get:
:(. I'll try to reboot, I don't get how to remove/unmount this /dev/mapper/loop0p2 (I tried "dmsetup remove", "losetup -d" without success...)
So, I rebooted, but I still had the /dev/mapper/loop problem. I was able to "dmsetup remove" these, though...
I deleted router.img and router.img.parttable...
...and I'm back to the grub-install/grub-update problem, which seems to apply to grub-efi-amd64. It's weird, because it's the version I have on my laptop, and I did not notice this issue (but I installed debian on it a long time ago, so, the bug may have appeared since then).
\o/. Let's see if it boots... I just have one try, then I'll have to move for a few days...
Unfortunately it didn't... But I think it's probably a problem of choosing the right grub version. I did boot a grml64 sdcard, and I think they use hybrid bios/uefi boot. I have to investigate, let's see this in a few days
Thanks a lot for your help!
Is the working config somewhere available?
If yes, where??
Yes, I what to reproduce it.
Cheers Geert Stappers
As the config with Grub.EFI64 didn't boot, I'd like to be sure that Grub.MSDOS does not boot either. But GPT tables seem to need a BIOS Boot partition:
I don't know much about GPT boot stuff. I found mention of a BIOS boot partition for GPT here:
https://help.ubuntu.com/community/DiskSpace
So, 1 mb partition with no filesystem and a "bios_grub" flag.
Propellor's partitioning DSL will need to be extended in order to support that. Currently,
Partitionhas aFsthat is one of the common filesystems or swap. Now we need no filesystem, so either add a NoFs to Fs, or change it to useMaybe Fs. I chose the latter, because with NoFs, Partition.formatted would be a no-op, which would be kinda surprising.I've made a commit adding all the stuff you should need, but I have not tested making a BIOS boot partition with it. Should look something like this:
If you get it working, it would be good to add an example to propellor's docs.
I tried several configurations, without success. Without a serial console, that was not fun to debug... I finally tried to boot the image with qemu, and that worked! So I thought that maybe I should try to use a MSDOS partition table instead of a GPT one, just to be sure. And that finally produced a bootable image on that damn card!
I'll report a bug to PCEngines. It's unfortunate I can't test the GPT code more, but it would probably work, as it booted in qemu.
Thanks a lot Joey!