On Tue, Jan 23, 2018 at 10:49:47PM -0500, Hendrik Boom wrote: > My microSD card is a lot larger than the root partition.
You should be able to resize the file system to take advantage of the full second partition. I'm not sure what the status of raspiconfig is in devuan. If that's usable, you should just be able to run that, and choose the resize option. If that isn't useable, and if <https://bugs.devuan.org//cgi/bugreport.cgi?bug=84> is indeed fixed, then you should be able to run a partitioner like cfdisk, delete the second partition, recreate it, and run resize2fs on it. You'll probably want to do this on a pc though. You could of course create more partitions on the empty sd card space, instead of resizing root. > I was thinking of multiple partitions on the microSD card, managed by LLVM. Last time I checked, the rpi3 kernel shipped with devuan didn't include lvm support built in. This was a number of months ago, so things might have changed. If they did, then this should work. If lvm still isn't built into the kernel, then you can either recompile the kernel to include lvm in the kernel itself, or use an initrd. You could again have enough on root to boot, and have the rest besides root and boot on lvm, which wouldn't require a kernel compile, or initrd. > How safe is it to do that while the root partition is mounted? I would advise against that. > Is there another next to it? I'd have to check. The boot partition is first, and root is second. > > If I do that with the microSD card plugged into the USB port of another > Linux machine, will I end up messing with the partition identity so the > boot process doesn't find it? If bug 84 is in fact fixed, and you do what I described above, you should be just fine. Of course if something does go wrong during your resize, you get to keep the pieces, I'm not responsible. > > How does the boot process find its .boot and other partitions on the > Raspberry pi anyway? From what I understand, and I could be wrong, the GPU searches for the first partition, which it expects to be fat32. It reads and processes from that partition config.txt, cmdline.txt, firmware from the firmware directory, and the kernel image, which is kernel7.img (armhf) or kernel8.img (arch64). This may not be in that exact order, but the gist should be close enough. > > Does it use grub? Or is there something peculiar to ARM processors, > like uboot? What is that anyway. No, no grub. The heavy lifting during boot is done by the GPU on the rpi as far as I know. As for uboot: <https://en.wikipedia.org/wiki/Das_U-Boot> Hope that helps some what. Greg -- web site: http://www.gregn.net gpg public key: http://www.gregn.net/pubkey.asc skype: gregn1 (authorization required, add me to your contacts list first) If we haven't been in touch before, e-mail me before adding me to your contacts. -- Free domains: http://www.eu.org/ or mail dns-mana...@eu.org _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
