On Tue, Jan 23, 2018 at 10:42:02PM -0700, Gregory Nowak wrote: > 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.
That's what I was thinking. Having an easily removable disk and a having computer around with *much* more disk capacity make it a lot less critical than it used to be exactly how partitions are set up, because it's easy to copy everything off and on again. > > > 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. Are there considerations against lvm that are specific to raspberry pi or microsd cards? I dont know of any, but there are a lot of things I don't know. > > > 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. Considering that all I've done so far is install by dd'ing from a file on my laptop, I still have all the pieces correctly assembled elsewhere. Now if the time to fuck up, if I'm going to > > > > > 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 Really? The GPU? not the CPU? Interesting. > 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 Thanks. -- hendrik _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
