Omitting partitions during install

[tdma]

Hi all,

Is there a way to omit the creation of partitions in the intaller?
In virtual environments they don't have much use anymore, and I hear many people are not using them anymore. However, the manual partitioner (on Jessie) seems to insist to create primary/logical partitions.

More clearly, I mean installing for example root onto vda instead of vda1, /tmp onto vdb instead of vda1 or vdb1, etc.

Thanks

[Ardouos]

I am not sure, you will probably have to use mkfs on the installer and create a file system without a partition table.

Edit: Changed fdisk to mkfs.

[tdma]

Not sure, I don't think fdisk is involved right since that tool is for partitioning, which I am trying to avoid.

The idea would be to create a filesystem on the bare disk.

It's fine for me to do that manually but do you know how to switch to command line to create the filesystem when the Partitioning page in the shell installer comes up and get the installer to recognize it?

[kiyop]

The idea would be to create a filesystem on the bare disk.

It's fine for me to do that manually but do you know how to switch to command line to create the filesystem when the Partitioning page in the shell installer comes up and get the installer to recognize it?

Press CTRL+ALT+F2 or F3, and then press ENTER key, before partitioning step starts.
You can execute commands with root privilege.
Press CTRL+ALT+F1 to return to the installation step.
Pressing CTRL+ALT+F4 shows logs.

[Ardouos]

Not sure, I don't think fdisk is involved right since that tool is for partitioning, which I am trying to avoid.

The idea would be to create a filesystem on the bare disk.

It's fine for me to do that manually but do you know how to switch to command line to create the filesystem when the Partitioning page in the shell installer comes up and get the installer to recognize it?

Oops, I do not know what comes over me sometimes. I meant use mkfs to create a filesystem over the entire drive.

[tdma]

Thank you, Kiyop.
Doing the CTRL+ALT didn't work for me in the VNC console, but alternatively you can just do "GO BACK" in the partitioning screen, then you get the menu from where you can choose "EXECUTE SHELL".
Afterwards you can go back to the partitioning step.

The funny thing is that if you format the filesystems manually in the shell, and then go to the partitioning step, the partitioner allows you to work with them perfectly, and even reformat them, it no longer cares about partitions.

After that I went through a whole adventure as GRUB wouldn't install. I had to boot from a rescue disk and install grub manually to /dev/vda using the --force option (reason is that GRUB refuses to install without the --force option without MBR). Do you think this should be reported as an installer bug? It's pretty inconvenient, and might run into problems again in the future without knowing when the system tries to upgrade the bootloader and fail again because of thte same reason. (It is my understanding that ext2/3/4 filesystems allow for the bootloader to be installed into the beginning of their filesystem.)

[Head_on_a_Stick]

Try https://wiki.archlinux.org/index.php/GR ... nless_disk

I use btrfs without a partition table and GRUB embeds just fine with that.

EDIT: Also, see https://www.debian.org/releases/jessie/ ... 03.html.en

[tdma]

Ok that's interesting, I didn't know this "blocklists" thing implies hard-pointing to the core.img file inside the partition. So from the first link you posted it seems like when the core.img file is updated/moved by a simple Grub update, the whole setup breaks?

Aren't you concerned about that? Or does btrfs handle it differently?

[Head_on_a_Stick]

So from the first link you posted it seems like when the core.img file is updated/moved by a simple Grub update, the whole setup breaks?

Aren't you concerned about that? Or does btrfs handle it differently?

I think btrfs has a large (128KiB) post-MBR "gap" that allows it to handle embedded bootloaders.

From the ArchWiki page:

grub-install will give out warnings like which should give you the idea of what might go wrong with this approach:

Code: Select all

/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.
                        However, blocklists are UNRELIABLE and their use is discouraged.

Whereas in my system:

Code: Select all

empty@alpine ~ % sudo lsblk
NAME MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda    8:0    0 111.8G  0 disk /
empty@alpine ~ % sudo grub-install --recheck /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
empty@alpine ~ %

I am using Alpine Linux (edge) with GRUB compiled from the latest git pull as of about a week ago and I don't use `update-grub`/`grub-mkconfig`

[tdma]

See also the accepted answer here:
http://unix.stackexchange.com/questions ... tion-table
That post made me assume it was fine to do it on ext4 as well.

So I did this with ext4 and got the second warning about blocklists, but not the first warning aka "THIS IS A BAD IDEA". Interesting.
Passing --force made it pass, but I'm not sure towards reliability now and future updates of the grub image