TL;DR fdisk seems to default (lately) to start partitions at 2048. This feels like a bug, in the past it positioned you one sector after the last partition ended. Fixed, facepalm, sorry for the noise.
Hi,
I didn’t like that dietpi took the whole SD card for root. I’m using a 256G card and I prefer separate filesystems.
I was able to resize the root filesystem to 6G using resize2fs and then I fdisk’d the SD card and adjusted the partition size. System comes up, fsck runs fine, system mounts clean.
When I do fdisk -l on /dev/mmcblk0 there are only two partitons there, as expected, boot and root. The problem is when I tried to create partition three and start partitioning the rest of the disk, the system thinks there is only 3M left. How do I get it to see the rest of the card?
Thanks.
Disk /dev/mmcblk0: 234.1 GiB, 251406581760 bytes, 491028480 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000 <not shown>
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 532479 524288 256M c W95 FAT32 (LBA)
/dev/mmcblk0p2 532480 13115392 12582913 6G 83 Linux
I didn’t like that dietpi took the whole SD card for root
I guess that’s the same behaviour as on plain Raspberry OS. Isn’t it?
I have no idea. This is my first Pi. But, all the Linux distros and UNICES I have used in the past gave you more or less control over the installation, either taking the whole disk and having some kind of default partition setup with at least /, /home, /var, /tmp on separate filesystems or allowing you to do the partitioning totally manually.
On this kind of a distro (dietpi) where somebody downloads an image and uses a flashing tool (I tried dd before resorting to rpi-imager but it didn’t boot or I didn’t wait long enough) and expects to be able to ssh into his system, I don’t see that there is much in the way of options.
My comments are certainly not a criticism of the distro, as I have said a few times I’m really impressed with dietpi. And whether one system for the whole drive makes sense or not depends on the use of the box, how big the SD card is etc. I’m sure for many use cases the way it works is optimal.
I do think fdisk has inappropriate, dangerous behavior. There is no way the defaults it suggests on primary partitions are ok. In the hands of a tyro, fdisk is going to end badly. If I hadn’t been partitioning for so long and on so many boxes I would not have noticed it and that would have toasted my installation. I don’t remember the last time I used fdisk on Linux but this is definitely a change in behavior from the past.
I guess if any suggestion comes out of this I’d like to see a preinstaller where you either accept dietpi defaults (somebody new to Linux) or something that gives you full control in creating the installation image, before using rpi-imager etc. As far as I’m concerned, the command line tools that are already there when you first boot the new system are rather superb. There is quite a lot of control and the interface is intuitive and pretty complete. It seems to strike a very good balance between making it possible for Linux n00bs to do some important things without dumbing the system down to the point experienced Linux users pull their hair out.
This is the first Debian-based distro I have tried that didn’t make me want to throw the device off the roof. Really great stuff, and most my comments are just due to some personal preferences for *NIX after having used it a fair amount of time.
Many thanks for your feedback. There is already a feature request to define the root partition size via dietpi.txt instead of having it maximised. As SD card sizes raise and USB drives become more common for SBCs, this makes quite sense, allows for a swap partition etc. I’ll see if I can implement it soon, is quite small code as I can think of.
I use fdisk regularly and also though it would always position any new partition one sector after the last. Also the “optimal I/O” size in your case is one sector, so not sure why it would do different. But this is something to ask/report at the Debian bug tracker: https://www.debian.org/Bugs/Reporting.en.html
or upstream. I’ll see if I can verify and find a pattern, based on drive type or partition table.
Hi Michal, many thanks for the amazing work you did on this distro! I have used more than a dozen Linux in the past, I used Slackware for more than 15 years until I got tired of building everything I wanted from source, chasing down deps etc. Recently moved to Fedora and like it. This in addition to running NetBSD, OpenBSD, FreeBSD, on various platforms and also Solaris SPARC and Intel.
I tried Debian and several Debian-based distros and found them all intolerable. When it came to RPi I knew most of the work was done by Debian devs so I did some research and picked dietpi. I was not only not disappointed, but really happy and impressed with the distro. Great stuff!
From my fdisk adventures in the last few days it looks like the fdisk bug concerns only primary partitions. It wants to start at 2048 off the beginning of the partition table (or maybe from the beginning of the previous primary partition, I can’t remember). But for extended partitions after I defined the correct boundaries, additional partitions inside the extended are handled by fdisk correctly.
If I guess I would say maybe the problem was introduced since the gpt support, because most people don’t use fdisk at all and the bug in DOS partition handling was not detected or stumbled upon frequently after UEFI became almost mandatory.
Again, BIG THANK YOU to you and Joulinar and all the dietpi devs and maintainers!
John